Skip to content

Lab 5 · RDS Multi-AZ

Resilient · Est. time: 30–40 min (plus RDS provisioning wait) · Cost: ⚠️ Multi-AZ is NOT Free Tier — it runs a second (standby) instance, so it bills even though single-AZ db.t*.micro is Free-Tier eligible. Keep it short and delete at the end.

Goal. Create an RDS database with Multi-AZ, trigger a failover, and confirm the application endpoint doesn't change — the core of Database Resilience.

Cost note

Multi-AZ doubles the instance cost and isn't Free Tier. If you only want to stay within Free Tier, create a single-AZ db.t3.micro and just read Steps 3–4 rather than running the failover.

Step 1 — Create a Multi-AZ database

  1. RDS console → Create database → Standard create.
  2. Engine: MySQL (or PostgreSQL). Template: Dev/Test.
  3. Availability & durability: choose Multi-AZ DB instance (creates a synchronous standby in another AZ).
  4. DB instance class: db.t3.micro. Credentials: set a master username/password.
  5. Storage: 20 GiB gp3. Create database. Provisioning takes several minutes.
aws rds create-db-instance --db-instance-identifier lab-rds \
  --engine mysql --db-instance-class db.t3.micro \
  --allocated-storage 20 --master-username admin --master-user-password 'ChangeMe123!' \
  --multi-az
aws rds wait db-instance-available --db-instance-identifier lab-rds

Step 2 — Note the endpoint

The endpoint (e.g. lab-rds.abc123.us-east-1.rds.amazonaws.com) is a DNS name. Your app always connects to this — never to a specific instance IP. That indirection is what makes failover transparent.

aws rds describe-db-instances --db-instance-identifier lab-rds \
  --query 'DBInstances[0].[Endpoint.Address,MultiAZ]' --output text

Step 3 — Trigger a failover

  1. Select the DB → Actions → Reboot → tick Reboot with failover → confirm.
  2. AWS promotes the standby in the other AZ to primary and re-points the same endpoint DNS to it. The database is briefly unavailable (typically ~60–120s), then back.
aws rds reboot-db-instance --db-instance-identifier lab-rds --force-failover

Step 4 — Confirm the endpoint is unchanged

Check the endpoint again — it's identical. The Availability Zone behind it changed, but your app's connection string didn't. Look at Events (RDS → the DB → Logs & events) to see the failover recorded.

Multi-AZ ≠ read scaling

The standby you just failed over to was not serving reads — it sat idle until failover. To offload reads you'd add a read replica (Topic 5), which is asynchronous and promoted manually. Different tools, different jobs.

Teardown

RDS → select lab-rds → Actions → Delete. Uncheck "create final snapshot" for a lab (or keep one — note snapshots also cost a little storage). Confirm.

aws rds delete-db-instance --db-instance-identifier lab-rds \
  --skip-final-snapshot --delete-automated-backups

Confirm the instance (and any manual snapshots you don't want) are gone so billing stops.

✅ What you should understand now

  • Multi-AZ keeps a synchronous standby in another AZ and fails over automatically by re-pointing the same DNS endpoint — no application change.
  • The standby is not readable — Multi-AZ is about availability, not read scaling.
  • Failover is fast (seconds–low minutes) and the app reconnects to the same endpoint.
  • Multi-AZ costs roughly double single-AZ and isn't Free Tier.
  • For read scaling you'd use read replicas (async, manual promote); for cross-Region relational DR, Aurora Global Database.

Related: Learn — Database Resilience