AWS Disaster Recovery - Backup Restore, Pilot Light, Warm Standby, Multi-Site

What you will learn

• What constitutes a disaster in AWS terms — it is not just earthquakes and fires
• RPO and RTO — the two numbers that define your entire DR strategy and budget
• The four DR strategies — Backup and Restore, Pilot Light, Warm Standby, Multi-Site
• Exactly when each strategy makes sense and what it costs relative to alternatives
• AWS Elastic Disaster Recovery (DRS) — continuous block-level replication and the Staging vs Production area design
• AWS Database Migration Service (DMS) — homogeneous and heterogeneous migrations with CDC
• Aurora migration paths — Snapshot, Read Replica, Percona XtraBackup, and mysqldump
• On-premises strategy tools — VM Import, Application Discovery Service, MGN
• AWS Backup — centralised backup across all services, Vault Lock, and WORM protection
• How to choose between internet, Direct Connect, and Snowball for large data transfers

Why this matters

When a production database crashes at 2 AM or a ransomware attack encrypts an entire on-premises data center, the difference between 5 minutes of downtime and 5 days of downtime is whether you designed your DR architecture before the disaster — not during it. At Razorpay, payment processing must resume within minutes of any incident — that SLA requires a Warm Standby or better. At a company with RBI compliance requirements, data must be recoverable within a defined window. These are not theoretical exercises. RPO and RTO are commitments made to the business, and every architecture decision is a direct trade-off between cost and how well those commitments can be kept.

What is a Disaster

Any event that negatively impacts business continuity or finances qualifies as a disaster. It does not have to be an earthquake or a fire.

RPO and RTO — The Two Numbers That Define Everything

Before picking any DR strategy, two numbers must be confirmed in writing from the business.

RPO (Recovery Point Objective) — how much data loss is acceptable:

RTO (Recovery Time Objective) — how much downtime is acceptable:

DR works across three environments:

DR Strategy 1 — Backup and Restore

The cheapest and simplest strategy. Highest RPO and RTO of all four options. Nothing runs in AWS during normal times except stored backups.

Common Mistake

Teams set snapshot frequency to once per day because it is the default, then discover their RPO is actually 24 hours — meaning they can lose an entire day of transactions. Set backup frequency based on your actual RPO requirement, not the default.

DR Strategy 2 — Pilot Light

Faster than Backup and Restore because the most critical and hardest-to-restore component — the database — is always running in AWS and always in sync. Only the application server is stopped.

Remember

In Pilot Light, the DB is always running (most critical, hardest to restore). The EC2 is stopped (cheapest to keep off). Backup and Restore restores everything from scratch. Pilot Light already has the DB live — so recovery is measured in minutes instead of hours.

DR Strategy 3 — Warm Standby

The entire stack runs in AWS at minimum size, not just the database. Nothing needs to start — only scales up. This dramatically reduces RTO.

Pilot Light vs Warm Standby:

DR Strategy 4 — Multi-Site and Hot Site

The most expensive and fastest strategy. Both on-premises and AWS run at full production scale simultaneously. Route 53 actively sends real traffic to both at the same time.

All AWS Multi-Region follows the same pattern without on-premises:

Aurora Global handles cross-region replication automatically with sub-second lag.

DR Strategy Comparison:

AWS Elastic Disaster Recovery (DRS)

Previously called CloudEndure Disaster Recovery. Continuously replicates your physical, virtual, or cloud-based servers into AWS so you can recover in minutes when disaster hits.

Why two areas — Staging and Production:

You do not want to pay for full production EC2 instances 24 hours a day just waiting for a disaster. DRS splits into two areas:

Full DRS flow:

DRS vs MGN:

AWS Database Migration Service (DMS)

DMS migrates databases to AWS quickly and securely — and the source database stays available and running throughout. No downtime for users. Self-healing — if the migration fails midway, it recovers automatically.

You must create an EC2 instance to run DMS — it sits between source and target and does all the migration work. DMS is not serverless.

Two types of migration:

AWS Schema Conversion Tool (SCT):

Remember

You do NOT need SCT if migrating the same engine. On-premises PostgreSQL to RDS PostgreSQL — schema stays identical. SCT is only needed when the engine type itself changes.

CDC — Continuous Data Capture:

DMS uses CDC to continuously capture and replicate every new change from source to target while migration is in progress.

DMS Multi-AZ Deployment:

Aurora Migration Paths

When your source is RDS MySQL or PostgreSQL, two paths exist that do not require DMS.

Option 1 — Snapshot (simplest, one-time move):

Option 2 — Read Replica (stay in sync during migration):

External MySQL to Aurora:

AWS Backup — Centralised Backup Management

Before AWS Backup you configured backups inside each service separately — RDS had its own backup settings, EBS had snapshots, DynamoDB had its own configuration. No central visibility or policy.

AWS Backup centralises all of this — one managed service to automate and manage backups across every supported service.

Supported services:

Backup Plans — what you configure:

Tag-based backup policies:

Assign a tag (e.g. backup: daily) to any resource and AWS Backup automatically includes it in the matching plan. No need to manually add each resource.

Additional features:

AWS Backup Vault Lock:

A backup that can be deleted is not a real backup. Ransomware attackers target backup systems first precisely because deleting backups forces companies to pay.

Security

Backup Vault Lock is one of the very few AWS controls that even the root user cannot override. Once enabled, plan your retention policies carefully before turning it on — you cannot shorten or change them after.

Transferring Large Amounts of Data into AWS

Real scenario: transfer 200 TB from on-premises into AWS. You have a 100 Mbps internet connection.

Option 1 — Internet or Site-to-Site VPN:

Option 2 — Direct Connect (1 Gbps):

Option 3 — Snowball:

For ongoing replication after the initial transfer, use Site-to-Site VPN or Direct Connect with DMS or DataSync.

Quick decision:

Hands-on Lab — AWS Backup with Vault Lock and Cross-Region Snapshot

Step 1 — Create a Backup Vault

Step 2 — Create a Backup Plan

Step 3 — Assign resources to the backup plan

Step 4 — Run an on-demand backup

Step 5 — Enable Vault Lock (WORM protection)

Step 6 — Enable CloudTrail to audit all backup actions

Step 7 — Cleanup

Production Best Practices and Common Pitfalls

• Choose the DR strategy based on confirmed RPO and RTO numbers — never design DR without these numbers agreed in writing with the business
• Test your DR plan quarterly — run the full failover procedure including EC2 startup, database connectivity, and application health checks
• Use AWS Backup instead of per-service manual backup configuration — central visibility prevents the common mistake of some services having no backup policy
• Enable Backup Vault Lock for compliance-sensitive workloads — ransomware that cannot delete your backups cannot force you to pay
• Use Snowball for large initial data transfers to AWS — attempting 100 TB over the internet wastes months
• Run the Pilot Light EC2 in a stopped state but test startup time regularly — a stopped EC2 with a complex startup script might take 20 minutes instead of 2

Quick Reference and Troubleshooting Commands

Common problems and fixes:

Common Mistake

Choosing Backup and Restore when the actual RPO requirement is 30 minutes. Daily snapshots give RPO of up to 24 hours. If the business needs 30-minute RPO, you need Pilot Light with a continuously syncing database — not daily snapshots in S3. Always get RPO and RTO confirmed in writing before designing anything.

Common Mistake

Enabling Backup Vault Lock without testing retention policies first. Once WORM is applied, nobody — not even root — can delete a backup before the minimum retention period. If you set a 7-day minimum and need to delete a backup for compliance reasons before then, you cannot. Test in a non-production vault first.

Security

DMS requires an EC2 instance to run and is billed for the entire time migration is running. For long-running CDC migrations lasting weeks or months, this EC2 cost adds up. Size the Replication Instance correctly for your data volume — too small causes migration lag and data accumulation, too large wastes money.

Common Mistakes to Avoid

Common Mistake

Setting automated backup retention to 0 days. This disables PITR entirely. If a developer accidentally truncates a production table, there is nothing to restore from. Always keep retention at minimum 7 days for production databases.

Common Mistake

Choosing Backup and Restore when RPO is 30 minutes. Daily snapshots give up to 24 hours of data loss. For 30-minute RPO you need Pilot Light with a continuously syncing database. Always confirm RPO and RTO numbers in writing before designing anything.

Security

Enable Backup Vault Lock for compliance workloads. Ransomware attackers target backups first — deleting your backups forces you to pay. Vault Lock WORM protection means even root cannot delete backups before the minimum retention period.