Claude Prompt to Scaffold Terraform / CloudFormation

What this prompt does

This prompt produces a complete IaC template — Terraform HCL or AWS CloudFormation YAML/JSON — covering every layer a production workload actually needs: networking (VPC and subnets), compute, managed database with HA, CDN/edge, observability, and auto-scaling policy. Because you declare all six resource groups in one prompt, the model can wire them together coherently: security groups referencing the correct VPC ID, IAM roles scoped only to the services they touch, and scaling triggers tied to the exact metric you specify.

The placeholder structure forces specificity. Variables like [subnet_config], [ha_config], and [scaling_metric] require you to commit to real architectural decisions before generation starts, so the output reflects your actual requirements rather than a lowest-common-denominator example. The cost-estimation tags clause ensures every resource gets tagged with environment, owner, and budget ceiling — readable by AWS Cost Explorer or Infracost without additional configuration.

When to use it

• Spinning up a new SaaS environment (staging or production) from scratch and need every layer documented in version-controlled code from day one.
• Migrating a manually provisioned AWS/GCP/Azure setup to IaC and need a starting template that matches your existing topology.
• Onboarding a new cloud provider and want a baseline architecture to diff against your current setup.
• Preparing a cost estimate for a client or CTO before committing to infrastructure spend.
• Enforcing least-privilege IAM across a new microservices deployment where hand-writing role policies is error-prone.
• Generating a reference architecture to review with a cloud vendor or during a Well-Architected Review.

Example output

Input values: iac_tool=Terraform, app_type=Laravel API, cloud_provider=AWS, architecture_pattern=multi-AZ active-passive, subnet_config=public/private/data, compute_type=ECS Fargate, database_type=RDS Aurora MySQL, ha_config=Multi-AZ, cdn_config=CloudFront, monitoring_stack=CloudWatch + SNS, scaling_metric=CPU > 70%, budget=$400/month.

# VPC — enable both DNS flags so Fargate task DNS resolves inside the VPC
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = { Project = "laravel-api", MonthlyCap = "400" }
}

# Aurora MySQL cluster + two instances for actual Multi-AZ failover
resource "aws_rds_cluster" "db" {
  cluster_identifier = "laravel-aurora"
  engine             = "aurora-mysql"
  engine_version     = "8.0.mysql_aurora.3.04.0"
  master_username    = var.db_user
  # Credentials fetched from Secrets Manager at apply time — never hardcoded
  manage_master_user_password = true
}

resource "aws_rds_cluster_instance" "writer" {
  identifier         = "laravel-aurora-writer"
  cluster_identifier = aws_rds_cluster.db.id
  instance_class     = "db.r6g.large"
  engine             = aws_rds_cluster.db.engine
  promotion_tier     = 0
}

resource "aws_rds_cluster_instance" "reader" {
  identifier         = "laravel-aurora-reader"
  cluster_identifier = aws_rds_cluster.db.id
  instance_class     = "db.r6g.large"
  engine             = aws_rds_cluster.db.engine
  promotion_tier     = 1  # fails over to this instance
}

# ECS Auto-scaling on CPU — all three required arguments included
resource "aws_appautoscaling_policy" "ecs_cpu" {
  name               = "laravel-cpu-scaling"
  policy_type        = "TargetTrackingScaling"
  resource_id        = "service/${aws_ecs_cluster.main.name}/${aws_ecs_service.app.name}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace  = "ecs"

  target_tracking_scaling_policy_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ECSServiceAverageCPUUtilization"
    }
    target_value = 70.0
  }
}

The model also outputs an IAM role JSON with only the required actions (e.g., ecr:GetAuthorizationToken, logs:CreateLogStream) rather than wildcard policies, a CloudFront distribution config referencing the ECS ALB as its origin, and a CloudWatch alarm wired to an SNS topic for the CPU threshold.

Pro tips

• Pin provider versions. Ask the model to add a required_providers block with an exact version constraint (e.g., aws = "~> 5.0") — otherwise the template may use deprecated resource arguments that fail silently on terraform init after a provider release.
• Separate state backends upfront. If you use architecture_pattern=multi-account, explicitly add "with S3 remote state and DynamoDB locking table" to the prompt. Without this the model defaults to local state, which breaks concurrent team workflows and loses lock protection.
• Use [ha_config]=read-replica for dev, Multi-AZ for prod. The model adjusts both the number of cluster instances and their promotion_tier values based on this — it is the single biggest cost lever in the output, often the difference between a $40/month and $200/month database line item.
• Feed the output to Infracost before applying. The cost tags the prompt adds are machine-readable markers, not a substitute for a real bill estimate. Run infracost breakdown --path . against the generated .tf files — you will frequently discover that the model chose an instance class that fits the architecture but overshoots your [budget].
• Pair with a variables.tf pass. After generation, send a follow-up: "Extract all hardcoded values into a variables.tf with descriptions and validation rules." This converts a working one-off template into a reusable module with input validation, which is the difference between a script and infrastructure you can safely hand to a teammate.