Aurora Global and Multi-Region Design

While Aurora Serverless v2 solves the problem of compute elasticity within a single region, production workloads often face a broader challenge. Users distributed across continents need low-latency reads, and business continuity requirements demand that the application survive even if an entire AWS Region becomes unavailable. Standard Aurora clusters, including multi-AZ deployments and in-region read replicas, operate within a single-region boundary. They protect against instance and Availability Zone failures, but they cannot address cross-region latency or regional outages. Aurora Global Database is AWS’s purpose-built answer to this gap. It establishes one primary region that owns all writes and supports up to five secondary regions that receive data through a dedicated, storage-level replication stream. This replication mechanism transfers redo log recordsThe low-level change entries that describe physical modifications to database storage pages, replicated at the storage layer rather than as parsed SQL statements. rather than replaying SQL statements, which keeps typical replication lag under one second without consuming the database engine CPU in the secondary regions. This lesson covers the division of responsibility between writer and reader regions, how write forwarding simplifies application design, how regional promotion works for both planned and unplanned events, and why secondary regions require deliberate capacity planning.

The following diagram illustrates the high-level architecture of an Aurora Global Database spanning multiple regions:

With this architecture in mind, the next step is understanding exactly how the primary and secondary regions divide their responsibilities.

Primary and secondary region roles

The primary region contains the only writer instance in the entire global cluster. All DML operations, such as inserts, updates, and deletes, along with all DDL operations, such as schema changes, execute exclusively in this region. The primary region can also host read replicas for local read scaling, functioning like any standard Aurora cluster.

Secondary regions are strictly read-only at the storage level. They cannot accept writes directly. Each secondary region maintains its own full copy of the Aurora storage volume, kept current through the dedicated ...