Skip to content

SYSTEM Cited by 2 sources

Aurora Global Database

What it is

Amazon Aurora Global Database is AWS's cross-region read-replica cluster feature for Amazon Aurora. A "separate read-only Aurora cluster that your data will be replicated to" running in a secondary region, fed by asynchronous replication from the primary- region cluster, so applications in the secondary region read from a topologically-nearby Aurora endpoint rather than paying the cross-region latency of every read. (Source: )

Each participating region "is independently scalable, so understanding the compute requirements for that region and selecting an appropriate instance type can help optimize costs."

Why it shows up on this wiki

Aurora Global Database is the canonical wiki instance of patterns/global-read-replica-cluster — one primary region + N read-only secondary regions, with asynchronous replication in between. The pattern's defining characteristic is its three-layer cost model (per Morrison):

  1. Compute — secondary-region reader instances billed at standard Aurora per-hour rates.
  2. Storage — secondary-region storage billed as a separate Aurora storage SKU.
  3. Replication — "Amazon charges additional fees per 1 million write operations performed, as well as standard data transfer costs to replicate data between regions."

The third layer is what distinguishes Global Database from a single-region Aurora cluster: every write to the primary region becomes a billable event at the replication layer, and the cross-region bytes themselves are charged at AWS's data-transfer rates.

Cost shape summary

  • Primary-region compute + storage — standard Aurora billing.
  • Secondary-region compute + storage — standard Aurora billing, per region.
  • Per-million-writes replication fee — Global Database surcharge.
  • Cross-region data transfer — per-GB bytes billed.

Morrison's framing: Global Database "allows you to have a separate read-only Aurora cluster that your data will be replicated to" — but the per-write fee + transfer cost mean the operator absorbs a replication-cost surface that scales with primary-region write volume, not just with secondary-region read volume.

Contrast with newer Aurora family members

  • Aurora DSQL — multi-region active-active from day one, with consistency guarantees via time-based MVCC. Different trade-off: DSQL writes coordinate across regions, so the cost model isn't per-million-writes to a passive replica.
  • Aurora Limitless — horizontally-scaled within-region Postgres; different scale axis than Global Database's within-cluster cross-region replication.

Aurora Global Database is the read-replica form: primary region owns writes, secondary regions read.

Global Write Forwarding: closing the async gap for consistency

By default Aurora Global Database's cross-region storage replication is asynchronous, which admits stale reads against secondary-region replicas. Global Write Forwarding lets applications in a secondary region issue writes that are forwarded to the primary, and — critically — exposes consistency levels that turn the async replica into a consistent read source:

  • SESSION level — enforces read-your-own-writes: makes a client "wait for its own forwarded writes to replicate back before reading." An agent that writes a decision then re-reads to continue its plan sees its own write.
  • GLOBAL level — the strongest: a read query "waits for replication to catch up to the exact point in time when the read started," delivering global strong consistency for that read.

The AWS "Consistency is the new latency" post positions this as Pattern A — precision through global consistency for high-stakes data (permissions, security policy, financial records, immutable system prompts) where a stale read is unacceptable, and pairs it with Aurora DSQL as the newer native-synchronous alternative. (Source: sources/2026-08-18-aws-consistency-is-the-new-latency-ai-at-the-data-layer) See consistency-matched-to-truth-requirement for the task-to-consistency decision framework.

Contrast with PlanetScale read-only regions

Morrison's counter-positioning in the same post: "PlanetScale offers the ability to create read-only regions, where your data is replicated to a selected region that is closer to your application servers in that region. It is very similar to Global database, except you don't need to pay for the data transfer costs, and you still get a full MySQL cluster with the same resources as the selected instance type." Canonical instance of the PlanetScale-bundles-transfer-cost counter-positioning vs Aurora's per-axis billing.

Failover in DR: coordinated vs unplanned (RPO consequence)

As the writer-promotion mechanism in a multi-Region pilot-light DR, Aurora Global Database has two distinct failover paths with different timing and RPO, and conflating them is a planning error:

  • Coordinated failover (switchover) — failover-global-cluster without --allow-data-loss. Waits for the secondary to synchronize before promoting, so it requires the primary Region to be reachable. This is the planned path (DR drills, maintenance). Athenahealth's FIS test measured a 58-second promotion with ~15 s write unavailability and sub-second lag — but those are coordinated-path numbers.
  • Unplanned managed failover — failover-global-cluster --allow-data-loss, or a manual detach-and-promote. Used during an actual primary-Region impairment (the primary is not reachable). Does not wait for replication to synchronize, so promotion timing differs and RPO is bounded by the replication lag at the moment of the event, not zero.

The practical lesson: don't quote a DR drill's coordinated-path promotion time or its zero data loss as your event-time expectation. Plan near-zero, not zero RPO. The RDS Global Endpoint automatically redirects connections to the new writer after promotion, but the application still has to reconnect — Athenahealth found TFE's connection pool timeout (60 s) badly extended recovery until cut to 10 s. Promotion must also be sequenced before DNS shifts traffic, or both Regions can accept writes (split-brain). (Source: sources/2026-09-09-aws-validating-multi-region-dr-for-terraform-enterprise-with-aws-fis)

Seen in

  • sources/2026-09-09-aws-validating-multi-region-dr-for-terraform-enterprise-with-aws-fis — DR-failover instance. Aurora global database as the writer- promotion tier in Athenahealth's multi-Region Terraform Enterprise pilot light; canonical wiki source for the coordinated (switchover) vs unplanned (--allow-data-loss managed failover) distinction and its RPO consequence, the 58 s coordinated-path measurement, and aws:rds:failover-db-cluster as the FIS action used to validate it.

  • sources/2026-08-18-aws-consistency-is-the-new-latency-ai-at-the-data-layer — Pattern A of the replication trinity: Global Write Forwarding with SESSION (read-your-own-writes) and GLOBAL (point-in-time strong-consistency read) levels as the way to give AI agents a consistent cross-region read source for high-stakes state.

  • — Brian Morrison II (PlanetScale, 2024-01-24). Canonical wiki pairing of Aurora Global Database against PlanetScale Portals as architectural duals for cross-region read-only replicas. Both use async cross-region replication: "When a read-only region is created, replicas will be created in the region of your choice and asynchronous replication will be configured between the home region (where the production database currently resides) and the selected region." Canonical instance of patterns/async-replication-for-cross-region — the physics-mandated trade-off where 60ms+ RTT makes sync replication infeasible.

  • — canonical disclosure of Global Database's three-layer cost model (compute + storage + per-million-writes + transfer). First canonical wiki instance of Aurora Global Database.

Last updated · 766 distilled / 2,225 read