You're building production infrastructure for a fintech startup in Nairobi — a VPC with public and private subnets across two availability zones, an RDS PostgreSQL database, and an Application Load Balancer, all in Terraform.
The discipline skills: organising Terraform into separate files instead of one monolith, reading plan diffs that show modifications to existing infrastructure (not just creates), adding provider version constraints, extracting hardcoded values into variables, and running a cost analysis that compares what AI estimated against what the bill actually shows.
The AI-direction lesson: last project, you checked AI's output against verification targets. This time, you start directing AI to check its own work — and you discover that how you ask determines what you get. "Review this Terraform for security issues" produces generic reassurance. "List every security group rule and flag any that allows access from the entire VPC CIDR" produces specific findings. The difference between a useful self-review and a useless one is the specificity of your prompt.
Your Role
You are the cloud engineer. A colleague is handing off the Pesa Bora project to you — James needs production infrastructure before his launch.
The structure is the same as last time: a handoff with context, a detailed project brief, a CLAUDE.md governance file, and verification targets. You direct Claude Code through the work and review every plan before it touches live infrastructure. What's new is the terrain — a database in a private subnet, a load balancer spanning availability zones, a NAT Gateway that costs money per gigabyte, and modification plans that change existing infrastructure instead of just creating it.
What Gets Built
Four AWS services, each with a specific job:
- A VPC (Virtual Private Cloud) — a private network with public and private subnets across two availability zones. The public subnets hold the load balancer and NAT Gateway. The private subnets hold the database. This separation is mandatory for financial data.
- An RDS instance — a managed PostgreSQL database. Encrypted storage, automated daily backups, private subnet only. This holds savings balances and M-Pesa transaction data — it must not be reachable from the public internet.
- An Application Load Balancer — distributes incoming traffic across the public subnets. HTTP listener with health checks. This is the front door.
- A NAT Gateway — allows resources in the private subnets to reach the internet (for OS updates, outbound API calls, logging) without being reachable from the internet. Every outbound byte from the private subnets costs $0.045 per GB — the app's calls to the M-Pesa API cross this, though inbound callbacks from M-Pesa do not (they arrive through the ALB).
These resources cost more than the last project. The NAT Gateway alone is ~$32/month before data processing charges. James's board reviews this bill every month.
Tools
- Claude Code — the primary tool for writing and reviewing Terraform
- Terraform CLI —
init,fmt,validate,plan,apply,destroy - AWS CLI — resource verification and Cost Explorer queries
- AWS Console — visual verification and cost breakdown dashboard
- Git and GitHub — version control
- VS Code + Terraform extension — code editor
Materials
In the project folder you'll find:
- The colleague's handoff (
first-contact.md) — the internal handoff with context about James and Pesa Bora. - Project brief (
project-brief.md) — the detailed requirements document: VPC architecture, RDS specification, ALB configuration, security requirements, cost constraints, M-Pesa integration context. - CLAUDE.md — the project governance file. Claude Code reads this at the start of every session. It contains the client context, security policies, cost constraints, and verification targets.