Terraform with AI: Build AWS Infra (Cursor + MCP)

Based on the article, the author describes how using AI to generate Terraform code for AWS infrastructure often fails because the AI lacks context about project structure, dependencies, and documentation. To solve this, they built an internal tool using a vector database and RAG, but found it still struggled with complex setups until they integrated a Terraform MCP (Model Context Protocol) server with Cursor. The MCP server acts as a bridge, giving the AI access to structured Terraform knowledge—such as module definitions, input/output structures, and resource relationships—enabling it to generate more reliable and usable infrastructure code.

Writing Terraform for anything beyond a small setup quickly becomes tedious. Once you start dealing with multiple modules, cross-resource dependencies, and AWS-specific quirks, the workflow slows down. Most of the time isn’t spent writing code — it’s spent checking documentation, fixing edge cases, and rerunning terraform apply. Many teams are now experimenting with Terraform with AI to speed this up. In practice, that only works partially — unless the AI has proper context. A typical workflow looks like this: Read Terraform docs Write modules and resources manually Run terraform plan Fix errors Repeat For small setups, this is manageable. For production infrastructure, it becomes repetitive and slow. Most engineers end up switching between Terraform registry docs, AWS docs, and their codebase constantly. The obvious idea is to use AI to generate Terraform. In most cases, it starts like this: “Generate Terraform for a VPC with public and private subnets” You do get output. But: It may use outdated arguments It ignores your module structure Dependencies are incomplete It often fails during terraform apply 👉 The core issue: AI does not understand your infrastructure context To solve this, we built an internal tool using: Vector database RAG Retrieval-Augmented Generation The idea was to fetch Terraform documentation and index it in a vector database and provide it to an agent It helped slightly — but failed in practice: Iteration was difficult - terraform plan and apply loop - fix errors Context size limitations No awareness of project structure Could not refine outputs It generated code, but only for simple infrastructure. For complex ones it used to fail after a few iterations. We didn't try to optimise it further because while we were in middle of it - cursor agents became extremely powerful and they pretty much solved this iteration problem. The behavior changed once we introduced Terraform MCP Server and used it with Cursor. Instead of generating code blindly, the system now had access to: Terraform module documentation Input/output structures Resource relationships The difference was noticeable. The output was not perfect — but much closer to something usable. At a high level, MCP acts as a bridge between the editor Cursor and Terraform context. Instead of guessing, the AI can: Look up module definitions Understand required inputs Follow dependencies across resources This is the key difference from standard AI usage. The improvement with MCP is not just better prompting — it’s access to structured Terraform knowledge. The MCP server exposes tools that allow the AI to query real Terraform data: Fetches full documentation for resources, data sources, and functions Finds Terraform modules from the registry with usage examples Retrieves inputs, outputs, and configuration patterns Helps identify best practices and security policies 👉 In simple terms: Instead of guessing, the AI can look things up like an engineer would. In practice, most teams try AI first, then realize that without context, results are unreliable. MCP fixes that gap. Let’s take a realistic setup: VPC with public and private subnets NAT Gateway and Internet Gateway Application Load Balancer Auto Scaling group EC2 CloudFront distribution Cloudflare DNS Jump box for access This is a typical production-style setup. Writing this manually takes time — especially when wiring dependencies correctly. Instead of writing everything manually, we broke the problem into smaller steps and guided the AI. Instead of vague prompts, we used a structured, step-by-step approach to guide the AI. Start code generation. Do it step by step. Move to next step only after the current step is complete. Step: Create VPC and Network Infrastructure - use vpc module - Create VPC with appropriate CIDR block - Create public and private subnets across 2 AZs - Set up Internet Gateway - Configure NAT Gateways in public subnets - Configure route tables for public/private subnets Step: Create Security Groups - ALB security group allow HTTP/HTTPS inbound - EC2 security group - allow traffic from ALB - allow ssh from the vpc - Allow all outbound traffic Step: Create Auto Scaling Group - use autoscaling module - Create launch template for EC2 instances - Use ubuntu ami for the instances - Configure ASG across private subnets - Use keypair named "vikas-aws" - Add a user data script to install nginx and create a simple html page Step: Create a jumpbox - Create a jumpbox in the public subnet - Ensure it has a public IP - Allow SSH from internet Step: Create Application Load Balancer - use alb module - Create ALB in public subnets - Configure HTTP listener - Attach to autoscaling group Step: CloudFront Distribution - Configure CloudFront with ALB as origin - Set caching TTL to 0 Step: DNS Configuration - DNS handled via Cloudflare no route53 In practice, breaking the problem into steps like this improves output quality significantly compared to single prompts. A simplified example: module "vpc" { source = "terraform-aws-modules/vpc/aws" version = "5.0.0" name = "demo-vpc" cidr = "10.0.0.0/16" azs = "us-east-1a", "us-east-1b" public subnets = "10.0.1.0/24", "10.0.2.0/24" private subnets = "10.0.3.0/24", "10.0.4.0/24" enable nat gateway = true single nat gateway = true } This wasn’t perfect out of the box, but: Structure was correct Inputs were mostly valid Dependencies were aligned That already saves a significant amount of time. From real usage: 2–4 hours to assemble infra Multiple documentation lookups Several failed applies Initial setup generated in minutes Fewer structural errors Faster iteration In most teams, the biggest gain is reduced context switching. This approach still requires discipline: Always run terraform plan Review changes carefully Do not trust generated code blindly IAM policies and security configurations must always be reviewed manually. In most teams, this approach works well when: You are building new infrastructure You need to scaffold modules quickly You want to reduce repetitive work It is less effective when used blindly or without validation. Avoid relying on it when: Infrastructure requires strict compliance You don’t understand the generated code You need deterministic, audited configurations This is not a replacement for Terraform expertise. This approach integrates naturally with: Git-based workflows CI/CD pipelines Infrastructure reviews The deployment process does not change — only the way code is written. Terraform with AI refers to using AI tools to generate and manage infrastructure code more efficiently. It provides AI tools with Terraform context, including modules and documentation. Yes, but only after proper validation and review. Terraform itself hasn’t changed. What’s changing is how engineers interact with it. Using Terraform with AI + MCP Server reduces friction in writing infrastructure — especially for repetitive setups. It doesn’t replace engineering judgment, but it does make the workflow more efficient. https://www.kubeblogs.com/how-civo-kubernetes-routes-pod-traffic-single-egress-ip-explained/ https://www.kubeblogs.com/gp3-vs-gp2-ebs-volume-aws/