11.2 Project — a three-tier application, built properly

What this is and why it exists

This is the project that stands for the whole course. A working application, a database no stranger can reach, a load-balanced application tier, the entire thing defined as code and deployable from nothing, monitoring that would tell you it was broken, and a teardown that leaves no bill. Nothing here is beyond what you have learned; the difficulty is that it must all be true at once, which is exactly what makes it evidence.

The vocabulary

• Three tiers — the public entry point, the application, and the data store.
• Private subnet — one with no route to the internet, so nothing in it is reachable from outside.
• Bastion or managed access — how you reach a private machine when you need to.
• From scratch — the configuration creates everything, in an empty account, with no manual step.
• Meaningful alert — one that fires on something a user would feel.
• Teardown — one command that removes everything and leaves nothing billing.
• README — the document that lets a stranger run this without asking you.

The mental model

The design is the network module's three-tier picture, made real. A load balancer in a public subnet is the only thing the internet can reach. The application tier sits in a private subnet, reachable only from the load balancer. The database sits in another private subnet, reachable only from the application tier. If you can connect to your own database from your laptop without going through something you deliberately built for the purpose, the design is not finished — that is the single clearest test of whether this project is real.

The second idea is that the code is the artefact, not the running system. Somebody should be able to clone the repository, supply their own account credentials, run the tool, and have the whole thing exist. That is a much higher bar than "it is running", and it is the bar that makes it evidence of engineering rather than of clicking. It also has a pleasant consequence: because you can rebuild it, you can destroy it, which is what makes this project affordable to have done.

Third, the monitoring. One meaningful alert is worth more than a wall of dashboards, and the rule from the observability module applies: alert on the symptom. The load balancer reporting failing responses, or the application's error rate crossing a threshold, is something a user would feel. Processor use is not. One alert, on a symptom, that you have deliberately triggered once to confirm it arrives.

The work

1. Draw the network first — the address block, the subnets, which is public and which is private, and the rule saying the database accepts traffic only from the application tier. Everything else follows from this drawing.
2. Write it as infrastructure code from the beginning, not afterwards. Building by hand and then describing it later is how imports and drift enter your life; describing it first is barely more work and produces the thing you wanted anyway.
3. Deploy the application to the private tier behind the load balancer, with a health check that tests something the application really depends on rather than only that the port is open.
4. Wire up logs and metrics, add exactly one alert on a user-visible symptom, and break the application on purpose once so you see it fire.
5. Write the README a stranger can follow: what this is, an architecture diagram, the prerequisites, the commands to deploy, what to expect, roughly what it costs to run, and the single command that removes everything.
6. Run the teardown. Then run the deploy again from nothing, and confirm you get the same system. That round trip is the proof, and it is the thing you will describe in an interview.

What you should now be able to explain or do

Show a working application whose database cannot be reached from the internet, and demonstrate that. Recreate the entire system in an empty account from your repository. Explain your one alert: what it measures, why it is a symptom, and how you know it fires. Hand somebody your README and have them deploy it without asking you a question. Destroy everything and rebuild it, and describe that round trip as what it is — proof the description is complete.

Check yourself