Amazon Aurora Global Database extends one Aurora database across AWS Regions with a single primary cluster and one or more secondary clusters. The primary Region remains the source of truth for writes; secondary clusters provide regional read capacity and promotion targets for disaster recovery. This is a read-local, write-primary architecture—not a true multi-writer database. Recovery time and possible data loss depend on topology, replication state, dependencies, routing, and the runbook your team has actually tested.
Understand the Topology Boundary
| Capability | What Aurora Global Database provides | What the application still owns |
|---|---|---|
| Regional high availability | Each Aurora cluster can use multiple Availability Zones and Aurora Replicas | Connection retry, transaction retry, pool behavior, and dependency availability |
| Cross-Region reads | Read-only secondary clusters with regional endpoints | Read routing and acceptance of replication delay for each workflow |
| Cross-Region writes | Writes execute on the primary cluster; supported write forwarding can relay statements from a secondary | Latency budgets, compatibility checks, session consistency, and retry safety |
| Regional recovery | Planned switchover and unplanned failover operations can make a secondary the new primary | RTO/RPO objectives, traffic cutover, dependency recovery, validation, and regular exercises |
Aurora replicates changes from the primary cluster to secondary Regions using its global database mechanisms. Cross-Region replication is asynchronous, so a regional reader can be behind the writer. AWS describes typical service behavior, but workload rate, distance, incidents, and secondary capacity affect observed lag. Never turn a marketing latency statement into a fixed recovery-point guarantee. Measure the lag distribution and the age of a business canary under normal, peak, and impaired conditions.
Route Reads by Correctness, Not Geography Alone
Use a secondary cluster's reader endpoint for requests that can tolerate its measured freshness. Route a read that must observe a just-committed write to the primary writer path or use a supported, tested consistency mechanism.
Create a contract for every read class: maximum acceptable staleness, fallback when the secondary is unavailable, behavior when lag exceeds budget, and whether the request may be retried in the primary Region. Include caches and search indexes in that contract because a database failover cannot make those dependencies current. Monitor both Aurora's engine-specific global database status and an application-level heartbeat containing the primary commit time.
Write Forwarding Is Still Single-Writer
With global write forwarding enabled on a supported Aurora engine version and Region, a secondary cluster can accept supported write statements and forward them to the primary cluster. The primary executes the change and Aurora replicates the result back to secondary clusters. This can simplify endpoint management, but it does not create independent writers in every Region. Every forwarded write still crosses Regions, consumes primary capacity, and depends on the primary being reachable.
Check the current compatibility tables and SQL limitations for the exact Aurora MySQL or Aurora PostgreSQL release. Configure the documented session consistency mode, then test read-after-write, transactions, timeouts, primary restart, forwarding disablement, and connection-pool reuse. Some session settings and operations can be unsupported or behave differently. A client timeout does not prove that a write failed; use idempotency keys or another business-level deduplication design before automatic retry. Monitor forwarded sessions, failures, and primary saturation separately from ordinary regional reads.
Separate Switchover from Failover
A switchover is the controlled operation for healthy clusters, such as a planned regional move or recovery exercise. Aurora synchronizes the selected secondary before changing roles. An unplanned failover is a disaster-recovery action when the primary Region is unavailable. Transactions not yet replicated to the chosen secondary can be lost, and AWS warns that failover is susceptible to split-brain hazards. Choose the target using current replication and dependency evidence, not simply the nearest Region.
Do not promise a universal number of seconds for either operation. Measure from the first user-visible failure until healthy application service is restored, not only until the RDS API reports a new role. The observed interval includes detection, authorization, control-plane operation, endpoint propagation, DNS and driver caching, connection establishment, application warm-up, queue recovery, and validation. The recovery point must be measured from confirmed business data on the promoted cluster.
Design the Whole Regional Cell
- Capacity: Size the secondary DB instances for recovery traffic, not only quiet read traffic. A headless secondary needs an instance before it can be a failover target.
- Network: Prebuild VPC routing, security groups, DNS, certificates, secrets access, and client connectivity in each Region.
- Compute: Keep deployable application versions, configuration, feature flags, and scaling limits ready in the recovery Region.
- Dependencies: Identify queues, object storage, search, caches, identity providers, KMS keys, observability, and third-party endpoints that can block service after database promotion.
- Fencing: Define how writes to the former primary are stopped and how background workers, schedulers, and migration jobs learn the new writer.
- Endpoints: Evaluate the Aurora global writer endpoint where supported, but still test resolver, driver, proxy, and pool behavior. Long-lived connections do not move because DNS changed.
- Backups: Maintain and test backup restore as an independent recovery path; replication can copy logical mistakes and destructive writes.
Build Measurable Recovery Objectives
Set an RTO from business impact and include the application and dependencies. Set an RPO from the maximum acceptable committed data loss for each workflow. Aurora PostgreSQL provides an optional global RPO parameter with documented behavior, but a parameter is not a substitute for capacity and failure testing. Track replication or durability lag, transaction rate, secondary resource saturation, forwarding health, connections, application error and latency, and the age of the canary record. Alert when the tested recovery envelope is at risk, not from a copied “less than one second” threshold.
Define degraded modes before an incident. A service might become read-only, reject correctness-sensitive reads, queue idempotent writes, or route all traffic to the primary Region. Each choice needs a timeout and an owner. Avoid allowing two application stacks to accept uncoordinated writes against different database histories; role confirmation and write fencing belong at the start of the recovery procedure.
Cross-Region Exercise Runbook
- Declare the exercise. Record scope, target Region, change window, abort conditions, owners, and the exact evidence required to pass.
- Capture the baseline. Record global cluster membership, engine versions, parameter groups, instance capacity, replication status, endpoints, canary age, traffic, and pending schema changes.
- Verify the target cell. Test application deployment, secrets, certificates, network access, monitoring, queues, caches, and third-party dependencies without changing production roles.
- Fence risky work. Pause schema migrations and non-idempotent background jobs. For a planned switchover, quiesce or control writes according to the approved procedure and observe synchronization.
- Invoke the correct operation. Use Aurora Global Database switchover for a healthy planned move or the documented managed failover for a genuine recovery scenario. Record API request and state-transition times.
- Reconnect deliberately. Drain or expire old pools, confirm the global writer endpoint or routing target, and verify applications and workers identify one writer.
- Validate data and service. Read pre-cutover canaries, write a new idempotent canary, confirm it from required read paths, reconcile critical counts or business invariants, and check error, latency, and queue recovery.
- Prove fencing. Confirm the former primary cannot accept unintended application writes. Verify scheduled jobs and automation target the current primary.
- Restore resilience. Reestablish a healthy secondary topology, capacity, monitoring, and backup coverage before declaring recovery complete.
- Review. Compare measured RTO and recovery point with objectives, document manual steps and surprises, and assign dated remediation work.
When You Really Need Multi-Writer
If independent Regions must accept writes while disconnected, Aurora Global Database's write forwarding does not satisfy that requirement. You need an explicit ownership and conflict model: partition writes by tenant or Region, make operations commutative or idempotent, define conflict detection and resolution, and decide what users observe during convergence. That is an application and datastore architecture decision, not a toggle on an Aurora secondary.
For broader planning, use the database disaster-recovery runbook and the Aurora PostgreSQL architecture guide. The Aurora failover and write-forwarding guide covers the feature-specific operating path.
Official AWS Documentation
- Aurora Global Database overview and limitations
- Aurora Global Database endpoints and read routing
- Global write forwarding behavior
- Aurora Global Database switchover and failover
- Monitoring Aurora Global Database
Architecture Summary
- Aurora Global Database has one primary writer cluster; regional secondaries serve reads and recovery.
- Write forwarding relays work to the primary and is not active-active multi-writer.
- Read routing needs an explicit freshness contract and a tested primary fallback.
- Measure application recovery and confirmed data, not only database control-plane completion.
- Exercise switchover, failover, fencing, reconnection, and dependency recovery as one system.