ExamFinch.com My Study

Study guide

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

Practice this exam

AWS Certified DevOps Engineer – Professional Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: CI/CD Pipeline Architecture & Source Integration

1.1 Multi-Stage & Multi-Account CodePipeline Design 1.2 CodeBuild Projects, Build Environments & Pipeline Secrets 1.3 Source Control Workflows, Webhooks & Branching Models

2 Chapter 2: Automated Testing, Test Gates & Quality Verification

2.1 Automated Unit, Integration & Acceptance Testing in Pipelines 2.2 Load Testing, Performance Benchmarking & Synthetic Canaries 2.3 Security Scanning, SAST/DAST & Approval Gates

3 Chapter 3: Artifact Management & Multi-Platform Deployment Strategies

3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3 3.2 Automated Image Baking with EC2 Image Builder 3.3 In-Place, Rolling & Immutable Deployments on EC2 3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda

4 Chapter 4: CloudFormation, CDK & Reusable IaC Components

4.1 Advanced CloudFormation: Nested Stacks, Change Sets & Custom Resources 4.2 Cross-Account & Multi-Region StackSets & Drift Detection 4.3 Modern IaC: AWS CDK, SAM & Service Catalog Governance

5 Chapter 5: Multi-Account Architecture, Organizations & Control Tower

5.1 AWS Organizations Hierarchy, OUs & Account Provisioning 5.2 Service Control Policies (SCPs) & Multi-Account Guardrails 5.3 AWS Control Tower, Account Factory & Landing Zone Automation

6 Chapter 6: Systems Manager & Large-Scale Fleet Configuration

6.1 SSM Agent, Hybrid Activation & Session Manager 6.2 Systems Manager Run Command, State Manager & Associations 6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig

7 Chapter 7: High Availability & Multi-Region Resiliency

7.1 Designing Resilient Multi-AZ & Multi-Region Architectures 7.2 Route 53 Traffic Flow, Health Checks & DNS Failover 7.3 Data Replication: Aurora Global DB, DynamoDB Global Tables & S3 CRR

8 Chapter 8: Scalability, Auto Scaling & Disaster Recovery Automation

8.1 EC2 Auto Scaling Policies, Lifecycle Hooks & Warm Pools 8.2 Container & Serverless Scalability: ECS Capacity Providers, EKS & API Gateway 8.3 Disaster Recovery Strategies: RTO, RPO & Architecture Tiers 8.4 Automated Backup & Recovery with AWS Backup & Elastic Disaster Recovery

9 Chapter 9: CloudWatch Metrics, Agent Collection & Log Aggregation

9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution 9.2 Unified CloudWatch Agent & Custom Metric Collection 9.3 Centralized Log Aggregation, Retention & Cross-Account Subscriptions

10 Chapter 10: Log Analysis, Dashboards & Distributed Tracing with X-Ray

10.1 CloudWatch Logs Insights, Filter Syntax & Query Optimization 10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection 10.3 Distributed Tracing with AWS X-Ray & Service Maps

11 Chapter 11: Automated Observability & Event-Driven Monitoring

11.1 Application & Infrastructure Health Checks with Route 53 & ALB 11.2 Centralized Observability with Amazon OpenSearch & Athena 11.3 Synthetic Monitoring with CloudWatch Synthetics Canaries

12 Chapter 12: Event-Driven Incident Detection & Notification Pipelines

12.1 AWS Health, CloudTrail Events & Operational Notification 12.2 EventBridge Event Routing, Patterns & Multi-Account Buses 12.3 Asynchronous Event Processing: SNS, SQS Queues & Dead-Letter Handling

13 Chapter 13: Automated Remediation & Deployment Troubleshooting

13.1 AWS Config Managed Rules & Automated Remediation with SSM 13.2 Event-Driven Infrastructure Self-Healing with Lambda & Step Functions 13.3 Troubleshooting CI/CD Pipeline & Deployment Failures 13.4 Root Cause Analysis for Auto Scaling & Container Failures

14 Chapter 14: Identity, Access Management & Secrets at Scale

14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies 14.2 IAM Permissions Boundaries & Delegated Administration 14.3 IAM Identity Center, Cross-Account Roles & STS Session Policies 14.4 Automated Secrets Management & Secret Rotation with Secrets Manager

15 Chapter 15: Security Automation, Data Protection & Compliance Auditing

15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF 15.2 Cryptographic Controls & Key Management with AWS KMS & ACM 15.3 Automated Threat Detection: GuardDuty, Inspector & Security Hub 15.4 Continuous Compliance Auditing & Log Integrity with CloudTrail & Config

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

Key Takeaways Explain This Topic AI

Amazon Aurora Global Database uses dedicated storage-level physical replication across regions over the AWS private backbone, achieving typical replication lag of under 1 second without database compute engine overhead.

Aurora Global Database uses a zero-data-loss switchover for planned events and a managed failover for unplanned outages. Failover RPO is normally nonzero and measured in seconds, and RTO is in the order of minutes.

Amazon DynamoDB Global Tables provide multi-active, multi-Region replication using DynamoDB Streams and resolve concurrent write conflicts across regions using the Last-Write-Wins (LWW) timestamp rule.

Current DynamoDB global tables synchronize capacity mode, provisioned write capacity, and write auto scaling across replicas. Each provisioned Region can still scale independently within those shared settings, so monitor throttling and ReplicationLatency.

S3 CRR requires versioning, can use Replication Time Control, and needs explicit KMS permissions for encrypted objects. In cross-account destinations, prefer Bucket owner enforced Object Ownership or configure the legacy owner override.

Last updated: September 2026

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

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.

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 .

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.

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:

Operation Operational Context Data Loss (RPO) Recovery Time (RTO) Operational Workflow

Switchover (formerly managed planned failover) Planned drills, maintenance, or Region rotation while all clusters are healthy RPO = 0 because Aurora synchronizes the target before role reversal In the order of minutes; measure for the workload Use switchover-global-cluster to promote the target and demote the old primary while retaining the global topology

Managed failover Unplanned outage where the primary is unavailable Normally nonzero and measured in seconds because replication is asynchronous In the order of minutes; depends on lag and application reconnection Use failover-global-cluster --allow-data-loss to promote a secondary without waiting for synchronization; Aurora rebuilds the old primary storage when it recovers

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:

The mutation is recorded immediately in that region's DynamoDB Stream.

The Global Tables replication engine reads the stream record and asynchronously applies the update to replica tables in all other designated regions.

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.

Loading diagram... Cross-Region Stateful Replication Architecture

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

S3 Versioning : Versioning must be explicitly enabled on both the source bucket and destination bucket.

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.

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.