I Let AI Build My AWS Infrastructure — Here’s What I Learned

Introduction

I spend a lot of time working with AWS resources, usually through Infrastructure as Code (IaC) tools like OpenTofu and Terragrunt. They do a solid job — I can define resources predictably, reuse modules and stacks, and manage everything with version control and automation.

But recently, when AWS Model Context Protocols (MCPs) were announced, I started wondering: what if I didn’t need IaC at all? What if I could describe what I wanted — in natural language — and have AWS handle the rest? Skip the syntax and he plan/apply cycle; just talk directly to the AWS API.

Sounds too good to be true, right? Well… it kind of is.

To find out, I decided to run a small experiment: spin up a simple EKS cluster using Amazon Q (AWS’s AI assistant), with the addition of a few MCPs, and Claude Sonnet 4. My goal wasn’t to let AI design a full-blown architecture, but to see if it could handle the basics — creating the cluster, managing updates, and deploying a Helm chart — all with minimal human input.

About AWS MCPs

Before diving into the experiment itself, let’s talk briefly about AWS Model Context Protocols (MCPs) — the backbone of this setup. MCPs are essentially connectors that let AI models interact directly with AWS services and APIs in a structured, secure way. Instead of just generating code, they give the AI real operational context — the ability to query, create, and manage AWS resources through well-defined endpoints.

For this project, I used the following MCPs:

• ccapi-mcp-server – provides integration with the Common Cloud API for resource management.
• aws-api-mcp-server – exposes direct access to AWS service APIs.
• cfn-mcp-server – allows AI to interact with AWS CloudFormation stacks and templates.
• eks-mcp-server – focuses on managing Amazon EKS clusters, nodes, and configurations.

Each MCP acts like a specialized plugin, giving the AI controlled visibility and operational capability within my AWS environment.

Here’s what I configured for my Amazon Q agent, to make things clear before we dive into the results:

"mcpServers": {
    "awslabs.aws-api-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.aws-api-mcp-server@latest"],
      "disabled": false,
      "autoApprove": []
    },
    "awslabs.ccapi-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.ccapi-mcp-server@latest"],
      "disabled": false,
      "autoApprove": []
    },
    "awslabs.eks-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.eks-mcp-server@latest",
        "--allow-write",
        "--allow-sensitive-data-access"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "autoApprove": [],
      "disabled": false
    },
    "awslabs.cfn-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.cfn-mcp-server@latest"
      ],
      "disabled": false,
      "autoApprove": []
    }
  }

There’s already a growing list of MCPs out there, and I probably could’ve configured a few more to make things smoother. But for this test, I wanted to keep it simple and focus on the core ones most relevant to EKS.

Concerns

I had three main concerns for this project: security, accuracy, and state management. So let’s address them one by one:

Security

Letting an AI interact with your AWS environment raises a few obvious security concerns. Amazon Q provides some guidance. Here are the main issues I kept in mind:

1. Over-permissioned roles: The AI shouldn’t have AdministratorAccess. Least-privilege IAM roles are essential.

2. Unintended resources or risky defaults: AI can accidentally create public resources, open ports, or deploy to the wrong region if prompts are vague. Using CloudFormation change sets helped me catch these before anything went live.

3. Sensitive data exposure: Prompts shouldn’t include secrets or sensitive identifiers. I made sure all secret handling stayed in AWS-native tools.

4. Traceability: When multiple people use Amazon Q, it’s easy to lose track of who changed what. Consistent tagging and logging solved most of that.

5. Keep it read-only: Let Q make recommendations and generate CloudFormation templates or scripts, but avoid giving it direct write access to your environment. A simple request like “make my EC2 instances more cost-efficient” could unintentionally terminate running workloads.

Accuracy

One of my main goals was reproducibility. I didn’t want to correct the same mistakes repeatedly or end up with slightly different clusters each time I ran the same request.

To tackle this, I implemented two things:

1. A project standards file outlining naming conventions, tags, rules, and baseline configurations for all resources. Every prompt had to follow this as its foundation.

2. A prompt template that I reused every time I wrote a new prompt.

This ensured that my prompts were detailed, structured, and consistent — leading to an infrastructure that was repeatable and predictable. The AI still made the occasional assumption, but it was far easier to debug and refine when the input format was standardized.

State management

I was also a bit worried about state management. What happens when I start a new session or multiple engineers start applying resources through AI? How do we know who changed what, and when?

To keep things under control, I followed a few best practices:

1. Every resource was created through CloudFormation first, allowing me to preview and approve changes safely.

2. All resources were tagged consistently, making ownership, purpose, and environment immediately visible.

3. I had the AI generate cache files documenting which CloudFormation stacks were created, updated, or deleted, giving me a clear summary of everything it touched.

# Deployment Monitoring Checklist
## Mandatory Steps for Every Infrastructure Deployment
### Pre-Deployment
- [ ] Template validated with `aws cloudformation validate-template`
- [ ] Deployment tracking directory created
- [ ] deployment-info.md created with initial status
### During Deployment
- [ ] **IMMEDIATE**: First status check within 60 seconds of deployment start
- [ ] Status checks every 2-3 minutes until completion
- [ ] deployment-info.md updated after each status check
- [ ] Progress reported to user with current resources being created
- [ ] Any failures immediately reported with detailed error analysis
### Post-Deployment
- [ ] Final deployment status confirmed (SUCCESS or FAILED)
- [ ] deployment-info.md updated with final status
- [ ] If successful: kubectl configuration command provided
- [ ] If failed: Root cause analysis and template fixes documented
## Enforcement Reminders
- **Never end deployment conversation without final status**
- **Always provide next steps based on final outcome**
- **User should ask "What's the deployment status?" if monitoring stops**

This workflow gave me a transparent audit trail — and it worked surprisingly well (as I accidentally tested once by closing my terminal session mid-operation).

Prompt engineering

I didn’t dive too deeply into prompt engineering for this project. Instead, I mostly relied on AWS’s existing prompt patterns from their prompt library, which gave me a good starting point without having to reinvent anything.

The final prompt included:

1. A step-by-step instruction flow (ask for cluster name → generate template → deploy → verify)

2. Strict requirements for EKS and CloudFormation (tag formats, endpoint configs, IAM roles, subnet layouts)

3. Explicit validation rules to avoid common EKS mistakes

4. Integrated project standards, so output stayed consistent

5. Deployment automation, including scripts, directory structure, and tracking files

6. Addon installation instructions (autoscaler + ALB controller) with IRSA requirements

What I have learnt

1. Amazon Q is very easy to set up and use — getting it connected to the MCPs and interacting with AWS took surprisingly little time.

2. The EKS MCP API works very well for troubleshooting — querying cluster state and diagnosing issues felt smooth and often faster than manual CLI work.

3. CloudFormation templating still has quirks, even with the CloudFormation MCP — the AI can generate templates quickly, but they almost always need small fixes.

4. Creating a fully reproducible prompt is harder than expected — iterative chatting and fine-tuning produced more reliable results than a single static prompt.

5. AI is better at making suggestions than acting autonomously — its output still needs review and validation, especially for production-grade infrastructure.

Summary

I was genuinely surprised several times throughout this project — sometimes by how impressively the AI handled certain tasks, and other times by how wildly it missed the mark.

In the end, I’d say this: AI isn’t a magic tool capable of managing complex infrastructure on its own (at least not yet), but it’s already a helpful assistant. Still, and honestly, it’s a bit better at writing articles than building production-ready AWS environments.

Are you interested in this topic? Do you have any questions about the article? Book a free consultation and let’s see how the Code Factory team can help you! You can find a list of our services here!