← all posts

AWS Migration And Disaster Recovery Patterns

May 19, 2025
AWS Migration And Disaster Recovery Patterns

Migration and disaster recovery are related, but they are not the same problem. Migration moves workloads. Disaster recovery keeps a recovery path ready when the primary environment fails.

Choosing the right AWS service starts with the phase of the work.

Discovery And Planning

Use discovery tools when the hardest problem is understanding the current estate:

  1. Which servers exist?
  2. Which applications depend on each other?
  3. What utilization and sizing are realistic?
  4. Which migration waves make sense?

Migration Hub and Application Discovery Service help build that picture. Agent-based discovery is stronger for dependency mapping. Agentless discovery is easier when installing agents is not possible.

One mistake I see a lot is using execution tools as if they were discovery tools. MGN is a mover, not a mapper.

Server Migration

AWS Application Migration Service is a common choice for lift-and-shift server migration. It continuously replicates source servers and lets you launch test or cutover instances in AWS.

Use it when the goal is to move machines with minimal application change.

That phrase matters: move machines. If the real requirement is application redesign, data transformation, or domain refactoring, MGN is not the interesting part of the plan.

Disaster Recovery

AWS Elastic Disaster Recovery is designed for DR. It continuously replicates source servers into a staging area and supports recovery launches when needed.

The important distinction is intent. MGN is migration-oriented. DRS is recovery-oriented, including failback patterns.

That is the clean rule I use: if the sentence includes "minute-level RPO" and "failback," you are usually in DRS territory, not DataSync or backup tooling.

Data Movement

Use DataSync when the task is moving file data between on-premises storage and AWS services such as S3, EFS, or FSx. It is operationally simple and works well for scheduled or large file transfers.

Use Snowball when network transfer is impractical because of volume, time, or bandwidth constraints.

The key is to avoid promoting file-transfer tools into system-level recovery tools. DataSync is excellent at moving files. It is not continuous VM replication.

DR Strategy Levels

Common DR patterns include:

  1. Backup and restore.
  2. Pilot light.
  3. Warm standby.
  4. Multi-site active-active.

Cost and recovery speed move together. Backup and restore is cheaper but slower. Active-active is faster but operationally expensive.

Connectivity Matters

Replication traffic may need private connectivity. Direct Connect, VPN, private IP replication settings, and VPC routing must be designed before the DR plan is trusted.

For database migrations, engine compatibility also matters. Same-engine moves such as PostgreSQL to Aurora PostgreSQL can be much simpler than heterogeneous migrations because you may not need schema conversion tooling at all.

The Practical Rule

  1. Unknown estate: discover first.
  2. One-time server move: use migration tooling.
  3. Continuous recovery posture: use DRS.
  4. File transfer: use DataSync.
  5. Too much data for network: use Snowball.

The best migration plan is not the one with the most AWS services. It is the one where cutover, rollback, ownership, and recovery evidence are clear.

;