Terraform on AWS — Reusable IaC Modules + CLI Workflow

Problem

Most AWS projects start with click-ops — VPCs created in the console, security groups patched ad-hoc, no drift detection. That works for a demo and breaks the moment a second engineer needs to touch the environment.

Solution

I built a Terraform codebase that treats infrastructure as software: composable modules for VPC, subnets, ALB, ASG and IAM; remote state on S3 with DynamoDB locking so two engineers can't stomp on each other; and a documented CLI workflow (init → plan → apply) wired into a CI pipeline that runs `terraform plan` on every pull request and posts the diff back as a PR comment.

Architecture

• ▸S3 bucket holds tfstate, versioned + encrypted (SSE-KMS).
• ▸DynamoDB table provides state-locking — no concurrent applies.
• ▸Modules: `network/` (VPC + subnets), `compute/` (ASG + ALB), `iam/` (least-privilege roles).
• ▸Workspaces separate dev / staging / prod with the same code.
• ▸GitHub Actions runs `terraform fmt`, `tflint`, and `plan` on PRs; `apply` only on merge to main with manual approval.

Outcomes

• ✓Reproducible environments — full stack rebuilt from scratch in under 15 minutes.
• ✓Zero drift incidents after CI plan-on-PR caught two manual console changes before they hit prod.
• ✓Reusable modules cut new-environment setup time from days to hours.

What I'd do differently

The S3 + DynamoDB backend pattern is non-negotiable for any team work. And `tfstate` is the single most sensitive file in the repo — guard it like a secret, never commit it.