Cloud infrastructure decisions are rarely just about getting an application running. Developers also need to consider cost, security, troubleshooting, and the operational impact of changing resources.
As I continue learning and building with AWS, I wanted to explore how generative AI could help make these decisions easier to understand.
That idea led me to build CloudPilot, an AWS Cost & Deployment Copilot developed as part of the Build an Agent Weekend Challenge.
The goal is to help users explore deployment options, understand estimated costs, troubleshoot common problems, and review potential risks before making infrastructure decisions.
🔗 Live demo: http://cloudpilot-app-528582359305.s3-website-us-east-1.amazonaws.com
💻 GitHub repository: https://github.com/omayrq/Cloudpilot
🎯 The Problem
Imagine you're building a web application on AWS.
You need to decide which services to use, understand how configuration choices affect cost, and identify possible risks before making changes.
Even a technically successful deployment can have problems:
- Resources may be more expensive than necessary.
- Networking and data transfer can introduce unexpected costs.
- Configuration changes may affect availability.
- Troubleshooting can require investigating multiple services.
- An AI agent with excessive permissions could make risky changes.
I wanted to build a tool that brings these considerations into one conversational experience.
CloudPilot is designed as a copilot for AWS learners, developers, and cloud practitioners. It provides guidance and estimates rather than treating every recommendation as an instruction to execute.
🏗️ Architecture and AWS Services
I chose a serverless architecture to keep the frontend and backend separate and integrate AI capabilities through Amazon Bedrock.
The primary components are:
- Amazon S3: Hosts the static frontend.
- Amazon API Gateway: Exposes the backend HTTP API.
- AWS Lambda: Runs the Python 3.11 backend.
- Amazon Bedrock: Provides access to Amazon Nova Lite for supported AI-powered responses.
- Python application modules: Organize workflow routing, tools, response schemas, and safety-related checks.
Request flow
The high-level request flow is:
- A user interacts with the frontend hosted on Amazon S3.
- The frontend sends a request to the API endpoint.
- Amazon API Gateway forwards the request to AWS Lambda.
- Lambda processes the request through the application workflow.
- The application uses deterministic logic, supported tools, or Amazon Bedrock as appropriate.
- A structured response is returned to the frontend.
Architecture diagram: Add your CloudPilot architecture image here.
This separation makes the application easier to understand and provides a foundation for adding more capabilities over time.
🧠 Why Amazon Bedrock?
I wanted to integrate generative AI without managing the underlying foundation model infrastructure myself.
Amazon Bedrock provides access to supported foundation models through managed APIs. In CloudPilot, Amazon Nova Lite is used for supported natural-language and reasoning tasks.
However, I didn't want every application decision to depend entirely on model output.
Where appropriate, deterministic application logic handles calculations and structured checks, while the model supports tasks that benefit from natural-language understanding.
This is an important distinction when building agents for technical workflows: AI-generated recommendations should be validated rather than automatically trusted.
💰 Cost Awareness Before Deployment
One of CloudPilot's main goals is helping users understand cost considerations before they deploy or modify resources.
AWS costs can depend on several factors, including:
- Resource configuration and runtime.
- Number of requests and Lambda execution duration.
- Data transfer and networking.
- Storage and logging.
- Foundation model usage.
CloudPilot provides illustrative cost calculations to help users explore these factors.
These calculations are estimates, not live AWS quotes. Actual charges depend on current pricing, Region, configuration, usage patterns, and services included in the workload.
For real deployments, estimates should be checked against current AWS pricing and appropriate cost-management tools.
🔐 Why Human Review Matters
I believe an AI copilot should help users make better decisions without automatically receiving unrestricted access to their infrastructure.
For example, a request to reduce costs should not automatically authorize an agent to stop resources or modify a production environment.
CloudPilot includes a change-review workflow designed to help users consider the potential impact of proposed changes and review recommended next steps.
Reviewing a proposal is not the same as executing an infrastructure change. The current prototype should not be understood as having applied changes to AWS unless a specific operation has actually been implemented and verified.
If I extend the project to execute AWS operations, I would prioritize:
- Least-privilege IAM permissions.
- Explicit authorization for sensitive operations.
- Input and action validation.
- Logging and monitoring.
- Clear separation between recommendations and execution.
- Testing in a controlled environment.
Security should be part of the architecture from the beginning, not something added after an agent gains access to infrastructure.
🧪 Testing and Validation
I checked the application's main interaction workflows and the deployed backend's health endpoint.
The health endpoint provides a basic indication that the backend is responding. However, a successful health check does not prove that every feature works correctly or that the system is ready for production.
Additional production-focused testing should include:
- Input validation and malformed requests.
- Error handling and response-schema validation.
- API authentication and rate limiting.
- Integration and load testing.
- Security review of permissions and exposed endpoints.
- Monitoring of actual AWS costs.
Screenshot: Add a screenshot of a successful interaction with the deployed application here.
🛠️ Lessons Learned
1. Not every task needs an LLM
AI is useful for natural-language understanding and explanations, but calculations and predictable checks often belong in deterministic code.
Combining these approaches can make the application easier to validate.
2. Estimates need clear assumptions
A cost number without context can be misleading. Users need to understand what is included, what is excluded, and why actual charges may differ.
3. A working prototype is only the beginning
Connecting a frontend, API, backend, and model is one milestone. Authentication, permissions, observability, error handling, and operational testing are equally important before production use.
4. AI agents need boundaries
An agent should not automatically receive every permission it might theoretically need. Its access should match its actual responsibilities, with explicit approval for sensitive actions.
🚀 What's Next?
I see several opportunities to improve CloudPilot:
- More detailed cost scenarios and documented assumptions.
- Expanded architecture guidance for common AWS workloads.
- Additional automated tests for the main workflows.
- Stronger production security, access controls, and monitoring.
- Carefully controlled integrations for validating recommendations against real AWS environments.
These improvements would help evolve CloudPilot from a learning-focused prototype toward a more robust assistant for cloud planning and operations.
Try CloudPilot
You can explore the deployed prototype and inspect the source code here:
- 🌐 Live application: http://cloudpilot-app-528582359305.s3-website-us-east-1.amazonaws.com
- 💻 GitHub: https://github.com/omayrq/Cloudpilot
- 🔎 Backend health check: https://l4jxfpbef1.execute-api.us-east-1.amazonaws.com/prod/health
Building CloudPilot has been a useful opportunity to explore how AWS managed services and generative AI can work together to make cloud decisions more understandable.
My biggest takeaway is that a useful AI agent should do more than generate an answer. It should help users understand their options, recognize trade-offs, and remain in control of important decisions.
What would you prioritize in an AWS copilot: cost optimization, deployment planning, troubleshooting, or safely reviewing infrastructure changes?
I'd love to hear your thoughts in the comments.
Top comments (0)