Amazon Aurora cluster endpoint

Your reasoning is correct. Option A is the most appropriate and aligns with best practices for minimizing downtime and ensuring availability during maintenance. The votes for Option C might stem from a misunderstanding of how Multi-AZ works or the specific configuration steps involved.

If you follow Option A, you ensure that your application can handle read and write operations efficiently during the maintenance window with minimal interruption.

Hi... I wanted to add some clarity around your specific question related to minimizing downtime for maintenance activities. Generally, this will depend on the type of maintenance (e.g., database upgrade, OS upgrade, etc.).

Aurora's shared storage architecture has many benefits but one of its challenges is that database engine upgrades must occur across all db-instances at the same time. This is not too bad for backward-compatible minor versions and database engine patches because we have invested a lot into the low-downtime patching and faster restarts using a technique we call "zero downtime patching" (ZDP). While we don't quite live up to the name yet, we are able to maintain most app connections across the upgrade and get it all done in "low double-digit" seconds once the upgrade begins. For more info on ZDP, please see the docs at the link [1] below.

Major version upgrades and some Aurora MySQL minor version upgrades are not guaranteed by the respective open source community to be backward compatible so we have built a "managed blue/green" approach to reduce downtime. In Aurora database engines, we use storage clones to create the "green" deployment while your existing workload continues to operate as normal against the original and now known as the "blue" deployment. We instantiate and start a native replication technique that queues committed transactions in the blue deployment such that they can be replicated to the newly upgraded green deployment in advance of the cutover. For more info on Blue/Green Deployments, please see the docs at the link [2] below.

Operating system updates are performed at an instance level so it is possible to perform "rolling upgrades" through all the instances in the cluster one at a time. As long as your application uses the "cluster endpoint" for connecting to the writer and the "reader endpoint" for connecting to a read-only instance, we handle all the DNS manipulation behind the scenes so connections are routed to the proper instance. Typically you would perform the OS upgrade on all the read-only instances first and then when you need to do the writer, you would "failover" the writer role to one of the read-only instances. The old writer then becomes a read-only instance which you can then perform the OS upgrade on it with minimal impact to your running workload.

Hope this is all helpful...

Links:

[1] - https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.ZDP.html ;

[2] - https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html ;

[3] - https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html#OS_Updates ;