# Configuring the default post-launch actions Post-launch actions After finishing the AWS DRS initialization process, you can configure your default post-launch actions settings. The default post-launch actions settings apply to newly added source servers and controls which post-launch actions run when launching new instances. These settings are created automatically for each server based on the default settings and can be modified at any time for any individual source server. You can also use this settings to install the IAM roles required for post-launch actions to work, if the roles were not already installed in your account during the first initialization of AWS DRS. The IAM roles need to be installed once per AWS account, regardless of the region used. Post launch actions can be of two different types: command and automation. Command post-launch actions run on the launched instance using the instance profile attached to the instance. Note that if no instance profile is defined on the EC2 launch template, AWS Elastic Disaster Recovery (AWS DRS) places the **AWSElasticDisasterRecoveryRecoveryInstanceWithLaunchActionsRole** instance profile by default if post-launch actions is active for the source server. Automation actions run with the credentials of the same IAM entity that started the drill, recovery or failback. In addition some automation actions accept a parameter that is sent to the assumeRole key in the SSM document if provided, the action assumes that role for that action execution. **Note** In order to use post-launch actions, you should make sure you have the required permissions. To get these permissions, you can attach the **AWSElasticDisasterRecoveryLaunchActionsPolicy** or **AWSElasticDisasterRecoveryConsoleFullAccess\$1v2** policies to your IAM identity. These policies contain the permissions needed to run SSM Command and Automation documents that are owned by Amazon or by the account as post-launch actions. 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 **Note** In order to run an SSM command or Automation document owned by a different account as a post-launch action you should provide the permission to use `ssm:SendCommand` and `ssm:StartAutomation` on the relevant document. For example, if you have shared the SSM documents MyCommand (command) and MyAutomation (automation) from account 111111111111, you should attach these permissions to you your IAM entities: **Example** ``` { "Effect": "Allow", "Action": [ "ssm:SendCommand", ], "Resource": "arn:aws:ssm:*:111111111111:document/MyAutomation", "Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": [ "drs.amazonaws.com" ] } } }, { "Effect": "Allow", "Action": [ "ssm:StartAutomationExecution" ], "Resource": "arn:aws:ssm:*:111111111111:automation-definition/MyAutomation", "Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": [ "drs.amazonaws.com" ] } } } ``` **Topics** + [ # Install the required IAM roles if needed ](post-launch-action-settings-roles.md) + [ # Activating post-launch actions default settings ](post-launch-action-settings-activation-default.md) + [ # Adding custom actions ](post-launch-action-settings-adding-custom-default.md) + [ # Activating, deactivating and editing predefined or custom actions ](post-launch-action-settings-editing-default.md) + [ # Deleting custom actions ](post-launch-action-settings-deleting-default.md) + [ # Predefined post-launch actions ](predefined-post-launch-actions-default.md) + [ ## Validate disk space ](#validate-disk-space) + [ ## Amazon EC2 connectivity checks ](#ec2-connectivity-checks) + [ ## Verify HTTP/HTTPS response ](#verify-http-response) + [ ## Verify tags ](#verify-tags) # Install the required IAM roles if needed To operate post-launch actions and allow to run SSM documents on launched instances, certain IAM roles must be installed. Usually these roles are installed into an AWS account when AWS DRS is initialized in the account for the first time in any region. If you have already initialized Elastic Disaster Recovery in your account before September 13, 2023, it's possible that the required IAM roles were not installed in your account. To verify the IAM roles are installed or install them if not installed (a one time operation, go to **Settings → Default post-launch actions** and check **Post-launch actions settings**. If you see the message **Install the required IAM roles to allow using post-launch actions** select **Install post-launched IAM roles**. If the roles were installed successfully, the message to install the roles is not present in **Post-launch actions settings**. # Activating post-launch actions default settings Activate post-launch actions in the default settings, to make it active by default for newly added source servers and to enable updating of the default list of actions. Activating and deactivating is only possible if the required IAM roles have been installed. To activate, make sure the required IAM role is installed by following [this guide](https://docs.aws.amazon.com/drs/latest/userguide/post-launch-action-settings-roles.html). After that, go to **Settings → Default post-launch actions** and check **Post-launch actions settings** to see if **Post-launch actions** is set to **Active**. In case it is not, select **Edit** and make sure **Post-launch actions activated** is checked. Then select **Save** to store these settings. To deactivate go to **Settings → Default post-launch actions** and check **Post-launch actions settings** to see if **Post-launch actions** is set to **Not active**. In case it is not, select **Edit** and make sure **Post-launch actions activated** is not checked. Then select **Save** to store these settings. # Adding custom actions AWS Elastic Disaster Recovery (AWS DRS) allows you to run any SSM document that you like – public SSM documents or ones you created and uploaded to your account. You can configure a custom action to run any SSM document that is available in your account. To be able to create, edit or delete a default custom action, make sure the post-launch actions are activated in the default settings. ## Create a custom action Adding a custom action through the default settings adds it to newly added servers. To add a custom action to an existing source server use the **Post-launch settings** tab in the source server details page. To add a new custom action to the default post-launch action settings, go to **Settings → Default post-launch actions**. If the default post-launch actions settings is **Active**, you can create new custom actions by selecting **Add action**. The **Add action** page includes these parameters: **Action name** – The name of the action in AWS DRS, which should be intuitive, meaningful and unique in this AWS account and region. **Activate this action** – Use this checkbox to activate or deactivate the action by default. Newly added source servers have the action set to active or not active according to the value this field had when the source server was added. **Mark launch as successful only if this action finishes running successfully** – This checkbox dictates whether or not the launch is marked as successful, based on the successful run of this action. Instance launches still progress normally regardless of the success of the action. **System Manager document name** – Select any Systems Manager document that is available to be used in this account. **System Manager document name** – Select any Systems Manager document that is available to be used in this account. **View in Systems Manager** – select to open **System Managers** and view additional information about the document. **Description** – Add a description or keep the default. **Document version** – Select which SSM document version to run. AWS DRS can run a default version, the latest version, or a specific version, according to your preferences. **Category** – Select from various available categories including monitoring, validation, security and more. **Order** – Specify the order in which the actions are executed. The lower the number, the earlier the action is executed. Values allowed are between 2 and 10,000. The numbers must be unique but don’t need to be consecutive. **Platform** – Taken from the SSM document and reports which Operating System platform (Windows/Linux) is supported by the action. **Creator** – Who created the action. For custom actions, the default is always **This account**. 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, AWS DRS dynamically populates the value. **Note** AWS Elastic Disaster Recovery (AWS DRS) places **AWSElasticDisasterRecoveryRecoveryInstanceWithLaunchActionsRole** instance profile on the launch instance if post-launch actions is active for the source server. If you add an SSM command action that requires additional permissions in the launch instance, you must ensure that the instance profile has the right policies or the right permissions. In order to do so, create a role that has the required permissions as per the policies above or has a policy or policies with those permissions attached to it. 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** 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 Systems Manager 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 run on target instances. We recommend to consider security implications, when choosing to use parameters that contain scripts or sensitive information, such as API keys and database passwords. # Activating, deactivating and editing predefined or custom actions You can activate, deactivate and edit actions available in the default post-launch actions settings. Activating an action in the default settings, adds the action as activated to newly added servers. Likewise, deactivating it, adds it as a non-active action to newly added servers. Source servers already created with this action are not affected by changes in the default settings. Editing an action in the default settings, adds the edited action to newly added servers. Servers already created with the action before the edit, are not updated with the changes present in any edit to the default settings that was made after their creation. Changes to actions on an existing source server can be made from the **Source server details** page, by going to the **Post-launch settings** tab and performing the change there. To be able to activate, create, deactivate, edit, or delete a custom action and to activate, deactivate or edit predefined actions, make sure the post-launch actions are activated in the default settings. ## Activate, deactivate or edit a post-launch action To activate, deactivate or edit a post launch action in the default post-launch actions settings, go to **Settings → Default post-launch actions**. If **Post-launch actions settings** shows **Post-launch actions** to be **Active**, you can edit any action defined in the default settings. Locate the action you want to edit in the **Actions** card view, or use the search field to filter the actions by name. Select the action’s card to select it, and then select **Edit**. To activate the action, make sure the **Activate this action** setting is checked and select **Save**. To deactivate, make sure the **Activate this action** setting is un-checked and select **Save**. The edit page allows to change the value of some of the parameters for both pre-defined actions and custom actions. Some parameters can only be edited if the action is a custom action. See below for specific information. The parameters that appear on the edit page: **Action name** – Editable for custom actions. The name of the action in AWS DRS, which should be intuitive, meaningful and unique in this AWS account and region. **Activate this action** – Use this checkbox to activate or deactivate the action by default. Newly added source servers have the action set to active or not active according to the value this field had when the source server was added. **Mark launch as successful only if this action finishes running successfully** – This checkbox dictates whether or not the launch is marked as successful, based on the successful run of this action. Instances launches still progress normally regardless of the success of the action. **System Manager document name** – Editable for custom actions. Select any Systems Manager document that is available to be used in this account. **View in Systems Manager** – Select to open **System Managers** and view additional information about the document. **Description** – Editable for custom actions. Add a description or keep the default. **Document version** – Editable for custom actions. Select which SSM document version to run. AWS DRS can run a default version, the latest version, or a specific version, according to your preferences. **Category** – Editable for custom actions. Select from various available categories including monitoring, validation, security and more. **Order** – Specify the order in which the actions run. The lower the number, the earlier the action runs. Values allowed are between 2 and 10,000. The numbers must be unique but don’t need to be consecutive. **Platform** – Not editable. Taken from the SSM document and reports which Operating System platform (Windows/Linux) is supported by the action. **Creator** – Not editable. Who created the action. For custom actions, the default is always **This account**. 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, AWS DRS dynamically populates the value. Some predefined actions, where applicable allow to use a dynamically populated value for the volumes. This value is dynamically populated by AWS DRS with the volumes of the instance being launched. After making the required changes, select **Save**, to save the changes and **Cancel** to abort them. # Deleting custom actions Custom actions created in default settings can also be deleted. Deleting a custom action in the default settings removes it from the default settings and means the action is no longer added to newly added servers. Deleting the action in the default settings does not remove it from existing source servers that have it. To delete a custom action from existing servers, go to the **Source server details** page, select the **Post-launch settings** tab and delete the action from there. Pre-defined actions cannot be deleted through AWS console. If a pre-defined action is not required, it can be deactivated or deleted via API. Locate the action you want to delete in the **Actions** card view, or use the search field to filter the actions by name. Select the action, and select **Delete**. To confirm, press **Delete**. # Predefined post-launch actions AWS Elastic Disaster Recovery allows you to run various predefined post-launch actions on your EC2 launched instance. Use these out-of-the-box actions to validate your launch or improve your launch flexibility. ***Choose from a variety of predefined post-launch actions*** + [Enable SSM](#enable-ssm) + [Install a CloudWatch Agent](#install-cloudwatch-agent) + [Create AMI from instance](#create-ami-form-instance) + [Configure Time Sync](#configure-time-sync) + [Volume integrity validation](#volume-integrity-validation) + [Process status validation](#process-status-validation) + [Validate disk space](post-launch-action-settings-overview.md#validate-disk-space) + [EC2 connectivity check](post-launch-action-settings-overview.md#ec2-connectivity-checks) + [HTTP/HTTPS response validation](post-launch-action-settings-overview.md#verify-http-response) + [Verify tags](post-launch-action-settings-overview.md#verify-tags) **Note** These predefined post-launch actions are supported in the Middle East: (UAE) Region: Enable SSM CloudWatch agent installation Create AMI from instance Volume integrity validation Process status validation Validate disk space EC2 connectivity check HTTP/HTTPS response validation Verify tags ## Enable SSM The AWS Systems Manager (AWS SSM) allows AWS Elastic Disaster Recovery to run post-launch actions on your recovery instances after they are launched. When you activate the post-launch actions, AWS Elastic Disaster Recovery installs the **AWS SSM agent**. The AWS 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). ## Install a CloudWatch Agent Use the **CloudWatch agent installation** feature to install and configure the CloudWatch Agent and Application Insights. The launched instance requires 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 have 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 will not be 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, simply 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) ## Create AMI from instance Use the Create AMI from Instance feature to create a new Amazon Machine Image (AMI) from your AWS DRS launched instance. 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 to have 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) ## 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) ## Volume integrity validation Use the **Volume integrity validation** to ensure that 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. ## Process status validation 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. ## 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. ## Amazon EC2 connectivity checks Use the **EC2 connectivity checks** 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. ## 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. ## Verify tags Use the **Verify Tags** feature to validate that tags which have been defined in the launch template and on the source server are copied to the migrated server.