AWS Cloud Architecture
An end-to-end production deployment across six AWS services, built and maintained rather than followed from a tutorial.
Cloud Yard is the district where the server stacks are labelled with the services they stand for, because this project is infrastructure rather than an interface.
An end-to-end, production-grade cloud deployment on AWS:
| Service | Job |
|---|---|
| EC2 | Application compute. |
| RDS | Managed relational database, so backups and failover are not my cron job. |
| S3 | Object storage for static assets and uploads. |
| CloudFront | CDN in front of the origin — the thing that makes it fast outside one region. |
| Route 53 | DNS and record management. |
| ACM | TLS certificates, issued and renewed automatically. |
Why six services and not one
Any one of these is a tutorial. Wiring all six into a system that stays up is a different exercise, and it is the one worth talking about in an interview.
The interesting problems were never “how do I launch an EC2 instance.” They were the seams: getting CloudFront to cache what should be cached and pass through what must not be, getting ACM’s validation to actually complete against Route 53’s records, putting RDS somewhere that is reachable by the app and by nothing else, and deciding what belongs on S3 versus what belongs in the database.
What I took away from it
Infrastructure work is mostly about failure modes. The deployment that matters is not the one that works on the day you build it — it is the one that still works after a certificate expires, a region has a bad hour, or traffic arrives from somewhere you did not plan for.
That instinct is the direct reason the game layer of this portfolio has an eight-step performance bail-out ladder and a guaranteed HTML fallback underneath it. Same habit, different stack.