The 7-Day Cloud Architecture Challenge

One week, roughly two hours an evening, one small application that survives having a machine killed underneath it. The shapes below are the same on AWS, Google Cloud and Azure, and the whole build sits around $40-70 a month if you leave it running. Costs are approximate and vary by region.

Day 1 — Network and identity baseline

Create one VPC with a /16 range, then two public and two private /20 subnets spread across two availability zones. Public subnets get the internet gateway; private subnets hold compute and the database. Deliverable: a shell on a private host with no bastion, via the provider's session manager.

On identity, turn on MFA for the root account and then stop using it — one admin user for yourself, one role per workload with only the permissions it needs. Cost trap of the day: a managed NAT gateway typically runs about $32 a month per zone before data processing, so use one, in one zone, and accept the reduced redundancy.

Day 2 — Stateless compute behind a load balancer

Deploy the app twice, in different zones, behind an application load balancer with a real health check on /healthz that returns 200 only when dependencies are reachable. The instances must hold no state: no session files on disk, no uploads, no in-memory cache anyone depends on. Terminate TLS at the load balancer with a free managed certificate and redirect port 80 to 443. Deliverable: kill one instance and confirm the site stays up. Budget roughly $18-22 a month for the load balancer plus $8-15 per small instance.

Day 3 — Managed database and a restore you have actually done

Provision the smallest managed Postgres or MySQL your provider offers, in a private subnet, reachable only from the app's security group. Enable automated backups with 7-day retention and point-in-time recovery. Expect $15-30 a month at the smallest size.

Then do the part everyone skips: restore. Create a table, insert a row, note the time, drop the table, then recover to a timestamp before the drop into a new instance and write down how long it took. A backup you have never restored is a hypothesis, and restores are slower than people assume — tens of minutes is normal, not seconds.

Day 4 — Object storage, CDN and cache headers

Move every static asset to object storage with public access blocked, and put the CDN in front as the only reader. Storage runs around $0.02-0.03 per GB per month; CDN egress is what actually shows on the bill. Then get the headers right, because that is where the performance is:

# fingerprinted assets: app.9f2c1a.js
Cache-Control: public, max-age=31536000, immutable

# HTML that must reflect a deploy immediately
Cache-Control: public, max-age=0, s-maxage=60, must-revalidate

Deliverable: x-cache: Hit on a second request, and a deploy that invalidates HTML without invalidating the whole distribution.

Day 5 — Put it all in Terraform

Re-declare days 1 to 4 as code. Keep state in a remote backend — a versioned object storage bucket with locking — never on your laptop. Split it into network, data and app so a mistake in one cannot destroy the others.

terraform fmt -check -recursive
terraform validate
terraform plan -lock-timeout=120s -out=tfplan
terraform show -json tfplan | jq '[.resource_changes[]
  | select(.change.actions[] == "delete")] | length'

Run that on every pull request and post the plan as a comment. The jq line is the guardrail: it counts planned deletions, and a non-zero count on a routine change means read the plan properly before merging.

Day 6 — Observability, and exactly one alert that pages

Emit structured JSON logs carrying a request ID that propagates from the load balancer through the app, so one grep reconstructs a whole request. Chart five metrics: request rate, error rate, p50/p95/p99 latency and database connection count. That dashboard answers most incidents on its own.

Then create exactly one alert that wakes someone: 5xx rate above a small percentage of requests, sustained for five minutes. Everything else goes to a chat channel. A pager that fires for anything other than "users are affected right now" gets muted within a fortnight — and the real alert gets muted with it.

Day 7 — Break it on purpose and time the recovery

Run three drills and write down the clock time for each. Kill an instance and measure how long until traffic stops flowing to it and a replacement is healthy — a couple of minutes with a sensible check interval. Restore or fail over the database and record the real RTO and how much data you lost, which is your RPO. Then revoke the app's database credentials: if the dashboard still says "healthy" while every request 500s, your health check is lying, and that is the most valuable finding of the week.

Finish with terraform destroy and a rebuild from scratch, which proves day 5 works. To keep it running cheaply afterwards, the sub-$100 hosting comparison covers providers where this architecture costs considerably less.