- Newest
- Most votes
- Most comments
Hello.
Aurora allows you to set the failover priority.
I think it is possible to perform a failover within the same AZ by setting the leader in the same AZ to a higher failover priority.
However, if an entire AZ fails, it may fail over to a leader in another AZ.
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraHighAvailability.html#Aurora.Managing.FaultTolerance
You can customize the order in which your Aurora Replicas are promoted to the primary instance after a failure by assigning each replica a priority. Priorities range from 0 for the highest priority to 15 for the lowest priority. If the primary instance fails, Amazon RDS promotes the Aurora Replica with the highest priority to the new primary instance. You can modify the priority of an Aurora Replica at any time. Modifying the priority doesn't trigger a failover.
The behavior you are observing is the designed and expected functionality of Amazon Aurora's failover mechanism. By default, Aurora assigns promotion tiers to its reader instances based on their proximity to the writer. Readers located in the same Availability Zone (AZ) as the writer are placed in the highest priority tier (tier 0 or 1), while readers in different AZs are assigned to lower priority tiers (up to tier 15). During a failover, Aurora automatically promotes the healthiest reader from the highest available tier to minimize latency and ensure the fastest possible recovery. This is why it consistently picks the reader in the same AZ, as explained in the AWS Documentation on Aurora Failover.
To properly test a cross-AZ disaster recovery scenario, you need to manually override this default behavior. You are correct to be cautious about "promoting a reader," as that specific action (promote-read-replica-db-cluster) can create a new, standalone database cluster, which is not what you want for a failover test and would absolutely break your application connections. The correct and safe method is to use the dedicated failover command, which allows you to specify the exact target instance you want to become the new writer. The cleanest way to do this is via the AWS Command Line Interface (CLI). You can force a failover to your desired cross-AZ reader with the following command, as detailed in the failover-db-cluster CLI Reference:
aws rds failover-db-cluster --db-cluster-identifier <your-cluster-name> --target-db-instance-identifier <your-cross-az-reader-instance-name>
This command initiates a controlled failover within your existing cluster, and Aurora will handle promoting the specified reader to the new writer role. There is no risk of creating a separate cluster or invalidating your setup.
To add to Riku's correct answer... If all your db-instances are the same instance type and size, it's less of an issue but this becomes super important if you align differing workloads to certain instances where you might choose different instance class/size, such as heavy reporting / analytic workloads requiring a larger or 'd' class (optimized reads [ref 1]) instance with local NVMe for large / faster temp files. You should assign all nodes a failover priority for the most control. If you have two nodes in different AZs you want to always be the writer, set failover priority for both to the lowest values. Note, having them both set to 0 is fine.
[ref 1] - https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.optimized.reads.html