The zero-idle stack
The third reference architecture replaces every always-on component with pay-per-use pieces:
- API Gateway (lesson 7-2) is a managed HTTPS endpoint that accepts each incoming request and turns it into a Lambda event, the front door of the stack. It plays the ALB's role with no fixed hourly fee, billed per million requests instead.
- Lambda functions (unit 7) hold the application logic, one function per route or one for the whole API, your choice.
- DynamoDB stores the data. It is AWS's serverless NoSQL database: no instance, no subnet, per-request billing, and a generous always-free tier (lesson 8-2). It stores items by key, so it trades SQL's flexible queries for effortless scale, a real trade to weigh against RDS.
- S3 + presigned URLs (lesson 4-3) handle file uploads, so big payloads never touch Lambda.
Notice what is missing: no VPC to design, no security groups to chain, no instances to patch. IAM roles (lesson 2-3) are the only security wiring: each function's role allows exactly its own table and bucket, least privilege from lesson 2-1.
When the classic architecture is the better choice
The classic architecture wins when traffic is high and steady, when requests need SQL's flexible queries, or when p99 latency budgets cannot absorb cold starts.
Each of those is one of the honest trade-offs from earlier lessons, one level up:
| condition | why serverless loses | source |
|---|---|---|
| high, steady load | per-request billing overtakes flat rates | 1-3, buy vs rent |
| relational queries and joins | DynamoDB's key-based model fits some data poorly | 9-3 |
| strict p99 latency budget | cold starts live in the latency tail | 7-3 |
The crossover on cost is real arithmetic rather than a matter of taste. Enough constant requests will cost more per month than $42 of rented capacity that sits there ready, and past that point the flat rate is simply cheaper.
Architecture is choosing trade-offs on purpose, not picking the newest option. The $0 idle bill is an advantage only for a workload that is actually idle sometimes.
Where you are now
You can now read all three of these diagrams cold, and that was the goal of the course:
- Static site (9-1): S3 + CloudFront + Route 53. Cents per month.
- Classic web app (9-2): ALB + EC2 + RDS across two AZs. Fixed cost, maximum control.
- Serverless API (9-3): API Gateway + Lambda + DynamoDB. Zero idle cost, scales itself.
Every real AWS estate is these three patterns mixed. When you meet a new service, place it with the questions this course drilled: which meter does it spin (8-1)? What does its default-deny look like (2-2)? Which subnet does it belong in (5-2)? Who holds its role (2-3)?
Next steps when you are ready for a real account: set the billing alarm first (lesson 8-2), lock root behind MFA (lesson 2-1), tag everything you create (lesson 8-3), then build architecture 1 for your own portfolio. It is the cheapest possible way to practice everything here for real.
Placing three workloads
The answer is 1-3-2.
- The marketing page is architecture 1, static. Unchanging files need no compute at all, and the whole thing costs cents.
- The bursty API is architecture 3, serverless. Bursty and unpredictable traffic is the poster child for pay-per-request from lesson 7-1, since serverless absorbs the spikes and bills nothing between them.
- The dashboard is architecture 2, classic. Steady all-day load makes flat-rate EC2 economical, and relational SQL reporting is exactly what RDS is for.
What makes this a realistic answer is that one company is running all three at once. Nothing about choosing serverless for the API argues against a rented instance for the dashboard, and the marketing page has no reason to touch either.
That mixing is the normal state of a mature AWS estate. Each workload is placed by its own traffic shape and data shape, and the account ends up holding all three patterns side by side.