dr aws multi-region claude-curated
Replicating data and traffic across AWS regions is the foundation of any DR strategy that needs to survive a region-scoped failure. The mechanics differ per service; the considerations (cost, consistency, failover) generalise.
RDS and Aurora
RDS cross-region read replicas
- Available for MySQL, MariaDB, Postgres, Oracle.
- Asynchronous logical replication.
- Replica can be promoted to primary on disaster (manual operation; not automatic).
- Replication lag is typically seconds but spikes during heavy writes; RPO is “however far behind the replica is at the moment of failure”.
- Built for cross-region.
- Sub-second replication lag using the Aurora storage layer (not logical).
- One primary region (read/write), up to five secondary regions (read-only).
- Managed planned failover (under a minute) and unplanned failover (typically 1–2 minutes RTO).
- The right choice when both RPO and RTO need to be in the seconds-to-minutes range for a relational workload.
S3
Cross-Region Replication (CRR)
- Asynchronous, eventual.
- Requires versioning enabled on both source and destination S3 buckets.
- Replication time is typically seconds to minutes; SLA available via S3 Replication Time Control (RTC) — 99.99% within 15 minutes.
- Supports replicating delete markers (or not) and existing objects (with batch operations).
- Can replicate to multiple destinations (multi-destination replication).
S3 replication is one-way by default. For active-active S3, configure two-way replication with care to avoid loops (replication itself does not re-replicate).
DynamoDB
- Multi-region, multi-active across DynamoDB regions.
- Writes accepted in any region; replicated to all others, typically within a second.
- Last-writer-wins conflict resolution based on timestamps.
- Genuine active-active — failover is just stop sending traffic to the failed region; no promotion step.
- Watch for: clock skew between regions affecting last-writer-wins, and cost of replicated writes (each replicated write is a billed write in the destination).
Other services
- EBS snapshots — copy across regions on demand or via AWS Backup.
- EFS — replication to another region (one-to-one, async).
- Secrets Manager — multi-region secrets with replicated copies.
- ECR — cross-region replication for container images.
- KMS — multi-region keys for cross-region decryption without re-encrypt.
Considerations
Data egress costs
Inter-region data transfer is the single largest line item for many cross-region DR setups. Pricing varies by region pair but is typically per-GB and meaningful at scale. Continuous replication of a high-write workload can cost more in transfer than the underlying storage.
Mitigations: compress before replicating, replicate only what’s needed (some buckets, some prefixes), and right-size the secondary region capacity if it never serves traffic.
Consistency
Most cross-region replication is asynchronous and eventually consistent. Application code must tolerate stale reads on secondary regions. Anything that depends on strict read-after-write across regions needs synchronous replication (Aurora Global write-forwarding, or single-writer architectures).
Latency
Inter-region round-trip is tens to hundreds of milliseconds. Designs that synchronously hit a remote region per request will have user-visible latency. Move read-heavy paths to local replicas; keep writes either local or batched.
Regulatory / data residency
GDPR, regional data laws, contractual restrictions. Replicating personal data into another region can be a breach if not permitted. Encode the constraint in the replication rule (e.g. exclude certain prefixes), not in a wiki page nobody re-reads. See Anonymization Patterns for handling regulated data.
Active-active vs active-passive
Active-passive — primary region serves all traffic; secondary is a hot standby. Failover is a deliberate cutover. Simpler, cheaper, but RTO = cutover time.
Active-active — both regions serve traffic concurrently. No cutover; failed region is removed from rotation. Higher cost, but RTO approaches zero. Requires:
- Stateless or globally-replicated state.
- Conflict resolution for any data that can be written in both regions.
- Routing logic (latency-based, geolocation, or weighted DNS).
Most workloads should start active-passive and graduate only when the latency or RTO benefits justify the complexity. Active-active is not a free upgrade — it’s a different architecture.
Failover mechanics
- Health checks ping the primary endpoint at intervals.
- On failure, DNS records flip to the secondary (failover routing policy).
- DNS TTL determines how quickly clients see the change. A 60-second TTL is standard; shorter is possible but increases query volume.
- Real-world failover time = health-check interval × failures threshold + TTL + client cache behaviour. Often 2–5 minutes end to end.
Manual cutover vs automatic
- Automatic failover — fast, but risks flapping and split-brain. Best for stateless tiers and managed services with built-in arbitration.
- Manual cutover — operator decides, runs runbook, verifies. RTO bounded by human reaction time, but avoids unnecessary failovers and gives a chance to verify data integrity. Required for split-brain-prone systems (e.g. promoting a relational replica when the primary may still be alive). See Database Migration Patterns and AWS DMS for promotion mechanics.
The pragmatic answer is often automatic for the load balancer and CDN tier, manual for the database tier. See Multi-Failure Defence Patterns and AWS Backup vs PITR for the broader strategy.