Aurora Global Database

Attaching a second Region is the moment everything changes. Your Aurora cluster stops being an independent unit and becomes one member of a global cluster. The global cluster is now the unit of operation. You patch it, fail it over, and reason about it as one thing.

Membership requires engine-version lockstep. The managed cross-region paths for moving the primary — switchover when it is planned, failover when the primary Region is down — require the same major and minor version on every cluster. Aurora MySQL is stricter: no minor version tolerates differing patch levels at all.

Do not expect automation to hold versions in line. Automatic minor version upgrades silently stop applying to global-database clusters. The setting exists, but it has no effect.

A list of single-region features also turns off at the boundary: Backtracking, Secrets Manager integration, Aurora Auto Scaling on secondary clusters, per-cluster stop/start, and renaming member clusters.

What you are buying is DR posture. What you are paying is a bill that scales as N × full copy.

Every secondary Region runs a full copy of the database: its own instances, its own storage at the same GB as the primary, its own read I/Os. On top of that come the replicated writes. The primary's storage layer ships every write to each secondary Region, and AWS bills those replicated write I/Os per secondary, at the same count as the primary's in-region write I/Os. In AWS's us-east-1 worked example, that is $0.20 per million. The replication stream itself also crosses inter-region transfer: about 2.75 KB per write I/O, at $0.02/GB in the same example.

Aurora I/O-Optimized, the configuration that replaces per-I/O charges with a higher storage rate, eliminates the in-region I/O charges. It does not eliminate replicated write I/Os. AWS's own I/O-Optimized example still bills the secondary $9 a month for 45 million replicated writes.

The endpoint you put writes on decides how failover behaves. The global writer endpoint is a DNS name that always resolves to the current primary, through switchovers and managed failovers alike. During fencing windows — the intervals when a failed Region is being cut off from writes — Aurora applies additional write safeguards to the traffic you send through this endpoint.

Cluster endpoints do not follow the role. When a secondary is promoted, its writer endpoint is its old reader endpoint minus -ro: my-global.cluster-ro-… becomes my-global.cluster-…. Applications bound to cluster endpoints therefore need config changes in the middle of the incident.

Reads belong on each Region's own reader endpoint, for local latency. RDS Proxy users have one more move after a promotion: repoint to the new primary's proxy endpoint.

The replication is asynchronous, at the storage layer, typically lagging about 1 second. That lag number is what people quote. The real trade is the failover semantics.

Managed failover promotes a secondary without waiting for synchronization. AWS's User Guide says it completes "typically within a few minutes"; the product page markets under 1 minute. As part of it, Aurora attempts write fencing through the storage layer — cutting the old primary off from writes — as best-effort. It also snapshots the old primary's storage at the failure point.

After promotion, every other secondary Region is rebuilt to the new primary's point in time, which takes minutes to hours depending on storage size and distance. The old primary returns with a brand-new storage volume.

Write forwarding lets a session connected to a secondary Region submit writes instead of connecting to the primary. The cost is a hidden round trip: a forwarded write commits on the primary first, then replicates back, and only then can your session see it. You are trading write locality for that round trip on every write.

Sessions opt in per connection, through aurora_replica_read_consistency (MySQL 2.08.1+; a cluster parameter from 3.04+). There are three values. 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. The statement is one line: SET aurora_replica_read_consistency = 'SESSION';. A session that skips it stays a plain reader, and its writes are rejected like any replica write.

The restrictions are hard borders. Only REPEATABLE READ isolation works. DDL, XA transactions, SAVEPOINTs, LOAD into permanent tables, and DML referencing temp tables are rejected outright.

These are the MySQL rules. Aurora PostgreSQL has its own write forwarding (14.9+, 15.4+, 16+) with a different consistency parameter (apg_write_forward.consistency_mode), READ COMMITTED allowed alongside REPEATABLE READ, and a different restricted list — no cursors, no COPY, no VACUUM. Do not assume one engine's rules carry to the other.

Provisioned instances in secondary Regions run memory-optimized classes only, and db.r5 or higher is the recommendation. Instance class is the small decision. The real one is promotion headroom: on failover, a secondary's reader becomes the global writer and must absorb 100% of the write throughput plus its own Region's reads. That is a load it never carried before, and it is the number to size for.

The reader budget is bounded and shared oddly. A secondary cluster tops out at 16 readers. The primary's budget drops to 15 − s, where s is the number of secondary Regions; attach another secondary, and the primary loses another reader slot.

Aurora Auto Scaling does not work on secondary clusters at all. Serverless v2 readers are allowed, and if the primary Region runs Serverless, AWS recommends a minimum of 8 ACU there.

Lifecycle operations change the unit you operate. You stop operating a cluster and start operating the global cluster, every member Region at once.

Minor upgrades split by engine. Aurora PostgreSQL has a single managed operation, modify-global-cluster --engine-version, which upgrades the global cluster and rolls back automatically on failure. Aurora MySQL has no equivalent: upgrades run per-cluster, and the order is secondaries before primary.

Major upgrades hit hard walls. PostgreSQL blocks a major upgrade entirely while the RPO feature is on — the rds.global_db_rpo parameter, which makes Aurora hold commits on the primary until at least one secondary cluster is inside your target RPO. MySQL 2→3 in-place requires lower_case_table_names at its default value; if it is not at default, the path is remove all secondaries, upgrade, re-attach.

Switchovers are the planned, RPO-0 path: roles move with no data loss. Aurora waits for full synchronization before flipping roles, so a switchover's duration is proportional to current replication lag.