Architecture, Migration, Hybrid and Disaster Recovery

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

See the section bibliography for the reference material consulted while preparing these pages.

Commands on this page target AWS CLI v2 (2.37 line, command reference checked on 2026-10-01) and use us-east-1 as a placeholder Region, the placeholder account ID 111122223333 and obviously fake identifiers. The migration and disaster-recovery services (mgn, drs, dms, backup, wellarchitected, outposts) are separate CLI namespaces with their own Command Reference pages; the service statuses quoted below were re-read on the official documentation on 2026-10-01, but this is the part of AWS where products are renamed, closed to new customers and merged most often, so check the AWS lifecycle changes page before you commit a plan to a specific tool.

Earlier pages in this section build individual services. This page steps back to the questions that decide whether and how a workload such as Bookshelf should run on AWS at all and how it survives a bad day: how to judge an architecture (the Well-Architected Framework and its Tool), how an organization plans its move (the Cloud Adoption Framework), how existing systems get in (the 7 Rs and the migration services), what to do with systems that cannot leave (hybrid), and how to recover from failure (disaster-recovery strategies and AWS Backup). Choosing a compute service for something already destined for AWS is covered in Choosing a Compute Service; what a design costs is covered in Cost Management and Support; the Azure counterpart of this page is Architecture, Migration and Hybrid Cloud.

export AWS_REGION=us-east-1
export DR_REGION=us-west-2
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

The Well-Architected Framework

The AWS Well-Architected Framework is AWS’s set of design questions and best practices for evaluating a workload. It is organised in six pillars:

Pillar Workload concern

Operational excellence

Running and monitoring systems and continually improving processes: infrastructure as code, small reversible changes, observability, runbooks. See Monitoring and Observability.

Security

Protecting data, systems and assets: identity foundation, traceability, defence in depth, automated protection, encryption. See Identity and Access, Secrets Manager, Parameter Store and KMS and Governance, Security and Compliance.

Reliability

Recovering from failures, scaling to demand and meeting availability goals: foundations and quotas, workload architecture, change management, failure management (backups, replication, DR). Most of this page.

Performance efficiency

Using computing resources efficiently as demand and technology change: choosing the right resource types and sizes, measuring, and trading consistency or durability for speed deliberately. See Choosing a Compute Service.

Cost optimization

Delivering business value at the lowest price point: cloud financial management, matching supply to demand, measuring and attributing spend. See Cost Management and Support.

Sustainability

Minimising the environmental impact of running workloads: higher utilisation, managed services, efficient hardware (for example Graviton) and data lifecycle policies.

Older guides describe five pillars; Sustainability was added later, so the current framework has six. Every pillar contains tradeoffs (multi-Region active/active buys reliability with cost and complexity), so the framework is a lens applied repeatedly, not a checklist to maximise or a one-time gate.

Besides the general framework there are lenses that add technology- or industry-specific questions (for example Serverless Applications, Container Build, SaaS, Generative AI and Financial Services) and custom lenses an organisation can write for its own standards, plus the supporting material in the AWS Architecture Center.

The AWS Well-Architected Tool

The AWS Well-Architected Tool (WA Tool) is a free service in the console that turns the framework into a repeatable review: you define a workload, choose one or more lenses, answer the questions per pillar, and receive a list of high-risk and medium-risk issues with an improvement plan linked back to the relevant guidance. You save milestones to compare answers over time, can share a workload with other accounts, users or an organization, and can integrate Trusted Advisor and Service Catalog AppRegistry to prefill answers from the real environment. The Tool itself has no charge; the resources you build while following its recommendations do.

In the AWS Management Console

  1. Open AWS Well-Architected Tool (search the console, any Region that offers it; workload data lives in the Region where it was created).

  2. Choose Define workload. Enter a name (bookshelf-catalog-api), description, environment Production, the AWS Regions it uses and the review owner.

  3. On the next page pick lenses: keep AWS Well-Architected Framework and add Serverless Applications or Container Build where they apply. Choose Define workload.

  4. Choose Start reviewing and answer each pillar’s questions, ticking the best practices you already follow. Use Notes to record decisions; "Question does not apply" is allowed with a reason.

  5. Open the workload’s Improvement plan to see high-risk issues first and follow the links in each one.

  6. Choose Save milestone after each review round, so progress is visible in Milestones.

With the AWS CLI

aws wellarchitected create-workload \
  --workload-name bookshelf-catalog-api \
  --description "Bookshelf catalog API on ECS and Aurora" \
  --environment PRODUCTION \
  --aws-regions "$AWS_REGION" \
  --lenses wellarchitected serverless \
  --review-owner "platform-team@example.com" \
  --pillar-priorities security reliability cost-optimization \
  --query WorkloadId --output text

# Available lenses and the high-risk items found so far
aws wellarchitected list-lenses --query 'LensSummaries[].[LensAlias,LensName]' --output table
aws wellarchitected list-lens-review-improvements \
  --workload-id "$WORKLOAD_ID" --lens-alias wellarchitected \
  --query 'ImprovementSummaries[?Risk==`HIGH`].[PillarId,QuestionTitle]' --output table

aws wellarchitected create-milestone --workload-id "$WORKLOAD_ID" --milestone-name "2026-Q4-review-1"

Reference: aws wellarchitected create-workload and What is the AWS Well-Architected Tool?.

Other tools complement the review: Trusted Advisor and Compute Optimizer report on the real environment, AWS Resilience Hub continuously assesses whether a workload is likely to meet its RTO and RPO targets, and Application Recovery Controller provides data-plane failover switches (see Disaster recovery strategies).

Design principles that recur in the reliability pillar

  • High availability versus fault tolerance. High availability means the workload keeps serving through the loss of a component, usually by running across several Availability Zones behind a load balancer (see Amazon EC2 and Auto Scaling and Load Balancers and Gateways), with a brief disruption acceptable. Fault tolerance aims for no interruption at all, which costs more and often needs redundant, synchronously replicated components. Decide per workload; most business systems need the first.

  • RTO and RPO. The recovery time objective is how long the workload may be down; the recovery point objective is how much data, measured in time, may be lost. They are business decisions that select the DR strategy below.

  • Idempotency. In a distributed system retries and duplicate deliveries are normal (SQS standard queues deliver at least once). An operation is idempotent when repeating it has the same effect as doing it once. Use natural keys and conditional writes, client tokens on creation APIs, and FIFO deduplication IDs where ordering matters.

  • Retries with backoff and jitter. Retry transient failures, but wait exponentially longer between attempts and add randomness so many clients do not retry in lock step, and cap the attempts. The AWS SDKs do this by default.

# Idempotent order creation: the second identical call fails instead of overwriting
aws dynamodb put-item --table-name Orders \
  --item '{"orderId":{"S":"o-1001"},"status":{"S":"PLACED"}}' \
  --condition-expression "attribute_not_exists(orderId)"
// SDK for Java 2.x: the standard retry strategy (exponential backoff with jitter)
DynamoDbClient dynamo = DynamoDbClient.builder()
        .overrideConfiguration(c -> c
                .retryStrategy(RetryMode.STANDARD)
                .apiCallTimeout(Duration.ofSeconds(10)))
        .build();

Reference: DynamoDB condition expressions and the SDK for Java retry strategies. Tables, limits and Bookshelf’s Orders design are on Amazon DynamoDB; queue semantics on Messaging and Integration.

The Cloud Adoption Framework

Where the Well-Architected Framework judges one workload, the AWS Cloud Adoption Framework (CAF) guides an organization’s move to the cloud. It groups capabilities into six perspectives, three business-facing and three technology-facing:

Perspective Concerned with

Business

Strategy, portfolio, innovation, product management and data and insights: making sure cloud investment serves business outcomes.

People

Culture, change leadership, workforce transformation, skills and organisation design.

Governance

Programme and project management, benefit and risk management, cloud financial management and data governance.

Platform

Platform architecture, data engineering, provisioning and orchestration, modern application development, CI/CD.

Security

Security governance, assurance, identity and access, threat detection, vulnerability, infrastructure and data protection and incident response.

Operations

Observability, event management, incident and problem management, change and release management, performance and capacity management, configuration management and patch management.

CAF recommends moving through iterative transformation phases (Envision, Align, Launch, Scale) rather than a single big-bang migration, and it assumes a landing zone: a governed multi-account foundation (see Accounts and Organizations for Organizations and Control Tower). The framework is maintained as a set of whitepapers; some individual perspective papers carry a "historical reference" banner, so use the CAF overview and the AWS Prescriptive Guidance material as the current entry points.

Migrating to AWS

The 7 Rs

AWS Prescriptive Guidance defines seven migration strategies, the 7 Rs. Older material lists five or six (without Relocate and sometimes without Retain), so check which list a plan uses:

Strategy Meaning Bookshelf-style example

Retire

Decommission or archive the application; shut down its servers.

An unused reporting tool found by discovery (very low CPU and no inbound connections for 90 days).

Retain

Keep it where it is for now (compliance, dependencies, a recent upgrade, unresolved hardware).

A mainframe or plant-floor system with no cloud equivalent.

Rehost

"Lift and shift": move servers as they are, typically with replication tooling.

The on-premises Bookshelf VMs to EC2 with AWS Transform MGN.

Relocate

Move a large group of servers or instances to the cloud version of the same platform, or to another VPC, Region or account, with no re-architecture.

Moving an RDS instance to another account or VPC; moving a VMware estate to its cloud equivalent.

Repurchase

"Drop and shop": replace with a different product, usually SaaS.

Replacing a self-hosted mail server with a managed email service.

Replatform

"Lift, tinker and shift": a few optimisations, such as a managed database or a container.

Self-managed PostgreSQL to Aurora PostgreSQL with DMS; a Tomcat VM to ECS on Fargate.

Refactor / re-architect

Redesign to use cloud-native services.

Splitting a monolith into catalog-api and orders-api services on ECS or Lambda.

For large migrations AWS recommends rehost, relocate, replatform and retire first and modernising after the move, because refactoring during the move is the most complex and costly option. Pick a strategy per application, not per organization.

flowchart TD A["Application in portfolio"] --> B{"Still needed?"} B -- "No" --> RET["Retire"] B -- "Yes" --> C{"Can it move now?"} C -- "No: compliance, hardware, dependency" --> RTN["Retain"] C -- "Yes" --> D{"SaaS equivalent fits?"} D -- "Yes" --> REP["Repurchase"] D -- "No" --> E{"Same platform exists in the cloud?"} E -- "Yes" --> REL["Relocate"] E -- "No" --> F{"Change worth it now?"} F -- "No" --> RH["Rehost: AWS Transform MGN"] F -- "Some" --> RP["Replatform: managed DB, containers"] F -- "A lot" --> RF["Refactor: cloud-native"]

Reference: About the migration strategies.

Migration services and their current status

Names and availability changed substantially in 2025. Older tutorials still point at services that new customers can no longer onboard to.

Service Role Status to know

AWS Transform

An agentic AI service that discovers server inventory, plans application groups and migration waves, builds landing zones, migrates networks, rehosts servers, containerises source code, modernises .NET and mainframe workloads and assesses migration readiness. Used through a web experience with workspaces and connectors.

The current starting point for migration programmes. The user guide states there is no additional charge to use AWS Transform itself; you pay for the resources it creates and for underlying services.

AWS Transform MGN (formerly Application Migration Service)

Continuous block-level replication of physical, virtual and cloud servers to AWS, then test and cutover launches, typically with cutover windows of minutes. Replication, launch and post-launch templates; servers grouped into applications and waves.

Renamed; the console URL and the mgn CLI namespace are unchanged. Older guides call it Application Migration Service (MGN) or CloudEndure.

AWS Migration Hub

A single place to discover servers, group them into applications and track migration status from other tools, with a "home Region" for tracking data.

No longer open to new customers since 2025-11-07; the documentation points to AWS Transform for similar capabilities. Existing customers continue to use it.

AWS Database Migration Service (DMS)

Replicates databases between engines or environments (full load, change data capture, or both); DMS Schema Conversion converts schemas and code; Fleet Advisor inventories on-premises databases.

Current. The standalone AWS Schema Conversion Tool still exists as a downloadable alternative to DMS Schema Conversion.

AWS DataSync

Online transfer of file and object data (NFS, SMB, object stores, S3, EFS, FSx) with scheduling and verification.

Current, and the recommended online alternative for new customers who would previously have ordered Snowball Edge.

AWS Transfer Family

Managed SFTP, FTPS, FTP and AS2 endpoints in front of S3 or EFS.

Current; for partners that insist on file-transfer protocols.

AWS Snow Family

Rugged devices for physical data transfer and edge compute.

Snowball Edge is no longer available to new customers since 2025-11-07; Snowcone and Snowmobile are no longer offered. See Hybrid and edge options.

Reference: What is AWS Migration Hub?, What is AWS Transform MGN?, What is AWS Transform?.

Rehosting servers with AWS Transform MGN

The mechanics are the same under the console and the CLI:

  1. Initialise the service in the target Region (creates the service-linked roles and default templates) and edit the replication settings template (staging-area subnet, replication-server instance type, EBS encryption, data routing over private IPs or the internet) and the launch settings (instance type right-sizing, subnet, security groups, whether to copy tags).

  2. Install the replication agent on each source server. It needs outbound HTTPS to the service endpoints and the staging subnet; the installer authenticates with an IAM identity dedicated to agent installation. Because the agent is an installer outside AWS, treat its credentials as short-lived and delete them after installation, following the guide, rather than reusing an administrator’s keys.

  3. Data replicates continuously. When the server shows Ready for testing, launch a test instance, validate the application, and mark the test finished.

  4. At the agreed window, launch the cutover instance, switch DNS or load balancers, then finalize cutover, which stops replication and releases the staging resources.

In the AWS Management Console

  1. Open AWS Transform MGN, choose Get started in the target Region and accept the default templates.

  2. Choose Source servers to see agents that have registered, then select one and open Launch settings and Replication settings to adjust them.

  3. Choose Test and cutover → Launch test instances, validate, then Mark as "Ready for cutover" and Launch cutover instances, and finally Finalize cutover.

  4. Group servers into Applications and Waves to run these actions on many servers at once.

With the AWS CLI
aws mgn initialize-service --region "$AWS_REGION"

aws mgn describe-source-servers --region "$AWS_REGION" \
  --filters '{}' \
  --query 'items[].[sourceServerID,sourceProperties.identificationHints.hostname,lifeCycle.state]' --output table

aws mgn start-test  --region "$AWS_REGION" --source-server-ids "$SOURCE_SERVER_ID"
aws mgn start-cutover --region "$AWS_REGION" --source-server-ids "$SOURCE_SERVER_ID"
aws mgn finalize-cutover --region "$AWS_REGION" --source-server-id "$SOURCE_SERVER_ID"

Reference: AWS CLI Command Reference — mgn and the AWS Transform MGN User Guide.

Migrating a database with DMS

For Bookshelf, suppose the catalog lives in a self-managed PostgreSQL on-premises and the target is the Aurora PostgreSQL cluster bookshelf-catalog (see Amazon Aurora). The same-engine case is a replatform; for a different engine, run DMS Schema Conversion first to translate schemas and code, then DMS for the data.

A DMS migration has four parts: a replication instance (or DMS Serverless, which provisions and scales capacity for you), a source endpoint, a target endpoint and a replication task with table mappings, in one of three modes: full load, change data capture (CDC) only, or full load plus CDC. The usual pattern for minimal downtime is full load plus CDC, wait until lag is near zero, stop writes on the source, let the last changes drain, then switch the application.

In the AWS Management Console

  1. Open Database Migration Service → Replication instances → Create replication instance: choose the class, Multi-AZ for production, the VPC and a subnet group with routes to the source (VPN or Direct Connect, see VPN and Hybrid Connectivity).

  2. Open Endpoints → Create endpoint twice (source and target). Prefer Provide access information using AWS Secrets Manager so credentials live in a secret (see Secrets Manager, Parameter Store and KMS); run Test endpoint connection.

  3. Open Database migration tasks → Create task: pick the replication instance and endpoints, set the migration type to Migrate existing data and replicate ongoing changes, add a selection rule for the public schema and create it.

  4. Watch Table statistics and the CDCLatency metrics in CloudWatch until the task is caught up.

With the AWS CLI
aws dms create-replication-instance \
  --replication-instance-identifier bookshelf-dms \
  --replication-instance-class dms.t3.medium \
  --allocated-storage 50 --multi-az \
  --vpc-security-group-ids "$DMS_SG_ID" --replication-subnet-group-identifier "$DMS_SUBNET_GROUP"

aws dms create-endpoint --endpoint-identifier onprem-catalog --endpoint-type source \
  --engine-name postgres \
  --postgre-sql-settings "SecretsManagerSecretId=$SRC_SECRET_ARN,SecretsManagerAccessRoleArn=$DMS_ACCESS_ROLE_ARN"

aws dms create-endpoint --endpoint-identifier aurora-catalog --endpoint-type target \
  --engine-name aurora-postgresql \
  --postgre-sql-settings "SecretsManagerSecretId=$TGT_SECRET_ARN,SecretsManagerAccessRoleArn=$DMS_ACCESS_ROLE_ARN"

aws dms test-connection --replication-instance-arn "$REPL_ARN" --endpoint-arn "$SRC_ENDPOINT_ARN"
{
  "rules": [
    {
      "rule-type": "selection",
      "rule-id": "1",
      "rule-name": "catalog-public",
      "object-locator": { "schema-name": "public", "table-name": "%" },
      "rule-action": "include"
    }
  ]
}
aws dms create-replication-task --replication-task-identifier catalog-full-load-cdc \
  --migration-type full-load-and-cdc \
  --replication-instance-arn "$REPL_ARN" \
  --source-endpoint-arn "$SRC_ENDPOINT_ARN" --target-endpoint-arn "$TGT_ENDPOINT_ARN" \
  --table-mappings file://table-mappings.json

aws dms start-replication-task --replication-task-arn "$TASK_ARN" --start-replication-task-type start-replication

Reference: AWS CLI Command Reference — dms and the AWS DMS User Guide. The target engines themselves are covered on Amazon RDS, Amazon Aurora, Amazon DynamoDB and Managed Databases on AWS. Moving objects rather than rows is a DataSync job or an S3 batch operation (see S3 Object Storage and Block and File Storage on AWS).

Hybrid and edge options

Not every workload can, or should, live in a Region. AWS offers several ways to bring AWS APIs closer to the user or the data. They differ in who owns the hardware and where it sits:

Option What it is When to choose it

Local Zones

An extension of a parent Region placed near a population or industry centre, offering a subset of services (EC2, EBS, ECS/EKS nodes, load balancers and others). Opted in per zone group; resources are billed at the zone’s own prices, and there is no extra charge for enabling one.

Single-digit-millisecond latency to a city, local data-residency rules, or hybrid migrations that need a nearby landing place.

Wavelength Zones

AWS infrastructure embedded in telecom provider 5G networks.

Ultra-low-latency mobile applications.

AWS Outposts

AWS-owned and operated racks (42U) or 1U/2U servers installed in your own site and managed as part of a Region through a service link. You create subnets on the Outpost and place EC2, EBS, ECS, RDS, S3 on Outposts, ElastiCache, EMR and (on racks) EKS nodes there, using the same APIs.

Low-latency access to on-premises systems, local data processing, or residency rules that forbid a Region.

ECS Anywhere and EKS Anywhere

Registering your own servers as ECS external instances (via SSM and the EXTERNAL launch type) or running EKS distributions on your own hardware, managed with AWS tools.

You own the hardware but want one control plane. ECS external instances lack load balancing, service discovery, awsvpc networking and capacity providers.

Systems Manager hybrid activations

Registers on-premises servers as managed nodes so Patch Manager, Session Manager, Run Command and Inventory work the same as on EC2.

Operating a mixed estate with one tool.

Storage Gateway, DataSync, Transfer Family

Hybrid storage and transfer: file, volume or tape gateways with local caches, and online data movement.

Gradual storage migration or on-premises access to S3 (see Block and File Storage on AWS).

Snow Family

Rugged devices for offline transfer and edge compute.

Existing Snowball Edge customers only: it has been closed to new customers since 2025-11-07, and the official guidance for new needs is DataSync (online), AWS Data Transfer Terminal (secure physical transfer) or partner solutions, and Outposts for edge compute.

Outposts is an AWS-managed purchase, not a self-service console action: you describe the site and capacity, choose a contract term and payment option, and AWS delivers and installs the hardware. The CLI is mostly for inspecting and managing what you have:

aws outposts list-sites --query 'Sites[].[SiteId,Name]' --output table
aws outposts list-outposts --query 'Outposts[].[OutpostId,Name,AvailabilityZone]' --output table
aws outposts get-outpost-instance-types --outpost-id "$OUTPOST_ID"

Reference: What is AWS Outposts? and AWS CLI Command Reference — outposts.

Local Zones are opted into per zone group; once enabled you create a subnet in the zone and place supported resources in it:

aws ec2 describe-availability-zones --all-availability-zones \
  --filters Name=zone-type,Values=local-zone \
  --query 'AvailabilityZones[].[ZoneName,GroupName,OptInStatus]' --output table

aws ec2 modify-availability-zone-group --group-name us-east-1-bos-1 --opt-in-status opted-in

Reference: What is AWS Local Zones?. How Regions, Local Zones and Wavelength relate is in AWS Global Infrastructure. For an on-premises server registered with ECS Anywhere, the AWS-provided install script performs the SSM registration and agent installation; see the ECS Anywhere documentation for the current supported operating systems (support for several older ones, including Amazon Linux 2, ends on 2026-08-07) and ECS and Fargate for the service itself.

Disaster recovery strategies

A disaster is any event that stops the workload meeting its objectives: loss of a data centre, a Region impairment, data corruption, a bad deployment, a compromised account. The strategy is chosen from the business’s RTO and RPO and the kind of disaster to survive. AWS describes four strategies on a spectrum from cheap and slow to expensive and instant:

Strategy What runs in the recovery Region Typical objective Relative cost

Backup and restore

Nothing except copies of data (cross-Region or cross-account backups) plus infrastructure as code, AMIs and container images; everything is redeployed and restored at failover.

RPO and RTO in hours.

Lowest.

Pilot light

Data replicated continuously and core data stores running; application servers exist as configuration but are switched off or at zero capacity.

RTO of tens of minutes.

Low.

Warm standby

A scaled-down but fully functional copy that already handles traffic at reduced capacity; scale out on failover.

RTO of minutes.

Medium.

Multi-site active/active

The full workload runs in two or more Regions and all serve traffic; there is no failover step, only loss of a Region to survive. (Hot standby is the active/passive variant at full capacity.)

RPO near zero and RTO near zero for most disasters.

Highest.

The objectives in the last-but-one column are the order of magnitude AWS gives for each strategy; your actual numbers come from testing. Whatever the strategy, data corruption and malicious deletion are not solved by replication, which copies the damage; they need point-in-time backups, versioning and immutability.

flowchart LR BR["Backup and restore
RTO and RPO: hours"] -->|"more cost, faster recovery"| PL["Pilot light
tens of minutes"] PL --> WS["Warm standby
minutes"] WS --> AA["Active/active
near zero"]

Bookshelf in a second Region

Bookshelf’s recovery Region is us-west-2 ($DR_REGION). The building blocks map to services already documented in this section:

Component Mechanism Page

Container images

ECR cross-Region replication, so tasks can pull images in the recovery Region.

Container Registry

Static site and uploads

S3 versioning plus cross-Region replication, with delete markers not replicated.

S3 Object Storage

bookshelf-catalog (Aurora)

Aurora Global Database with a secondary cluster; promote it on failover.

Amazon Aurora

Orders (DynamoDB)

Global tables (multi-Region, last-writer-wins) plus point-in-time recovery.

Amazon DynamoDB

Secrets and keys

Secrets Manager replication and multi-Region KMS keys.

Secrets Manager, Parameter Store and KMS

Compute

The same CloudFormation or CDK templates deployed in $DR_REGION, at zero or low capacity until needed.

Infrastructure as Code

Traffic

Route 53 failover or latency records with health checks, or Application Recovery Controller routing controls.

Route 53, DNS and ACM Certificates

Two operational rules deserve emphasis. First, prefer data-plane operations during a failover: a Route 53 health-check-driven DNS failover or an Application Recovery Controller switch keeps working when control planes (creating resources, editing weights, scaling) are impaired, so avoid designs whose failover needs those. Second, fail over deliberately: automated failover on an unreliable signal causes outages itself, so many teams automate the steps and keep a human, or an ARC routing control, as the trigger. Cross-service quotas in the recovery Region must be raised in advance (see Cloud Concepts for the general quota model).

AWS Elastic Disaster Recovery

For servers that are not already managed services, AWS Elastic Disaster Recovery (DRS) implements a pilot-light pattern. An agent on each source server (on-premises, another cloud or EC2) replicates blocks continuously to a low-cost staging area subnet in your account; at failover or drill time DRS converts and launches full-capacity instances in the recovery VPC, using the latest state or a previous point in time, and later supports failback. You configure replication and launch settings per source server, run non-disruptive drills regularly, and watch replication lag. It replicates server-hosted applications and databases, not managed services such as RDS, whose native replication features apply instead.

aws drs initialize-service --region "$DR_REGION"
aws drs describe-source-servers --region "$DR_REGION" \
  --query 'items[].[sourceServerID,dataReplicationInfo.dataReplicationState]' --output table
aws drs start-recovery --region "$DR_REGION" --is-drill \
  --source-servers sourceServerID="$SOURCE_SERVER_ID"

Reference: What is Elastic Disaster Recovery? and AWS CLI Command Reference — drs.

Testing the plan

An untested plan is a hypothesis. Run game days that actually fail over, restore a backup into a scratch account and measure how long it takes, include the people and runbooks as well as the technology, and re-run after significant changes. Keep recovery configuration (templates, AMIs, secrets) available even if the primary Region and primary account are gone; a different account for the recovery environment also limits the blast radius of compromised credentials.

AWS Backup

AWS Backup centralises and automates data protection across supported services and, with some resource types, on-premises VMware. Instead of each service’s own scheduler, you define policies and see activity in one place.

Concept Meaning

Backup plan

A policy of one or more rules: schedule (cron), start and completion windows, lifecycle (transition to cold storage and expiry), the target vault, optional continuous backup for point-in-time recovery, and copy actions.

Resource assignment

Which resources a plan protects, by ARN or, most usefully, by tag, so a resource tagged backup=daily is covered automatically.

Backup vault

The container for recovery points, encrypted with a KMS key and protected by a resource-based access policy.

Vault Lock

Write-once-read-many protection: no one, including administrators, can delete backups or shorten retention. Compliance mode becomes immutable after a cooling-off period.

Logically air-gapped vault

A vault with Vault Lock compliance mode built in, encrypted with an AWS-owned key by default (or your own KMS key) and shareable with other accounts through Resource Access Manager so recovery can start from a clean account.

Cross-Region and cross-account copy

Copy actions in a rule (or on demand) store backups in another Region or account, protecting from regional events and from account compromise. Cross-account management works inside AWS Organizations.

Restore testing, Audit Manager

Scheduled restore tests validate backups; Backup Audit Manager checks that backups follow your controls and produces reports.

Supported resources include EC2/EBS, S3, RDS and Aurora, DynamoDB, EFS, FSx, DocumentDB, Neptune, Redshift, Storage Gateway volumes, CloudFormation stacks and EKS clusters with their persistent storage, among others; support for features such as continuous backup or full AWS Backup management varies by resource, so consult the feature availability table. For services with their own native backups, AWS Backup either reuses the same mechanism or adds a separate layer, so read the service-specific page to avoid paying twice for duplicate copies.

In the AWS Management Console

  1. Open AWS Backup → Backup vaults → Create backup vault: name bookshelf-vault, choose the KMS key (see Secrets Manager, Parameter Store and KMS). For ransomware protection create a logically air-gapped vault too.

  2. Open Backup plans → Create backup plan → Build a new plan. Add a rule: daily, schedule, window, lifecycle (for example delete after 35 days), target vault bookshelf-vault, and under Generate copy to destination a vault in us-west-2.

  3. In Assign resources choose the default role and Include specific resource types or select by tag backup = daily.

  4. Open Jobs to watch backup jobs, and Protected resources to see recovery points.

  5. To restore, choose a recovery point → Restore, review the restore metadata (new resource names, subnet and security group) and choose Restore backup. Restoring creates a new resource; it never overwrites the original.

With the AWS CLI

aws backup create-backup-vault --backup-vault-name bookshelf-vault

cat > plan.json <<'EOF'
{
  "BackupPlanName": "bookshelf-daily",
  "Rules": [
    {
      "RuleName": "daily-35d",
      "TargetBackupVaultName": "bookshelf-vault",
      "ScheduleExpression": "cron(0 5 ? * * *)",
      "StartWindowMinutes": 60,
      "CompletionWindowMinutes": 360,
      "Lifecycle": { "DeleteAfterDays": 35 },
      "CopyActions": [
        {
          "DestinationBackupVaultArn": "arn:aws:backup:us-west-2:111122223333:backup-vault:bookshelf-vault-dr",
          "Lifecycle": { "DeleteAfterDays": 35 }
        }
      ]
    }
  ]
}
EOF
PLAN_ID=$(aws backup create-backup-plan --backup-plan file://plan.json --query BackupPlanId --output text)

aws backup create-backup-selection --backup-plan-id "$PLAN_ID" --backup-selection '{
  "SelectionName": "bookshelf-tagged",
  "IamRoleArn": "arn:aws:iam::111122223333:role/service-role/AWSBackupDefaultServiceRole",
  "ListOfTags": [
    { "ConditionType": "STRINGEQUALS", "ConditionKey": "backup", "ConditionValue": "daily" }
  ]
}'

The destination vault must exist in the other Region first (aws backup create-backup-vault --region us-west-2 --backup-vault-name bookshelf-vault-dr). On-demand backups, restores and immutability use the same namespace:

aws backup start-backup-job --backup-vault-name bookshelf-vault \
  --resource-arn "$AURORA_CLUSTER_ARN" \
  --iam-role-arn "arn:aws:iam::111122223333:role/service-role/AWSBackupDefaultServiceRole"

aws backup list-recovery-points-by-backup-vault --backup-vault-name bookshelf-vault \
  --query 'RecoveryPoints[].[RecoveryPointArn,ResourceType,Status]' --output table

aws backup get-recovery-point-restore-metadata \
  --backup-vault-name bookshelf-vault --recovery-point-arn "$RECOVERY_POINT_ARN"

# Make the vault immutable: retention can no longer be shortened by anyone after the cooling-off period
aws backup put-backup-vault-lock-configuration --backup-vault-name bookshelf-vault \
  --min-retention-days 7 --max-retention-days 365 --changeable-for-days 3

Reference: aws backup create-backup-plan, What is AWS Backup?, AWS Backup Vault Lock and Logically air-gapped vault. Per-service restore specifics (for example restoring an EBS volume or an RDS snapshot) are on Block and File Storage on AWS and Amazon RDS.

Security and networking considerations

  • Migration and DR roles are powerful: the replication agent, DMS endpoints, backup service role and recovery procedure all need scoped IAM roles, preferably in a dedicated account (see Identity and Access).

  • Encrypt replicated data and backups with customer-managed KMS keys where compliance requires, and plan key availability in the recovery Region (multi-Region keys).

  • Migration traffic should use private connectivity (VPN or Direct Connect, see VPN and Hybrid Connectivity) and private staging subnets with VPC endpoints where possible.

  • Backups are a ransomware target: use Vault Lock, a separate backup account and cross-account copy, and monitor with CloudWatch and EventBridge events from AWS Backup (see Monitoring and Observability).

Limits and quotas

Each service has its own adjustable and fixed limits in Service Quotas (aws service-quotas list-service-quotas --service-code <code>); the ones that most often bite these workflows are listed below. Confirm current values on the linked quota pages before designing.

  • Well-Architected Tool: limits on workloads, milestones and custom lenses per account and Region.

  • AWS Transform MGN: a maximum number of source servers and concurrent replicating servers per account and Region, and per-server limits on disks and volume sizes; plan waves within them.

  • DMS: replication instances, endpoints and tasks per account and Region, and per-instance storage; large objects (LOBs) need explicit task settings.

  • AWS Backup: backup plans, vaults, rules per plan and concurrent copy jobs per account and Region; some resource types do not support every feature (for example continuous backup).

  • DR Region: EC2 vCPU, Fargate, RDS and load-balancer quotas are per Region, so a recovery Region starts with default quotas that may be too low for production capacity.

Pricing model

Prices change; use the dated pricing pages: AWS Backup, DMS, AWS Transform MGN, Elastic Disaster Recovery, Outposts racks and Local Zones. The cost drivers:

Service What you pay for

Well-Architected Tool

Nothing for the Tool; the remediation work it recommends is where cost lies.

AWS Transform

The user guide states no additional charge for the service itself; you pay for the resources it uses and creates.

AWS Transform MGN

Per source server per hour while it is replicating (a free period applies at the start of a migration, per the pricing page), plus the staging-area resources: replication-server instances, EBS volumes, snapshots and data transfer. Test and cutover instances are billed as ordinary EC2.

DMS

Replication instance hours (or DMS Serverless capacity units), storage, and data transfer; DMS Schema Conversion and Fleet Advisor have their own terms.

Elastic Disaster Recovery

Per source server per hour while replicating, plus staging storage and minimal compute; full-size recovery instances are billed only during drills and real recoveries.

AWS Backup

Warm and cold backup storage (GB-month), data restored, restore testing, cross-Region data transfer and Backup Audit Manager; early deletion from cold storage is charged, so mind minimum retention.

Outposts

Configuration, contract term and payment option; includes delivery, infrastructure maintenance and software upgrades for racks, plus charges for shared resources and data transfer to the Region.

Local Zones

No charge to enable; resources have their own (often higher) prices than in the parent Region.

DR strategy

Backup and restore costs mostly storage; pilot light adds always-on data stores; warm standby adds a running scaled-down fleet; active/active roughly doubles the compute bill plus inter-Region data transfer.

Tag everything created for a migration or a DR drill so that its cost is visible, and use budgets and anomaly detection (see Cost Management and Support).

Troubleshooting

Symptom Likely cause and fix

A DMS endpoint test fails

Security groups or routes between the replication instance and the source; the source user lacks replication privileges (rds_replication or equivalent); the secret access role is missing secretsmanager:GetSecretValue.

A DMS task stays in Running but CDC lag grows

Source write rate exceeds the instance class, a long-running transaction holds the log, or the target is throttling; scale the instance and check CloudWatch CDCLatencySource and CDCLatencyTarget.

MGN agent installs but the server never appears or stays Stalled

The server cannot reach the replication servers or the service endpoints on port 443 and 1500, or the staging subnet has no route; check the replication settings template and the agent’s logs.

MGN test instance does not boot or lacks network

Wrong launch template subnet or security group, or an unsupported OS or kernel; adjust launch settings and try again.

A backup job fails with an access error

The backup service role cannot access the resource or KMS key, or the key policy of the vault key blocks it.

A cross-Region copy never completes

The destination vault does not exist, its access policy denies the source account, or the KMS key in the destination is unavailable.

A restore creates a resource that cannot be reached

Restore metadata chose the default VPC, subnet or security group; restore with explicit metadata.

A DR drill fails to scale

Quotas in the recovery Region, missing AMIs or images in that Region, or a dependency on a control-plane action that was unavailable.

Clean up

The exercises above create billable resources. Delete them in this order:

# Backup: recovery points must be deleted before a vault; locked vaults cannot be emptied early
aws backup delete-backup-selection --backup-plan-id "$PLAN_ID" --selection-id "$SELECTION_ID"
aws backup delete-backup-plan --backup-plan-id "$PLAN_ID"
for RP in $(aws backup list-recovery-points-by-backup-vault --backup-vault-name bookshelf-vault \
    --query 'RecoveryPoints[].RecoveryPointArn' --output text); do
  aws backup delete-recovery-point --backup-vault-name bookshelf-vault --recovery-point-arn "$RP"
done
aws backup delete-backup-vault --backup-vault-name bookshelf-vault

# DMS: stop and delete the task, then endpoints, then the replication instance
aws dms stop-replication-task --replication-task-arn "$TASK_ARN"
aws dms delete-replication-task --replication-task-arn "$TASK_ARN"
aws dms delete-endpoint --endpoint-arn "$SRC_ENDPOINT_ARN"
aws dms delete-endpoint --endpoint-arn "$TGT_ENDPOINT_ARN"
aws dms delete-replication-instance --replication-instance-arn "$REPL_ARN"

# Well-Architected Tool workload
aws wellarchitected delete-workload --workload-id "$WORKLOAD_ID" --client-request-token "$(uuidgen)"

Remove the same backup vault and recovery points in us-west-2. In AWS Transform MGN, Disconnect from AWS or Mark as archived for finished servers, terminate the test and cutover instances you no longer need, uninstall the replication agent from source servers, and delete the IAM identity created for agent installation. In Elastic Disaster Recovery, delete drill instances and, once no longer protecting a server, Disconnect it and delete its recovery snapshots and staging resources. Opt out of Local Zone groups you no longer use and delete the resources inside them first. Vault Lock in compliance mode cannot be removed after its cooling-off period, so only enable it on vaults you intend to keep.

Recent changes

Date Change

2025-11-07

AWS Snowball Edge closed to new customers; AWS Migration Hub closed to new customers. AWS DataSync, AWS Data Transfer Terminal, Outposts and AWS Transform are the recommended replacements.

2025 (see lifecycle page)

Application Migration Service renamed AWS Transform MGN and AWS Transform introduced as the umbrella for discovery, planning and execution.

2026-08-07

Several older operating systems, including Amazon Linux 2, no longer supported by ECS Anywhere.

Older guides therefore recommend Migration Hub as the migration control tower, five- or six-"R" lists without Relocate, a five-pillar Well-Architected Framework, and Snowball for any large transfer; the current approach is AWS Transform for planning, AWS Transform MGN and DMS for execution, six pillars and 7 Rs, and DataSync or a dedicated connection for data transfer.

Related pages

References