Module 9 · Deployment and operations

Lesson 42 — Cloud

Compute, storage, networking and IAM on AWS/GCP/Azure.

Published
In this lesson
  1. Exercise 1 — The lock-free map
  2. Exercise 2 — The compute
  3. Exercise 3 — The data
  4. Exercise 4 — The network and the bill
  5. Exercise 5 — The IAM
  6. Submit

TicketFlow's deployment in the cloud, without vendor lock. No solutions.md before submitting.

Exercise 1 — The lock-free map

  1. Complete §1's table for YOUR chosen provider (or whichever is at hand) with the services' EXACT names and their tier/free tier. How many map pieces does the starting free tier cover?
  2. The code's anti-lock: search your project for the spots touching the provider (the GDPR export's storage, the email sending, the rate limiter). How many have a Protocol/interface (24) and how many import the SDK directly? Migrate the worst one.
  3. The translation exercise: write TicketFlow's deployment for TWO providers (the chosen one + an alternative) in 15 lines each (just services and configs, not full manifests). What changed? What did NOT change (the image, the per-environment config)?

Exercise 2 — The compute

  1. Deploy (or simulate with the compose + env vars) the app in PaaS mode: concurrency 1 per instance, edge timeout 120 s, 40's healthcheck. How many instances does 36's plateau (200 VUs) consume? Compute the monthly cost with the provider's simulator.
  2. The edge timeout vs your p99: with 36's numbers (checkout p99 720 ms post-improvements), what timeout does the provider configure and what happens if you leave it at 10 s? (any endpoint of yours taking >10 s? the synchronous GDPR export — 23's finding).
  3. The healthcheck as liveness signal: kill the app's process in the environment and time how long the PaaS/healthcheck takes to replace it (or in compose: restart: unless-stopped + the healthcheck). Document the pod's MTTR (41: the metric).

Exercise 3 — The data

  1. Managed Postgres: review the tier you would use and note its real max_connections. Recompute 39's arithmetic against that limit: does it fit? What needs tuning (pool per process, 43's PgBouncer)?
  2. The restore drill: create the test environment's backup, DELETE the test DB, restore. Time it. How long? Does the restore go to a DIFFERENT environment (the honest drill) or over the live one? Write the 5-step restore runbook.
  3. The GDPR export bucket: create (or simulate) the bucket with Block Public Access + 15-min signed URLs. Test: the signed link downloads; at 16 min, 403. What's in the bucket at 30 days? (23's lifecycle/retention policy?)

Exercise 4 — The network and the bill

  1. Draw (ASCII) TicketFlow's VPC: subnets, security groups, who talks to whom. Verify: does Postgres accept connections from ANYTHING other than the app/workers? From the Internet? Document each firewall rule with its reason.
  2. The egress bill: estimate TicketFlow's monthly egress with 36's metrics (browse bandwidth × visits) and compute how much the CDN (38) saves by absorbing 90% of browse. Does the CDN pay for itself?
  3. Orphan hunting: list (or imagine) 5 typical orphan resources of the project (the 36 experiment's elastic IP, 34's staging disk, the restore drill's snapshot, 42's NAT, 53's cluster that never deployed). Assign each its monthly cost and the cleanup task.

Exercise 5 — The IAM

  1. The worker's role: write the least-privilege policy for the export worker (23): what it can do, what it CANNOT, and the blast radius if the container is compromised. Can it delete the bucket? Can it read another client's bucket?
  2. The Access Key anti-pattern: search your environment (or your git history, 06) for any long-lived credential in versioned code/.env. Document the finding and the fix (27's dual rotation + secrets manager).
  3. The audit: turn on (or document turning on) the provider's audit log (CloudTrail/Audit Logs). Which event did (or would) exercise 3's bucket deletion record, and by whom?

Submit

Paste the map's table, the worker's IAM policy, the restore runbook and the VPC with its rules. Next: Lesson 43 — Kubernetes and managed services.