{"slug": "terraform-with-ai-build-aws-infra-cursor-mcp", "title": "Terraform with AI: Build AWS Infra (Cursor + MCP)", "summary": "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.", "body_md": "Writing Terraform for anything beyond a small setup quickly becomes tedious.\nOnce 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.\nMany teams are now experimenting with Terraform with AI to speed this up.\nIn practice, that only works partially — unless the AI has proper context.\nA typical workflow looks like this:\nRead Terraform docs\nWrite modules and resources manually\nRun terraform plan\nFix errors\nRepeat\nFor small setups, this is manageable.\nFor production infrastructure, it becomes repetitive and slow. Most engineers end up switching between Terraform registry docs, AWS docs, and their codebase constantly.\nThe obvious idea is to use AI to generate Terraform.\nIn most cases, it starts like this:\n“Generate Terraform for a VPC with public and private subnets”\nYou do get output. But:\nIt may use outdated arguments\nIt ignores your module structure\nDependencies are incomplete\nIt often fails during terraform apply\n👉 The core issue: AI does not understand your infrastructure context\nTo solve this, we built an internal tool using:\nVector database\nRAG (Retrieval-Augmented Generation)\nThe idea was to fetch Terraform documentation and index it in a vector database and provide it to an agent\nIt helped slightly — but failed in practice:\nIteration was difficult - terraform plan and apply loop - fix errors\nContext size limitations\nNo awareness of project structure\nCould not refine outputs\nIt generated code, but only for simple infrastructure. For complex ones it used to fail after a few iterations.\nWe 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.\nThe behavior changed once we introduced Terraform MCP Server and used it with Cursor.\nInstead of generating code blindly, the system now had access to:\nTerraform module documentation\nInput/output structures\nResource relationships\nThe difference was noticeable.\nThe output was not perfect — but much closer to something usable.\nAt a high level, MCP acts as a bridge between the editor (Cursor) and Terraform context.\nInstead of guessing, the AI can:\nLook up module definitions\nUnderstand required inputs\nFollow dependencies across resources\nThis is the key difference from standard AI usage.\nThe improvement with MCP is not just better prompting — it’s access to structured Terraform knowledge.\nThe MCP server exposes tools that allow the AI to query real Terraform data:\nFetches full documentation for resources, data sources, and functions\nFinds Terraform modules from the registry with usage examples\nRetrieves inputs, outputs, and configuration patterns\nHelps identify best practices and security policies\n👉 In simple terms:\nInstead of guessing, the AI can look things up like an engineer would.\nIn practice, most teams try AI first, then realize that without context, results are unreliable. MCP fixes that gap.\nLet’s take a realistic setup:\nVPC with public and private subnets\nNAT Gateway and Internet Gateway\nApplication Load Balancer\nAuto Scaling group (EC2)\nCloudFront distribution\nCloudflare DNS\nJump box for access\nThis is a typical production-style setup.\nWriting this manually takes time — especially when wiring dependencies correctly.\nInstead of writing everything manually, we broke the problem into smaller steps and guided the AI.\nInstead of vague prompts, we used a structured, step-by-step approach to guide the AI.\nStart code generation. Do it step by step. Move to next step only after the current step is complete.\nStep: Create VPC and Network Infrastructure - use vpc module\n- Create VPC with appropriate CIDR block\n- Create public and private subnets across 2 AZs\n- Set up Internet Gateway\n- Configure NAT Gateways in public subnets\n- Configure route tables for public/private subnets\nStep: Create Security Groups\n- ALB security group (allow HTTP/HTTPS inbound)\n- EC2 security group\n- allow traffic from ALB\n- allow ssh from the vpc\n- Allow all outbound traffic\nStep: Create Auto Scaling Group - use autoscaling module\n- Create launch template for EC2 instances\n- Use ubuntu ami for the instances\n- Configure ASG across private subnets\n- Use keypair named \"vikas-aws\"\n- Add a user data script to install nginx and create a simple html page\nStep: Create a jumpbox\n- Create a jumpbox in the public subnet\n- Ensure it has a public IP\n- Allow SSH from internet\nStep: Create Application Load Balancer - use alb module\n- Create ALB in public subnets\n- Configure HTTP listener\n- Attach to autoscaling group\nStep: CloudFront Distribution\n- Configure CloudFront with ALB as origin\n- Set caching TTL to 0\nStep: DNS Configuration\n- DNS handled via Cloudflare (no route53)\nIn practice, breaking the problem into steps like this improves output quality significantly compared to single prompts.\nA simplified example:\nmodule \"vpc\" {\nsource = \"terraform-aws-modules/vpc/aws\"\nversion = \"5.0.0\"\nname = \"demo-vpc\"\ncidr = \"10.0.0.0/16\"\nazs = [\"us-east-1a\", \"us-east-1b\"]\npublic_subnets = [\"10.0.1.0/24\", \"10.0.2.0/24\"]\nprivate_subnets = [\"10.0.3.0/24\", \"10.0.4.0/24\"]\nenable_nat_gateway = true\nsingle_nat_gateway = true\n}\nThis wasn’t perfect out of the box, but:\nStructure was correct\nInputs were mostly valid\nDependencies were aligned\nThat already saves a significant amount of time.\nFrom real usage:\n2–4 hours to assemble infra\nMultiple documentation lookups\nSeveral failed applies\nInitial setup generated in minutes\nFewer structural errors\nFaster iteration\nIn most teams, the biggest gain is reduced context switching.\nThis approach still requires discipline:\nAlways run terraform plan\nReview changes carefully\nDo not trust generated code blindly\nIAM policies and security configurations must always be reviewed manually.\nIn most teams, this approach works well when:\nYou are building new infrastructure\nYou need to scaffold modules quickly\nYou want to reduce repetitive work\nIt is less effective when used blindly or without validation.\nAvoid relying on it when:\nInfrastructure requires strict compliance\nYou don’t understand the generated code\nYou need deterministic, audited configurations\nThis is not a replacement for Terraform expertise.\nThis approach integrates naturally with:\nGit-based workflows\nCI/CD pipelines\nInfrastructure reviews\nThe deployment process does not change — only the way code is written.\nTerraform with AI refers to using AI tools to generate and manage infrastructure code more efficiently.\nIt provides AI tools with Terraform context, including modules and documentation.\nYes, but only after proper validation and review.\nTerraform itself hasn’t changed.\nWhat’s changing is how engineers interact with it.\nUsing Terraform with AI + MCP Server reduces friction in writing infrastructure — especially for repetitive setups.\nIt doesn’t replace engineering judgment, but it does make the workflow more efficient.\nhttps://www.kubeblogs.com/how-civo-kubernetes-routes-pod-traffic-single-egress-ip-explained/\nhttps://www.kubeblogs.com/gp3-vs-gp2-ebs-volume-aws/", "url": "https://wpnews.pro/news/terraform-with-ai-build-aws-infra-cursor-mcp", "canonical_source": "https://dev.to/sanjay_yadav_/terraform-with-ai-build-aws-infra-cursor-mcp-4hga", "published_at": "2026-05-23 05:21:24+00:00", "updated_at": "2026-05-23 05:34:23.793175+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "cloud-computing"], "entities": ["Terraform", "AWS", "Cursor", "MCP"], "alternates": {"html": "https://wpnews.pro/news/terraform-with-ai-build-aws-infra-cursor-mcp", "markdown": "https://wpnews.pro/news/terraform-with-ai-build-aws-infra-cursor-mcp.md", "text": "https://wpnews.pro/news/terraform-with-ai-build-aws-infra-cursor-mcp.txt", "jsonld": "https://wpnews.pro/news/terraform-with-ai-build-aws-infra-cursor-mcp.jsonld"}}