System: Declarative Cloud with Terraform
Category: DevOps · Infrastructure as Code
Reading Time: 6 min read
What the Terraform recording shows for Expense Tracker
The console VPC and the Terraform files visible in the repository recording.
Covered: Terraform · VPC · EC2 · RDS · S3 · ap-south-1
01. WHY I BUILT IT
The Trigger & Underlying Problem
The Trigger: Manual console provisioning caused configuration drift between development and testing setups.
The Core Problem: When infrastructure is provisioned by clicking in the AWS web console, nobody knows why a security group was opened or why a subnet was resized. Manual mistakes are inevitable and disaster recovery is impossible.
Why Standard Solutions Were Insufficient: Terraform is the industry standard for declarative infrastructure management across cloud providers.
02. PRACTICAL IMPACT
What It Solves in Practice
PRACTICAL PROBLEM
Transforms infrastructure into version-controlled, reproducible code that can be planned, reviewed in pull requests, and applied deterministically.
BENEFICIARIES
Guarantees consistent environments and documents the exact state of infrastructure in Git.
BEFORE THIS SYSTEM
Infrastructure was manually configured with notes in text files.
03. IMPLEMENTATION
Architecture & Key Engineering Decisions
The Ansible recording shows a terraform directory with vpc.tf, alb.tf, ec2.tf, rds.tf, s3.tf, iam.tf, ecr.tf, api_gateway.tf, and lambda.tf. The console recording shows the VPC those files produced. A remote state backend is not on screen.
Key Decisions:
- Kept network, compute, database, and storage in separate Terraform files rather than one scratch file.
- The visible rds.tf sets the database to PostgreSQL 17, db.t3.micro, not publicly accessible, and storage encrypted.
- I am not describing a DynamoDB lock table. The recordings do not show one.
File: not captured — do not treat as the project backend
# The Expense Tracker recordings show Terraform files and the # resulting VPC in the AWS console. They do not show a remote # state backend block. No bucket name or lock table is claimed here.
04. CHALLENGES & SOLUTIONS
What Failed in Practice & How It Was Addressed
WHAT WENT WRONG
- Nothing in the Terraform or console recording shows a failed apply, a state lock, or a drift incident. I am not adding one.
HOW I SOLVED IT
- No fix is claimed here. The useful evidence is the console resource map matching the subnet and gateway names, and rds.tf matching the database drawn as not public.
05. REFLECTION & LESSONS
Takeaways & Future Iterations
What I Learned:
- The file tree and the console need to be read together. A diagram title is not the same thing as the resource map.
- Remote state locking is a separate topic. It is not demonstrated in these recordings.
WHAT I WOULD CHANGE NOW:
I would add a remote state backend only after I can show the bucket and the lock table. I am not claiming that setup today.