Disaster Recovery & Migrations

1. What disaster recovery means

The deck’s definition is deliberately wide: a disaster is any event at all that damages a company’s business continuity or its finances. Disaster recovery (DR) is then the work of preparing for such an event and of recovering once it has happened. It is not a service you switch on; it is an architectural decision about how much data you are willing to lose and how long you can afford to be down.

The deck separates three kinds of DR by where the two sides live:

Setup	Character
On-premises to on-premises	Traditional DR, and very expensive
On-premises to AWS Cloud	Hybrid recovery
AWS Cloud Region A to AWS Cloud Region B	Entirely inside AWS

Before choosing between them you need two numbers.

RPO and RTO

Picture the disaster as a point on a timeline. RPO (Recovery Point Objective) sits before it and measures the data loss you accept: the gap between the disaster and the last good recovery point. RTO (Recovery Time Objective) sits after it and measures the downtime you accept: how long until the system is serving again.

• A smaller RPO means backing up or replicating more often, which costs more.
• A smaller RTO means keeping more of the target environment warm, which also costs more.

Exam tip

Do not mix the two up. RPO looks backwards and is measured in lost data; RTO looks forwards and is measured in lost time. A question that says “we can lose at most 15 minutes of transactions” is setting an RPO; one that says “we must be back within an hour” is setting an RTO.

2. The four disaster recovery strategies

The deck lists four strategies, ordered by faster RTO:

1. Backup and Restore
2. Pilot Light
3. Warm Standby
4. Hot Site / Multi Site Approach

They are the same ladder seen from cost: the further down the list, the more you keep running, the faster you recover, and the more you pay.

Backup and Restore

This is the high RPO end. Nothing is running on the recovery side; you are just making sure the data exists somewhere else. From a corporate data center the data moves into AWS with AWS Storage Gateway or AWS Snowball, landing in Amazon S3 and aging into Glacier through a lifecycle policy. Inside AWS, scheduled regular snapshots cover EBS snapshots, RDS, Redshift and AMIs. When disaster strikes you restore from those artifacts into Amazon EC2 and Amazon RDS.

Pilot Light

A small version of the app is always running in the cloud, covering the critical core — this is the pilot light. It is very similar to Backup and Restore but faster, because the critical systems are already up. In the deck’s picture, RDS is running and receiving data replication from the corporate data center while EC2 is not running; Route 53 points traffic at whichever side is live.

Warm Standby

Here nothing is missing — every part of the system is already running — but everything is sized as small as it will go. The disaster is what triggers the scale-up to production load. On the AWS side that means an ELB in front of an EC2 Auto Scaling group at its minimum, with an RDS Secondary running and fed by data replication from the primary DB behind the on-premises reverse proxy and app server. Route 53 performs the failover.

Multi Site / Hot Site Approach

Very low RTO — minutes or seconds — and very expensive. Full production scale runs on AWS and on-premises at the same time, active-active, with Route 53 spreading traffic across both and failing over instantly. The AWS side carries a full ELB + EC2 Auto Scaling at production size and an RDS secondary running under continuous replication.

All AWS Multi Region

The same hot-site idea without any on-premises footprint: two AWS Regions, each with an ELB and an EC2 Auto Scaling group at production size, Route 53 in front doing active-active with failover, and Aurora Global holding the primary in one Region and the secondary in the other with data replication between them.

Real-world example

A payments platform runs Pilot Light for years — the database replicates continuously, the application fleet is defined but not running. The week before a regulatory audit they start the fleet at minimum size, which converts the same architecture into Warm Standby without redesigning anything. The ladder is a dial, not four separate systems.

3. Disaster recovery tips

The deck closes the DR half with a checklist grouped into five areas.

Backup

• EBS Snapshots, RDS automated backups and snapshots, and similar per-service backups.
• Regular pushes to S3 / S3 IA / Glacier, with a Lifecycle Policy and Cross Region Replication.
• From on-premises: Snowball or Storage Gateway.

High Availability

• Use Route 53 to migrate DNS over from Region to Region.
• RDS Multi-AZ, ElastiCache Multi-AZ, EFS, S3.
• Site-to-Site VPN as a recovery path from Direct Connect.

Replication

• RDS Replication (Cross Region) and AWS Aurora + Global Databases.
• Database replication from on-premises to RDS.
• Storage Gateway.

Automation

• CloudFormation / Elastic Beanstalk to re-create a whole new environment.
• Recover or reboot EC2 instances with CloudWatch if alarms fire.
• AWS Lambda functions for customized automations.

Chaos

• Netflix has a “simian-army” that randomly terminates EC2 instances — the point being that a recovery plan you never exercise is not a plan.

4. DMS — Database Migration Service

AWS DMS migrates databases to AWS quickly and securely, and is resilient and self-healing. Its defining property is that the source database remains available during the migration, which is what makes it usable on production systems.

It supports:

• Homogeneous migrations — for example Oracle to Oracle.
• Heterogeneous migrations — for example Microsoft SQL Server to Aurora.
• Continuous Data Replication using CDC (Change Data Capture).

One operational detail that shows up in exam answers: you must create an EC2 instance to perform the replication tasks. DMS is not entirely serverless in this model — there is a replication instance you size and pay for.

Sources and targets

Sources	Targets
On-premises and EC2-hosted databases: Oracle, MS SQL Server, MySQL, MariaDB, PostgreSQL, MongoDB, SAP, DB2	On-premises and EC2-hosted databases: Oracle, MS SQL Server, MySQL, MariaDB, PostgreSQL, SAP
Azure: Azure SQL Database	Amazon RDS
Amazon RDS, including Aurora	Redshift, DynamoDB, S3
Amazon S3	OpenSearch Service
DocumentDB	Kinesis Data Streams, Apache Kafka
	DocumentDB and Amazon Neptune
	Redis and Babelfish

The asymmetry is worth noticing: the target list includes analytics and streaming destinations that are not databases in the usual sense, so DMS doubles as an ingestion tool.

AWS Schema Conversion Tool (SCT)

SCT converts a database’s schema from one engine to another.

• OLTP example: SQL Server or Oracle to MySQL, PostgreSQL, Aurora.
• OLAP example: Teradata or Oracle to Amazon Redshift.
• Prefer compute-intensive instances to optimize the data conversions.

The rule the exam tests: you do not need SCT if you are migrating to the same DB engine. Moving on-premises PostgreSQL to RDS PostgreSQL keeps the engine PostgreSQL — RDS is only the platform.

In a full continuous-replication setup the two tools work together: a server with AWS SCT installed does the schema conversion, while the AWS DMS Replication Instance in a public subnet performs the data migration with full load + CDC from the on-premises Oracle DB (source) into the Amazon RDS for MySQL DB (target) in a private subnet.

Exam tip

Same engine means DMS alone. Different engine means DMS plus SCT. If an answer offers SCT for a PostgreSQL-to-PostgreSQL move, it is the distractor.

DMS Multi-AZ deployment

Enable Multi-AZ and DMS stands up a synchronous standby replica in another Availability Zone, then keeps it there for you. The advantages listed are data redundancy, eliminating I/O freezes and minimizing latency spikes — so it is a performance feature as much as an availability one.

5. Migrating into RDS and Aurora

RDS & Aurora MySQL

RDS MySQL to Aurora MySQL

• Option 1: take DB Snapshots from RDS MySQL and restore them as an Aurora MySQL DB.
• Option 2: create an Aurora Read Replica from the RDS MySQL instance and, when the replication lag is 0, promote it as its own DB cluster. This can take time and cost money.

External MySQL to Aurora MySQL

• Option 1: use Percona XtraBackup to create a file backup in Amazon S3, then create an Aurora MySQL DB from Amazon S3.
• Option 2: create an Aurora MySQL DB and use the mysqldump utility to migrate into it — slower than the S3 method.
• Use DMS if both databases are up and running.

RDS & Aurora PostgreSQL

RDS PostgreSQL to Aurora PostgreSQL follows the same two options: restore a DB Snapshot as an Aurora PostgreSQL DB, or create an Aurora Read Replica and promote it when the lag reaches 0 (again, time and cost).

External PostgreSQL to Aurora PostgreSQL: create a backup and put it in Amazon S3, then import it using the aws_s3 Aurora extension. As before, use DMS if both databases are up and running.

Exam tip

“Both databases are up and running” is the phrase that selects DMS. A one-shot move from a database you can take offline is a snapshot restore or an S3 import; a move that must not interrupt service is DMS with CDC.

6. Strategies for moving on-premises systems to AWS

The deck collects the on-premises toolbox on one slide:

• Download the Amazon Linux 2 AMI as a VM in .iso format, for VMware, KVM, VirtualBox (Oracle VM) and Microsoft Hyper-V — so your local hypervisor can run the same image as EC2.
• VM Import / Export — migrate existing applications into EC2, create a DR repository strategy for your on-premises VMs, and export VMs back from EC2 to on-premises.
• AWS Application Discovery Service — gather information about your on-premises servers to plan a migration, including server utilization and dependency mappings, tracked with AWS Migration Hub.
• AWS Database Migration Service (DMS) — replicate on-premises to AWS, AWS to AWS and AWS to on-premises, across various database technologies (Oracle, MySQL, DynamoDB and others).
• AWS Server Migration Service (SMS) — incremental replication of on-premises live servers to AWS.

AWS Application Discovery Service in detail

You plan migration projects by gathering information about on-premises data centers, because server utilization data and dependency mapping are important for migrations. There are two collection modes:

Mode	What it collects
Agentless Discovery (AWS Agentless Discovery Connector)	VM inventory, configuration, and performance history such as CPU, memory and disk usage
Agent-based Discovery (AWS Application Discovery Agent)	How each system is configured and how it performs, which processes are running on it, and which network connections join it to the other systems

The resulting data can be viewed within AWS Migration Hub.

The split is easy to remember by depth: agentless sees the virtual machines from outside, agent-based sees inside them — processes and who talks to whom.

AWS Application Migration Service (MGN)

The deck calls MGN the “AWS evolution” of CloudEndure Migration, and it is what AWS Server Migration Service (SMS) was replaced by. The approach is lift-and-shift, or rehost: servers you already have — physical, virtual or already in some cloud — are converted so they run natively on AWS, which takes most of the difficulty out of moving an application over. Its reach across platforms, operating systems and databases is broad, and the payoff the deck advertises is minimal downtime and a lower bill.

Mechanically, an AWS Replication Agent installed on the source servers — in a corporate data center or any cloud — performs continuous replication of the disks, OS, apps and DB into a staging area of low-cost EC2 instances and EBS volumes. At cutover, that staging area becomes the target EC2 instances and EBS volumes in production.

Exam tip

If a question names SMS as the answer for a new migration, treat it with suspicion: MGN is the replacement. Discovery Service plans the migration, MGN performs it, and Migration Hub is where you watch it.

7. AWS Backup

AWS Backup is fully managed, and its purpose is to put backup policy for many AWS services in one place and run it automatically — which is precisely what removes the custom scripts and hand-driven procedures teams otherwise accumulate.

Supported services:

• Amazon EC2 / Amazon EBS
• Amazon S3
• Amazon RDS (all DB engines) / Amazon Aurora / Amazon DynamoDB
• Amazon DocumentDB / Amazon Neptune
• Amazon EFS / Amazon FSx (Lustre & Windows File Server)
• AWS Storage Gateway (Volume Gateway)

It supports cross-region backups and cross-account backups, which is exactly what a DR plan needs.

Other capabilities: PITR (point-in-time recovery) for supported services, on-demand and scheduled backups, and tag-based backup policies.

Backup Plans

You express the policy as a Backup Plan:

Setting	Options
Backup frequency	Every 12 hours, daily, weekly, monthly, or a cron expression
Backup window	The window in which backups may run
Transition to Cold Storage	Never, Days, Weeks, Months, Years
Retention Period	Always, Days, Weeks, Months, Years

The workflow is two steps: create the Backup Plan (frequency, retention policy), then assign AWS resources to it — EC2, EBS, RDS, DynamoDB, EFS, Aurora, FSx, Storage Gateway, DocumentDB, Neptune. Everything is then automatically backed up to Amazon S3.

AWS Backup Vault Lock

Turn Backup Vault Lock on and everything sitting in that AWS Backup Vault falls under a WORM (Write Once Read Many) regime. The deck frames it as one more layer of defense, and it closes two specific holes:

• deletes, whether someone did it by accident or on purpose;
• edits to the retention period that would shorten it or otherwise change it.

The part that makes it worth an exam question: with the lock in place, not even the root user can delete a backup.

Exam tip

“Even the root user cannot delete it” is the signature of a lock feature. When a question asks how to guarantee backups survive a compromised administrator account, Backup Vault Lock is the answer — not IAM policies, which the same administrator could change.

8. VMware Cloud on AWS

Some customers use VMware Cloud to manage their on-premises data center and want to extend that capacity to AWS while continuing to use the VMware Cloud software. VMware Cloud on AWS exists for exactly that: an on-premises vCenter manages a vSphere-based environment, and the same vSphere tooling manages workloads running on AWS, which in turn reach Amazon EC2, Amazon S3, Direct Connect, Amazon FSx, Amazon RDS and Amazon Redshift.

The use cases named are:

• Migrate VMware vSphere-based workloads to AWS.
• Run production workloads across VMware vSphere-based private, public and hybrid cloud environments.
• Have a disaster recovery strategy.

9. Transferring a large amount of data into AWS

The deck closes with an arithmetic exercise that makes the choice obvious. The scenario: transfer 200 TB of data into the cloud over a 100 Mbps internet connection.

Path	Setup time	Transfer time
Over the internet / Site-to-Site VPN	Immediate	200 × 1000 × 1000 × 8 / 100 Mbps = 16,000,000 s ≈ 185 days
Over Direct Connect 1 Gbps	Long — over a month for the one-time setup	200 × 1000 × 8 / 1 Gbps = 1,600,000 s ≈ 18.5 days
Over Snowball	—	About 1 week end to end, and can be combined with DMS

For ongoing replication or transfers, the answer is different again: Site-to-Site VPN or Direct Connect, with DMS or DataSync.

Real-world example

The pattern most media archives end up with is both: Snowball moves the historical petabytes once, then DataSync over Direct Connect keeps the daily deltas flowing. One-time bulk and steady-state sync are separate problems with separate tools.

Quick recap

Topic	What to remember for the exam
RPO vs RTO	RPO = how much data you lose (before the disaster); RTO = how long you are down (after it)
DR strategies	Faster RTO in order: Backup and Restore, Pilot Light, Warm Standby, Hot Site / Multi Site
Pilot Light	RDS running, EC2 not running — the critical core only
Warm Standby	Whole system running at minimum size, scaled up on disaster
Hot Site	Full production scale on both sides, active-active, minutes or seconds of RTO, very expensive
All AWS Multi Region	Route 53 plus Aurora Global (primary and secondary) for a hot site entirely inside AWS
DMS	Source stays available, homogeneous and heterogeneous, CDC for continuous replication, needs an EC2 replication instance; Multi-AZ adds a synchronous standby
SCT	Only needed when the engine changes; PostgreSQL to RDS PostgreSQL needs no SCT
Into Aurora	DB Snapshot restore, or Aurora Read Replica promoted at lag 0; from outside via S3 (Percona XtraBackup for MySQL, aws_s3 extension for PostgreSQL) or mysqldump (slower)
Application Discovery Service	Planning: agentless = VM inventory and performance history; agent-based = processes and network connections; results in Migration Hub
Application Migration Service (MGN)	Lift-and-shift rehost, replaces SMS, continuous replication into a low-cost staging area, then cutover
AWS Backup	Central, automated backups across many services, cross-region and cross-account, PITR, tag-based policies, Backup Plans with retention and cold storage
Backup Vault Lock	WORM — blocks deletes and retention changes, even for the root user
VMware Cloud on AWS	Keep using vSphere tooling while extending the data center into AWS; also a DR strategy
200 TB transfer	Internet at 100 Mbps ≈ 185 days, Direct Connect 1 Gbps ≈ 18.5 days, Snowball ≈ 1 week; ongoing sync uses VPN or DX with DMS or DataSync