AI Prompts for AWS Configuration

Before: The Weak Prompt

Have you ever deployed an AWS resource with AI help, only to get an email from your finance team three weeks later asking why the bill doubled?

It happens constantly. Not because the AI wrote wrong AWS configuration — but because AI-generated AWS configs optimize for "it works" rather than "it works and doesn't cost you money."

Here's the prompt pattern that causes unexpected AWS bills:

Write a Terraform configuration to deploy a Node.js API on AWS.

The AI produces a reasonable-looking configuration: an EC2 instance, a security group, maybe an Application Load Balancer. The Node.js API runs. Everyone is happy.

Until the bill arrives. The EC2 instance is an

m5.xlarge

The configuration was functional. It was not production-appropriate.

Why It Fails

"Write a Terraform config to deploy X on AWS" fails for three reasons:

No cost constraints. AWS has dozens of instance types and deployment patterns at wildly different price points. Without guidance, AI picks something that works without regard to cost.

No security requirements. Security groups default to permissive configurations in AI output unless you specify least-privilege explicitly.

No context for the right deployment pattern. A high-traffic API belongs on ECS Fargate with auto-scaling. A low-traffic internal tool might be a Lambda function. A static site shouldn't be on EC2 at all. Without context, the AI picks a pattern it's seen frequently, not the pattern that fits your use case.

⚠️ Common mistake: Not specifying the deployment pattern before writing AWS config. "Deploy my Node.js API" could mean EC2, ECS, EKS, Lambda, Elastic Beanstalk, App Runner, or Lightsail — each with different cost, operational, and scaling characteristics.

After: The Improved Prompt

You are an AWS solutions architect. Design a Terraform configuration for the following workload.

Workload: Node.js REST API
Traffic: ~500 requests/day average, spikes to ~2,000 requests/day
Availability requirement: 99.9% uptime
Team: 3 developers, no dedicated Ops — minimize operational overhead

Deployment pattern recommendation: based on this traffic and team size, recommend the appropriate AWS deployment pattern (Lambda, ECS Fargate, EC2 with ASG, App Runner) and explain why. Then implement it.

Requirements:
1. Cost optimization: right-size for the traffic described — flag if you're choosing a configuration that would cost more than $50/month
2. Security: least-privilege security groups (only necessary ports open, no 0.0.0.0/0 on SSH), IAM roles with minimal permissions, no public access to backend resources
3. Scalability: auto-scaling configuration appropriate for the traffic pattern
4. Observability: CloudWatch alarms for CPU, memory, error rate, and latency — with SNS notification on alarm
5. Tagging: all resources tagged with: Environment, Service, Owner, CostCenter

Terraform requirements:
- Use variables for environment-specific values (region, instance size, environment name)
- Use Terraform state in S3 with DynamoDB locking
- Output the service URL and any other relevant endpoints

After the Terraform:
- Estimate the monthly cost at average and peak traffic
- List the AWS services used and their purposes
- Flag any single points of failure

What this does: Forces the AI to recommend the appropriate architecture before implementing it, adds explicit cost awareness, enforces security best practices, and asks for a cost estimate — so you know what you're deploying before it runs.

⚡ Pro tip: Add "compare the cost of this architecture versus using a serverless alternative (Lambda + API Gateway) for the same workload" to any EC2/ECS AI prompt. The cost comparison is often surprising — and the right answer for low-to-medium traffic applications is frequently serverless.

Breaking Down Each Element

"Recommend the deployment pattern first" — this is the highest-value instruction. Before writing any Terraform, the AI reasons about whether your workload fits Lambda, ECS, EC2, or something else. Getting this decision right saves more money than any other optimization.

"Flag if cost exceeds $50/month" — explicit cost thresholds make the AI's cost consciousness concrete. Without this, AI optimizes for correctness and picks appropriately-sized resources.

"0.0.0.0/0 on SSH" — this exact pattern is in the prompt because it's the most common security mistake in AI-generated AWS configs and a well-known attack vector. Naming it explicitly prevents it.

CloudWatch alarms — production AWS infrastructure without alarms is flying blind. Specifying CloudWatch + SNS in the prompt ensures observability is built in from day one.

Tagging requirements — AWS tags are how you identify which resources belong to which project when the bill arrives. Missing tags mean mystery costs. Specifying tags in the prompt ensures every resource has them.

⚡ Pro tip: For multi-environment setups, add: "Design the Terraform to support multiple environments (dev, staging, prod) using Terraform workspaces or separate state files. Show how environment-specific variables are managed." Environment-specific configuration is one of the most common Terraform pain points — prompting for it upfront produces a pattern you can actually maintain.

Variations for Different Contexts

For S3 static site hosting:

Write Terraform for a static website hosted on S3 with CloudFront. Requirements: S3 bucket with website hosting disabled (CloudFront serves from S3 origin, not S3 website endpoint), CloudFront distribution with HTTPS redirect, custom domain with ACM certificate, CloudFront cache invalidation on deploy, S3 bucket policy that only allows CloudFront access (not public S3 access). Estimate monthly cost at 100 GB bandwidth.

For RDS database:

Write Terraform for an RDS PostgreSQL instance. Requirements: Multi-AZ for production (single-AZ for dev — make this a variable), encrypted storage, automated backups with 7-day retention, security group allowing access only from application subnet (not 0.0.0.0/0), secrets stored in AWS Secrets Manager (not hardcoded). Flag: what happens to data if this instance is deleted (deletion protection)?

Save and Reuse This

The improved prompt's key elements — deployment pattern recommendation, cost estimate, security requirements, and tagging — are the checklist for every AWS configuration. Save your environment-specific AWS prompt templates in PromptABCD so your ai prompts aws configuration starting point includes your team's cost and security standards every time.

AWS Cost Optimization Prompts

AWS bills have a way of growing invisibly. Services that were the right choice at launch can become expensive as scale changes. A targeted cost review prompt:

Review this AWS architecture for cost optimization opportunities. Current monthly bill: ~$[N]. Services in use: [list]. Traffic pattern: [describe].

Check:
1. Over-provisioned instances: are instance sizes appropriate for actual CPU/memory utilization?
2. Always-on services that could be serverless: are there EC2 instances or ECS services with low utilization that would be cheaper as Lambda?
3. Data transfer costs: are there cross-AZ or cross-region data transfers that could be reduced?
4. Storage lifecycle policies: are S3 buckets moving old data to cheaper storage classes?
5. Reserved vs On-Demand: for steady-state workloads, are Reserved Instances or Savings Plans in place?

For each finding, estimate the monthly savings.

What this does: Cost optimization needs to be specific to your actual architecture — generic cost tips rarely apply. This prompt reviews your actual services and estimates concrete savings.

⚡ Pro tip: Add "flag any resources that are running but not tagged as belonging to an active project" to any AWS cost review prompt. Orphaned resources — load balancers, RDS instances, Elastic IPs from projects that ended — are a common source of unnecessary spend and are easy to miss without systematic tagging and review.

Infrastructure Drift Detection

AWS configurations drift from their Terraform definitions when someone makes a manual change in the console. A prompt for catching drift:

Write a CI/CD step that: runs `terraform plan` against the current AWS state, fails if any differences are found (indicating manual changes have been made outside Terraform), and posts the drift details to a Slack channel for review. This should run nightly, not on every deploy.

Terraform backend: S3 + DynamoDB
CI platform: GitHub Actions

What this does: Infrastructure drift is the operational equivalent of untested code — it means your documented state doesn't match reality. Nightly drift detection catches manual changes before they cause confusion during the next Terraform apply.

Multi-Account AWS Strategy

For organizations managing multiple AWS accounts (dev, staging, production, security), AI can help design the account structure:

Design a multi-account AWS strategy for a SaaS company with these requirements: strict production isolation, shared development tooling, centralized security logging, and cross-account deployment pipelines. Include: account structure (which accounts for which purpose), cross-account IAM role assumptions, shared services VPC design, and AWS Organizations structure. Reference AWS Well-Architected Framework recommendations where appropriate.

What this does: Multi-account strategy is one of those AWS architecture topics where the right answer is highly context-dependent — getting AI to reason through it with your specific requirements produces a concrete recommendation you can evaluate, rather than generic "use multiple accounts" advice.

⚡ Pro tip: For AWS Lambda functions, ask specifically for cold start optimization: 'Review this Lambda function configuration and handler code for cold start optimization. Check: package size (smaller = faster cold start), initialization code outside the handler (runs once per cold start, not per invocation), memory allocation (higher memory = more CPU = faster cold start), and whether Provisioned Concurrency is worth the cost for this function's traffic pattern.' Lambda cold start is a common performance complaint that has specific, measurable fixes.

The ai prompts aws configuration library you build — covering deployment patterns, cost optimization, security hardening, and drift detection — becomes a reference architecture for every AWS decision your team makes.