← Back to the course home

⏮️ Before & trade-offs

Every tool replaced something worse — and is itself the wrong tool somewhere. For each big idea in this course: what life was like before it, its honest merits ✅ and demerits ❌, and where to use it 👍 vs where not 👎.

🪪 IAM — identity & access management (lessons 01–06)

⏮️ Before IAM (launched 2011)

Early AWS accounts had essentially one login: root. Teams shared that password in a spreadsheet or chat. Everyone was all-powerful; nobody was accountable ("who deleted the bucket?" — silence); leaving employees meant rotating THE password for everyone. On-prem before that: shared admin accounts and sticky notes. IAM brought per-person identity, per-action permission, and an audit trail.

✅ Merits

  • every person/robot has its own checked identity
  • least privilege possible at all (slips per action)
  • audit: every call attributable (with CloudTrail)
  • free — no excuse not to use it fully

❌ Demerits

  • policy JSON gets complex fast (ARNs, conditions)
  • debugging "AccessDenied" can eat an afternoon
  • easy to over-grant out of frustration (Admin*)

👍 Use when

  • always — from your first day on AWS
  • separate identities even for a solo account (you + CI)

👎 Think twice when

  • …never. But DO avoid: daily root use, shared users, and one mega-policy for everything

Diagram ↗

🎩 Roles (temporary credentials) vs long-lived access keys (lessons 04–05)

⏮️ Before roles & STS

Machines authenticated with AKIA… access keys — permanent passwords pasted into config files, CI settings, and (tragically often) git repos. Key leaks are still the #1 cause of AWS account compromises; the crypto-mining bill arrives before the apology. Roles flipped the model: identities you wear briefly, credentials that expire in an hour.

✅ Merits (roles)

  • credentials expire — a leak has a 1-hour blast radius
  • nothing to store: EC2/EKS get theirs from metadata
  • CI via OIDC: zero secrets in pipeline settings
  • audit shows person AND hat worn

❌ Demerits

  • trust policies are one more document to reason about
  • role-chaining/debugging takes practice
  • local laptops still need SSO or (careful) keys

👍 Roles, when

  • every machine: EC2, EKS, Lambda, CI — no exceptions
  • humans via IAM Identity Center (SSO) sessions

👎 Keys only when

  • a third-party tool truly can't assume roles
  • …then: minimal policy, rotation, and regret 😄

Diagrams ↗

🖥️ EC2 — rented computers (lessons 07–12)

⏮️ Before EC2 (2006)

Buying servers. Capacity planning a year ahead, purchase orders, waiting weeks for delivery, racking hardware, and paying for it whether used or not. A startup's first expense was a server room. EC2's radical idea: a computer in minutes, by the hour, hand it back anytime — compute as a utility, like electricity.

✅ Merits

  • minutes to get one, seconds-based billing
  • every size from scooter to truck, GPUs included
  • full control: your OS, your software, your kernel
  • the substrate everything else (EKS!) runs on

❌ Demerits

  • YOU patch, secure and babysit the OS
  • idle instances bill silently (the classic bill shock)
  • pets accumulate unless you enforce cattle discipline

👍 Use when

  • you need full OS control or special software
  • steady, predictable workloads (with savings plans)
  • as managed-service underlay (EKS nodes) — mostly invisible

👎 Think twice when

  • an event-driven script → Lambda (no server at all)
  • a containerized web app → Fargate/Cloud Run style
  • you'd rather never SSH again → managed everything

Diagram ↗

🎟️ Spot instances (lesson 08)

⏮️ Before spot

AWS's spare desks sat empty; your batch jobs paid full price. Spot (2009) auctions the empty seats: up to ~90% off, with one catch — AWS may take the seat back with a two-minute warning when a full-fare customer arrives.

✅ Merits

  • ~60–90% cheaper than on-demand
  • perfect for k8s: pods just reschedule (lesson 03 of ☸️)
  • huge scale available in bursts

❌ Demerits

  • can vanish with 2 minutes' notice
  • capacity varies by type/AZ/time
  • needs interruption-tolerant design (checkpoints, queues)

👍 Use when

  • batch jobs, CI runners, rendering, big data
  • stateless k8s workers mixed with on-demand base

👎 Think twice when

  • databases or anything stateful-and-singular
  • latency-critical singletons that can't move

Diagram ↗

🛗 SSM Session Manager vs SSH (lesson 09)

⏮️ Before SSM

Everyone SSH'd: port 22 open to the office IP (or worse, the world), key files passed around when people joined and left, bastion hosts to maintain, and zero record of who typed what. Session Manager (2018) routes the shell through AWS's API — no open port, no shared keys, every session loggable.

✅ SSM merits

  • no inbound port at all — nothing to scan
  • access via IAM (revoke a person, not a key file)
  • sessions auditable/recordable
  • works without public IPs or bastions

❌ SSM demerits

  • needs the agent + instance role set up
  • a hair slower; file transfer is clunkier
  • one more AWS-specific thing to learn

👍 SSH still fine when

  • quick personal labs (like this course's — from YOUR IP only)
  • rsync/scp-heavy workflows
  • non-AWS machines (SSM is AWS-shaped)

👎 Avoid entirely

  • port 22 open to 0.0.0.0/0 — the classic honeypot
  • team-shared private key files
  • long-lived bastions nobody patches

Diagram ↗

🗃️ RDS — managed database vs running your own (lesson 17)

⏮️ Before managed databases

Every team ran Postgres/MySQL on its own machine: a DBA (or an unlucky developer) owned backups, patches, replication, and 3 AM failovers. RDS (2009) rents you the database WITH the clerk — the craft parts come tested and boring.

✅ Merits

  • backups that actually restore (point-in-time)
  • Multi-AZ failover in ~a minute, no drama
  • patching, metrics, read replicas — included

❌ Demerits

  • bills hourly, idle or not (lesson 20!)
  • no OS access; extension list is curated
  • easy to outgrow the wallet before the engine

👍 Use when

  • state that must survive — almost always
  • small teams: buy the boring, build the special
  • k8s apps too: stateless in-cluster, state in RDS

👎 Think twice when

  • exotic engines/extensions RDS doesn't offer
  • DB-per-tenant fleets where cost explodes
  • you truly have the team to run it (rare)

Diagram ↗

⚡ Lambda — serverless vs renting desks (lesson 19)

⏮️ Before serverless

Even a once-a-day errand needed a desk running 24/7 — patched, monitored, and billed while idle. Lambda (2014) flipped the unit of compute from "a machine" to "an errand": code appears when called, vanishes after, and idle costs zero.

✅ Merits

  • idle = $0 · a million errands/month are free
  • scaling is implicit: one helper per errand
  • no OS to patch, no fleet to manage

❌ Demerits

  • cold starts (~100ms–2s) sting latency-critical APIs
  • 15-minute cap; steady heavy load costs MORE than desks
  • local dev/debug is clunkier; vendor-shaped

👍 Use when

  • event glue: uploads, webhooks, queues, schedules
  • spiky or rare workloads (the once-a-day report)
  • ops automation — lesson 12's scripts, serverless

👎 Think twice when

  • constant high traffic (desks/k8s win on cost)
  • long-running jobs, websockets held for hours
  • special hardware (GPUs) or huge memory

Diagram ↗