Aurora Global Database

Attaching a second Region converts your Aurora cluster from an independent unit into a member of a global cluster — and the global cluster becomes the unit of operation. Engine versions must stay in lockstep: managed cross-region switchovers and failovers require the same major and minor versions, and for Aurora MySQL no minor version tolerates differing patch levels at all. Automatic minor version upgrades silently stop applying — the setting exists but has no effect. A list of single-region features turn off at the boundary: Backtracking, Secrets Manager integration, Aurora Auto Scaling on secondary clusters, per-cluster stop/start, and renaming member clusters.

What you're trading: DR posture for a bill that scales as N × full copy. Every secondary Region pays full retail — its own instances, its own storage (the same GB as the primary), its own read I/Os — plus replicated write I/Os billed per secondary at the same count as the primary's in-region write I/Os ($0.20 per million in AWS's us-east-1 worked example), plus inter-region transfer for the replication stream itself (~2.75 KB per write I/O at $0.02/GB in the same example). Aurora I/O-Optimized eliminates in-region I/O charges but not replicated write I/Os: AWS's own I/O-Optimized example still bills the secondary $9/month for 45 million replicated writes.

The endpoint decision trades flexibility for failover semantics. The global writer endpoint always resolves to the current primary — including after a switchover or managed failover — and Aurora applies additional write safeguards to traffic through it during fencing windows. Cluster endpoints don't follow: a promoted secondary's writer endpoint is its old reader endpoint minus -ro (my-global.cluster-ro-… becomes my-global.cluster-…), so applications bound to cluster endpoints need config changes mid-incident. Reads belong on each Region's own reader endpoint for local latency; RDS Proxy users must repoint to the new primary's proxy endpoint after promotion.

Asynchronous storage replication gives ~1-second typical lag, but failover semantics are the real trade: managed failover promotes a secondary without waiting for synchronization ("typically within a few minutes" per the User Guide; the product page markets under 1 minute), attempts write fencing through the storage layer as best-effort, and snapshots the old primary's storage at the failure point. Every other secondary Region is then rebuilt to the new primary's point-in-time — minutes to hours depending on storage size and distance — and the old primary returns with a brand-new storage volume.

Write forwarding trades write locality for a hidden round trip: a forwarded write commits on the primary, then replicates back before your session can see it. Sessions opt in per connection via aurora_replica_read_consistency (MySQL 2.08.1+; cluster parameter from 3.04+): EVENTUAL may read your own writes stale; SESSION waits for your session's writes to replicate back; GLOBAL waits for all committed data as of query start. Only REPEATABLE READ isolation works, and DDL, XA transactions, SAVEPOINTs, LOAD into permanent tables, and DML referencing temp tables are rejected outright.

Secondary Regions run memory-optimized classes only (db.r5 or higher recommended), and the real capacity decision is promotion headroom: on failover, a secondary's reader becomes the global writer and must absorb 100% of write throughput plus its own Region's reads. The reader budget is bounded and shared oddly — a secondary cluster tops out at 16 readers, while the primary's budget drops to 15 − s with s secondary Regions. Aurora Auto Scaling doesn't work on secondary clusters at all; Serverless v2 readers are allowed (primary-Region Serverless minimum recommended: 8 ACU).

Lifecycle operations change unit: you operate the global cluster, not the cluster. Minor upgrades: Aurora PostgreSQL has a single managed operation (modify-global-cluster --engine-version, auto-rollback on failure); Aurora MySQL is per-cluster, secondaries before primary. Major upgrades: PostgreSQL is blocked entirely while the RPO feature is enabled; MySQL 2→3 in-place needs lower_case_table_names at default, otherwise remove all secondaries, upgrade, re-attach. Switchovers — the planned, RPO-0 path — wait for full synchronization first, so their duration is proportional to current replication lag.