Introduction
In continuation of Part 1, we’ll delve deeper into the Application Migration Service, focusing on downloading and configuring the replication agent on the source servers. Additionally, we’ll explore how all launched instances can follow a global template to ensure consistent configuration settings, and how to run scripts after launch for further customization.
Prerequisites
- AWS account
- AWS IAM Account with necessary privileges
- AWS IAM Account with programmatic access to replicate from source to AWS
- the AWS Managed Policy to attach is called AWSApplicationMigrationAgentPolicy and has an ARN of arn:aws:iam::aws:policy/AWSApplicationMigrationAgentPolicy
- AWS VPC with subnets
Replication Agent Installation
Windows (Powershell)
- Pull down the agent locally to the source (replace us-east-1 region with your region)
Start-BitsTransfer https://aws-application-migration-service-us-east-1.s3.us-east-1.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe- Install agent without any prompts/user intervention
.\AwsReplicationWindowsInstaller.exe --region 'us-east-1' --aws-access-key-id <programmatic access key for replication IAM user object> --aws-secret-access-key <programmatic secret access key for replication IAM user object> --no-promptOther parameters of note include:
- –region – the region where the installer will register the source machine
- –aws-session-token – this is used for temporary credentials along with the access key and secreat access key
- –devices – allows you to specify only those disks you want to replicate
- Confirm successful installation and replication start on the source machine
- Confirm successful replication has been initiated in the AWS MGM Console
Linux
- Pull down the agent locally to the source (replace us-east-1 region with your region)
wget -O ./aws-replication-installer-init.py https://aws-elastic-disaster-recovery-us-east-1.s3.us-east-1.amazonaws.com/latest/linux/aws-replication-installer-init.py- Install agent without any prompts/user intervention
sudo python3 aws-replication-installer-init.py --region us-east-1 --aws-access-key-id <programmatic access key for replication IAM user object> --aws-secret-access-key <programmatic secret access key for replication IAM user object> --no-prompt- Confirm successful installation and replication start on the source machine
- Confirm successful replication has been initiated in the AWS MGM Console
Launch Template
- Log into AWS and browse to the Application Migration Service console
- Under Settings, click on Launch template
- Click Edit
General Launch Settings
- Activate instance type right-sizing
- This will allow AWS to make the decision on the EC2 family type when replicated instances are launched. Enabling this will override the instance type you set in a customized template.
- Start instance upon launch
- This will allow the replicated instance to boot up when launched
- Copy private IP
- This will copy the source IP to the replicated instance when launched. Unless you have your VPC CIDR and subnet(s) CIDR(s) set the same as the source or you will create a new ENI (network interface) on the launched instance, you can leave this unchecked.
- Transfer server tags
- If you are replicating a native AWS EC2 instance, the original tags can be transferred over
- Operating system licensing
- You can bring your own OS licensing or use the AWS provided/built-in licensing model
Default EC2 Launch Template
This template can be used for ALL replicated instances that you launch (in the Testing Phase and/or Cutover Phase). You can also create customized templates for each replicated instance as well if you so desire.
- Default target subnet
- this will be the subnet where all your launched instances will be created in.
- Additional security groups
- this will be all the security groups attached to your launched instance.
- Default instance type
- this option will be disabled if you chose to have AWS make the decision above; however if you have unchecked the option for Active instance type right-sizing earlier, you can pick the default instance type.
- EBS volume type
- this will be the default volume type for all newly launched instances. Although the newly available gp3 is the default, you are also able to choose from other types.
- IOPS
- with GP3 EBS volume types, you can throttle the IOPS as needed.
- Throughput
- with GP3 EBS volume types, you can throttle the throughput as needed.
Post-Launch Actions
To run post launch scripts, you have a couple of options. Using Systems Manager, you can run any type of scripts upon launch of a replicated EC2 instance.
Option 1 – Post-Launch Template
- Install the Systems Manager agent and allow executing actions on launched servers
- this will install the agent as well as create roles so that you can use Systems Manager to run any type of scripts during launch
- Deployment
- you can enable the post launch actions/scripts for instances that are launched in the Testing Phase and/or the Cutover Phase.
Option 2 – Launch Template Modifications
Find the Default EC2 Launch Template from MGM
- Log into AWS and browse to MGM
- Under Settings, click on Launch template
- Under Default EC2 Launch Template section, you will see a Template ID starting with the letters ‘lt-‘
- Open the EC2 console in AWS
- Click on Launch Templates
- Click on the lt link that matches what you saw earlier
- Click on Actions, then Modify template (Create new version)
- Scroll down and click on Advanced details
- Scroll down and under User data, you can write a script to run (example below has a PowerShell script to create a new file on the C:\ drive)
- Click on Create template version and then View template version
- Back at the Launch Templates screen, you will see a new version under the Latest version column (example below has version 3 as the latest)
- With the template radio button still selected, click on Actions, then Set default version
- Click the drop down under Template version and pick the latest version id
- Click on Set as default version
Please note that this new version will ONLY apply to net new replicated instances and will not apply to currently replicated objects.
Conclusion
In conclusion, this second blog post on Migration Services in AWS provided an in-depth exploration of the installation process for replication agents and various options available for launching instances using migration services. We discussed important considerations such as the location and specifications of the destination instance, as well as the need for post-launch scripts. By understanding these factors, businesses can make informed decisions when migrating their workloads to AWS and ensure a smooth and successful migration process