Avoid affecting your production environment during migration with AWS Application Migration Service
AWS Architecture BlogAvoid affecting your production environment during migration with AWS Application Migration Serviceby Michael Spence | on28 FEB 2022| inArchitecture,AWS Application Migration Service,Migration & Transfer Services,Technical How-to|Permalink|ShareCustomers commonly useAWS Application Migration Service to migrateActive Directoryjoined Windows or Linux servers to Amazon Web Services (AWS). However, this process can affect the production environment during testing. For example, if you update DNS addresses during testing, clients that try to reach the original server will be redirected to the testing server.To avoid this issue, you could launch instances in a completely isolated network environment. However, this may not be an option for you if your application stack depends on other applications or services.In this post, we offer an architecture and process that can be applied to applications that cannot be completely isolated during testing. It usesMicrosoft Domain Name System (DNS) Query Policiesand a Group Policy and does not affect the production environment.Overview of solutionUsing a simple application stack of a WordPress site as an example, we’ll show you how to implement this solution. We’ll also discuss the prequisites required to implement this solution and describe potential domain issues you may encounter and how to solve them.Figure 1 shows a view of the testing architecture on-premises and in AWS:It uses anAmazon Virtual Private Cloud (Amazon VPC)that was set up specifically for testing.Within this Amazon VPC, a management subnet that runs onAmazon Elastic Compute Cloud (Amazon EC2)contains the production environment’s self-managed domain controller. This domain controller provides authentication and DNS services to the instances launched during testing.The client that tests the application is located within the same private subnet as the applications being tested.Figure 1. Testing architecture designPrerequisitesTo implement this solution, you will need:An AWS accountNetwork connectivity between an on-premises server (or other cloud) and AWSActive Directory (Windows Server 2016 or later)Active Directory Integrated DNSBasic understanding of the following technologies:Application Migration ServiceEC2 launch templatesActive Directory (Windows Version 2016, 2019, or 2022)Microsoft Group PolicyActive Directory Integrated DNSWindows PowerShellPotential domain issues and how to solve themApplication Migration Service is a block-level replication of the original source server, meaning that the replicated server is an exact copy of the original server. During testing, the original source server and the server that was launched for testing are active on the domain at the same time.This has the potential to create these issues:Each server joined to an Active Directory domain has an associated computer object, and that object has a password. The server will change this password automatically every 30 days by default.If either server changes the password for that object, it will cause the other server to fail because it cannot establish a secure session with a domain controller.Active Directory supports dynamic DNS updates by allowing servers to register and dynamically update their resource records.If the replicated server updates DNS with a new IP address, that change can propagate to the rest of the environment. This means that clients trying to reach the original server will be redirected to the testing server, which will affect the production environment.By creating a new Group Policy Object (GPO) with the following settings (and as shown in Figure 2), you can avoid these potential issues.Disable Machine Password Changes.Use reverse logic notation to enable the setting to disable the automatic password changes on the server.Disable Dynamic Updates from the DNS Client.This setting will prevent the server from updating DNS with a new IP address when you are testing it.Apply this newly created GPO to the servers that are being migrated. The servers can be targeted for the policy by Active Directory security group, or you can move the servers to a separate organizational unit (OU) within Active Directory and apply the GPO to that OU.Figure 2. GPO settingsAfter you apply GPO settings to the server being migrated, verify the GPO settings from an administrative command prompt:C:\> gpupdate /forceC:\> gpresult /r /scope computerActive Directory replicationYou can disable outbound replication from the domain controller in the testing VPC while still allowing inbound replication. We intentionally configured the network configuration within the testing VPC to allow connectivity to on-premises and other networks.To do this, issue the following command from an administrative command prompt with a domain administrator privileged user:C:\> repadmin /options <Testing DC> +disable_outbound_replExample walkthrough1.Example application descriptionLet’s look at a simple application stack of a WordPress site. It consists of a single web server and a single database server that are being migrated from on-premises to AWS. The WordPress stack could be Linux or Windows. The WordPress configuration on the web server points to the database by hostname only (not by IP address).When the web server starts up during the testing phase, it issues a DNS query to find the database server by name. Note that we don’t want to return the IP address of the current production database server; we want the one currently being tested. When our workstation in the testing VPC opens up a browser to the WordPress site, we also want it to return the IP address of the web server being tested.For reference, Table 1 reflects the IP addresses, network information, and URL used in the testing example.Table 1. Example values for the testing scenarioTesting Private Subnet CIDR10.0.67.0/24Domain Zone Nameawslaunch.localWordPress Site URLhttp://wswpweb1HostnameOriginal IP AddressTesting IP Addresswswpweb110.0.4.17110.0.67.171wswpsql110.0.4.20210.0.67.2022.Modify EC2 launch templatesTo ensure that we launch the EC2 instances with the IP addresses we specified in Table 1, let’s change the EC2 launch template associated with each of the source servers from within Application Migration Service. The EC2 launch template should specify the testing subnet and the IP address to be assigned to the test instances.Figure 3. EC2 launch template settingsOnce you’ve modified the EC2 launch template, be sure to set it as the “Default” template because this is the version of the template that Application Migration Service will launch upon testing.3.Create Microsoft DNS Query PoliciesNow that we’ve launched the EC2 instances for testing, let’s set up DNS Query Policies for DNS to return an alternate set of IP addresses during the testing phase.We’ll set these policies to return alternate IP addresses from DNS for the servers involved in testing and only within the boundary of the testing private subnet (Policy 3.4). By doing this, if any client outside of the testing private subnet queries this domain controller, it will return the original IP addresses and not the testing ones.Because DNS Query Policies are specific to a specific domain controller, let’s issue the following PowerShell commands on the domain controller that is active in our testing VPC (AD-DC-2 in Figure 1) to create the following policies:Policy 3.1A client subnet that represents our private subnet in the testing VPC. This is a one-time configuration.Add-DnsServerClientSubnet -Name"MGN-Testing-AZ1" -IPv4Subnet "10.0.67.0/24"Policy 3.2A zone scope within the domain zone name. This is a one-time configuration.Add-DnsServerZoneScope -ZoneName"awslaunch.local" -Name "MGN-Testing-AZ1-Scope"Policy 3.3Alternative IP addresses in the new zone scope.Add-DnsServerResourceRecord -ZoneName"awslaunch.local" -A -Name "wswpweb1" -IPv4Address"10.0.67.171" -ZoneScope "MGN-Testing-AZ1-Scope"Add-DnsServerResourceRecord -ZoneName"awslaunch.local" -A -Name "wswpsql1" -IPv4Address"10.0.67.202" -ZoneScope "MGN-Testing-AZ1-Scope"Policy 3.4A query resolution policy that returns alternate IP addresses for our testing servers without impacting the rest of the domain.Add-DnsServerQueryResolutionPolicy -Name"MGN-Testing-AZ1-Policy" -Action ALLOW -FQDN "eq,wswpweb1.awslaunch.local,wswpsql1.awslaunch.local"-ClientSubnet "eq,MGN-Testing-AZ1" -ZoneScope"MGN-Testing-AZ1-Scope,1" -ZoneName "awslaunch.local"4.Verify current production IP addressesNow that we have our policies set, let’s make sure that the application stack IP addresses are still returning correctly from the current production environment with the following command:C:\>nslookup wswpweb1Server: WSDC1.awslaunch.localAddress: 10.0.5.10Name: wswpweb1.awslaunch.localAddress:10.0.4.171C:\>nslookup wswpsql1Server: WSDC1.awslaunch.localAddress: 10.0.5.10Name: wswpsql1.awslaunch.localAddress:10.0.4.202These are the correct IP addresses. They match the original IP addresses from Table 1.5.Verify testing IP addressesNow let’s verify that the application stack IP addresses are returning correctly from the testing environment.C:\>nslookup wswpweb1Server: WSDC5.awslaunch.localAddress: 10.0.69.10Name: wswpweb1.awslaunch.localAddress:10.0.67.171C:\>nslookup wswpsql1Server: WSDC5.awslaunch.localAddress: 10.0.69.10Name: wswpsql1.awslaunch.localAddress:10.0.67.202There are the correct addresses. They match the testing IP addresses from Table 1.We can also verify that the WordPress site is functional by opening a browser from our testing client and browsing to the URL (https://wswpweb1, listed in Table 1).Figure 4. WordPress site verificationAdditionally, we can verify that the web server is connecting to the correct SQL server database by issuing the following command when logged into the WordPress web server:C:\ >netstat | findstr /c:"ms-sql-s"TCP 10.0.67.171:50355 10.0.67.202:ms-sql-s TIME_WAITTCP 10.0.67.171:5036110.0.67.202:ms-sql-sTIME_WAIT6.CleanupAfter you’ve tested everything, mark the source servers in Application Migration Service as “Ready for Cutover.” This will terminate the EC2 testing instances.The following PowerShell commands will remove the DNS resource records and the DNS Query Policy:Remove-DnsServerResourceRecord -ZoneName"awslaunch.local" -ZoneScope "MGN-Testing-AZ1-Scope"-RRType "A" -Name "wswpweb1"Remove-DnsServerResourceRecord -ZoneName"awslaunch.local" -ZoneScope "MGN-Testing-AZ1-Scope"-RRType "A" -Name "wswpsql1"Remove-DnsServerQueryResolutionPolicy -Name"MGN-Testing-AZ1-Policy" -ZoneName "awslaunch.local"This command will re-enable replication from the testing domain controller.C:\> repadmin /options <Testing DC>-disable_outbound_replOnce the servers are launched for final cutover, you can remove the Group Policy applied to the servers to allow the server to resume password changes and dynamic DNS updates.ConclusionWhen you migrate your server resources to AWS with Application Migration Service, the testing phase of the migration lifecycle is critical. It verifies that your application will function properly within the AWS environment before committing to a final cutover. The testing phase can uncover unexpected application dependencies, gauge application performance, and deliver the confidence that your migration to AWS will be successful without risks to your production environment.In this blog post, we explored an architecture and process that uses Microsoft DNS Query Policies and Group Policy to address potential domain issues and avoids affecting the production environment. This testing framework persists during the entire cloud migration and across multiple application migrations. Once migration is complete, the testing architecture can be removed or maintained for future cloud migrations.Ready to get started?Read more about theAWS Application Migration Serviceand other blog posts related to migrations on theAWS Cloud Enterprise Strategy Blogand theAWS Architecture Blog.Looking for more architecture content?AWS Architecture Centerprovides reference architecture diagrams, vetted architecture solutions,Well-Architectedbest practices, patterns, icons, and more!Michael SpenceMichael is a Senior Solutions Architect based out of Tennessee. He has extensive experience in enterprise cloud migrations. He is currently working with AWS partners in the WWPS focused on migrations. He has a Master of Science degree in Software Engineering from East Tenn. State University and believes in quote: “The most damaging phrase in the language is ‘We’ve always done it this way’.” - Adm. Grace Hopper
Customers commonly use AWS Application Migration Service to migrate Active Directory joined Windows or Linux servers to Amazon Web Services (AWS). However, this process can affect the production environment during testing. For example, if you update DNS addresses during testing, clients that try to reach the original server will be redirected to the testing server. […]
Michael Spence
Architecture AWS Application Migration Service Migration & Transfer Services Technical How-to