NEW - You can now accelerate your migration and modernization with AWS Transform. Read [Getting Started](https://docs.aws.amazon.com/transform/latest/userguide/getting-started.html) in the *AWS Transform User Guide*. # Configuring AWS Application Migration Service Settings Settings AWS Application Migration Service uses replication settings to determine how data is replicated from source servers to your AWS account and Region. Learn how to configure your initial replication template and how to set individual server replication settings. You must configure the replication template upon first use of AWS Application Migration Service. The replication template determines how your servers are replicated to AWS through settings such as Replication Server instance type, Amazon Elastic Block Store volume type, Amazon EBS encryption, security groups, data routing, and tags. The settings configured in the replication template are automatically used for every server you add to AWS Application Migration Service. Once you have configured your Replication template, you can make changes to individual servers or a group of servers by editing their replication settings within the Server Details View. You can also configure optional post-launch settings that automate target instance deployment and prepare your migrated servers for disaster recovery with AWS Elastic Disaster Recovery. **Topics** + [ # Replication settings ](replication-settings-template.md) + [ # Launch template settings ](launch-template.md) + [ # Post-launch settings ](post-launch-settings.md) # Replication settings Replication settings determine how data is replicated from your source servers to AWS. Configure the replication settings in the replication template before adding source servers to AWS Application Migration Service. You can modify the template at any time. Template settings are transferred to each newly added server. You can also edit the replication settings for a particular server or group of servers after you add them to AWS Application Migration Service. You can also control other source server settings through the **Settings** section in the menu on the left of the console. **Topics** + [ ## Understanding template settings and server-specific settings ](#template-vs-server) + [ ## Edit your replication settings template ](#edit-replication-template) + [ ## Edit replication settings for a server ](#edit-replication-settings) + [ # Replication server settings reference ](replication-server-settings.md) ## Understanding template settings and server-specific settings The replication template settings determine how data replication works for each new server you add to AWS Application Migration Service. These settings are applied to each source server you add. You are prompted to configure your replication template upon your first use of AWS Application Migration Service. You can change the replication settings for individual source servers or for a group of source servers. These changes do not affect the replication settings template. [Learn more about configuring your initial replication template](first-time-setup-gs.md). ## Edit your replication settings template To edit the replication settings template: + Choose **Replication template**, under **Settings** on the left-hand console menu. + This opens the **Replication template** view. Choose **Edit** to edit your account-wide replication settings. These changes are applied to each server you add to your account but do not affect servers that you already added to AWS Application Migration Service. ## Edit replication settings for a server To edit the settings for an individual server or group of servers: + Select servers on the **Source servers** page. + Open the **Replication** menu and choose **Edit replication settings**. The names of the servers you are editing appear under the **Selected servers** dropdown. + Edit individual replication settings under the **Replication settings** category. + To change the settings, choose the preferred option from the drop-down menu under each setting category. Any setting that you don't change is labeled **Do not change** option + Choose **Save replication settings**. The replication settings categories are explained in the following sections. # Replication server settings reference Replication servers are lightweight Amazon EC2 instances that are used to replicate data between your source servers and AWS. Replication servers are automatically launched and terminated as needed. You can modify the behavior of the replication servers by modifying the settings for a single source server or multiple source servers. Alternatively, you can run AWS Application Migration Service with the default replication server settings. The replication server options, include: + The subnet within which the replication server is launched. The subnet can use both IPv4 and IPv6 CIDRs. + Replication Server instance type + Amazon EBS volume types + Amazon EBS encryption + Security groups + IP Version - you can choose IPv4 or IPv6. ## Staging area subnet Choose the **Staging area subnet** that you want to allocate as the staging area subnet for all of your replication servers. If you chose to use IPv6, you must choose a subnet that uses IPv6 CIDRs. The best practice is to create a single dedicated, separate subnet for all of your migration waves using your AWS account. Learn more about creating subnets in [this AWS VPC article](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html). If a default subnet does not exist, select a specific subnet. The drop-down menu contains a list of all subnets that are available in the console's AWS Region. **Note** Changing the subnet does not significantly interfere with ongoing data replication, although there may be a minor delay of several minutes while the servers are moved from one subnet to another. ### Using multiple subnets The best practice is to use a single staging area subnet for all of your migration waves within a single AWS account. You may want to use multiple subnets in certain cases, such as the migration of thousands of servers. **Note** Using more than one staging area subnet might result in higher compute consumption as more replication servers are needed. ### Launching replication servers in Availability Zones If you want your replication servers to be launched in a specific Availability Zone, then select or create a subnet in that specific Availability Zone. Learn more about using Availability Zones in [this Amazon Elastic Compute Cloud article](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html). ## Replication server instance type Choose the **Replication server instance type**. This determines the instance type and size that is used for the launch of each replication server. The best practice is to not change the default replication server instance type unless there is a business need for doing so. By default, AWS Application Migration Service uses the **t3.small** instance type. This is the most cost effective instance type and should work well for most common workloads. You can change the replication server instance type to speed up the initial sync of data from your source servers to AWS. Changing the instance type will likely lead to increased compute costs. You can choose a the **Replication server instance** type from the drop-down menu contains all available types. Recommended and commonly used instance types are displayed first. You can also search for a specific instance type in the search box. You can change the replication server instance type for servers that are replicating too slowly or servers that are constantly busy or experience frequent spikes. These are the most common instance type changes: + Servers with less than 26 disks – Change the instance type to **m5.large**. Increase the instance type to m5.xlarge or higher as needed. + Servers with more than 26 disks, or servers in AWS Regions that do not support m5 instance types – change the instance type to **m4.large**. Increase to m4.xlarge or higher, as needed. **Note** Changing the replication server instance type will not affect data replication. Data replication will automatically continue from where it left off, using the new instance type you selected. By default, replication servers are automatically assigned a public IP address from Amazon's public IP space. Replication Servers are only supported on x86\$164 CPU architecture instance types. ## Dedicated instance for replication server Choose whether you would like to use a **Dedicated instance for replication server**. When an external server is very write-intensive, the replication of data from its disks to a shared Replication Server can interfere with the data replication of other servers. In these cases you should choose the **Use dedicated replication server** option (and also consider changing Replication server instance type). Otherwise, choose the **Do not use dedicated replication server** option. **Note** Using a dedicated replication server may increase the Amazon EC2 cost you incur during replication. ## Amazon EBS volume type Choose the default Amazon **Amazon EBS volume type** to be used by the replication servers for large disks. Each disk has minimum and maximum sizes and varying performance metrics and pricing. Learn more about Amazon EBS volume types in [this Amazon EBS article.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) The best practice is to not change the default Amazon EBS volume type, unless there is a business need for doing so. **Note** This option only affects disks over 500 GiB (by default, smaller disks always use Magnetic HDD volumes). The default **Lower cost, Throughput Optimized HDD (st1)** option utilizes slower, less expensive disks. You may want to use this option if: + You want to keep costs low + Your large disks do not change frequently + You are not concerned with how long the initial sync process will take The **Faster, General Purpose SSD (gp3)** option utilizes faster, but more expensive disks. You may want to use this option if: + Your source server has disks with a high write rate or if you want faster performance in general + You want to speed up the initial sync process + You are willing to pay more for speed **Note** You can customize the Amazon EBS volume type used by each disk within each source server in that source server's settings. [Learn more about changing individual source server volume types.](staging-disk.md) ## Amazon EBS encryption Choose whether to use the default or custom Amazon **EBS encryption**. This option will encrypt your replicated data at rest on the Staging Area Subnet disks and the replicated disks. + Default – The default Amazon EBS encryption Volume Encryption Key will be used (which can be an Amazon EBS-managed key or a CMK). + Custom – You will need to enter a custom customer-managed key (CMK) in the regular key ID format. If you select the **Custom** option, the **EBS encryption key** box appears. Enter the ARN or key ID of a customer-managed CMK from your account or another AWS account. Enter the encryption key (such as a cross-account KMS key) in the regular key ID format (KMS key example: 123abcd-12ab-34cd-56ef-1234567890ab). To create a new AWS Key Management Service key, click **Create an AWS KMS key**. You will be redirected to the Key Management Service (KMS) Console where you can create a new key to use. Learn more about Amazon EBS Volume Encryption in [this Amazon EBS article](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html). **Important** Reversing the encryption option after data replication has started will cause data replication to start from the beginning. ### Using an AWS KMS Customer Managed Key (CMK) for encryption If you decide to use a Customer Managed Key (CMK), or if your default Amazon EBS encryption key is a CMK, you will need to add additional permissions to the key to allow AWS Application Migration Service to use it. To modify the existing key policy using the AWS Management Console *policy view*. 1. Navigate to the AWS KMS Console and select the AWS KMS key you plan to use with AWS MGN. 1. Scroll to **Key policy** and click **Switch to policy view**. 1. Click **Edit** and add the following JSON statements to the **Statement** field. ``` { "Sid": "Allow AWS Services permission to describe a customer managed key for encryption purposes", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::$ACCOUNT_ID:root" }, "Action": [ "kms:DescribeKey" ], "Resource": "*", "Condition": { "StringEquals": { "kms:CallerAccount": [ "$ACCOUNT_ID" ] }, "Bool": { "aws:ViaAWSService": "true" } } }, { "Sid": "Allow AWS MGN permissions to use a customer managed key for EBS encryption", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::$ACCOUNT_ID:root" }, "Action": [ "kms:CreateGrant" ], "Resource": "*", "Condition": { "StringEquals": { "kms:CallerAccount": [ "$ACCOUNT_ID" ], "kms:GranteePrincipal": [ "arn:aws:iam::$ACCOUNT_ID:role/aws-service-role/mgn.amazonaws.com/AWSServiceRoleForApplicationMigrationService" ] }, "ForAllValues:StringEquals": { "kms:GrantOperations": [ "CreateGrant", "DescribeKey", "Encrypt", "Decrypt", "GenerateDataKey", "GenerateDataKeyWithoutPlaintext" ] }, "Bool": { "aws:ViaAWSService": "true" } } }, { "Sid": "Allow EC2 to use this key on behalf of the current AWS Application Migration Service user, during target launches", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::$ACCOUNT_ID:root", "arn:aws:iam::$ACCOUNT_ID:role/aws-service-role/mgn.amazonaws.com/AWSServiceRoleForApplicationMigrationService" ] }, "Action": [ "kms:ReEncrypt*", "kms:GenerateDataKey*" ], "Resource": "*", "Condition": { "StringEquals": { "kms:CallerAccount": [ "$ACCOUNT_ID" ], "kms:ViaService": "ec2.$REGION.amazonaws.com" } } } ``` **Important** Replace `$ACCOUNT_ID"` with the AWS account ID you are migrating into. Replace `$REGION` with the AWS Region you are migrating into. The last statement can be made stricter by ensuring the principal refers to users who are going to perform [StartTest](https://docs.aws.amazon.com/mgn/latest/APIReference/API_StartTest.html) or [StartCutover](https://docs.aws.amazon.com/mgn/latest/APIReference/API_StartCutover.html) API calls 1. Click **Save changes**. **Note** If you are using a Customer Managed Key (CMK) from another account, you need to take an additional step from within that account to allow the service to leverage the CMK. From the account in which you want to stage MGN replication servers, create a grant that delegates the relevant permissions to the appropriate service-linked role. The Grantee Principal element of the grant is the ARN of the appropriate service-linked role. The key-id is the ARN of the key. The following is an example [create-grant](https://docs.aws.amazon.com/cli/latest/reference/kms/create-grant.html) CLI command that gives the service-linked role named **AWSServiceRoleForApplicationMigrationService** in account 111122223333 permissions to use the customer-managed key in account 444455556666. aws kms create-grant \$1 --region us-west-2 \$1 --key-id arn:aws:kms:us-west-2:444455556666:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d \$1 --grantee-principal arn:aws:iam::111122223333:role/aws-service-role/mgn.amazonaws.com/AWSServiceRoleForApplicationMigrationService \$1 --operations "Encrypt" "Decrypt" "ReEncryptFrom" "ReEncryptTo" "GenerateDataKey" "GenerateDataKeyWithoutPlaintext" "DescribeKey" "CreateGrant" For this command to succeed, the user making the request must have permissions for the CreateGrant action. ## Store snapshots in AWS Local Zone When you replicate to a Local Zone, you can store Amazon EBS snapshots in the Local Zone instead of the parent AWS Region. By default, snapshots of Amazon EBS volumes in a Local Zone are stored in the parent AWS Region. If you replicate to a Local Zone that supports local snapshots, you can store the snapshots locally in the Local Zone to meet data residency requirements. This setting is available only when the staging area subnet is in a supported Local Zone. For more information about local snapshots in Local Zones, see [Local snapshots in Local Zones](https://docs.aws.amazon.com/ebs/latest/userguide/snapshots-localzones.html) in the Amazon EBS User Guide. ## Always use Application Migration Service security group Choose whether you would like to **Always use the Application Migration Service security group**. A security group acts as a virtual firewall, which controls the inbound and outbound traffic of the staging area subnet. The best practice is to have AWS Application Migration Service automatically attach and monitor the default Application Migration Service Security Group. This group opens inbound TCP Port 1500 for receiving the transferred replicated data. When the default Application Migration Service Security Group is activated, Application Migration Service will constantly monitor whether the rules within this security group are enforced, in order to maintain uninterrupted data replication. If these rules are altered, Application Migration Service will automatically fix the issue. Select the **Always use Application Migration Service security group ** option to allow data to flow from your source servers to the replication servers, and that the replication servers can communicate their state to the AWS Application Migration Service servers. Otherwise, select the **Do not use Application Migration Service security group option**. Selecting this option is not recommended. Additional security groups can be chosen from the Additional security groups dropdown. The list of available security groups changes according to the **Staging area subnet** you selected. You can search for a specific security group within the search box. You can add security groups via the AWS Management Console, and they will appear on the security group drop-down list in the AWS Application Migration Service Console. Learn more about AWS security groups in [this VPC article](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html). You can use the default Application Migration Service security group, or you can select another security group. However, take into consideration that any selected security group that is not the Application Migration Service default, will be added to the default group, since the default security group is essential for the operation of Application Migration Service. ## Data routing and throttling AWS Application Migration Service allows you to control how data is routed from your source servers to the replication servers on AWS through the **Data routing and throttling** settings. By default, data is sent from the source servers to the replication servers over the public internet, using the public IP that was automatically assigned to the replication servers. Transferred data is always encrypted in transit. **Note** The **Data routing and throttling** view differs slightly between the replication template view and the individual source server replication settings view, but the instructions apply to both views. ### Use private IP for data replication Choose the **Use private IP** option if you want to route the replicated data from your source servers to the staging area subnet through a private network with a VPN, AWS Direct Connect, VPC peering, or another type of existing private connection. Choose **Do not use private IP** if you do not want to route the replicated data through a private network. **Important** Data replication will not work unless you have already set up the VPN, AWS Direct Connect, or VPC peering in the AWS Console. **Note** Use of private IP is not supported for IPv6. If you selected the Default subnet, it is highly unlikely that the private IP is used for that subnet. Ensure that Private IP (VPN, AWS Direct Connect, or VPC peering) is used for your chosen subnet if you wish to use this option. You can safely switch between a private connection and a public connection for individual server settings choosing the **Use private IP** or **Do not use private IP** option, even after data replication has begun. This switch will only cause a short pause in replication, and will not have any long-term effect on the replication. Choosing the **Use private IP** option will not create a new private connection. You should use this option if you want to: + Allocate a dedicated bandwidth for replication + Use another level of encryption + Add another layer of security by transferring the replicated data from one private IP address (source) to another private IP address (on AWS) #### Network architecture diagram – private IP The following diagram illustrates the high-level interaction between the different replication system components when using private IP or VPC endpoint. ![\[Application Migration Service network architecture diagram featuring a private link/VPC\]](http://docs.aws.amazon.com/mgn/latest/ug/images/AWS-MGN-Network-Architecture-Private-Link.png) #### Create public IP When the **Use private IP** option is chosen, you will have the option to create a public IP. Public IPs are used by default. Choose **Create public IP** if you want to create a public IP. Choose **Do not create a public IP** if you do not want to create a public IP. ### Throttle bandwidth You can control the amount of network bandwidth used for data replication per server. By default, AWS Application Migration Service will use all available network bandwidth utilizing five concurrent connections. Choose **Throttle bandwidth** if you want to control the transfer rate of data sent from your source servers to the Replication Servers over TCP Port 1500. Otherwise, choose **Do not throttle bandwidth**. If you chose to throttle bandwidth, the **Throttle network bandwidth** (per server, in Mbps) box will appear. Enter your desired bandwidth in Mbps. ## Replication resources tags Add custom **Replication resources tags** to resources created by AWS Application Migration Service in your AWS account. These are resources required to facilitate data replication, testing and cutover. Each tag consists of a key and an optional value. You can add a custom tag to all of the AWS resources that are created on your AWS account during the normal operation of AWS Application Migration Service. To add a new tag, take the following steps: 1. Click **Add new tag**. 1. Enter a **Custom tag key** and an optional tag value. **Note** Application Migration Service already adds tags to every resource it creates, including service tags and user tags. These resources include: + Amazon EC2 instances + Amazon EC2 launch templates + Amazon EBS volumes + Snapshots + Security groups (optional) Learn more about AWS Tags in [this Amazon EC2 article](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html). # Launch template settings The **Launch template** allows you to control the way AWS Application Migration Service launches instances in AWS. The default configuration defined in the template is automatically applied to every newly added server. To edit the launch template for your entire account, you need to edit your launch template. Choose **Launch template** from the left-hand navigation menu. This opens the account template view. Click **Edit** to update your account-level launch template. **Note** Ensure the Account Level EC2 Launch Template is not deleted. If it is, edit and save the launch template page to create a new Account Level Template. You can change the settings for specific servers without affecting the launch template as described in [Edit replication settings for a server ](replication-settings-template.md#edit-replication-settings). See [ Assign an IPv6 address to an instance](https://docs.aws.amazon.com/WSEC2/latest/UserGuide/working-with-ipv6-addresses.html#assign-ipv6-address) in the *Amazon EC2 User Guide* for a list of instance types that do not support IPv6 addresses **Topics** + [ ## General launch settings reference ](#general-launch-settings) + [ ## Default EC2 launch template settings ](#default-ec2-launch-template) + [ ## MAP program tagging setting ](#map-program-tagging) ## General launch settings reference In the **General launch settings** section, you can define: + **Instance type right sizing**: If you select this option, AWS Application Migration Service launches a test or cutover AWS instance type that best matches the OS, CPU, and RAM of your source server. Please note that the AWS instance type selected by Application Migration Service when this option is selected overwrites the instance type defined in your EC2 launch template. + **Start instance upon launch**: Choose whether to start your test and cutover instances automatically upon launch or launch them in a stopped state. + **Copy private IP**: Select if you want AWS Application Migration Service to ensure that the private IP used by the test or cutover instance matches the private IP used by the source server. If selected, AWS Application Migration Service monitors the source server on an hourly basis to identify the Private IP and uses the private IP of the primary network interface. Make sure that the IP range of the subnet you set in the EC2 Launch Template includes the private IP address for this feature to work. Copy private IP is not supported for IPv6. + **Transfer server tags**: Select if you want AWS Application Migration Service to transfer user-configured custom tags from your source servers to your test or cutover instance. If selected, server tags are transferred. These tags are attached to all source servers, all launched test and cutover instances, and all of the ephemeral resources that are created on your AWS account during the normal operation of AWS Application Migration Service, such as snapshots, Amazon EBS volumes, replication and conversion servers, and security groups. + **Operating system licensing**: Select if you want to Bring Your Own Licenses (BYOL) from the source server into the test or cutover instance. Select the “Bring your own license (**BYOL**)” option if you are migrating a Linux server. All Linux licenses are BYOL by default. Any RHEL, SUSE or Debian licenses are transferred in their current form to the migrated instance. For Windows servers choose if you want to **BYOL**)”. This sets set up a Dedicated Host. All the licenses from the source Windows source server are automatically transferred to the test or cutover instance. Please note that if you use BYOL licensing for Windows you have to change the **Placement.tenancy** type in the EC2 launch template to **Host**. Otherwise, instance launch fails. + **Boot mode**: When a computer boots, the first software that it runs is responsible for initializing the platform and providing an interface for the operating system to perform platform-specific operations. In Amazon EC2, two variants of the boot mode software are supported: Unified Extensible Firmware Interface (UEFI) and Legacy BIOS. The boot mode allows Application Migration Service to launch a test or cutover instance type that best matches the configuration of the source server. You can select between **Keep the source boot mode** or change it to **BIOS/UEFI modes** . **Note** UEFI is not supported in CentOS 6 and Rhel 6. ## Default EC2 launch template settings In the **Default EC2 launch template** section, you can define the following options: + **Default target subnet** – Choose the target subnet for the test and cutover machines. All the test and cutover machines are launched in this target subnet. + **Target security groups** – Choose a number of security groups for the test and cutover machines. Upon the target launch, the selected security groups are attached to the Amazon EC2 instances. + **Default instance type** – Choose a default instance type for the test and cutover machines. The instance type chosen in this template is propagated to source server’s launch template and is used to launch the target instance. + **EBS volume type** – Choose an Amazon EBS volume type for the test and cutover machines. The Amazon EBS volume type options are io1, io2, gp3, st1, and sc1. If this setting is not chosen, the default volume type selected in the launch template is gp3 with maximum IOPS (16000). If a volume type is selected in this option, and if the disk size does not match the limits of the volume type, the default gp3 volume type is used with maximum IOPS. **Note** Note: if you manually delete the default launch template, AWS Application Migration Service generates a new default launch template. Any changes previously made to the default template are discarded, including subnet and security groups. You can make the same changes on the new launch template, and they are applied to servers you add to the console after you make the changes. ## MAP program tagging setting Use this setting to determine whether to apply Migration Acceleration Program (MAP) tags to your launched instances. Learn more about MAP tagging in [What is tagging for MAP](https://aws.amazon.com/migration-acceleration-program) in the AWS Migration Hub Launch Guide. Select**Add MAP tag to Launched Instances** option, if you want Application Migration Service to automatically tag your launched instances with the tag key and value combination required for MAP program. Once selected you must specify the MAP tag value that is used in your MAP tagging. Application Migration Service automatically tagw your migrated resources with the key: “map-migrated” and the value of the tag that you provided. For more details about the tag value that should be used here, please refer to the MAP tagging guide provided in your MAP term. [Learn more about the AWS Migration Acceleration Program (MAP).](https://aws.amazon.com/migration-acceleration-program) # Post-launch settings Post-launch settings allow you to control and automate actions performed after the server has been launched in AWS. These settings are created automatically based on the **Post-launch template**. To access the template, choose **Post-launch template** on the left-hand menu. The settings defined in the template are applied to every newly added server. You can change the settings for existing and newly added servers individually within the server details view. **Important** To use the post-launch settings feature, you must first activate at the account level. Deactivation is also at the account level. The **Post-launch template** allows you to control various post-launch actions, including: + Deployment of test and cutover instances + Disaster recovery configuration (installing the AWS Replication Agent for Elastic Disaster Recovery and configuring the target disaster recovery AWS Region). + Operating system conversion on the target machine + License and subscription changes on the target machine **Topics** + [ ## Activating post-launch settings ](#post-launch-settings-activation) + [ ## Editing the post-launch settings template ](#post-launch-settings-editing) + [ ## Deploying post-launch actions ](#deploying-post-launch-actions-2022) + [ ## Encrypt post-launch action parameters ](#encrypt-post-launch-actions-parameters) + [ ## Post-launch actions table ](#post-launch-actions-table) + [ ## Create a custom post-launch action ](#post-launch-settings-custom-actions-add) + [ ## Edit custom post-launch actions ](#post-launch-settings-custom-actions-edit) + [ # Predefined post-launch actions reference ](predefined-post-launch-actions.md) ## Activating post-launch settings To use the post-launch template activate the post-launch actions. This allows Application Migration Service to: + Install the [ SSM Agent ](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html)on your servers + Run the post-launch actions **Note** Installation of the SSM Agent requires a minimum of 200 MB of free disk space and 200 KB of free disk space in the `/var` directory. Installation of the SSM Agent is not supported on these operating systems: CentOS 5.x CentOS 6.x RHEL 6.x Oracle 6.x Amazon Linux 1 Windows 2008 Windows 2008 R2 To activate the post-launch actions: 1. Navigate to **Settings > Post-launch settings template**. 1. Choose **Edit**. 1. Toggle the **Install Systems Manager agent and allow executing actions on launched servers** option. 1. Choose **Save template**. The post-launch actions are shown in the **Settings >Post-launch template** view. ## Editing the post-launch settings template Application Migration Service supports post-launch modernization actions, giving you the opportunity to move and improve. The service provides actions that you can execute on your Amazon EC2 launch instances and enables you to create your own actions. The actions described in these sections can be edited within the post-launch template. Once you have edited your settings, choose **Save template**. ## Deploying post-launch actions Use this setting to choose whether to execute the post-launch actions on your cutover instances, on your test instances, or on both cutover and test instances. ## Encrypt post-launch action parameters The post-launch action parameters are stored in SSM [Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) . For enhanced security, ensure that users who do not have permissions to execute SSM documents, do not have access to the Parameter Store. For an additional layer of security you can select to encrypt the action parameters using AWS KMS encryption. SSM encrypts the parameter value of SecureString parameters type using AWS KMS with an AWS managed key or with the default AWS KMS key provided by AWS. You can specify different keys for each parameter, or use the same key for multiple parameters. ## Post-launch actions table The post-launch actions table includes both predefined actions and custom actions that are executed on your new Amazon EC2 instances. + Predefined post-launch actions are provided out of the box. They are prepopulated with the necessary values and only need to be activated or deactivated. These actions are based on public SSM documents that cannot be changed and have certain unchangeable parameters such as the platform name and order. + Custom post-launch actions are based on SSM documents that you create and upload to your account. Use the **Filter by** options on the left-hand side to filter the available actions according to your preferences. Click the settings icon in the right-hand corner of the screen to alternate between card and list view, according to your preferences. ## Create a custom post-launch action AWS Application Migration Service allows you to execute any SSM document that you like – public SSM document or ones you created and uploaded to your account. You can configure a custom action to execute any SSM document that is available in your account. To add a new customer action, go to the **Post-launch actions settings** and click **Create action**. The page includes these parameters: + **Action name** – The name of the action in Application Migration Service, which should be intuitive and meaningful to your migration users. + **Activate this action** – Use this checkbox to activate or deactivate the custom action. + **This action must be completed successfully before finalizing cutover** – This checkbox dictates whether or not the script prevents the cutover. + **System Manager document name** – Select any SSM document that is available for the specific account. + **View in Systems Manager** – Click to open **SSM** and view additional information about the document. + **Description** – Add a description or keep the default. + **Document version** – Select which SSM document version to run. Application Migration Service can run a default version, the latest version, or a specific version, according to your preferences. + Category – Select from various available categories including disaster recovery, security, validation, and more. + **Order** – Specify the order in which the actions is executed. The lower the number, the earlier the action is executed. 1–1,000 are reserved for predefined actions and 1,001–10,000 for custom actions. The numbers must be unique but don’t need to be consecutive. + **Operating system** – Select the source server's operating systems for which the custom action can be configured for. Note that if you associate a script with the wrong operating system, it is skipped. + **Creator** – Who created the action. For custom actions, the default is always **Me**. The **Action parameters** change according to the specific SSM document that is selected. Note that for the instance ID parameter, you can choose to use the launch instance ID, in which case, Application Migration Service dynamically populates the value. **Note** Only trusted, authorized users should have access to the parameter store. For enhanced security, ensure that users who do not have permissions to execute SSM documents / commands, do not have access to parameter store. [ Learn more about restricting access to SSM parameters. ](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-access.html) Action parameters are stored in the SSM parameter store as regular strings. Changing parameters in the SSM Parameter store may impact the post launch action execution on target instances. We recommend you consider security implications, when choosing to use parameters that contain scripts or sensitive information, such as API keys and database passwords. Edit each setting as required and then click **Add action**. ## Edit custom post-launch actions AWS Application Migration Service allows you to execute any SSM document that you like – public SSM document or ones you created and uploaded to your account. You can configure a custom action to execute any SSM document that is available in your account. Use this page to edit the parameters detailed in the **Create action** section. Edit each setting as required and then click **Save action**. # Predefined post-launch actions reference AWS Application Migration Service allows you to execute various predefined post-launch actions on your Amazon EC2 launch instance. Use these out-of-the-box actions to modernize your servers while you're migrating: Change existing license, upgrade your operating system, configure disaster recovery, and more. **Topics** + [ ## Install the SSM agent ](#predefined-ssm-agent) + [ ## Configure AWS Elastic Disaster Recovery ](#predefined-elastic-disaster-recovery) + [ ## Convert operating systems ](#predefined-operating-systems) + [ ## Replace SUSE subscription ](#predefined-license-and-subscription) + [ ## Conduct Amazon EC2 connectivity checks ](#predefined-ec2-connectivity-check) + [ ## Validate volume integrity ](#predefined-volume-integrity-validation) + [ ## Verify process status ](#predefined-process-status-validation) + [ ## Convert MS-SQL license ](#predefined-windows-ms-sql-conversion) + [ ## Install a CloudWatch Agent ](#predefined-cloudwatch-agent-installation) + [ ## Upgrade Windows ](#predefined-windows-upgrade) + [ ## Create AMI from instance ](#predefined-create-ami-from-instance) + [ ## Join Directory Service domain ](#predefined-joined-domain) + [ ## Configure Time Sync ](#predefined-time-sync) + [ ## Validate disk space ](#predefined-validate-disk-space) + [ ## Verify HTTP/HTTPS response ](#predefined-verify-http-https-response) + [ ## Enable Amazon Inspector Classic ](#predefined-inspector) + [ ## Verify Tags ](#predefined-verify-tags) + [ ## Auto Scaling group setting ](#predefined-autoscaling-group-setting) + [ ## Dynatrace ](#predefined-dynatrace) + [ ## New Relic ](#predefined-new-relic) + [ ## TrendMicro ](#predefined-trend-micro) ## Install the SSM agent The SSM allows AWS Application Migration Service to execute modernization actions on your servers after they are launched. When you activate the post-launch actions, AWS Application Migration Service installs the **SSM agent** and creates the required IAM roles. The SSM agent must be installed for any other post-launch action to run. Therefore, this is the only post-launch action that is activated by default and cannot be deactivated. [Learn more about SSM.](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) ## Configure AWS Elastic Disaster Recovery **Note** This feature is supported on operating systems that are supported by AWS Elastic Disaster Recovery (AWS DRS). [See the AWS DRS documentation.](https://docs.aws.amazon.com/drs/latest/userguide/Supported-Operating-Systems.html) This action is not supported in Application Migration Service GovCloud regions (US-East, US-West). Use the **DR after migration** feature to configure disaster recovery using AWS Elastic Disaster Recovery. This action installs the AWS Elastic Disaster Recovery Replication Agent on your Amazon EC2 instance. You must select the target disaster recovery region, which is the AWS Region in which the Recovery instances is deployed. AWS Elastic Disaster Recovery must be available in the selected Region and initiated in your account. You must initialize Elastic Disaster Recovery for this action to work. **Important** Ensure that you review the costs associated with AWS Elastic Disaster Recovery in the [service pricing documentation](https://aws.amazon.com/disaster-recovery/pricing/). [Learn more about Elastic Disaster Recovery AWS Regions.](https://docs.aws.amazon.com/drs/latest/userguide/supported-regions.html) [Learn more about initializing Elastic Disaster Recovery.](https://docs.aws.amazon.com/drs/latest/userguide/getting-started-initializing.html) ## Convert operating systems **Note** This feature is supported on CentOS version 8.x. Use the **CentOS to Rocky** feature to perform changes to the target machine operating system. It allows you to convert any of your source servers that are running CentOS to [Rocky Linux](https://rockylinux.org/). ## Replace SUSE subscription **Note** This feature is supported on SUSE Linux versions 12 SP 1 and later. This action is not supported on SLES4SAP servers. Use the **Replace SUSE subscription** feature to choose whether you want to change the SUSE Linux subscription of any source server that runs SUSE to an AWS-provided SUSE subscription. An AWS-provided SUSE subscription allows AWS to manage your licenses, including renewal handling, saving you time and simplifying your billing and license management processes ## Conduct Amazon EC2 connectivity checks Use the **EC2 connectivity check** feature to conduct network connectivity checks to a predefined list of ports and hosts. **Note** Up to 5 Port:IP couples can be checked in a single action. ## Validate volume integrity Use the **Volume integrity validation** feature to ensure that Amazon EBS volumes on the launched instance are: + The same size as the source (rounded up) + Properly mounted on the Amazon EC2 instance + Accessible This feature allows you to conduct the required validations automatically and saves the time of manual validations. **Note** Up to 50 volumes can be checked in a single action. ## Verify process status Use the **Process status validation** feature to ensure that processes are in running state following instance launch. You need to provide a list of processes that you want to verify, and define how long the service should wait before testing begins. To check a specific process that should run multiple times, include it several times in the list. ## Convert MS-SQL license Use the **Windows MS-SQL license conversion** feature to easily convert Windows MS-SQL BYOL to an AWS license. Application Migration Service: + Checks the SQL edition (Enterprise, Standard, or Web) as part of the launch process + Uses the right AMI with the right billing code to launch from The SSM document runs and verifies that the right billing code is used post launch. The action uses these APIs: + [DescribeImages](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImages.html) + [DescribeInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html) To allow the SSM document to run these APIs, you need the required permissions or have access to a role with those permissions and then provide the role’s ARN as an input parameter to the SSM automation document. ## Install a CloudWatch Agent Use the **CloudWatch agent installation** feature to install and configure the CloudWatch Agent and Application Insights. You need the AWSApplicationMigrationSSMAccess policy, or a user-defined policy that allows the SSM document to run, to run this post-launch action. This is in addition to the [full access policy](security-iam-awsmanpol-AWSApplicationMigrationFullAccess.md): The launched instance requirea these policies: + CloudWatchAgentServerPolicy – The permissions required to use AmazonCloudWatchAgent on servers + AmazonSSMManagedInstanceCore – The policy for Amazon EC2 Role to enable AWS Systems Manager service core functionality To ensure that the launch instance has the right policies, create a role that has the required permissions as per the policies above or has access to a role with those permissions. + Go to **Launch settings > EC2 launch template > Modify > Advance > IAM instance profile**. + Use an existing profile or create a new one using the **Create new IAM profile** link. **Note** You must attach both policies to the template for the CloudWatch agent to operate. Without the CloudWatchAgentServerPolicy, the action is still marked as successful but the CloudWatch Agent is not active. Configuring the Application Insights is optional. You can choose to skip the Application Insights agent configuration and only install the CloudWatch agent. To do so provide the required parameterStoreName parameter and leave the other parameters empty. [Learn more about the CloudWatch Agent.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) ## Upgrade Windows Use the **Windows upgrade** feature to upgrade your migrated server to a more recent verions of Windows Server ([see the full list of available OS versions](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awsec2-CloneInstanceAndUpgradeWindows.html)). You need the AWSApplicationMigrationSSMAccess policy, or a user-defined policy that allows the SSM document to run, to run this post-launch action. This is in addition to the [full access policy](security-iam-awsmanpol-AWSApplicationMigrationFullAccess.md): To allow the SSM document to run these APIs, you must have the required permissions (including [CreateImages](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateImage.html), [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html), [DescribeInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html), and more) or have access to a role with those permissions and then provide the role’s ARN as an input parameter to the SSM automation document. Learn more about the permissions required to perform the upgrade in [AWSEC2-CloneInstanceAndUpgradeWindows.](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awsec2-CloneInstanceAndUpgradeWindows.html) The SSM document: + Creates an Amazon Machine Image (AMI) from the instance using the [CreateImage](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateImage.html) API. + Uses the AMI to create a new instance and then upgrades that instance. + Creates an AMI from the upgraded instance and terminates the upgraded instance. **Note** This operation may run for several hours. All other post-launch actions run on the instance launched by Application Migration Service and not on the upgraded instance. [Learn more about upgrading Windows.](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awsec2-CloneInstanceAndUpgradeWindows.html) ## Create AMI from instance Use the **Create AMI from Instance** feature to create a new Amazon Machine Image (AMI) from your Application Migration Service launched instance. You need the AWSApplicationMigrationSSMAccess policy, or a user-defined policy that allows the SSM document to run, to run this post-launch action. This is in addition to the [full access policy](security-iam-awsmanpol-AWSApplicationMigrationFullAccess.md): The action uses these APIs: + [CreateImages](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateImage.html) + [DescribeImages](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImages.html) To allow the SSM document to run these APIs, you need the required permissions or have access to a role with those permissions and then provide the role’s ARN as an input parameter to the SSM automation document. [Learn more about creating AMI from instance.](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-createimage.html) ## Join Directory Service domain Use this **Join domain** feature to simplify the AWS Join Domain process. If you activate this action, your instance is managed by the AWS Cloud Directory (instead of on-premises). You need the AWSApplicationMigrationSSMAccess policy, or a user-defined policy that allows the SSM document to run, to run this post-launch action. This is in addition to the [full access policy](security-iam-awsmanpol-AWSApplicationMigrationFullAccess.md): The launched instance requires these policies: + AmazonSSMManagedInstanceCore – The policy for Amazon EC2 Role to enable AWS Systems Manager service core functionality. + AmazonSSMDirectoryServiceAccess – This policy allows the SSM Agent to access Directory Service on behalf of the customer for domain-join the managed instance. To ensure that the launched instance has the right policies, create a role that has the required permissions as per the policies above or has access to a role with those permissions. + Go to **Launch settings > EC2 launch template > Modify > Advance > IAM instance profile**. + Use an existing profile or create a new one using the **Create new IAM profile** link. ## Configure Time Sync Use the **Time Sync** feature to set the time for your Linux instance using ATSS. [Learn more about Amazon Time Sync.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html) ## Validate disk space Use the **Disk space validation** feature to obtain visibility into the disc space that you have at your disposal, as well as logs with actionable insights. ## Verify HTTP/HTTPS response Use the **Verify HTTP/HTTPS response** feature to conduct HTTP/HTTPS connectivity checks to a predefined list of URLs. The feature verifies that HTTP/HTTPS requests (for example, https://localhost) receive the correct response. ## Enable Amazon Inspector Classic The **Enable Inspector** feature allows you to run security scans on your Amazon EC2 resources. The Amazon Inspector service is enabled at the account level. **Note** Amazon Inspector is a paid AWS service. For additional information, [refer to the full Inspector pricing documentation](https://aws.amazon.com/inspector/pricing). This action uses these APIs: + [ Enable](https://docs.aws.amazon.com/inspector/v2/APIReference/API_Enable.html) + [BatchGetAccountStatus](https://docs.aws.amazon.com/inspector/v2/APIReference/API_BatchGetAccountStatus.html) + [CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html) To allow the SSM document to run these APIs, you need the required permissions or have access to a role with those permissions and then provide the role’s ARN as an input parameter to the SSM automation document. ## Verify Tags Use the **Verify tags** feature to validate that tags that have been defined in the launch template and on the source server are copied to the migrated server. ## Auto Scaling group setting Use the **Auto Scaling group setting** when you would like to create an Auto Scaling group for a migrated stateless web application. ## Dynatrace **Note** This action is provided by a third party vendor, and is not available in the GovCloud Regions. This action installs Dynatrace OneAgent on your launched instance. To configure this action, you need an existing Dynatrace account and configure the required additionalArguments for your particular usage. Learn more about Dynatrace in [Deploy OneAgent using AWS Systems Manager Distributor ](https://www.dynatrace.com/support/help/setup-and-configuration/setup-on-cloud-platforms/amazon-web-services/amazon-web-services-integrations/aws-ec2/deploy-oneagent-using-aws-systems-manager-distributor) ## New Relic **Note** This action is provided by a third party vendor, and is not available in the GovCloud Regions. This action installs New Relic Infrastructure agent on your launched Amazon EC2 instance. To configure this action, you need an existing New Relic account and configure the required additionalArguments for your particular usage. You must use an original account license key for this action to succeed. [Learn more about New Relic](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-sys-dist/) ## TrendMicro **Note** This action is provided by a third party vendor, and is not available in the GovCloud Regions. This action installs the Trend Micro agent on your launched instance. [Learn more about Trend Micro](https://docs.trendmicro.com/en-us/documentation/article/trend-vision-one-aws-systems-manager-distributor)