Why does AWS RDS Aurora have the option of "Multi-AZ Deployment" when it does replication across different zones already by default?
When launching an Aurora instance I have the option of "Multi-AZ Deployment", which it describes as "Specifies if the DB Instance should have a standby deployed in another Availability Zone."
However the Aurora documentation states that Aurora already automatically spreads the database across different availability zones?
Additionally, what is the difference between an Aurora Multi-AZ standby and an ordinary Aurora replica. Is that that an ordinary replica can be read from increasing performance whereas a standby cannot be read from?
Answer
Aurora replicates your data across three availability zones, at the storage layer... but the database server instance, itself, is still a virtual machine running on a single physical machine that is located in a single availability zone.
The Aurora storage layer is outside that instance, and is able to let access continue uninterrupted without data loss, even in the event of the loss of up to two AZs, but the loss of the zone containing the db instance will still cause an outage for you, if you only have a single Aurora instance in your cluster (1 master, 0 replicas). Loss of an entire availability zone is one of those things that is highly improbable but not impossible. Your db instance is still a single point of failure when you only have one.
Multi-AZ makes allowance for a complete redundant database instance, in a different AZ, which will automatically take over for the primary within one minute, if it works as designed, in case of the loss of the AZ hosting the primary instance or a catastrophic failure of the primary instance. It's a second virtual machine, on a second physical machine, in a second availability zone. It's always running, but you can't access it. It's in the background, managed and monitored by the RDS infrastructure, but it is only accessible to you in the case of primary instance failure. The secondary machine can also be used to reduce downtime in the event of a software upgrade or maintenance event on the primary. When failover occurs, if you are using DNS to connect to your database (as you should), you'll find that the DNS entry is automatically pointed to the secondary.
Contrast this to a read replica, which is accessible all the time and can thus provide a significant performance benefit, by allowing the offloading of reads. Failing over to a replica involves promoting it to become a standalone master (which permanently detaches it from its own former master) and reconfiguring your application to use the alternate endpoint. This, of course, is still faster than recovering from a failure in the master by using a point-in-time snapshot to create a replacement master instance.