Cloud Fundamentals
- Distinguish IaaS, PaaS, and serverless and pick the right tier for a workload
- Build a working mental model of AWS core services (EC2, S3, RDS, Lambda, IAM)
- Explain regions, availability zones, and the egress/pricing gotchas that surprise teams
- Map the capstone onto three deployment options with an honest trade-off table
| Spaced-rep warm-up: distributed systems + Docker cards (D46/D148) | 10 min |
| ELI5 + tech read: tiers, AWS core five, regions/AZs, pricing traps | 20 min |
| Guided: map the capstone to three tiers + reason about the invoice | 40 min |
| Practice: tier-selection drill | 15 min |
| Project: cloud placement decision doc | 25 min |
| Quiz + flashcards | 10 min |
Builds on: Day 46 — Distributed systems fundamentals · Day 148 — Docker fundamentals · Day 149 — Compose, registries & image hygiene
Once, to launch a web service, you bought physical servers, waited weeks for delivery, racked them in a room you cooled and powered, and hoped you'd guessed your traffic right — buy too few and you crash on launch day, too many and you've spent a fortune on idle metal. The cloud replaced that with a rental counter: you rent computers by the minute, summon a hundred in seconds when traffic spikes, and hand them back when it drops, paying only for what you used.
But the rental counter has tiers, and choosing the wrong one costs money and sleep. IaaS is renting the bare rack — a raw Linux machine (AWS EC2) you set up entirely yourself: maximum control, maximum babysitting. PaaS is renting a serviced office — you hand over your container and the platform runs it, scales it, and patches the OS (think Railway, Render, or a managed container service): less control, far less toil. Serverless is renting by the errand — your code runs only when called and you pay per invocation (AWS Lambda), with nothing idling between calls. The rest is logistics you can't ignore: which building (region) and which independently-powered floor (availability zone) you rent in, and the sneaky charge for carrying data *out* the door (egress) that isn't on the sticker price. Pick the tier that matches how much you want to manage, and read the whole invoice, not the headline rate.
Your capstone has to live somewhere a customer can reach, and the tier you choose is a direct cost, reliability, and speed decision an FDE makes constantly. Pick raw IaaS and you own patching, scaling, and 2am reboots; pick a PaaS and you trade some control for shipping in an afternoon; pick serverless for a bursty low-traffic tool and you pay nothing between requests — but eat cold-start latency that a chat UI feels. The pricing gotchas are where real money leaks: egress fees, always-on instances left running over a weekend, a chatty cross-region setup billed per gigabyte. Interviewers ask you to reason about deployment targets; customers ask "what will this cost to run?" (Day 173's ROI one-pager). Being able to map a workload to a tier, with the trade-offs and the invoice traps named, is core FDE and system-design fluency.
Guided practice
Map the capstone onto three tiers
22 min- Create
deploy/deployment_options.md. Define your capstone's requirements first: rough traffic (requests/day), latency target (p95), statefulness (the vector index + logs), and secrets it needs. - For each of three concrete targets — (A) a single EC2 VM running your Compose stack (IaaS), (B) a managed container platform like Google Cloud Run / AWS App Runner / Railway running your image (PaaS), (C) serverless functions (Lambda) fronting a managed vector store — write: how the pieces map, who manages what, the cold-start/latency story, and the rough monthly cost shape.
- Explicitly place the vector DB in each option (self-hosted on the VM vs a managed pgvector on RDS vs a hosted vector service) — this is usually the deciding constraint.
- Fill an honest trade-off table: control, ops burden, latency, cost at low vs higher traffic, and portability.
- Pick the option you'll actually use on Day 151 and write one paragraph defending it against the other two.
Reason about the invoice before you spend
18 min- For your chosen Day-151 option, itemize every billable dimension: compute-hours, storage-GB, egress-GB, load balancer / NAT hours, managed-DB hours, and per-request LLM API cost (from your Day-146 dashboard).
- Estimate a monthly bill at two traffic levels (e.g. 200 and 5,000 requests/day). Show which dimension dominates at each — for most low-traffic AI apps it's the LLM API tokens, not the infra.
- Identify the single biggest surprise risk (an always-on GPU instance? cross-region egress? a load balancer billed 24/7?) and how you'd cap it.
- Write the exact billing-alarm/budget you'd set (threshold + what it notifies) before launching.
- If you have a cloud account, actually create a budget alert now; otherwise write the console/CLI steps. This habit is graded again on Day 151's teardown and Day 173's ROI one-pager.
On your own
Tier-selection drill
15 minFor each workload, choose IaaS, PaaS, or serverless and defend it in two sentences naming the deciding factor: (1) a bursty internal Slack bot that answers a few dozen questions a day and can tolerate a 2-second first response; (2) a customer-facing docs-QA API with steady traffic, a 1.5s p95 target, and a persistent vector index; (3) a nightly batch job that re-embeds the whole corpus; (4) a service that must run inside a customer's VPC with no managed services allowed (Day 170 foreshadow); (5) a GPU-hosted open model you fine-tuned (Day 128). Then state, for the two you'd deploy as PaaS, what single requirement would force you down to IaaS.
Hints: scale-to-zero + tolerant latency screams serverless; a persistent index + steady low-latency traffic favors a long-running container (PaaS); "no managed services" or special hardware forces IaaS.
Capstone cloud placement decision doc
Produce the decision document an FDE would put in front of a customer to justify where the docs-QA service runs. In deploy/deployment_options.md, state the capstone's requirements (traffic, latency, statefulness, data residency, secrets), then present the three options (IaaS VM + Compose, PaaS container, serverless + managed vector store) with a real trade-off table across control, ops burden, latency, cost-at-two-traffic-levels, and portability. Include a per-dimension cost estimate for the recommended option (naming whether infra or LLM tokens dominate), the billing-alarm you'll set, and a one-paragraph recommendation with the deciding factor named. End with the concrete resource list you'll actually provision on Day 151 (which VM/service, which region, which vector-store placement, which secrets).
Common mistakes & misconceptions
- Reaching for raw EC2 by default. Unless a concrete need forces IaaS, a managed platform ships the same container in an afternoon with far less ops — default to the most managed tier that fits.
- Reading only the compute-hour rate. Egress, load balancers, NAT gateways, and managed-DB hours are separate line items that often dominate the bill — price per dimension.
- Putting serverless under a latency-sensitive chat UI. Cold starts add seconds to the first request; scale-to-zero savings aren't worth it when users feel the wake-up.
- Forgetting the vector store is stateful. Serverless functions scale to zero but your index cannot — it needs a persistent home (RDS/pgvector or a hosted service), which usually decides the architecture.
- Leaving instances running "just for now." An idle EC2 box bills 24/7; the teardown-and-billing-alarm habit is the difference between a free learning month and a surprise invoice.
- Ignoring IAM until launch. Over-broad roles (AdministratorAccess on a web server) are the classic security-review finding; least-privilege from the start is cheaper than a rewrite.
Q1. A bursty internal tool answers ~30 questions a day and tolerates a 2-second first response. Best default tier?
Q2. Which AWS service is the one security reviews scrutinize most, and why?
Q3. A team is shocked by their cloud bill despite modest compute. The most likely culprit?
Go deeper — curated resources
- AWS free tier + a billing budget ↗ — Before Day 151, create a free-tier account and set a $5 budget alert — the single habit that keeps the deploy lab free.
- Three deployment options mapped with the vector store placed in each
- Trade-off table and per-dimension cost estimate completed
- Billing-alarm plan written (or budget alert actually created)
- A defended recommendation and concrete Day-151 provisioning list
- Quiz ≥ 2/3
← Back: This grounds Day 46's distributed-systems abstractions (replication, AZs, stateless scaling) in real cloud primitives and gives the Day-148/149 container somewhere to run.
Forward →: Day 151 provisions the option you chose and deploys the container to a real URL; Day 153 expresses this infrastructure as code; Day 159 hardens the IAM/network choices for production, and Day 173 turns the cost estimate into an ROI one-pager.
Unlocks: D151 Deploy Lab — Container to Cloud URL · D153 Infrastructure as Code & Environments · D170 Customer Environments