{"id":287,"date":"2026-04-13T12:21:26","date_gmt":"2026-04-13T12:21:26","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/aws-application-migration-service-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-migration-and-transfer\/"},"modified":"2026-04-13T12:21:26","modified_gmt":"2026-04-13T12:21:26","slug":"aws-application-migration-service-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-migration-and-transfer","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/aws-application-migration-service-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-migration-and-transfer\/","title":{"rendered":"AWS Application Migration Service Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Migration and transfer"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Migration and transfer<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>AWS Application Migration Service is an AWS Migration and transfer service that helps you move applications that run on physical servers or virtual machines (VMs) into AWS with minimal downtime. It is designed primarily for \u201crehost\u201d (lift-and-shift) migrations where you want to run the same server-based workload on Amazon EC2 without rewriting the application.<\/p>\n\n\n\n<p>In simple terms: you install a small replication agent on your source servers, AWS continuously replicates the server disks into a low-cost staging area in your AWS account, and then you launch test or cutover instances in AWS when you\u2019re ready.<\/p>\n\n\n\n<p>Technically, AWS Application Migration Service (often abbreviated as <strong>MGN<\/strong>) performs continuous block-level replication from source servers to AWS. It orchestrates the replication lifecycle, tracks source server readiness, and automates the creation of Amazon EC2 instances from replicated volumes. You can launch <strong>test instances<\/strong> for validation, then perform a <strong>cutover<\/strong> launch when you\u2019re ready to migrate production traffic.<\/p>\n\n\n\n<p>The main problem it solves is the operational burden and risk of moving many servers to AWS: coordinating replication, managing conversion steps, minimizing downtime, and standardizing repeatable migration waves\u2014while still giving you control over networking, security, and instance configuration in the target AWS environment.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is AWS Application Migration Service?<\/h2>\n\n\n\n<p><strong>Official purpose (what it\u2019s for):<\/strong><br\/>\nAWS Application Migration Service helps you migrate applications to AWS by replicating source servers (physical, virtual, or cloud-based) into AWS and launching them as Amazon EC2 instances for testing and cutover. It focuses on the <strong>rehost<\/strong> migration pattern.<\/p>\n\n\n\n<p><strong>Service status and naming (important):<\/strong>\n&#8211; The current, official service name is <strong>AWS Application Migration Service<\/strong>.\n&#8211; It is the strategic successor to the older <strong>CloudEndure Migration<\/strong> service experience in AWS. If you encounter older CloudEndure references in existing runbooks, treat those as legacy and <strong>verify in official docs<\/strong> how they map to AWS Application Migration Service workflows today.\n&#8211; The older <strong>AWS Server Migration Service (SMS)<\/strong> is legacy\/retired (no longer the recommended path). For server lift-and-shift, AWS Application Migration Service is the primary AWS-native option.<\/p>\n\n\n\n<p><strong>Core capabilities:<\/strong>\n&#8211; Continuous, block-level replication from source servers to AWS.\n&#8211; Orchestrated lifecycle: add servers, replicate, test launch, cutover launch.\n&#8211; Launch configuration to control EC2 instance type, subnet, security groups, and other launch-time settings.\n&#8211; Grouping and wave-based migrations for scaled projects.\n&#8211; Optional post-launch automation (commonly via AWS Systems Manager) for tasks like domain join, agent install, or configuration changes.<\/p>\n\n\n\n<p><strong>Major components (conceptual):<\/strong>\n&#8211; <strong>MGN service control plane<\/strong>: Tracks source servers, replication state, and launch actions.\n&#8211; <strong>Replication agent<\/strong> (installed on source servers): Sends block changes to AWS.\n&#8211; <strong>Staging area<\/strong> (in your AWS account): AWS resources (typically EC2\/EBS in a designated subnet) used to receive and maintain replicated data.\n&#8211; <strong>Launch templates\/settings<\/strong>: Configuration applied when launching test or cutover instances.\n&#8211; <strong>Test and cutover instances<\/strong>: EC2 instances launched from replicated volumes.<\/p>\n\n\n\n<p><strong>Service type:<\/strong>\n&#8211; A managed migration orchestration service with agent-based replication.<\/p>\n\n\n\n<p><strong>Scope: regional and account considerations:<\/strong>\n&#8211; AWS Application Migration Service is <strong>region-scoped<\/strong> in the sense that you configure and execute migrations into a specific AWS Region. You typically plan migrations per target Region and per AWS account.\n&#8211; Replication and staging resources are created in <strong>your AWS account<\/strong> (within your VPC), so networking, IAM, and security posture are under your control.<\/p>\n\n\n\n<p><strong>How it fits into the AWS ecosystem:<\/strong>\nAWS Application Migration Service commonly integrates with:\n&#8211; <strong>Amazon EC2 \/ Amazon EBS<\/strong> for launched instances and replicated storage.\n&#8211; <strong>Amazon VPC<\/strong> for staging and target subnets, routing, and security groups.\n&#8211; <strong>AWS Identity and Access Management (IAM)<\/strong> for console\/API access and service roles.\n&#8211; <strong>AWS Key Management Service (KMS)<\/strong> if you enable EBS encryption using customer managed keys.\n&#8211; <strong>AWS CloudTrail<\/strong> for auditing API actions.\n&#8211; <strong>Amazon CloudWatch<\/strong> (and sometimes CloudWatch Logs) for operational telemetry depending on your monitoring approach.\n&#8211; <strong>AWS Systems Manager<\/strong> for post-launch automation and operational management of migrated instances.<\/p>\n\n\n\n<p>Official documentation entry point:<br\/>\nhttps:\/\/docs.aws.amazon.com\/mgn\/<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use AWS Application Migration Service?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster migration timelines:<\/strong> Standardized replication and launch workflows reduce custom scripting and manual procedures.<\/li>\n<li><strong>Lower migration risk:<\/strong> You can run repeated <strong>test launches<\/strong> before cutover, reducing \u201cbig bang\u201d surprises.<\/li>\n<li><strong>Minimize downtime:<\/strong> Continuous replication supports short cutover windows compared to cold migrations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Lift-and-shift for server-based workloads:<\/strong> Ideal when you want to keep the same OS and application stack, but move the compute to AWS.<\/li>\n<li><strong>Broad source environments:<\/strong> Commonly used for on-prem VMware\/Hyper-V, physical servers, and other cloud VMs\u2014without requiring hypervisor-level access (agent-based).<\/li>\n<li><strong>Works with existing AWS landing zones:<\/strong> You can launch into well-defined VPCs\/subnets and apply security standards.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Wave planning and repeatability:<\/strong> Migrations can be organized by application, environment, or business unit.<\/li>\n<li><strong>Testing-first approach:<\/strong> Launch test instances, validate, then cut over using the same replicated data stream.<\/li>\n<li><strong>Standardized cutover process:<\/strong> Consistent lifecycle states and controls help operations teams run predictable events.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Customer-controlled network boundaries:<\/strong> Staging area and launched instances run in your account\/VPC.<\/li>\n<li><strong>IAM-based access control and CloudTrail auditability:<\/strong> Supports separation of duties and traceability.<\/li>\n<li><strong>Encryption options:<\/strong> You can align replicated and launched storage with your encryption requirements (verify encryption settings in official docs for your exact scenario).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Continuous replication:<\/strong> Designed for large-scale server fleets where incremental changes are replicated continuously.<\/li>\n<li><strong>Parallel migrations:<\/strong> Multiple servers can replicate simultaneously (subject to quotas, bandwidth, and project design).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose AWS Application Migration Service when:\n&#8211; You need <strong>rehost migrations<\/strong> to EC2 with minimal app changes.\n&#8211; You want to <strong>test<\/strong> the migrated server in AWS before cutover.\n&#8211; You are migrating dozens to thousands of servers and need <strong>repeatable, auditable processes<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Consider alternatives when:\n&#8211; You are migrating <strong>databases<\/strong> and need logical replication\/heterogeneous migrations (use <strong>AWS Database Migration Service<\/strong> instead).\n&#8211; You only need to transfer <strong>files\/object data<\/strong> (use <strong>AWS DataSync<\/strong>, <strong>AWS Transfer Family<\/strong>, or storage replication features).\n&#8211; You need to migrate <strong>VMware environments as-is<\/strong> with minimal change and want to keep VMware operational model (consider <strong>VMware Cloud on AWS<\/strong>).\n&#8211; Your workload should be <strong>refactored<\/strong> to containers or managed services (MGN is for rehost; modernization is a separate workstream).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is AWS Application Migration Service used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Financial services and insurance (data center exits, DR improvements, compliance-driven migrations)<\/li>\n<li>Healthcare and life sciences (regulated workloads moving to controlled AWS landing zones)<\/li>\n<li>Retail and e-commerce (seasonal scaling, modernization programs with phased lift-and-shift)<\/li>\n<li>Manufacturing (plant data center consolidation, edge-to-cloud transitions)<\/li>\n<li>SaaS and technology (moving from colocations\/legacy clouds to AWS regions closer to customers)<\/li>\n<li>Public sector (standardization, procurement-driven migrations\u2014subject to region and compliance constraints)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform\/Cloud Center of Excellence (CCoE)<\/li>\n<li>Infrastructure and operations teams<\/li>\n<li>SRE\/DevOps teams supporting hybrid environments<\/li>\n<li>Security engineering teams validating target architecture controls<\/li>\n<li>Migration factory teams executing wave-based server migrations<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Web applications on Windows\/IIS or Linux\/Nginx\/Apache<\/li>\n<li>Commercial off-the-shelf (COTS) applications running on VMs<\/li>\n<li>Batch processing servers and internal tools<\/li>\n<li>Legacy line-of-business apps that are hard to refactor<\/li>\n<li>Multi-tier apps where database migration is handled separately<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Classic 3-tier server architectures (web\/app\/db) where web\/app tiers are rehosted first<\/li>\n<li>Hub-and-spoke VPC landing zones<\/li>\n<li>Shared services (AD\/DNS, logging, patching) in AWS plus migrated app networks<\/li>\n<li>Hybrid connectivity (Site-to-Site VPN\/Direct Connect) during transition<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production migrations:<\/strong> Most common; emphasis on testing, cutover planning, rollback, and observability.<\/li>\n<li><strong>Dev\/test migrations:<\/strong> Often used to validate AWS landing zone design, AMI baselines, and post-launch automation before production waves.<\/li>\n<li><strong>Data center exit programs:<\/strong> Large fleets migrated over months with strict wave governance.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where AWS Application Migration Service is a strong fit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Data center exit (VM fleet to EC2)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Hundreds of VMware VMs must be migrated before lease end.<\/li>\n<li><strong>Why this fits:<\/strong> Agent-based replication and wave-based orchestration support scaled lift-and-shift with repeated testing.<\/li>\n<li><strong>Example:<\/strong> 600 Windows and Linux VMs replicated continuously; waves cut over each weekend with predefined launch settings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Lift-and-shift of a legacy monolith with minimal change<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A critical monolithic app can\u2019t be refactored quickly.<\/li>\n<li><strong>Why this fits:<\/strong> Rehost allows moving infrastructure quickly while keeping the app stack intact.<\/li>\n<li><strong>Example:<\/strong> A Java app on Linux with local configuration is replicated and launched on EC2; modernization happens later.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Migrating from another cloud to AWS (VM-based workloads)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Cloud contract ends; workloads run on VM instances with attached disks.<\/li>\n<li><strong>Why this fits:<\/strong> Source can be a VM in another cloud; agent replicates to AWS over the internet\/VPN.<\/li>\n<li><strong>Example:<\/strong> Several Ubuntu VMs replicated into AWS, then cut over with DNS change.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Hardware refresh avoidance (physical servers)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Aging physical servers must be replaced; procurement lead time is long.<\/li>\n<li><strong>Why this fits:<\/strong> Physical servers can be replicated and rehosted to EC2.<\/li>\n<li><strong>Example:<\/strong> A physical Windows server hosting an internal tool is migrated to EC2 and decommissioned.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) DR-to-primary transition (promote AWS as new primary)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Organization has DR images but wants AWS as primary environment.<\/li>\n<li><strong>Why this fits:<\/strong> Continuous replication and test launches help validate DR readiness and then cut over.<\/li>\n<li><strong>Example:<\/strong> DR test in AWS becomes the final cutover process after validation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Migrate and standardize network\/security posture<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> On-prem has inconsistent firewall rules and IP plans.<\/li>\n<li><strong>Why this fits:<\/strong> Launch settings let you place instances into standardized AWS VPC subnets and security groups.<\/li>\n<li><strong>Example:<\/strong> Servers launched into separate subnets by tier, with consistent security groups and routing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Migration factory model (repeatable waves)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Multiple teams migrating apps need a shared process.<\/li>\n<li><strong>Why this fits:<\/strong> Centralized migration tooling with consistent lifecycle states improves governance.<\/li>\n<li><strong>Example:<\/strong> A migration team onboards 20 servers\/week with runbooks for test, signoff, cutover, and cleanup.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Rapid carve-out\/divestiture migration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A business unit split requires moving only selected servers quickly.<\/li>\n<li><strong>Why this fits:<\/strong> Agent-based approach can target specific servers without needing hypervisor-level integration.<\/li>\n<li><strong>Example:<\/strong> Replicate only finance app servers and cut over into a new AWS account.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Short maintenance-window migrations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Business allows only a short downtime window.<\/li>\n<li><strong>Why this fits:<\/strong> Continuous replication reduces delta at cutover time.<\/li>\n<li><strong>Example:<\/strong> Cutover completed in under an hour with final sync, launch, and DNS update.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Pre-modernization stepping stone<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You plan containers or managed services later, but need to exit a data center now.<\/li>\n<li><strong>Why this fits:<\/strong> Rehost first, then refactor in AWS with reduced time pressure.<\/li>\n<li><strong>Example:<\/strong> App moved to EC2; later decomposed into services and moved to ECS\/EKS and managed databases.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Compliance-driven region move (to an approved AWS region)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Workloads must run in a specific AWS region for data residency.<\/li>\n<li><strong>Why this fits:<\/strong> MGN allows controlled cutover into a chosen region and VPC design.<\/li>\n<li><strong>Example:<\/strong> EU workloads moved to an EU region, with KMS keys and logging aligned to policy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Pilot migrations to validate landing zone readiness<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Unsure if IAM, networking, and monitoring standards are correct.<\/li>\n<li><strong>Why this fits:<\/strong> A small set of servers can validate end-to-end process before scale-out.<\/li>\n<li><strong>Example:<\/strong> Migrate 2 dev servers, validate patching, logging, and incident workflows, then expand.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Feature availability and details can evolve. Verify the latest behavior in official docs: https:\/\/docs.aws.amazon.com\/mgn\/<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Continuous block-level replication<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Replicates disk blocks from source servers to AWS continuously after initial sync.<\/li>\n<li><strong>Why it matters:<\/strong> Minimizes cutover downtime by keeping AWS-side data current.<\/li>\n<li><strong>Practical benefit:<\/strong> You can schedule cutover windows confidently, with smaller final deltas.<\/li>\n<li><strong>Caveats:<\/strong> Replication performance depends on source I\/O, network bandwidth\/latency, and staging configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Agent-based source onboarding<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Uses a replication agent installed on each source server to replicate data.<\/li>\n<li><strong>Why it matters:<\/strong> Works across heterogeneous environments without needing deep hypervisor integration.<\/li>\n<li><strong>Practical benefit:<\/strong> Consistent onboarding process for physical servers and VMs.<\/li>\n<li><strong>Caveats:<\/strong> Requires OS support and permissions to install and run the agent. Validate supported OS versions in docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Staging area in your VPC<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Uses AWS resources in your account\/VPC to receive replication data.<\/li>\n<li><strong>Why it matters:<\/strong> Keeps data path inside your controlled network environment and security boundaries.<\/li>\n<li><strong>Practical benefit:<\/strong> You can apply security groups, subnets, routing, and (where supported) encryption controls.<\/li>\n<li><strong>Caveats:<\/strong> Staging resources incur cost (EC2\/EBS). Poor subnet routing\/NACLs can break replication.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Test launch and cutover launch workflows<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you launch EC2 instances for testing without stopping replication, and later launch cutover instances.<\/li>\n<li><strong>Why it matters:<\/strong> Supports validation before production cutover.<\/li>\n<li><strong>Practical benefit:<\/strong> Rehearse runbooks, verify application behavior, and confirm performance.<\/li>\n<li><strong>Caveats:<\/strong> Ensure test and cutover instances don\u2019t conflict with production IPs, DNS, or domain membership.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Launch configuration (instance type, networking, security)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Controls how instances are launched (subnet, security groups, instance type, etc.).<\/li>\n<li><strong>Why it matters:<\/strong> Ensures migrated servers align with your AWS target architecture.<\/li>\n<li><strong>Practical benefit:<\/strong> Place servers into tiered subnets, apply least-privilege security groups, and standardize instance families.<\/li>\n<li><strong>Caveats:<\/strong> Some settings may require additional AWS services or careful IAM permissions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Grouping and wave orchestration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Organizes servers into logical groups\/waves for phased migration.<\/li>\n<li><strong>Why it matters:<\/strong> Large migrations need governance: scheduling, dependencies, and rollback planning.<\/li>\n<li><strong>Practical benefit:<\/strong> Execute migration factory patterns (Wave 1 pilot \u2192 Wave 2 critical apps \u2192 \u2026).<\/li>\n<li><strong>Caveats:<\/strong> Waves help orchestration but don\u2019t automatically discover all app dependencies; you still need assessment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Post-launch actions \/ automation integration (commonly AWS Systems Manager)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Enables automated steps after a test\/cutover instance launches (for example, install agents, run scripts).<\/li>\n<li><strong>Why it matters:<\/strong> Many apps require changes on first boot in AWS (drivers, config, monitoring).<\/li>\n<li><strong>Practical benefit:<\/strong> Reduces manual steps and improves repeatability.<\/li>\n<li><strong>Caveats:<\/strong> Requires Systems Manager connectivity\/permissions and careful change control. Verify current MGN post-launch capabilities in docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tagging and metadata for governance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Allows tagging and organizing migrated resources for cost allocation and operations.<\/li>\n<li><strong>Why it matters:<\/strong> Migration projects generate many resources; tags are critical for chargeback and cleanup.<\/li>\n<li><strong>Practical benefit:<\/strong> Attribute staging\/test costs to teams and waves.<\/li>\n<li><strong>Caveats:<\/strong> Tag propagation varies by resource type. Enforce tagging with policies where appropriate.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM integration and service roles<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Uses IAM permissions and (typically) service-linked roles to operate.<\/li>\n<li><strong>Why it matters:<\/strong> Enables least privilege, separation of duties, and auditability.<\/li>\n<li><strong>Practical benefit:<\/strong> Migration operators can be restricted to only the actions they need.<\/li>\n<li><strong>Caveats:<\/strong> Misconfigured IAM is a common reason for onboarding\/launch failures.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>At a high level, AWS Application Migration Service works like this:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>You configure AWS Application Migration Service in a target AWS Region and select a <strong>staging area subnet<\/strong> and related settings.<\/li>\n<li>You install the <strong>replication agent<\/strong> on each source server.<\/li>\n<li>The agent performs <strong>initial sync<\/strong> (copying disk data) and then <strong>continuous replication<\/strong> (sending changed blocks).<\/li>\n<li>Replicated data lands in a <strong>staging area<\/strong> in your AWS account (implemented using AWS resources in your VPC).<\/li>\n<li>When ready, you perform a <strong>test launch<\/strong> to create EC2 instances from the replicated data.<\/li>\n<li>After validation, you perform a <strong>cutover launch<\/strong> to create production EC2 instances and complete migration.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Data flow vs control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane:<\/strong> You interact with MGN via the AWS Console\/API. MGN orchestrates replication state, launch lifecycle, and configuration.<\/li>\n<li><strong>Data plane:<\/strong> Replication data flows from source servers to AWS staging resources over the network. The exact ports and endpoints can vary\u2014verify network requirements in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Key integrations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Amazon VPC:<\/strong> Subnets, security groups, route tables for staging and target instances.<\/li>\n<li><strong>Amazon EC2:<\/strong> Test and cutover instances.<\/li>\n<li><strong>Amazon EBS:<\/strong> Replicated volumes and launched instance disks.<\/li>\n<li><strong>AWS IAM:<\/strong> Access control and service roles.<\/li>\n<li><strong>AWS CloudTrail:<\/strong> API auditing.<\/li>\n<li><strong>AWS KMS (optional):<\/strong> Encryption key management for EBS encryption (if configured).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Console\/API access uses IAM principals (users\/roles) with MGN permissions.<\/li>\n<li>The service typically uses a <strong>service-linked role<\/strong> (or equivalent) to create and manage required AWS resources in your account.<\/li>\n<li>The replication agent uses credentials\/activation workflows as defined by the current onboarding process. Follow the console-generated installation instructions to avoid credential mishandling.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Source \u2192 AWS:<\/strong> Outbound connectivity from the source environment to AWS is required (internet, VPN, or Direct Connect).<\/li>\n<li><strong>Staging subnet:<\/strong> Must have routing that supports required AWS service endpoints (public internet via NAT\/IGW, or VPC endpoints where supported).<\/li>\n<li><strong>Security groups\/NACLs:<\/strong> Must allow required traffic for replication and management. Always use the official port list\u2014verify in docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>CloudTrail<\/strong> to audit MGN actions (who launched test instances, who changed replication settings).<\/li>\n<li>Use <strong>CloudWatch<\/strong> and instance-level monitoring (CloudWatch Agent, logs) on launched EC2 instances.<\/li>\n<li>Use tagging standards for staging resources, migrated instances, and any supporting infrastructure.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  A[Source Server\\n(physical\/VM)] --&gt;|Replication agent\\n(block changes)| B[(AWS Staging Area\\nin your VPC)]\n  B --&gt; C[AWS Application Migration Service\\n(Control plane)]\n  C --&gt;|Test launch \/ Cutover launch| D[Amazon EC2 Instances\\n(Test\/Cutover)]\n  D --&gt; E[(EBS Volumes)]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph OnPrem[\"Source Environment (On-prem \/ Other Cloud)\"]\n    S1[Source Servers\\nWindows\/Linux]\n    NET1[Network egress\\nVPN\/Direct Connect\/Internet]\n    S1 --&gt; NET1\n  end\n\n  subgraph AWS[\"AWS Account (Target Region)\"]\n    subgraph VPC[\"Target VPC\"]\n      subgraph Staging[\"Staging Subnet (private)\"]\n        STGEC2[Staging resources\\n(EC2\/EBS used by MGN)\\nManaged by service]\n        STGEBS[(Replicated EBS volumes)]\n        STGEC2 --- STGEBS\n      end\n\n      subgraph App[\"Application Subnets\"]\n        WEB[EC2 - Web tier]\n        APP[EC2 - App tier]\n        MGMT[Shared services\\n(SSM, patching,\\nmonitoring agents)]\n      end\n\n      SG[Security Groups \/ NACLs]\n    end\n\n    MGN[AWS Application Migration Service\\nControl plane]\n    IAM[IAM\\nRoles\/Policies]\n    CT[CloudTrail]\n    KMS[KMS (optional)\\nEBS encryption keys]\n  end\n\n  NET1 --&gt;|Required endpoints\/ports\\nVerify in docs| STGEC2\n  MGN --&gt; STGEC2\n  MGN --&gt;|Launch test\/cutover| WEB\n  MGN --&gt;|Launch test\/cutover| APP\n  IAM --&gt; MGN\n  MGN --&gt; CT\n  KMS --&gt; STGEBS\n  SG --- Staging\n  SG --- App\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">AWS account and billing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An AWS account with billing enabled.<\/li>\n<li>A target AWS Region selected for the migration (MGN configuration is region-based).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM permissions and roles<\/h3>\n\n\n\n<p>You need IAM permissions to:\n&#8211; Configure AWS Application Migration Service.\n&#8211; Create\/modify VPC resources (or at least select existing subnets\/security groups).\n&#8211; Launch and manage EC2 instances, EBS volumes, and related resources.\n&#8211; View audit logs in CloudTrail.<\/p>\n\n\n\n<p>Common approaches:\n&#8211; Use an administrative role for the lab.\n&#8211; For production, create least-privilege migration operator roles using AWS-managed policies as a starting point, then tighten. Verify the current managed policy names in IAM and official docs.<\/p>\n\n\n\n<p>Also expect AWS Application Migration Service to create\/use a <strong>service-linked role<\/strong> in your account (verify exact role name and permissions in IAM and docs).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Source environment prerequisites<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>One source server you\u2019re allowed to migrate (Linux or Windows).<\/li>\n<li>Ability to install and run the replication agent (local admin\/root access).<\/li>\n<li>Stable outbound network connectivity from source to AWS endpoints (internet\/VPN\/Direct Connect).<\/li>\n<li>If your environment restricts egress, you must allow the required endpoints\/ports per the MGN network requirements documentation (verify in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Console access (recommended for beginners).<\/li>\n<li>Optional: AWS CLI (helpful for validation and cleanup).<\/li>\n<li>Install: https:\/\/docs.aws.amazon.com\/cli\/latest\/userguide\/getting-started-install.html<\/li>\n<li>Configure: <code>aws configure<\/code><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Application Migration Service is available in many (not all) regions. Confirm your target region supports it in the AWS Regional Services List (verify in official AWS docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Review <strong>Service Quotas<\/strong> for AWS Application Migration Service and dependent services (EC2, EBS, VPC).<\/li>\n<li>Confirm limits for:<\/li>\n<li>Number of source servers<\/li>\n<li>Concurrent replications<\/li>\n<li>EBS volume limits and EC2 instance limits in the target region<br\/>\n  Exact numbers can change; check Service Quotas in your account.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services (typical dependencies)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Amazon EC2, Amazon EBS, Amazon VPC<\/li>\n<li>IAM, CloudTrail<\/li>\n<li>(Optional) KMS, Systems Manager<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Always validate current pricing on the official pricing page because pricing changes and varies by region and usage patterns:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Official pricing page: https:\/\/aws.amazon.com\/application-migration-service\/pricing\/<\/li>\n<li>AWS Pricing Calculator: https:\/\/calculator.aws\/#\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (how you are charged)<\/h3>\n\n\n\n<p>AWS Application Migration Service typically has:\n&#8211; A <strong>service fee dimension<\/strong> based on the number of <strong>source servers<\/strong> being replicated and\/or managed for migration (for example, charged per source server-month).<br\/>\n  The exact billing unit, when charges start\/stop, and any free trial\/free period must be confirmed on the pricing page.<\/p>\n\n\n\n<p>In addition, you pay for <strong>underlying AWS resources<\/strong> created\/used during replication, testing, and cutover, such as:\n&#8211; <strong>Amazon EC2<\/strong> instances (staging resources, test instances, cutover instances)\n&#8211; <strong>Amazon EBS<\/strong> volumes and snapshots\n&#8211; <strong>Data transfer<\/strong> (especially source-to-AWS ingress\/egress patterns, inter-AZ transfer, NAT Gateway processing if used)\n&#8211; <strong>Elastic IPs<\/strong> (if allocated), <strong>Load Balancers<\/strong> (if used in target architecture)\n&#8211; <strong>CloudWatch<\/strong> metrics\/log ingestion if you enable enhanced monitoring\/log shipping\n&#8211; <strong>Systems Manager<\/strong> is often low-cost for many use cases, but verify any paid features you enable<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<p>AWS Application Migration Service may offer a free period or promotional pricing in some cases. Do not assume; confirm on the official pricing page.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Primary cost drivers<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Number of source servers<\/strong> under replication\/management and the duration they remain in that state.<\/li>\n<li><strong>Replication data volume and change rate<\/strong> (churn): more disk writes = more replication traffic and staging overhead.<\/li>\n<li><strong>Staging area design<\/strong>:\n   &#8211; Private subnet with NAT Gateway can add significant cost (NAT hourly + per-GB processing).\n   &#8211; Public subnet design may reduce NAT cost but must be secured carefully.<\/li>\n<li><strong>EBS volume size and type<\/strong> used for replicated data.<\/li>\n<li><strong>Test launches<\/strong>: each test instance runs EC2 + EBS and can generate additional costs.<\/li>\n<li><strong>Cutover sizing<\/strong>: instance families\/sizes chosen for production.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs to watch<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>NAT Gateway charges<\/strong> if staging subnet requires outbound internet access via NAT.<\/li>\n<li><strong>Inter-AZ data transfer<\/strong> if staging resources and replication endpoints cross Availability Zones.<\/li>\n<li><strong>Extended parallel run<\/strong>: keeping on-prem and AWS cutover instances running simultaneously during validation.<\/li>\n<li><strong>Operational tooling<\/strong>: third-party monitoring agents, security tooling, backup tools.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Source-to-AWS replication traffic typically enters AWS. In many cases, data transfer <strong>into<\/strong> AWS is cheaper than data transfer out, but billing depends on path, region, and services used. Confirm data transfer pricing here: https:\/\/aws.amazon.com\/ec2\/pricing\/on-demand\/#Data_Transfer  <\/li>\n<li>If replication traverses NAT, you also pay NAT processing charges.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep the pilot small; replicate only what you will test.<\/li>\n<li>Stop replication and decommission staging resources promptly after cutover.<\/li>\n<li>Use waves and schedules to avoid replicating hundreds of servers months ahead of cutover.<\/li>\n<li>Design staging networking to reduce NAT dependence (for example, VPC endpoints where supported, or carefully secured public staging\u2014verify recommended architectures in AWS docs).<\/li>\n<li>Right-size test instances and limit test runtime hours.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A minimal lab typically includes:\n&#8211; 1 small source server\n&#8211; Staging resources (EC2\/EBS) for replication\n&#8211; One short-lived test instance<\/p>\n\n\n\n<p>You can keep costs low by:\n&#8211; Running the test instance briefly (minutes to an hour)\n&#8211; Cleaning up staging promptly\n&#8211; Avoiding NAT Gateway where possible (or keeping the lab short if NAT is required)<\/p>\n\n\n\n<p>Because exact prices vary by region and configuration, use the AWS Pricing Calculator with:\n&#8211; EC2 instance type(s) you expect for staging\/test\n&#8211; EBS volumes sized to your source disks\n&#8211; Estimated GB transferred and hours run<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production migrations, build a cost model per wave:\n&#8211; Number of servers replicated concurrently\n&#8211; Average disk size and daily change rate\n&#8211; Expected replication duration (weeks\/months)\n&#8211; Staging network architecture (NAT vs endpoints)\n&#8211; Number and duration of test launches\n&#8211; Production EC2 + EBS steady-state costs after cutover<\/p>\n\n\n\n<p>Treat migration as a temporary cost spike, then plan a post-migration optimization phase (rightsizing, Savings Plans\/Reserved Instances, storage optimization).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab demonstrates a small, real migration flow: configure AWS Application Migration Service, install the replication agent on a Linux source server, replicate it to AWS, perform a test launch, and then clean up.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Replicate a single Linux source server into AWS using AWS Application Migration Service and launch a test EC2 instance to validate that migration works end-to-end.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Prepare AWS prerequisites (VPC\/subnets and IAM access).\n2. Initialize AWS Application Migration Service and define staging settings.\n3. Add a source server by installing the replication agent (console-guided).\n4. Wait for replication to reach a \u201cready\u201d state.\n5. Launch a <strong>test instance<\/strong>, connect to it, and validate basic functionality.\n6. Clean up test and staging resources to control cost.<\/p>\n\n\n\n<p><strong>Expected time:<\/strong> 60\u2013180 minutes depending on disk size and bandwidth.<br\/>\n<strong>Cost:<\/strong> Varies. Keep it low by using one small source server, small test instance, and cleaning up promptly.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Choose your target AWS Region and prepare a VPC<\/h3>\n\n\n\n<p><strong>Goal:<\/strong> Ensure you have a target network where staging and test instances will run.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the AWS Console, choose a target Region (for example, <code>us-east-1<\/code>). Use a Region close to your source for better replication performance.<\/li>\n<li>Ensure you have a VPC with:\n   &#8211; At least one subnet you can use as the <strong>staging area subnet<\/strong>\n   &#8211; At least one subnet where you want to launch the <strong>test instance<\/strong><\/li>\n<li>Confirm routing:\n   &#8211; If your staging subnet is private, ensure it has egress via NAT Gateway or other approved route for required AWS endpoints.\n   &#8211; If your subnet is public, ensure instances can reach required endpoints and that security is appropriate.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have a VPC, subnets, and routing ready to support staging and test launches.<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; In the VPC console, confirm subnet route tables and whether the subnet is public\/private.\n&#8211; Confirm you can create and attach security groups in the VPC.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Set up IAM access for the lab<\/h3>\n\n\n\n<p><strong>Goal:<\/strong> Ensure your operator identity can configure MGN and launch EC2.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Use an IAM role\/user with permissions to:\n   &#8211; Configure AWS Application Migration Service\n   &#8211; Create and manage EC2\/EBS resources\n   &#8211; Pass required roles (if the workflow requires it)<\/li>\n<li>For a lab, using an admin role is simplest. For real environments, use least privilege.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> You can open AWS Application Migration Service in the console without permission errors.<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; Open the service console: https:\/\/console.aws.amazon.com\/mgn\/\n&#8211; If you see access denied, adjust IAM permissions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Initialize AWS Application Migration Service and configure replication settings<\/h3>\n\n\n\n<p><strong>Goal:<\/strong> Tell MGN where to create the staging area and how replication should behave.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the AWS Application Migration Service console, follow the onboarding\/initialization flow.<\/li>\n<li>Configure <strong>Replication settings<\/strong>, including:\n   &#8211; <strong>Staging area subnet<\/strong> (choose a subnet in your VPC)\n   &#8211; <strong>Security groups<\/strong> for staging resources (use least privilege; start restrictive and open only what docs require)\n   &#8211; <strong>EBS encryption<\/strong> settings (default or KMS CMK depending on requirements)\n   &#8211; Any additional replication parameters available in the console<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> MGN is initialized and ready to accept source servers; staging area configuration is set.<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; In MGN console, confirm replication settings are saved and no warnings are shown.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Prepare a Linux source server (example: Ubuntu) and verify outbound connectivity<\/h3>\n\n\n\n<p><strong>Goal:<\/strong> Ensure the source server is ready for agent install and can reach AWS.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>On the source Linux server, confirm you have root\/sudo access.<\/li>\n<li>Confirm outbound connectivity to AWS:\n   &#8211; DNS resolution works\n   &#8211; HTTPS egress works<\/li>\n<li>If you use a proxy, confirm it is supported by the agent workflow (verify in docs).<\/li>\n<\/ol>\n\n\n\n<p>Run basic checks:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo whoami\ncurl -I https:\/\/aws.amazon.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You can run commands as root and reach the internet\/AWS endpoints.<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; <code>whoami<\/code> returns <code>root<\/code> (or you can use <code>sudo<\/code>).\n&#8211; <code>curl<\/code> returns HTTP headers (200\/301 is fine).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Add the source server in MGN and install the replication agent (console-guided)<\/h3>\n\n\n\n<p><strong>Goal:<\/strong> Register the source server with MGN by installing the AWS Replication Agent.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the MGN console, choose <strong>Add servers<\/strong> (or equivalent).<\/li>\n<li>Select your source OS type (Linux).<\/li>\n<li>The console provides <strong>region-specific download and install commands<\/strong> for the replication agent. Copy those commands exactly.<\/li>\n<\/ol>\n\n\n\n<p>On the source server:\n&#8211; Paste and run the commands shown in the console.<\/p>\n\n\n\n<p><strong>Important security note:<\/strong><br\/>\nDo not hardcode long-lived access keys into scripts or shell history in production. Use the recommended onboarding method shown in the console and follow your organization\u2019s credential-handling policy.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> The source server appears in the MGN console as a discovered\/added source server and begins initial replication.<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; In MGN console, your server shows up under Source servers.\n&#8211; Replication status changes from \u201cnot started\u201d to \u201cinitial sync\u201d (wording varies).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Monitor initial sync until the server is ready for test<\/h3>\n\n\n\n<p><strong>Goal:<\/strong> Wait for replication to complete enough to safely test launch.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In MGN console, open the source server details.<\/li>\n<li>Monitor:\n   &#8211; Replication progress\n   &#8211; Data replication health\n   &#8211; Any errors\/warnings<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> Server reaches a ready state such as \u201cReady for testing\u201d (exact label may vary).<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; MGN shows replication is healthy.\n&#8211; The console indicates test can be launched.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Configure launch settings for the test instance<\/h3>\n\n\n\n<p><strong>Goal:<\/strong> Ensure the launched EC2 instance lands in the right subnet and security groups.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the source server\u2019s launch settings:\n   &#8211; Choose the <strong>target subnet<\/strong> for the test instance.\n   &#8211; Choose security groups that allow:<ul>\n<li>SSH (TCP 22) from your IP for Linux validation (or from a bastion host).<\/li>\n<li>Select an instance type for the test (keep it small for cost).<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> Launch settings are saved and consistent with your VPC security model.<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; Launch settings show the expected subnet and security group IDs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Perform a test launch<\/h3>\n\n\n\n<p><strong>Goal:<\/strong> Launch an EC2 instance from replicated volumes without final cutover.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In MGN console, choose <strong>Test launch<\/strong> for the source server.<\/li>\n<li>Wait for test instance creation to complete.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> A new <strong>test EC2 instance<\/strong> appears in the EC2 console, and MGN marks the test as successful (or provides status).<\/p>\n\n\n\n<p><strong>Verification:<\/strong>\n&#8211; In EC2 console, find the new instance (use tags or launch time).\n&#8211; Confirm the instance is running and has the expected networking.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Connect to the test instance and validate<\/h3>\n\n\n\n<p><strong>Goal:<\/strong> Confirm the OS boots and basic services work.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>If the instance is in a public subnet and has a public IP, you can SSH directly (lab only).<\/li>\n<li>If it\u2019s in a private subnet, use a bastion host or AWS Systems Manager Session Manager.<\/li>\n<\/ol>\n\n\n\n<p>Example SSH (if reachable):<\/p>\n\n\n\n<pre><code class=\"language-bash\">ssh -i \/path\/to\/key.pem ubuntu@&lt;public-ip-or-dns&gt;\n<\/code><\/pre>\n\n\n\n<p>Validation checks:<\/p>\n\n\n\n<pre><code class=\"language-bash\">uname -a\ndf -h\nsystemctl --failed || true\nip a\n<\/code><\/pre>\n\n\n\n<p>If this server runs an app (web server, API, etc.), validate locally:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -I http:\/\/localhost || true\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You can log in, the filesystem looks correct, and key services behave as expected.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 10: Decide next steps (cutover planning)<\/h3>\n\n\n\n<p>For this lab, you will not perform a production cutover. In real migrations, you would:\n&#8211; Freeze changes or schedule a maintenance window.\n&#8211; Perform a final sync\/cutover launch.\n&#8211; Switch traffic (DNS, load balancer targets, routing).\n&#8211; Monitor, then decommission source.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> You understand the difference between test and cutover processes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:\n&#8211; Source server appears in MGN console.\n&#8211; Replication is healthy and reaches readiness for testing.\n&#8211; Test instance launches successfully.\n&#8211; You can connect to the test instance.\n&#8211; OS and disk layout match expectations (within normal cloud differences).\n&#8211; Basic app\/service validation passes (as applicable).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Source server never appears in MGN<\/strong>\n   &#8211; Confirm the agent install command was copied correctly from the console.\n   &#8211; Confirm outbound connectivity and DNS from the source.\n   &#8211; Check local OS logs (varies by distro) and agent logs (location depends on agent; verify in docs).<\/p>\n<\/li>\n<li>\n<p><strong>Replication unhealthy \/ stalled<\/strong>\n   &#8211; Check network path stability (VPN\/ISP).\n   &#8211; Ensure firewalls allow required ports. Don\u2019t guess\u2014use the official network requirements page (verify in docs).\n   &#8211; Ensure staging subnet route table allows required egress (NAT\/IGW\/endpoints).<\/p>\n<\/li>\n<li>\n<p><strong>Test launch fails<\/strong>\n   &#8211; Check IAM permissions (MGN needs to create EC2\/EBS resources).\n   &#8211; Check EC2 quotas (instance limit, EBS volume limit).\n   &#8211; Validate subnet IP capacity.<\/p>\n<\/li>\n<li>\n<p><strong>Instance boots but you cannot SSH<\/strong>\n   &#8211; Security group missing port 22 from your source IP.\n   &#8211; No public IP assigned (public subnet setting).\n   &#8211; Use SSM Session Manager instead (recommended for private access).<\/p>\n<\/li>\n<li>\n<p><strong>Application works on-prem but not on test instance<\/strong>\n   &#8211; Missing dependencies (license server, AD\/DNS, internal endpoints).\n   &#8211; Hardcoded IPs or environment-specific configs.\n   &#8211; Different security boundaries in AWS (SG\/NACL).\n   &#8211; Plan dependency mapping and connectivity early.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, clean up all migration resources you don\u2019t need.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Terminate the <strong>test EC2 instance<\/strong> from the EC2 console.<\/li>\n<li>In AWS Application Migration Service:\n   &#8211; Mark test complete (if required).\n   &#8211; Remove the source server from the service (if you are done).<\/li>\n<li>Delete or reset <strong>staging resources<\/strong> created for replication:\n   &#8211; MGN may manage staging resources; follow the official cleanup guidance to remove staging instances\/volumes safely.<\/li>\n<li>Review and delete:\n   &#8211; Unused EBS volumes\/snapshots created for the lab\n   &#8211; Unused security groups created for staging<\/li>\n<li>Confirm in <strong>Billing and Cost Management<\/strong> that no unexpected resources remain.<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Start with a landing zone:<\/strong> Define VPC structure, subnets, routing, DNS, IAM boundaries, and logging before migrating large waves.<\/li>\n<li><strong>Separate staging and application subnets:<\/strong> Keep staging resources isolated from production subnets.<\/li>\n<li><strong>Plan connectivity for dependencies:<\/strong> AD, DNS, NTP, license servers, API endpoints, SMTP\u2014many migrations fail due to overlooked dependencies.<\/li>\n<li><strong>Use wave planning:<\/strong> Group servers by application and dependency order; migrate shared services early if needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Least privilege:<\/strong> Create dedicated roles for migration operators, with approval workflows for cutover actions.<\/li>\n<li><strong>Use service-linked roles as intended:<\/strong> Don\u2019t over-customize; audit role permissions and CloudTrail logs.<\/li>\n<li><strong>Avoid long-lived access keys on servers:<\/strong> Follow the console onboarding workflow and organizational credential standards.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Time-box replication:<\/strong> Don\u2019t replicate months ahead unless required; replication duration is a cost driver.<\/li>\n<li><strong>Control NAT Gateway spend:<\/strong> NAT charges can dominate staging cost. Evaluate secure alternatives (private endpoints where supported) and keep staging duration short.<\/li>\n<li><strong>Shut down test instances promptly:<\/strong> Tests are valuable but should be scheduled and time-limited.<\/li>\n<li><strong>Tag everything:<\/strong> Use tags like <code>Project<\/code>, <code>Wave<\/code>, <code>App<\/code>, <code>Owner<\/code>, <code>CostCenter<\/code>, <code>Environment<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Measure source churn:<\/strong> High write rates require more bandwidth and staging capacity; plan replication windows accordingly.<\/li>\n<li><strong>Right-size target instances after cutover:<\/strong> Lift-and-shift is not rightsizing. Use CloudWatch metrics and adjust.<\/li>\n<li><strong>Validate storage performance:<\/strong> Ensure EBS volume types and IOPS align with workload needs post-migration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Runbook-driven cutovers:<\/strong> Use documented steps with backout plans.<\/li>\n<li><strong>Test repeatedly:<\/strong> Use test launches to validate OS boot, networking, IAM instance profile, monitoring, and backup.<\/li>\n<li><strong>Multi-AZ architecture after migration:<\/strong> MGN migrates servers; you still need to design for HA (load balancers, Auto Scaling, multi-AZ databases).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Observability baseline:<\/strong> Install monitoring\/logging agents via golden AMIs or post-launch automation.<\/li>\n<li><strong>Patch management:<\/strong> Integrate with Systems Manager Patch Manager or your tooling after cutover.<\/li>\n<li><strong>Backups:<\/strong> Enable AWS Backup (or alternative) for migrated EC2\/EBS where required.<\/li>\n<li><strong>Configuration management:<\/strong> Use SSM, Ansible, or your CM tool to standardize post-cutover state.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use consistent naming for:<\/li>\n<li>Source server records<\/li>\n<li>Test instances vs cutover instances<\/li>\n<li>Waves (<code>Wave-01<\/code>, <code>Wave-02<\/code>)<\/li>\n<li>Enforce tags via SCPs or tag policies (AWS Organizations) where appropriate.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use IAM roles for:<\/li>\n<li>Migration operators (human access)<\/li>\n<li>Automation pipelines (if any)<\/li>\n<li>Service roles used by AWS Application Migration Service<\/li>\n<li>Enforce MFA for human users.<\/li>\n<li>Prefer federation (IAM Identity Center) for enterprise access control.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>In transit:<\/strong> Replication traffic is protected according to the service design; verify exact protocols and port usage in official docs.<\/li>\n<li><strong>At rest:<\/strong> Use EBS encryption for staging and launched volumes. If you require customer-managed keys:<\/li>\n<li>Use KMS CMKs with strict key policies.<\/li>\n<li>Ensure MGN and EC2 roles are allowed to use the key.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep staging resources in private subnets where possible.<\/li>\n<li>Restrict security groups:<\/li>\n<li>No broad inbound rules (<code>0.0.0.0\/0<\/code>) for SSH\/RDP in production.<\/li>\n<li>Use bastion hosts or Session Manager for admin access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not embed secrets in user data or migration scripts.<\/li>\n<li>Use AWS Secrets Manager or Parameter Store for app secrets post-migration.<\/li>\n<li>Rotate any credentials that were present on source servers before migration if required by policy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable CloudTrail organization-wide where possible.<\/li>\n<li>Log and review:<\/li>\n<li>Who initiated test and cutover launches<\/li>\n<li>Changes to replication and launch settings<\/li>\n<li>Ensure EC2 instances ship OS\/application logs to a centralized logging platform.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Confirm region residency requirements.<\/li>\n<li>Confirm encryption and logging meet standards (PCI, HIPAA, ISO, SOC, etc.).<\/li>\n<li>Ensure migrated instances align with vulnerability management and patch SLAs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Leaving test instances running and reachable from the internet.<\/li>\n<li>Using overly permissive security groups for quick troubleshooting and forgetting to tighten them.<\/li>\n<li>Not restricting who can perform cutover launches.<\/li>\n<li>Migrating servers \u201cas-is\u201d with years of accumulated local users, keys, and insecure configs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat migration as a chance to improve baseline security:<\/li>\n<li>Harden AMIs after cutover<\/li>\n<li>Remove unused services<\/li>\n<li>Enforce IMDSv2 on EC2 where possible<\/li>\n<li>Apply least privilege instance profiles<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>This section highlights common constraints; always validate against official docs for your OS and scenario.<\/p>\n<\/blockquote>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Rehost-focused:<\/strong> AWS Application Migration Service is best for lift-and-shift to EC2, not full modernization.<\/li>\n<li><strong>OS support constraints:<\/strong> Not all OS versions are supported. Verify supported Windows\/Linux distributions and kernel requirements in the docs.<\/li>\n<li><strong>Application dependency blind spots:<\/strong> MGN migrates servers, not full application dependencies. Databases, directories, and external services must be planned separately.<\/li>\n<li><strong>Network planning is critical:<\/strong> Most replication issues trace back to routing, DNS, proxies, NACLs, or firewalls.<\/li>\n<li><strong>NAT Gateway surprise bills:<\/strong> Staging area egress through NAT can be expensive.<\/li>\n<li><strong>Quotas can block launches:<\/strong> EC2 instance limits, EBS volume limits, IP capacity in subnets, and service quotas can stop test\/cutover at the worst time.<\/li>\n<li><strong>Identity\/domain issues:<\/strong> Windows domain-joined servers often require careful handling (SID\/domain membership, DNS, GPO). Validate in test.<\/li>\n<li><strong>Licensing:<\/strong> Some commercial software has strict licensing tied to hardware\/host identifiers; validate license portability to EC2.<\/li>\n<li><strong>Cutover is not traffic switching:<\/strong> MGN launches instances; you still need DNS, load balancer registration, routing changes, and rollback planning.<\/li>\n<li><strong>Performance after migration may differ:<\/strong> Instance type, EBS performance, and network architecture in AWS affect behavior; expect tuning.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>AWS Application Migration Service sits within a broader Migration and transfer toolkit. Here\u2019s how it compares to common alternatives.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>AWS Application Migration Service<\/strong><\/td>\n<td>Rehosting server-based workloads to EC2<\/td>\n<td>Continuous replication, test\/cutover workflows, AWS-native orchestration<\/td>\n<td>Not a modernization tool; still need app dependency planning<\/td>\n<td>Lift-and-shift of VMs\/physical servers to EC2 with minimal downtime<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS DataSync<\/strong><\/td>\n<td>File\/object data transfer (NAS, NFS\/SMB, S3\/EFS\/FSx)<\/td>\n<td>Fast, managed transfers; scheduling<\/td>\n<td>Does not migrate running servers\/OS<\/td>\n<td>When you only need to move data, not full servers<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Transfer Family<\/strong><\/td>\n<td>Managed SFTP\/FTPS\/FTP into AWS storage<\/td>\n<td>Protocol-based ingestion<\/td>\n<td>Not a server migration tool<\/td>\n<td>Partner\/customer file exchange into S3\/EFS<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Database Migration Service (AWS DMS)<\/strong><\/td>\n<td>Database migrations\/replication<\/td>\n<td>Supports heterogeneous migrations and CDC<\/td>\n<td>Not for server OS migration<\/td>\n<td>When the primary challenge is the database, not the server<\/td>\n<\/tr>\n<tr>\n<td><strong>VMware Cloud on AWS<\/strong><\/td>\n<td>Keeping VMware operational model in AWS<\/td>\n<td>Minimal app changes; vSphere tooling continuity<\/td>\n<td>Cost and operational model differ; not EC2<\/td>\n<td>When you want VMware stacks in AWS with minimal replatforming<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Migrate (Microsoft Azure)<\/strong><\/td>\n<td>Migrating servers to Azure<\/td>\n<td>Integrated Azure assessment and migration<\/td>\n<td>Target is Azure, not AWS<\/td>\n<td>Choose if your destination cloud is Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Migrate to Virtual Machines (Google Cloud)<\/strong><\/td>\n<td>Migrating servers to Google Cloud<\/td>\n<td>VM migration tooling for GCP<\/td>\n<td>Target is GCP, not AWS<\/td>\n<td>Choose if your destination cloud is Google Cloud<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed replication (rsync, imaging, backups)<\/strong><\/td>\n<td>Small, bespoke migrations<\/td>\n<td>Full control; can be low tooling cost<\/td>\n<td>High engineering effort; higher risk; fewer guardrails<\/td>\n<td>Only for small one-off cases or specialized constraints<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: regulated company data center exit<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A regulated enterprise must exit two data centers in 9 months, migrating 1,200 VMs (mixed Windows\/Linux) into AWS while meeting strict audit and encryption requirements.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>AWS landing zone with separate accounts for networking, security, and workloads (AWS Organizations).<\/li>\n<li>Hub-and-spoke VPCs with centralized egress and inspection.<\/li>\n<li>AWS Application Migration Service configured per workload account\/region with isolated staging subnets.<\/li>\n<li>Post-launch automation via Systems Manager to install security agents, monitoring, and enforce configuration baselines.<\/li>\n<li>CloudTrail centralized to a security account; EBS encryption with KMS CMKs where required.<\/li>\n<li><strong>Why AWS Application Migration Service was chosen:<\/strong><\/li>\n<li>Continuous replication reduces downtime.<\/li>\n<li>Test launches support audit-friendly evidence (test results, signoffs).<\/li>\n<li>Scales with wave-based migration factory execution.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Predictable weekly cutovers.<\/li>\n<li>Reduced migration risk through repeatable testing.<\/li>\n<li>Clear audit trail of migration actions and configuration changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: moving from a single colo server to AWS<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A startup runs a single Ubuntu VM in a colocation facility; hardware failures and limited scaling are causing outages.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>One VPC with public\/private subnets.<\/li>\n<li>MGN replicates the source server; test launch validates boot and app functionality.<\/li>\n<li>Cutover launches EC2; DNS switched to Route 53; backups enabled with AWS Backup.<\/li>\n<li><strong>Why AWS Application Migration Service was chosen:<\/strong><\/li>\n<li>Minimal changes required to the application.<\/li>\n<li>Fast path to get out of the colo environment.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Faster recovery from failures (EC2 redeployability).<\/li>\n<li>Better observability and backups.<\/li>\n<li>Ability to iterate toward a more cloud-native architecture later.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Is AWS Application Migration Service only for on-premises migrations?<\/strong><br\/>\n   No. It\u2019s commonly used for on-premises, but it can also migrate VMs running in other clouds or remote environments as long as the source servers can install the agent and reach required AWS endpoints.<\/p>\n<\/li>\n<li>\n<p><strong>Does AWS Application Migration Service migrate to containers (ECS\/EKS)?<\/strong><br\/>\n   No. It primarily rehosts servers into <strong>Amazon EC2<\/strong>. Containerization is a separate modernization effort.<\/p>\n<\/li>\n<li>\n<p><strong>What is the difference between a test launch and a cutover launch?<\/strong><br\/>\n   A <strong>test launch<\/strong> is for validation and does not represent final production cutover. A <strong>cutover launch<\/strong> is used when you are ready to migrate production traffic to AWS.<\/p>\n<\/li>\n<li>\n<p><strong>How much downtime should I expect?<\/strong><br\/>\n   Downtime depends on final sync time, application shutdown\/startup requirements, and traffic switching (DNS\/LB). Continuous replication reduces data delta, but you must design a cutover plan.<\/p>\n<\/li>\n<li>\n<p><strong>Can I run multiple test launches?<\/strong><br\/>\n   Generally yes; repeated testing is a best practice. Verify the exact lifecycle behavior in the current docs.<\/p>\n<\/li>\n<li>\n<p><strong>Do I need a VPN or Direct Connect?<\/strong><br\/>\n   Not strictly, but you need reliable connectivity. VPN\/Direct Connect is common for enterprises; small labs might replicate over the internet.<\/p>\n<\/li>\n<li>\n<p><strong>Does MGN handle DNS cutover automatically?<\/strong><br\/>\n   No. You must switch traffic using DNS updates, load balancer changes, or routing changes.<\/p>\n<\/li>\n<li>\n<p><strong>Does it migrate databases too?<\/strong><br\/>\n   It can replicate the database server as a server rehost, but it doesn\u2019t replace database-native migration tools. For many databases, AWS DMS (and\/or native replication) is the better approach.<\/p>\n<\/li>\n<li>\n<p><strong>What AWS resources will I see created in my account?<\/strong><br\/>\n   You should expect staging resources and replicated EBS volumes, plus any test\/cutover EC2 instances you launch. Exact resources depend on settings\u2014review the service documentation.<\/p>\n<\/li>\n<li>\n<p><strong>How do I keep costs under control during migration?<\/strong><br\/>\n   Limit the number of concurrently replicated servers, reduce replication duration, avoid leaving test instances running, and pay attention to NAT and data transfer costs.<\/p>\n<\/li>\n<li>\n<p><strong>Is the staging area accessible from my production subnets?<\/strong><br\/>\n   It can be, depending on your VPC design\u2014but it\u2019s best to isolate staging in its own subnet and restrict security group rules.<\/p>\n<\/li>\n<li>\n<p><strong>Can I use customer-managed KMS keys for encryption?<\/strong><br\/>\n   Often yes for EBS encryption, but the exact configuration and key policy requirements should be validated in official docs for your environment.<\/p>\n<\/li>\n<li>\n<p><strong>What are the most common reasons migrations fail?<\/strong><br\/>\n   Network\/firewall issues, missing IAM permissions, quota limits, and unplanned application dependencies.<\/p>\n<\/li>\n<li>\n<p><strong>Is AWS Application Migration Service the same as CloudEndure?<\/strong><br\/>\n   AWS Application Migration Service is the current AWS service for this use case and is the successor to the CloudEndure Migration experience. Many concepts are similar, but follow current MGN docs.<\/p>\n<\/li>\n<li>\n<p><strong>Can I migrate Linux and Windows with the same process?<\/strong><br\/>\n   The workflow is similar, but agent installation, drivers, and post-launch validation differ. Always test each OS\/app combination.<\/p>\n<\/li>\n<li>\n<p><strong>Do I need to stop the source server during replication?<\/strong><br\/>\n   Typically no for ongoing replication, but you may stop or quiesce writes during final cutover to ensure consistency, depending on your application requirements.<\/p>\n<\/li>\n<li>\n<p><strong>How do I roll back if cutover fails?<\/strong><br\/>\n   Keep the source system intact until validation completes, and have a documented rollback plan (DNS\/traffic reversal, app startup on source).<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn AWS Application Migration Service<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official Documentation<\/td>\n<td>AWS Application Migration Service Docs \u2014 https:\/\/docs.aws.amazon.com\/mgn\/<\/td>\n<td>Primary source for features, workflows, networking, and troubleshooting<\/td>\n<\/tr>\n<tr>\n<td>Official Pricing<\/td>\n<td>AWS Application Migration Service Pricing \u2014 https:\/\/aws.amazon.com\/application-migration-service\/pricing\/<\/td>\n<td>Accurate, current pricing model and billing dimensions<\/td>\n<\/tr>\n<tr>\n<td>Pricing Tool<\/td>\n<td>AWS Pricing Calculator \u2014 https:\/\/calculator.aws\/#\/<\/td>\n<td>Build scenario-based cost estimates including EC2\/EBS\/data transfer<\/td>\n<\/tr>\n<tr>\n<td>Console<\/td>\n<td>AWS Application Migration Service Console \u2014 https:\/\/console.aws.amazon.com\/mgn\/<\/td>\n<td>Hands-on configuration and migration execution<\/td>\n<\/tr>\n<tr>\n<td>Security\/Audit<\/td>\n<td>AWS CloudTrail Docs \u2014 https:\/\/docs.aws.amazon.com\/awscloudtrail\/latest\/userguide\/cloudtrail-user-guide.html<\/td>\n<td>Auditing MGN actions and governance<\/td>\n<\/tr>\n<tr>\n<td>Compute<\/td>\n<td>Amazon EC2 Docs \u2014 https:\/\/docs.aws.amazon.com\/ec2\/<\/td>\n<td>Instance launch, storage, networking, and operations after migration<\/td>\n<\/tr>\n<tr>\n<td>Storage<\/td>\n<td>Amazon EBS Docs \u2014 https:\/\/docs.aws.amazon.com\/ebs\/<\/td>\n<td>Understand volume types, encryption, snapshots, performance<\/td>\n<\/tr>\n<tr>\n<td>Networking<\/td>\n<td>Amazon VPC Docs \u2014 https:\/\/docs.aws.amazon.com\/vpc\/<\/td>\n<td>Subnet routing, security groups, endpoints used during migration<\/td>\n<\/tr>\n<tr>\n<td>Automation\/Ops<\/td>\n<td>AWS Systems Manager Docs \u2014 https:\/\/docs.aws.amazon.com\/systems-manager\/<\/td>\n<td>Post-launch actions, patching, and secure instance access<\/td>\n<\/tr>\n<tr>\n<td>Architecture Guidance<\/td>\n<td>AWS Architecture Center \u2014 https:\/\/aws.amazon.com\/architecture\/<\/td>\n<td>Reference architectures and migration patterns (search for MGN-related guidance)<\/td>\n<\/tr>\n<tr>\n<td>Video Learning<\/td>\n<td>AWS YouTube Channel \u2014 https:\/\/www.youtube.com\/user\/AmazonWebServices<\/td>\n<td>Recorded sessions and migration talks (search for \u201cApplication Migration Service\u201d \/ \u201cMGN\u201d)<\/td>\n<\/tr>\n<tr>\n<td>Migration Strategy<\/td>\n<td>AWS Migration Hub \u2014 https:\/\/aws.amazon.com\/migration-hub\/<\/td>\n<td>Portfolio tracking and migration program governance (adjacent service)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>The following institutes may offer training relevant to AWS migration and AWS Application Migration Service. Verify current course availability and delivery modes on their websites.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, cloud engineers<\/td>\n<td>DevOps + cloud operations; may include AWS migration topics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate IT professionals<\/td>\n<td>Software configuration management and DevOps foundations; may include cloud\/migration modules<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations teams<\/td>\n<td>CloudOps practices, operations, automation; may cover AWS migration operations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, platform engineers<\/td>\n<td>Reliability engineering practices; operating workloads after migration<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops and monitoring teams<\/td>\n<td>AIOps concepts; monitoring\/automation relevant post-migration<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>The following sites are presented as training resources or platforms. Confirm specific AWS Application Migration Service coverage directly on each site.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content<\/td>\n<td>Students, engineers seeking practical guidance<\/td>\n<td>https:\/\/www.rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training<\/td>\n<td>Beginners to intermediate DevOps engineers<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance\/consulting-style DevOps enablement<\/td>\n<td>Teams needing hands-on help and coaching<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training<\/td>\n<td>Ops teams needing implementation support<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>The following consulting organizations may help with AWS migrations and operationalization. Verify exact service offerings, references, and engagement models on their websites.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps services<\/td>\n<td>Migration planning, implementation support, cloud operations<\/td>\n<td>Landing zone readiness checks; migration wave execution; post-migration ops setup<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and training<\/td>\n<td>DevOps enablement around migration programs<\/td>\n<td>Migration runbooks; automation; monitoring and CI\/CD alignment post-migration<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps and cloud consulting<\/td>\n<td>Advisory and implementation<\/td>\n<td>IAM and security hardening; cost optimization during migrations; operational handover<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before AWS Application Migration Service<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS fundamentals:<\/strong> IAM, VPC, EC2, EBS, security groups, route tables<\/li>\n<li><strong>Linux\/Windows administration:<\/strong> services, disks, boot process, networking<\/li>\n<li><strong>Networking basics:<\/strong> DNS, routing, NAT, firewalls, VPN concepts<\/li>\n<li><strong>Migration fundamentals:<\/strong> rehost vs replatform vs refactor, dependency mapping, cutover planning<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after AWS Application Migration Service<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Operational excellence on AWS:<\/strong> CloudWatch, Systems Manager, patching, backup\/restore<\/li>\n<li><strong>Cost optimization:<\/strong> rightsizing, Savings Plans, storage optimization<\/li>\n<li><strong>Resilience patterns:<\/strong> multi-AZ, load balancing, Auto Scaling, DR strategies<\/li>\n<li><strong>Modernization pathways:<\/strong> containers (ECS\/EKS), managed databases, serverless where appropriate<\/li>\n<li><strong>Security maturity:<\/strong> KMS key management, centralized logging, incident response<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud engineer \/ platform engineer<\/li>\n<li>Solutions architect<\/li>\n<li>DevOps engineer \/ SRE<\/li>\n<li>Migration specialist \/ migration factory engineer<\/li>\n<li>Security engineer (migration governance and validation)<\/li>\n<li>IT infrastructure engineer transitioning to cloud<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (AWS)<\/h3>\n\n\n\n<p>AWS certifications don\u2019t typically certify a single service, but these align well:\n&#8211; <strong>AWS Certified Solutions Architect \u2013 Associate\/Professional<\/strong>\n&#8211; <strong>AWS Certified SysOps Administrator \u2013 Associate<\/strong>\n&#8211; <strong>AWS Certified DevOps Engineer \u2013 Professional<\/strong><br\/>\nVerify current certification names and exam guides at: https:\/\/aws.amazon.com\/certification\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Migrate a small Linux web server VM into AWS and front it with an Application Load Balancer.<\/li>\n<li>Build a \u201cmigration wave\u201d plan for 20 mock servers (grouping, tagging, runbooks).<\/li>\n<li>Create post-launch automation to install CloudWatch Agent and register with a patch baseline.<\/li>\n<li>Run a cost analysis comparing NAT vs alternative staging egress designs (using Pricing Calculator).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>MGN:<\/strong> Common shorthand for AWS Application Migration Service.<\/li>\n<li><strong>Rehost (lift-and-shift):<\/strong> Moving an application\/server to the cloud with minimal changes.<\/li>\n<li><strong>Source server:<\/strong> The original machine (physical\/VM\/cloud VM) you are migrating from.<\/li>\n<li><strong>Replication agent:<\/strong> Software installed on the source server to replicate disk data to AWS.<\/li>\n<li><strong>Continuous replication:<\/strong> Ongoing replication of changed disk blocks after initial sync.<\/li>\n<li><strong>Staging area:<\/strong> AWS-side resources in your account\/VPC that receive and maintain replicated data.<\/li>\n<li><strong>Test launch:<\/strong> Launching an EC2 instance in AWS for validation without final production cutover.<\/li>\n<li><strong>Cutover launch:<\/strong> Launching the production EC2 instance intended to take over live traffic.<\/li>\n<li><strong>Landing zone:<\/strong> A standardized AWS environment (accounts, networking, security, logging) designed for workloads.<\/li>\n<li><strong>Security group:<\/strong> Stateful virtual firewall controlling inbound\/outbound traffic to AWS resources.<\/li>\n<li><strong>NACL (Network ACL):<\/strong> Stateless subnet-level traffic filter in a VPC.<\/li>\n<li><strong>NAT Gateway:<\/strong> Managed service enabling private subnets to access the internet\/AWS services; can be a major cost driver.<\/li>\n<li><strong>EBS encryption:<\/strong> Encryption at rest for EBS volumes using AWS-managed keys or KMS CMKs.<\/li>\n<li><strong>CloudTrail:<\/strong> AWS service that records API activity for audit and governance.<\/li>\n<li><strong>Wave:<\/strong> A batch of servers migrated together in a planned sequence.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>AWS Application Migration Service is AWS\u2019s primary Migration and transfer service for <strong>rehosting server-based workloads into Amazon EC2<\/strong> using continuous replication and structured test\/cutover workflows. It matters because it reduces migration downtime and operational risk while providing a repeatable process that scales from a single server to large migration factories.<\/p>\n\n\n\n<p>It fits best when you want to move existing VMs\/physical servers to AWS quickly, keep application changes minimal, and validate with test launches before cutover. Cost-wise, focus on the number of servers replicated, staging resource usage, NAT\/data transfer charges, and the runtime of test\/cutover instances. Security-wise, prioritize least-privilege IAM, staging network isolation, encryption alignment with policy, and auditable operations via CloudTrail.<\/p>\n\n\n\n<p>Use AWS Application Migration Service when lift-and-shift to EC2 is the goal; choose specialized services like AWS DMS or AWS DataSync when you\u2019re migrating databases or file datasets rather than full servers. The best next step is to run a small pilot, document a cutover runbook, and then scale using waves with strong tagging, quota checks, and post-launch automation.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Migration and transfer<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,35],"tags":[],"class_list":["post-287","post","type-post","status-publish","format-standard","hentry","category-aws","category-migration-and-transfer"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/287","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=287"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/287\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=287"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=287"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=287"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}