Terraform Architecture for a Production AWS SaaS: Modular, Multi-Region & Secure
The Enterprise Multi-Account IaC Blueprint
An enterprise SaaS architecture cannot survive in a single AWS account. We decouple infrastructure using AWS Organizations into isolated accounts:
- Management / Root Account: Billing, Organization SCPs, AWS IAM Identity Center (SSO). Zero workloads.
- Security & Audit Account: Centralized CloudTrail, GuardDuty, AWS Config, and KMS root keys.
- Shared Services Account: CI/CD runners, container registry (ECR), DNS root zones, artifact repositories.
- Development / Staging / Production Accounts: Dedicated VPCs, isolated IAM roles, and completely independent Terraform remote state backends.
Zero-Blast-Radius S3 & DynamoDB Backend
Every environment and service layer maintains its own state file. Never share a single terraform.tfstate across environments.
# backend.tf - Secured with KMS, versioning, and DynamoDB state locking
terraform {
backend "s3" {
bucket = "acme-corp-prod-tfstate-347166961665"
key = "compute/eks-cluster/terraform.tfstate"
region = "us-east-1"
dynamodb_table = "acme-corp-prod-tflocks"
encrypt = true
kms_key_id = "arn:aws:kms:us-east-1:347166961665:key/tfstate-key"
}
}
Mandatory S3 Bucket Policy: Deny all non-TLS traffic (aws:SecureTransport: false) and enforce server-side encryption with AWS KMS.
Directory Hierarchy: Decoupling Lifecycles
Infrastructure components have vastly different lifecycles. A VPC changes twice a year; an EKS nodegroup or Helm release changes daily. Grouping them together is dangerous.
environments/
├── live/
│ ├── prod/
│ │ ├── 00-bootstrap/ # IAM roles, KMS keys, baseline policies
│ │ ├── 10-network/ # VPC, Transit Gateway, NAT Gateways
│ │ ├── 20-database/ # Aurora PostgreSQL, ElastiCache Redis
│ │ ├── 30-compute/ # EKS cluster, Karpenter provisioners
│ │ └── 40-addons/ # ArgoCD, ExternalDNS, Cert-Manager
│ └── staging/
└── modules/
├── vpc/
├── aurora-postgresql/
└── eks-cluster/Automated Drift Detection & CI/CD Guardrails
Every pull request triggers an automated validation pipeline before any engineer can apply changes:
- Static Analysis & Security: Run
tflint,checkov, andtfsecto catch open security groups (0.0.0.0/0on port 22) and unencrypted EBS volumes before review. - Cost Estimation: Run
infracoston PRs to provide exact monthly dollar deltas for infrastructure additions. - Speculative Plan: Run
terraform planvia GitHub Actions with AWS OIDC, posting structured diff outputs directly into the GitHub pull request comment.
terraform plan -detailed-exitcode -no-color || exit_code=$?
if [ $exit_code -eq 2 ]; then
echo "CRITICAL: Infrastructure drift detected in production!"
# Dispatch alert to SRE webhook
fiHave questions about this architecture or scaling your infrastructure?
Whether you're planning a complex cloud migration, optimizing Kubernetes reliability, or designing autonomous AI workflows, I'm always open to discussing architecture and technical challenges with engineering teams.
Connect with Naveed on LinkedIn →Frequently Asked Questions
Why should Terraform state be split across multiple accounts and directories?
Splitting Terraform state across multiple AWS accounts and directory layers minimizes the blast radius of any individual apply operation. Monolithic state files result in slow plan times (15+ minutes), dangerous concurrency locks, and catastrophic failure modes where an error in a shared resource damages unrelated production systems.
What is the best way to handle secrets in Terraform without storing them in plaintext state?
Never pass secrets directly through Terraform variables or resources if avoidable, because Terraform state files store sensitive values in unencrypted JSON. Instead, manage secrets via AWS Secrets Manager or HashiCorp Vault, inject secret ARNs into application manifests, and use tools like External Secrets Operator (ESO) inside Kubernetes to retrieve secrets at runtime.
How do you detect and prevent Terraform infrastructure drift in production?
Drift is detected by running automated scheduled CI/CD jobs (e.g. via GitHub Actions or Spacelift) executing terraform plan -detailed-exitcode daily. If exit code 2 is returned (indicating drift), an alert is dispatched to Slack/PagerDuty. Prevention is achieved by strictly revoking AWS console write access in production accounts.
