Skip to content
Aurora Global Database
Sub-page 1 of 8
Core one-way-door · Free

Going Global Locks In More Than Topology: Version Lockstep and the Features That Turn Off

Decision drivers
  • Managed switchover/failover requires same major+minor versions; Aurora MySQL requires identical patch levels too (no minor version exempts).
  • Automatic minor version upgrade has no effect on global-database clusters.
  • Unsupported once global: Backtrack, Secrets Manager, secondary Auto Scaling, per-cluster stop/start, member-cluster rename.
  • Up to 10 secondary Regions; primary reader budget drops to 15 − s.

Production premise

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.

Failure mode & inflection point

The attach itself will not fail. The trap is month six.

The chain goes like this. Automatic minor upgrades are a no-op on the global cluster, and nobody is running coordinated patching, so patch levels drift apart. Then an emergency cross-region failover is needed. The managed failover path requires matching versions, finds drift, and is unavailable. The manual path is all that remains: detach the cluster back to standalone, then rebuild the topology region by region. That becomes the incident plan.

The second failure is assumption drift. A team carries single-region habits into the global world and says, mid-incident, "we can Backtrack the bad UPDATE." That option no longer exists. The discovery happens during the incident.

Production guardrail

Before you attach anything, run the give-up list as a pre-attach checklist. If Backtrack, Secrets Manager integration, secondary auto-scaling, or per-cluster stop/start is load-bearing in your operation, stay single-region until it isn't. Staying single-region is a valid answer; the attach will still be there when the dependency is gone.

Enter global only at an engine version every target Region supports. From that day on, treat "all clusters on the identical version, including patch level" as a standing invariant. Make the check executable: list members with describe-global-clusters, pull each member's EngineVersion with describe-db-clusters, and alert on any difference. Automatic upgrades will not maintain the invariant for you, and for MySQL managed failover depends on it.