Skip to main content
Welcome — this lesson focuses on practical reliability improvements for AWS migration and transfer services. We’ll cover:
  • Application Discovery & Migration Hub
  • Application Migration Service (MGN)
  • Database Migration Service (DMS)
  • Elastic Disaster Recovery (DRS)
  • Mainframe Modernization
  • DataSync and Transfer Family
  • Snow Family (Snowcone, Snowball Edge, Snowmobile)
For each service we highlight where you can tune reliability, what is already managed for you, and operational patterns to monitor, alert, and automate recovery.

​
Application Discovery and Migration Hub

A presentation slide showing the AWS Migration Hub dashboard with charts and widgets summarizing application migration status. The caption notes that Migration Hub gathers data from other tools and simply displays it.
  • Migration Hub is primarily a managed dashboard that aggregates metadata and migration status from other AWS migration tools.
  • There are essentially no internal reliability knobs in Migration Hub itself — rely on AWS observability services (CloudWatch, CloudTrail) for monitoring, auditing, and alerts.
  • Application Discovery actively inventories on‑premises systems. It supports agentless, agent-based, and manual discovery methods.
Operational guidance:
  • Export discovery logs and metrics to CloudWatch and CloudTrail for retention and auditing.
  • Use X-Ray if supported for deeper operational traces where instrumented.

​
Application Migration Service (MGN)

MGN automates lift‑and‑shift migrations by continuously replicating server state to AWS and enabling rapid launch of EC2 replicas. It’s a managed workflow with fewer low-level reliability settings.
A slide diagram showing AWS Application Migration Service workflows: portfolio assessment tools at the top and migration paths (lift-and-shift, database replatforming, and replatforming to containers) from on‑prem servers/databases/web apps to AWS services like MGN, DMS, EC2, RDS, and EKS/ECS.
Best practices:
  • Validate replication cutover procedures in a non-production account.
  • Bake monitoring and post-cutover health checks into runbooks.
  • Use tags and automation to track migration states and rollbacks.

​
Database Migration Service (DMS)

DMS uses a replication instance (managed EC2 under the hood) to perform extracts, apply CDC, and synchronize targets. The replication instance can become a single point of interruption unless designed for availability.
An architecture diagram titled "Designing for Reliability – Database Migration Service" showing users connecting over the Internet to an AWS VPC where AWS DMS (replication instance) migrates data from an RDS Oracle source to an RDS Aurora target inside a public subnet. The diagram highlights the DMS replication instance as a single point of failure.
Key reliability recommendations:
  • Enable Multi‑AZ on the replication instance to provision a standby in another AZ:
  • Monitor DMS metrics and task status with CloudWatch; set automatic alarms for ReplicationTasksStopped, FullLoadProgressPercent, and replication instance CPU/memory.
  • Plan for task restart semantics: during failover a task may need restart or validation; include this in runbooks and automation.
  • CDC reduces re-sync needs: after recovery, tasks often continue from the last applied change rather than reloading the full dataset.

​
Elastic Disaster Recovery (DRS, formerly CloudEndure)

DRS is purpose-built for resiliency and automated recovery. It performs near‑real‑time, block‑level replication into a staging VPC, uses scalable replication servers, and provisions recovery servers during failover.
A presentation slide titled "Designing for Reliability – Elastic Disaster Recovery Service" showing an AWS architecture diagram of source and target regions with VPC peering, replication servers, and recovery components. The slide also notes that EDR uses replication servers that auto-scale and auto-replace to support block-by-block replication.
Why choose DRS:
  • Low RPO and automated failover are built in through block‑level replication.
  • Replication servers auto-scale and auto‑replace, reducing single points of infrastructure failure.
  • Test failovers in a sandbox environment to validate runbooks and automated recovery.

​
Mainframe Modernization

Mainframe Modernization orchestrates migration and modernization pipelines for mainframe workloads, providing automated DevOps workflows for Analyze → Develop → Deploy → Operate.
A presentation slide titled "Designing for Reliability – Mainframe Modernization" showing an AWS Mainframe Modernization diagram. It illustrates an automated DevOps pipeline with stages labeled Analyze, Develop, Deploy, and Operate.
Reliability considerations:
  • The orchestration has replication features for moving data in near real time, but long‑term availability depends on target services.
  • Design the converted workloads for cloud resilience: use Multi‑AZ RDS, Auto Scaling groups across AZs, stateless services behind load balancers, and managed serverless (Lambda) where appropriate.
  • Test end‑to‑end failure scenarios post-migration (network partitions, AZ failover, scale events).

​
DataSync — file transfers between on‑prem and AWS

DataSync is a managed service that uses an on‑premises agent to accelerate and automate file transfers. It supports file‑level logging to support reliable processing.
An architectural diagram titled "Designing for Reliability – DataSync" showing an on‑prem storage array and AWS DataSync agent sending data to AWS DataSync, with CloudWatch Logs, Amazon S3, AWS Lambda, and Amazon SQS components. The diagram illustrates a file-level logging and reprocessing workflow via S3 triggers.
Operational guidance:
  • Treat the DataSync agent as a monitored component: run health checks and auto‑restart or replace the agent VM if it fails.
  • Enable DataSync file transfer logging and export to CloudWatch Logs and/or S3 for durable audit trails.
  • Use S3 event notifications (Lambda/SQS) and a reprocessing pipeline for any missed or failed file transfers.
  • Configure CloudWatch alarms on DataSync task metrics and statuses to trigger automated runbook steps.
If you need file-level visibility into transfers to S3, enable DataSync file transfer logs and integrate them with CloudWatch Logs and S3 for traceability.
An infographic asking which AWS DataSync feature provides file-level visibility when transferring on-premises data to Amazon S3. It lists answer options such as enabling DataSync file transfer logs to CloudWatch Logs, viewing CloudWatch metrics, checking DataSync task logs in the console, and enabling AWS CloudTrail logging.

​
AWS Transfer Family — partner file exchange (SFTP/FTPS/FTP)

Transfer Family is a fully managed service that hosts SFTP, FTPS, and FTP endpoints for external partners. It is designed with resilience and security in mind; operational visibility is provided via CloudWatch and CloudTrail.
A slide asking which AWS service best enables external vendors to securely upload large files reliably over poor networks, followed by four numbered options. The choices listed are AWS Transfer Family, an SFTP server on Lightsail, an EC2-hosted SFTP server, and an API Gateway upload.
Best practices:
  • Use Transfer Family for external vendor uploads when you need a managed, scalable endpoint with built‑in protocols.
  • Enable CloudWatch metrics and CloudTrail logging for auditing and SLA monitoring.
  • Combine with S3 lifecycle and replication policies for data durability and cross‑region protection.

​
Snow Family — physical data transfer (Snowcone, Snowball Edge, Snowmobile)

Snow devices are physical, ruggedized appliances for moving large datasets when networks are constrained. These are engineered for transport durability and secure handling rather than in-service HA knobs.
A slide titled "Designing for Reliability – Snow Family (storage)" showing a simple network diagram. It depicts an on‑premises source and staging workstation on a LAN connected via 10GE to a Snowball Edge device that exposes an S3‑compatible endpoint.
Sizing and use cases:
  • Snowball Edge storage‑optimized (e.g., 80 TB or 210 TB variants) is ideal for hundreds of terabytes. For exabyte-class or extreme volumes, Snowmobile is available.
  • Focus on secure handling, inventory tracking, and data validation (checksums) rather than traditional HA settings.
An AWS quiz-style infographic describing a scenario where a company must reliably transfer hundreds of terabytes of sensor data from a remote oil rig with limited connectivity. It lists four solution options including AWS Snowcone devices, AWS Direct Connect, Amazon S3 Transfer Acceleration, and SFTP.
A presentation slide titled "Designing for Reliability – Snow Family" showing a comparison table of AWS Snowball Edge storage‑optimized models (80 TB and 210 TB) and their specs. A left-side note states that Snowball Edge is the primary storage vehicle and to note the storage sizes.

​
Comparison: migration & transfer services (reliability focus)

​
Operational patterns and runbook checklist

  • Enable and centralize logs: CloudWatch Logs + S3 export for durable retention.
  • Alert on operational metrics: replication instance health, task failures, task progress, agent heartbeats.
  • Automate recovery actions: Lambda/SNS/SQS based playbooks to restart tasks, replace agents, or trigger failover.
  • Test: run scheduled dry-run migrations and failover drills to validate RPO/RTO and runbooks.
  • Reduce blast radius: perform migrations in isolated accounts or staging VPCs and promote only after validation.
Metrics and logs are the keys to reliability: enable CloudWatch metrics and logs, export service logs to S3 when useful, and automate alarms and remediation to reduce downtime during migrations and transfers.
This concludes the migration and transfer services guidance for designing for reliability. Thanks for reading.

Watch Video