Infrastructure as Code: Clean Modular Architecture with Terraform

// 01. The Monolithic State File Anti-Pattern

When teams first adopt Terraform, they frequently place all AWS resources into a single main.tf file: VPCs, RDS clusters, EKS control planes, and S3 buckets. As the infrastructure grows, running terraform plan takes 15 minutes, API rate limits are hit, and a human error in an IAM policy risks destroying database instances.

The solution is isolating blast radiuses into layered state files:

• Layer 0 (Foundation): VPC, Subnets, Internet Gateways, NAT Gateways, Transit Gateways.
• Layer 1 (Data Stores): RDS Aurora, DynamoDB, ElastiCache, S3 buckets with deletion protection.
• Layer 2 (Compute & Orchestration): EKS, ECS clusters, Auto Scaling Groups, IAM roles.
• Layer 3 (Application Releases): Route 53 DNS records, ALB listener rules, and certs.

// 02. State Storage & Distributed Locking

Every production repository must enforce centralized remote backends with server-side encryption and distributed locking via DynamoDB.

terraform {
  backend "s3" {
    bucket         = "corp-terraform-state-prod"
    key            = "infra/layer1-compute/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-lock-table"
  }
}

// 03. CI/CD Automated Plan Validation

Never allow manual terraform apply from engineer laptops. Implement automated GitHub Actions or Atlantis pipelines:

• Run tflint and checkov for security compliance checks on pull requests.
• Post diff plans directly as PR comments with cost estimation summaries (Infracost).
• Apply changes only after PR approval and automatic merge into the protected production branch.