One instance in one zone is one point of failure, as the web server was in Chapter 6. RDS has two kinds of copy, for two different problems.

Multi-AZ

A Multi-AZ instance keeps a standby in a second zone of its subnet group, written synchronously with the primary. --apply-immediately makes the change now (else in the weekly maintenance window):

aws rds modify-db-instance --db-instance-identifier market-db --multi-az --apply-immediately

aws rds describe-db-instances --db-instance-identifier market-db --query "DBInstances[0].[MultiAZ,AvailabilityZone,SecondaryAvailabilityZone]" --output text

If the primary or its zone fails, RDS fails over: the standby becomes the primary behind the same endpoint, in about a minute. Test it on purpose:

aws rds reboot-db-instance --db-instance-identifier market-db --force-failover

aws rds describe-events --source-identifier market-db --query "Events[].[Date,Message]" --output text records it: Multi-AZ instance failover completed.

Read replicas

A read replica is a copy that follows the primary asynchronously, a few seconds behind, with its own endpoint. Reports and read-heavy pages use it, and the primary keeps its capacity for writes:

aws rds create-db-instance-read-replica --db-instance-identifier market-db-reports --source-db-instance-identifier market-db

It refuses writes: cannot execute INSERT in a read-only transaction. It needs automated backups on the source (they are, for a day by default).

aws rds promote-read-replica --db-instance-identifier market-db-reports makes it a standalone database that accepts writes, for example to move a copy to another job; it no longer follows the source.