Beyond Backups: What a Real AWS S3 Disaster Recovery Plan Looks Like

Sailesh Ramesh

5 min read

·

Jul 20, 2026

--

Listen

Share

In a multi-region architecture, safeguarding your data requires moving beyond standard backups to an active resilience strategy. This article provides a hands-on guide to building a bulletproof AWS S3 disaster recovery plan using Cross-Region Replication (CRR) policies and Multi-Region Access Points (MRAP) for seamless failover. Walk through the exact implementation steps and learn how to run a controlled DR simulation to validate your setup before a real outage strikes.

Press enter or click to view image in full size

Strategy 1: Same-Account, Cross-Region (us-east-2 → us-west-1)

Protects against: regional AWS outage, regional data corruption, region-level disaster.

Architecture

• Source bucket in us-east-2, destination bucket in us-west-1, same account
• Versioning enabled on both buckets (mandatory prerequisite for replication)
• S3 Cross-Region Replication (CRR) rule, ideally with Replication Time Control (RTC) enabled → gives you a 15-minute replication SLA with CloudWatch metrics
• S3 Multi-Region Access Point (MRAP) created over both buckets, giving your application one global endpoint/ARN instead of hardcoding a bucket+region
• MRAP has a built-in failover control API — this is your actual “flip the switch” mechanism during a disaster

Setup Steps

1. Enable versioning on the us-east-2 source bucket.
2. Create the us-west-1 destination bucket, enable versioning on it.
3. Create an IAM replication role with s3:ReplicateObject, s3:ReplicateDelete, s3:ReplicateTags, s3:GetReplicationConfiguration on source, and s3:ReplicateObject, s3:ObjectOwnerOverrideToBucketOwner on destination.
4. Create the CRR replication rule on the source bucket, target = us-west-1 bucket, enable RTC.
5. Create an S3 Multi-Region Access Point spanning both buckets (aws s3control create-multi-region-access-point).
6. Point your application/SDK at the MRAP alias (e.g., mfzwi23gnjvgw.mrap global endpoint) instead of the direct bucket endpoint — this is the step teams often skip and then can't actually fail over cleanly.
7. Enable CloudWatch replication metrics: BytesPendingReplication, OperationsPendingReplication, ReplicationLatency.
8. Set up EventBridge rules on S3 Replication events → SNS/Slack alert on replication failures.
9. Document RPO (≈15 min with RTC) and RTO (time to execute failover control + app validation — typically target under 30 min).

Failover (Activation) Steps

1. Confirm the disaster is region-scoped (check AWS Health Dashboard / Personal Health Dashboard).
2. Check replication lag metrics — know how much data (if any) hasn’t replicated yet (this is your potential data loss window).
3. Submit an MRAP failover control request routing traffic away from us-east-2 toward us-west-1 (aws s3control submit-multi-region-access-point-routes).
4. Confirm application is reading/writing successfully via MRAP against us-west-1.
5. Run smoke tests against critical read/write paths.
6. Monitor and log the actual time taken (for RTO tracking).

Failback Steps

1. Once us-east-2 recovers, check for any writes made against us-west-1 during the incident.
2. Re-sync those objects back to us-east-2 (temporary reverse replication rule, or scripted copy using S3 Batch Operations).
3. Verify object counts/checksums match between buckets.
4. Submit MRAP failover control request to route back to us-east-2.
5. Disable the temporary reverse replication rule once confirmed in sync.

Edge Cases to Consider While Performing DR

• Add the reverse (west→east) replication rule; in case of failure in regions, there might be data loss.
• If this bucket has pre-existing data, schedule an S3 Batch Replication backfill job.
• Audit every consumer of this bucket to confirm they use the MRAP ARN, not a hardcoded bucket name.
• If SSE-KMS is in play, set up a destination-region KMS key + key policy now.

Cost Components for This Setup

• Replica storage — you have to pay for full second copy
• Inter-region data transfer — ~ $0.02/GB
• MRAP data routing — $0.0033 per GB processed

Strategy 2: Cross-Account, Same Region (us-east-2 → us-east-2, separate DR account)

Protects against: account compromise, ransomware/malicious deletion, insider threat, accidental account lockout/suspension — not regional failure, since it’s the same region.

Architecture

• Destination bucket lives in a separate AWS account (the “DR account”), same region us-east-2
• Same-Region Replication (SRR) rule, cross-account destination
• Destination bucket owned/controlled by DR account (ownership override so the source account can’t later reach in and delete replicas)
• Object Lock (Compliance mode) on the DR bucket — this is the key control; even a fully compromised primary account’s credentials can’t delete or overwrite these objects
• Delete marker replication disabled — a delete in the primary account must never propagate to the DR copy
• DR account access is deliberately isolated: separate IAM users/roles, MFA-enforced, “break-glass” credentials stored outside the blast radius of the primary account (e.g., a separate secrets vault, not shared secret store)

Setup Steps

1. Provision the DR AWS account (if not already), with its own root/IAM structure — do not let it trust the primary account’s IAM roles broadly.
2. Create the destination bucket in us-east-2 under the DR account. Enable versioning and Object Lock at bucket creation (Object Lock can’t be added after the fact).
3. Set Object Lock to Compliance mode with a retention period matching your recovery/compliance needs (e.g., 90–365 days).
4. Set the destination bucket policy to allow s3:ReplicateObject and s3:ObjectOwnerOverrideToBucketOwner from the source account's replication role ARN only.
5. In the source account, create the replication IAM role, and configure the SRR rule with: Destination = DR account bucket, Ownership override → destination account, DeleteMarkerReplication → Disabled
6. Enable replication metrics + EventBridge alerts for replication failures.
7. Store DR account break-glass credentials somewhere the primary account admin can’t touch (separate password manager vault, or a physically secured location) — if the same person/system that got compromised can reach the DR credentials, this control is worthless.
8. Schedule quarterly access reviews of the DR account’s IAM policies and users.

Disaster Simulation / Testing Plan

For Strategy 1 (regional failover)

1. Replication health check (routine, automated): upload a test object to us-east-2, poll us-west-1 until it appears, confirm within RTC’s 15-min SLA. Alert if it isn’t.
2. MRAP failover dry run: during a maintenance window, submit a failover-control request to shift traffic to us-west-1, run your app’s smoke test suite against the MRAP endpoint, then fail back. Time the whole thing — this is your measured RTO.
3. Simulated region unreachability: temporarily block your app’s network path to the us-east-2 S3 endpoint (e.g., via a security group/NACL rule or a feature flag that forces the SDK to the us-west-1 endpoint) and confirm the app degrades gracefully and alerts fire.
4. Chaos/game day: a scheduled, larger exercise — actually fail over, have the on-call team execute the runbook cold (no prior rehearsal that day), measure real-world RTO vs. target, then fail back and do a retro.
5. Tabletop exercise: walk the team through the runbook verbally without executing, to catch gaps in documentation/roles before doing a live game day.

Quick RTO/RPO comparison for your plan doc later

Press enter or click to view image in full size

Thank you for reading so far! Feel free to contact me on LinkedIn

Best Regards, Sailesh Ramesh