Current operating model and a testable failover runbook
Aurora Global Database now supports one primary Region and up to ten read-only secondary Regions, not five. Replication latency is typically under a second, but that is not an RPO or RTO guarantee. The current AWS workflow also distinguishes a healthy planned switchover from an unplanned managed failover; detaching a cluster is a manual fallback, not the default disaster-recovery command.
Choose the operation by failure state
Use switchover-global-cluster for a controlled move when the primary, target secondary, and dependent services are healthy. Aurora synchronizes the target before changing roles, so AWS documents an RPO of zero for this operation. Managed switchovers require compatible engine versions, and the database is briefly unavailable while roles change. Do not attach an arbitrary fixed RTO to the design; measure reconnect and application-recovery time in your own environment.
aws rds --region PRIMARY_REGION switchover-global-cluster \
--global-cluster-identifier GLOBAL_ID \
--target-db-cluster-identifier TARGET_CLUSTER_ARNUse failover-global-cluster --allow-data-loss for a genuine unplanned Regional outage. A managed failover does not wait for asynchronous replication to catch up, so its RPO is nonzero and depends on lag at the event. AWS recommends the managed method because it restores the old primary as a secondary when that Region recovers. The older detach-and-rebuild sequence is reserved for cases where managed failover is unavailable, such as incompatible engine versions.
aws rds --region TARGET_SECONDARY_REGION failover-global-cluster \
--global-cluster-identifier GLOBAL_ID \
--target-db-cluster-identifier TARGET_CLUSTER_ARN \
--allow-data-lossThe authoritative procedures and version prerequisites are in AWS's Aurora Global Database switchover and failover guide. Resolve command names from current documentation during a runbook review rather than copying a historical command into an incident terminal.
Prevent stale routing and split brain
Point writers at the Aurora Global Database writer endpoint so the hostname follows the current primary. Before an unplanned failover, stop application writes if possible, choose the eligible secondary with the least lag, and verify that clients honor DNS changes. AWS notes that write fencing is best effort and recommends a low DNS cache TTL, such as five seconds, for clients that cache the global endpoint. RDS Proxy endpoints associated with the old Region may still need explicit application routing changes.
After promotion, validate the new primary's parameter group, Secrets Manager and IAM setup, monitoring, logging, Lambda or S3 integrations, network paths, and capacity. Those settings are not all inherited from the old primary. Reconcile any transactions missing after the last durable replicated point; never assume a transactionally consistent promotion means zero lost writes. The database disaster-recovery runbook provides a framework for recording measured RTO and RPO.
Write forwarding is not multi-writer
With global write forwarding enabled, a statement received by a secondary is sent to the primary, executed there, and then replicated back. The primary remains the source of truth. This can simplify endpoint management for occasional writes, but it adds cross-Region round trips and couples the secondary session to primary availability. Supported SQL, transactions, isolation behavior, and consistency controls differ between Aurora MySQL and Aurora PostgreSQL and across engine versions. Check the engine-specific pages linked from AWS's current write-forwarding documentation before enabling it.
Test read-after-write behavior under the selected consistency mode, transaction aborts, connection loss after a forwarded commit, retries, and duplicate requests. Applications should use idempotency keys or another domain-level deduplication strategy where a retry could repeat a side effect. Monitor forwarding latency, open and rejected forwarding sessions, primary saturation, and cross-Region replication lag. For newer engine versions, AWS documents AuroraGlobalDBRPOLag for RPO-oriented monitoring; AuroraGlobalDBProgressLag plus local replica lag helps explain end-to-end secondary freshness. Metric availability is engine-version dependent, so alarms must be validated after every engine upgrade and role change.
Quarterly exercise checklist
- Confirm primary and target engine compatibility and that the target has a promotable DB instance.
- Measure DNS convergence, connection retry, write resumption, and data reconciliation instead of recording only the RDS operation duration.
- Run one healthy switchover and a controlled failover simulation; verify alarms and dashboards after roles reverse.
- Test failback as a separate switchover and preserve evidence of the latest replicated transaction.