Back to path
MediumWorking system ~15h· 5 milestones

Stand up a resilient 3-tier app across availability zones

A startup needs their web app off a single hand-configured EC2 box before launch. You own the infrastructure: it must survive an AZ outage, scale under load, keep the database private, and be reproducible from code.

VPC designAuto ScalingLoad balancingRDSIAM least-privilegeCloudWatchTerraformIncident runbooks
Build this freeBrowse all projectsNo credit card. Already a member?

What you'll build

A reproducible, multi-AZ AWS environment in Terraform: a load-balanced, auto-scaling app tier in private subnets, a managed database with backups, and dashboards proving it self-heals.

See how we teach, before you sign up

You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:

variables.tfhcl
variable "region" {
  type    = string
  default = "eu-west-1"
}

variable "azs" {
  type        = list(string)
  description = "Availability zone suffixes, e.g. [\"a\", \"b\"]"
  default     = ["a", "b"]
}

variable "vpc_cidr" {
  type    = string
  default = "10.0.0.0/16"
}

variable "db_password" {
  type      = string
  sensitive = true
}

Reading this file

  • variable "azs"A list of availability zones so spreading across AZs is built in from the start, not bolted on later.
  • default = ["a", "b"]Two zones by default, the minimum needed to survive one data center going dark.
  • variable "vpc_cidr"The private IP range for the whole network, sized big enough to carve subnets out of.
  • sensitive = trueHides the DB password from Terraform's console output so it does not leak into logs or screen shares.

Multi-AZ is parameterized from day one via var.azs, never hard-coded.

That's 1 of 9 explained code blocks in this single project.

The build, milestone by milestone

  1. 1

    Design the network

    5 guided steps

    The network is the blast-radius boundary. Get subnets and security groups right and everything above inherits a sane security posture; get it wrong and you are patching holes forever.

  2. 2

    Make the app tier elastic

    5 guided steps

    Auto Scaling across AZs is what turns a single box into something that survives a dead instance and a traffic spike without a human awake at 3am.

  3. 3

    Add a managed, private database

    5 guided steps

    The database is the part you cannot just re-launch. Multi-AZ failover, automated backups, and network isolation are non-negotiable for anything holding real data.

  4. 4

    Prove reliability & cost

    5 guided steps

    A reviewer does not trust "it’s resilient", they trust a recorded failover and a cost number. This milestone turns claims into evidence.

  5. 5

    Write the on-call runbook

    5 guided steps

    Alarms without a runbook just wake people up; they do not help them fix anything. The runbook is what turns your dashboard from a wall art into an operable service.

What's inside when you start

4 starter files, ready to clone
5 guided milestones
5 full reference solutions
9 code blocks explained line-by-line
5 "is it working?" checks
4 interview questions it prepares you for

You'll walk away with

A Terraform repo that stands up the full environment
An architecture diagram of the VPC and traffic flow
A write-up of the failover test (with timings) and cost estimate
A RUNBOOK.md mapping each alarm to a concrete diagnose-and-recover procedure

This is portfolio-grade. Build it free.

Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.

Start building