7.3 Data Replication: Aurora Global DB, DynamoDB Global Tables & S3 CRR

Cross-Region Stateful Data Replication Overview

Building multi-region active-active and active-passive architectures requires replicating stateful data across geographic distances. Unlike intra-region Multi-AZ replication—which operates synchronously over low-latency optical links—cross-region replication must navigate the physical constraints of the speed of light in fiber optics (transcontinental round-trip times typically range from 60ms to 120ms). Consequently, cross-region replication mechanisms are predominantly asynchronous and optimize for low replication lag, strong data integrity, and deterministic conflict resolution.

---

Amazon Aurora Global Database

Traditional relational database cross-region replication (such as standard Amazon RDS Read Replicas) relies on engine-level replication: the primary database writes changes to binary logs (MySQL binlog) or write-ahead logs (PostgreSQL WAL), which are parsed, transmitted, and replayed by the database engine on the replica. This introduces significant CPU overhead, engine lock contention, and replication lag that easily swells to minutes or hours under heavy write loads.

Amazon Aurora Global Database fundamentally re-architects cross-region replication by operating entirely at the distributed storage layer.

[ Primary Region (us-east-1) ]                               [ Secondary Region (us-west-2) ]
  +------------------------------+                             +------------------------------+
  | Primary DB Cluster (Writer)  |                             | Secondary Cluster (Readers)  |
  +--------------+---------------+                             +--------------+---------------+
                 | Redo Log Writes                                            | Cache Invalidation
  +--------------v---------------+                             +--------------+---------------+
  | Aurora Distributed Storage   | === Storage-Level Stream ==> | Aurora Distributed Storage   |
  | 6 Storage Copies across 3 AZs|     (<1 second latency)     | 6 Storage Copies across 3 AZs|
  +------------------------------+                             +------------------------------+

Storage-Level Physical Replication Mechanics

1. Redo Log Streaming: When a write occurs in the primary region, the primary cluster's compute node writes redo log records directly to its local distributed storage volume (replicated across 3 AZs). A dedicated fleet of storage agents then streams these redo log records directly across the AWS private global backbone to the secondary region's storage volume.
2. Zero Compute Overhead: The primary compute engine does not serialize or transmit binlogs; secondary compute nodes do not replay SQL statements. As a result, replication lag is typically under 1 second.
3. Scale: An Aurora Global Database supports one primary read-write Region and up to 10 secondary read-only Regions. A secondary cluster can contain Aurora Replicas for localized, low-latency reads.
4. Headless Clusters: In disaster recovery architectures where idle compute costs must be minimized, secondary regions can be configured as headless clusters (storage provisioned without any running DB compute instances). If a regional disaster occurs, compute instances can be launched on demand and attached to the pre-synchronized storage volume within minutes.

Switchover vs. Managed Failover

Choose the operation by whether the current primary is healthy:

[!CAUTION] Data-loss boundary: A managed failover does not wait for the unavailable primary and target secondary to synchronize. Inspect AuroraGlobalDBReplicationLag, stop writes where possible, and reconcile any missing transactions after recovery. Detaching a secondary is a manual alternative for older or exceptional runbooks, not the required current managed-failover procedure.

Cross-Region Write Forwarding

Aurora Global Database supports write forwarding on MySQL-compatible clusters. Applications connected to read replicas in secondary regions can issue write statements directly. The secondary cluster forwards write transactions over an encrypted network connection to the primary cluster writer node, which commits the transaction and replicates changes back to the secondary storage volume.

---

Amazon DynamoDB Global Tables

Amazon DynamoDB Global Tables provide a fully managed, serverless, multi-active (active-active) NoSQL database that replicates tables across chosen AWS Regions. Applications in any region can execute read and write operations locally with single-digit millisecond latency.

Replication Engine & DynamoDB Streams

Global Tables are powered by DynamoDB Streams. When an item is created, updated, or deleted in Region A:

1. The mutation is recorded immediately in that region's DynamoDB Stream.
2. The Global Tables replication engine reads the stream record and asynchronously applies the update to replica tables in all other designated regions.
3. Propagation across regions typically completes in under 1 second.

Conflict Resolution: Last-Write-Wins (LWW)

Because DynamoDB Global Tables operate in an active-active topology where multiple regions accept writes simultaneously, concurrent writes to the same item attribute in different regions can collide. DynamoDB resolves conflicts using Last-Write-Wins (LWW):

• DynamoDB automatically tracks the timestamp of each update at the storage layer (last_write_date).
• If two updates to the same attribute occur concurrently in different regions, DynamoDB compares the timestamps and applies the update with the most recent timestamp across all replicas.
• Consistency Model: Reads within the local region support both eventually consistent and strongly consistent reads. However, cross-region reads are always eventually consistent.

Capacity Planning & Replication Throttling

Current global tables (version 2019.11.21) synchronize capacity mode, table write capacity, and write auto scaling settings across replicas. Read capacity can use Region-specific overrides. In provisioned mode, the current write capacity in each Region can still rise and fall independently within the synchronized auto scaling configuration. A Region can therefore throttle if its local application writes plus replicated writes exceed its currently provisioned capacity. Monitor write throttles and ReplicationLatency, choose realistic shared maximum capacity and target utilization, or use on-demand mode for unpredictable traffic.

Amazon S3 Cross-Region Replication (CRR)

Amazon S3 Cross-Region Replication (CRR) automatically asynchronously copies objects across buckets in different AWS Regions for disaster recovery, compliance, and latency reduction.

Foundational Requirements for S3 CRR

1. S3 Versioning: Versioning must be explicitly enabled on both the source bucket and destination bucket.
2. IAM Permissions: S3 requires an IAM service role trusting s3.amazonaws.com with permissions to read objects and version tags from the source bucket and execute s3:ReplicateObject, s3:ReplicateDelete, and s3:ReplicateTags on the destination bucket.
3. Existing Objects: By default, CRR only replicates new objects created after the replication rule is enabled. To replicate pre-existing objects, use S3 Batch Replication.

Bidirectional (Two-Way) Replication & Loop Avoidance

In active-active multi-region architectures, applications in both regions upload files to their local regional S3 buckets. Organizations configure two-way CRR (Bucket A replicates to Bucket B, and Bucket B replicates to Bucket A). To prevent infinite replication loops, S3 applies internal metadata markers (REPLICA status): an object created as a replica in a destination bucket is never re-replicated to another destination by default.

To synchronize modifications made to replicas (such as updating metadata, ACLs, or tags), enable Replica Modification Sync in the replication rule.

S3 Replication Time Control (S3 RTC)

Standard S3 replication does not provide a guaranteed completion timeframe. For regulatory compliance and strict RTO/RPO SLAs, organizations configure S3 Replication Time Control (S3 RTC):

• 15-Minute SLA: S3 RTC guarantees that 99.9% of newly uploaded objects are replicated within 15 minutes, backed by an AWS Service Level Agreement.
• CloudWatch Metrics: RTC automatically emits CloudWatch metrics for real-time observability:
  • ReplicationLatency: Maximum replication time in seconds for objects pending replication.
  • BytesPendingReplication: Total volume of object bytes pending replication.
  • OperationsPendingReplication: Total number of replication operations queued.
• EventBridge Notifications: Emits events when an object replication misses the 15-minute threshold (Replication:OperationMissedThreshold).

Cross-Account CRR: KMS Re-Encryption & Ownership Override

In enterprise environments, the destination DR bucket frequently resides in an isolated security or archive AWS account. This introduces two critical configuration requirements:

1. AWS KMS Key Re-Encryption

When replicating objects encrypted with AWS Key Management Service (SSE-KMS):

• S3 cannot use the source KMS key in the destination region because KMS Customer Managed Keys (CMKs) are regional resources.
• The replication rule must specify the destination KMS key ARN in the destination region.
• S3 decrypts the source object using the source KMS key and re-encrypts the payload using the destination KMS key during replication.
• The replication IAM role must have kms:Decrypt permissions on the source key and kms:Encrypt permissions on the destination key.

2. Ownership Override (AccountOwnerOverride)

By default, an Amazon S3 object is owned by the AWS account that uploaded it. When Account A replicates objects to a bucket owned by Account B:

• Account A retains ownership of the replicated objects.
• Account B's bucket administrators cannot access, read, or enforce lifecycle policies on those objects unless Account A explicitly grants access.
• Remediation: Configure AccountOwnerOverride to Destination in the replication configuration and enable s3:ObjectOwnerOverrideToBucketOwner in the replication role. This automatically transfers ownership of all replicated objects to the destination bucket owner upon landing.

---

In-Memory Caching Replication: ElastiCache & MemoryDB Global Datastores

For high-performance caching and session storage, cross-region replication is extended to in-memory databases:

• Amazon ElastiCache for Redis Global Datastore: Provides fully managed cross-region replication. A primary cluster in one region serves read and write traffic, replicating data to up to two secondary read-only clusters in other regions with typical latency under 1 second. In the event of a regional outage, a secondary cluster can be promoted to primary in under 1 minute.
• Amazon MemoryDB Multi-Region: A durable, active-active database that accepts local reads and writes in multiple Regions. Replication is asynchronous and data is typically propagated within a second; applications must monitor replication lag and handle conflict resolution rather than assume instantaneous failover.