Repo: https://github.com/vatul16/terratier — full Terraform source, module docs, and architecture diagram.
When I set out to build this project, I didn't want another "deploy a VM and call it infrastructure" tutorial repo. I wanted something that would force me to think through the same questions a platform team actually argues about: how many subnet tiers do you really need, where do secrets live, how do you let engineers SSH in without handing out keys forever, and what's the cheapest way to stay highly available without going broke on NAT Gateway bills.
The result is TerraTier — a small Go/Node.js goal-tracking app, deployed across a fully isolated, auto-scaling, four-tier network on AWS, provisioned entirely through modular Terraform. The app itself is deliberately boring (it's a CRUD list of goals). The infrastructure underneath it is the actual point of the project, and this article walks through why it looks the way it does.
The problem with most "3-tier Terraform" examples
Search for AWS 3-tier Terraform examples and you'll find a lot of repositories that split a VPC into public, private, and database subnets, drop a web server in private, and call it done. That's a reasonable starting point, but it collapses two very different concerns into one "private" tier: the stateless web/API layer that talks to the internet (indirectly, via a load balancer) and the application layer that's allowed to talk to the database. If your web tier gets compromised, in that model, it's sitting in the same subnet — and often the same security group — as anything that can reach your data.
