AWS Step-by-Step

Migrating Workloads with AWS Application Migration Service, Part 1

Although this service won't take the place of proper migration planning, it can be used to assist with the actual migration of physical or virtual servers.

• By Brien Posey
• 09/13/2024

Migrating servers to the cloud is always a complex process that requires extensive planning. However, the AWS Application Migration Service can make migrating easier. Although this service cannot take the place of proper migration planning, it can be used to assist with the actual migration of physical or virtual servers. These servers can be located on-premises or even in other clouds.

In this two-part series, I will show you how to migrate a Windows Server to AWS.

To get started, sign into AWS and navigate to the AWS Application Migration Service. Click the Get Started button and you will be taken to the Set up Application Migration Service screen. This screen explains that before you can use the Application Migration Service, you will have to complete an initialization process. It is worth noting that this initialization process is region-specific, so if you plan to migrate workloads to multiple regions, you will have to complete a separate initialization process for each region.

To initialize the service, verify your region and then click the Set Up Service button, shown in Figure 1. After a few seconds, you should see a message telling you that the default templates have been created. AWS creates replication, launch and post-launch templates.

Creating an IAM Role
The next thing that you will need to do is to create an IAM role that will convey the required credentials. It is worth noting that you can use temporary credentials unless you plan to perform agentless, snapshot-based migration from a VMware environment. Because of the complexity involved in setting up temporary credentials, however, I am going to walk you through the process of creating permanent IAM credentials, which you can always delete when you are finished using them.

Open the IAM Service and then click on the Roles tab. Click the Create Role button. When you do, you will be taken to a screen that asks you to choose a trusted entity type. Set the Trusted Entity Type option to AWS Service and choose EC2 as the service or use case, as shown in Figure 2.

Click Next, and you will be asked to choose the permissions that you want to assign to the role. This screen lists a number of permissions policies. There are three policies that you will need to assign to the role. You can assign a permission by selecting its checkbox. Because there are over 900 permissions to choose from, it's best to use the search box to locate the required permissions. The permissions that you will need to assign are:

• AWSApplicationMigrationAgentPolicy
• AWSApplicationMigrationReplicationServerPolicy
• AWSApplicationMigrationConversionServerPolicy

At this point, the AWS console will take you to the Name, Review, and create screen. Here, you will need to assign a name for the role. I am going to call the role Migrate, but you can use any name that you want. When you are done naming the role, click the Create Role button. You should see a message telling you that the role has been created.

Create an IAM User
Now that you have created an IAM role, you will need to create an IAM user. This is the user account that will be used to perform the migration. To get started, open the IAM console and select the Users tab. Next, click on the Create User button. This will cause the console to display the Specify User Details screen. Here you will need to enter a name for the IAM user you are creating. I am going to call my user account EC2_Migration, but again, you can use any name that you want.

Be sure to select the option to provide the user access to the AWS management console. You can either manually assign a password to the user, or you can use an automatically generated password, as shown in Figure 4.

You don't really have to do anything on the next few screens. Just click Next, followed by Create User, and Return to Users List.

Create an IAM Policy
The next step in the process is to create an IAM policy and then assign that policy to the user account that you have just created. To do so, select the Policies tab within the IAM console, then click the Create Policy button. When the Specify Permissions screen appears, select the JSON Policy Editor option and paste the following code (any existing code should be replaced):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "mgn:*",
        "ec2:DescribeInstances",
        "ec2:DescribeRegions",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcs",
        "ec2:CreateTags"
      ],
      "Resource": "*"
    }
  ]
}

You can see what this looks like in Figure 5.

Click Next, and you will be prompted to assign a name to your policy. I am going to call my policy "AWS-EC2-Migration-Policy," but you can use any name that you want. Click the Create Policy button to create the policy.

Assigning Your Policy
Now that the new policy has been created, you will need to assign the policy to the IAM account that you created earlier. To do so, select the Users tab and then click on the user account that you created. Now, click the Add Permissions button and select the Add Permissions option. When prompted, select the Attach Policies Directly option and then select the checkbox corresponding to the policy that you created earlier. Again, there are over 1,200 policies on the list, so it's a good idea to use the search box to narrow down the list. When you have made your selection, click Next, followed by Add Permissions.

Retrieving the User's Keys
The last thing that I want to cover in Part 1 is how to retrieve the keys that will be necessary in order to use the user account. To do so, select the Users tab within the IAM console. Click on the IAM user that you created earlier, then select the Security Credentials tab on the resulting page. Scroll down to the Access Keys section and click the Create Access Key button. When you do, you will be taken to the Access Key Best Practices and Alternatives screen. Choose the Other option and click Next, followed by Create Access Key.

The resulting screen will display the access key and the corresponding secret key, although you will have to click the Show link in order to display the secret key. It's extremely important to document both the access key and the secret key right now, because you will not be able to access the secret key later.

Since all of the required permissions are now in place, we can move forward with the migration process. I will walk you through a migration in Part 2.