# AWS Elastic Disaster Recovery (AWS DRS) settings
AWS Elastic Disaster Recovery includes multiple configuration options for resources consumed and produced by the service. There are three main categories that these configuration options fall into:
+ **Replication Settings** - Configuration Options for Replication Servers.
+ **Launch Settings** - Configuration Options for Source Server Launches.
+ **Post Launch Actions** - SSM Documents associated with Source Servers after Recovery Instances launch.
**Launch Settings** and **Replication Settings** are configurable on an individual Source Server, as well as defaults for a Region. **Default launch** settings and **Default replication** settings are initially configured while Initializing the AWS Elastic Disaster Recovery Service. A newly added Source Server is implicitly configured with the same settings defined in the **Default launch** settings and **Default replication** settings upon installation. You can adjust the individual configuration of a Source Server's Settings anytime after installation.
**Topics**
+ [AWS DRS replication settings](replication-settings.md)
+ [AWS DRS launch settings](launch-settings-overview.md)
+ [Configuring the default post-launch actions](post-launch-action-settings-overview.md)
# AWS DRS replication settings
**Replication Settings** govern how data is replicated from Source Servers and stored within AWS.
These topics address the different types of replication settings:
**Topics**
+ [AWS DRS default replication](default-replication-settings.md)
+ [AWS DRS individual replication settings](individual-replication-settings.md)
# AWS DRS default replication
**Default replication** settings are created during the DRS Service Initialization within a Region. [Learn more about configuring your **Default replication** settings](getting-started-initializing.md). The options configured within the **Default replication** automatically apply to any newly added Source Server. Any changes made to the **Default replication** only apply to any Source Server added after the changes were made, they do not automatically update the corresponding settings on existing Source Servers.
Most Replication Settings can be configured through the Default replication settings:
| Replication setting | Default replication |
| --- | --- |
| Staging area subnet | Supported |
| Replication server instance type | Supported |
| EBS volume type | Supported |
| EBS encryption | Supported |
| Automatically replicate new disks | Supported |
| Always use AWS Elastic Disaster Recovery security group | Supported |
| Security Group | Supported |
| Dedicated instance for replication server | Unsupported |
| Data Routing (Private IP) | Supported |
| IP Version | Supported |
| Create public IP | Supported |
| Network Bandwidth Throttling | Supported |
| Point in time (PIT) policy | Supported |
| MAP program tagging | Supported |
| Tags | Supported |
# AWS DRS individual replication settings
AWS Elastic Disaster Recovery attempts to reduce costs by consolidating the replication of as many source servers as possible onto the same Replication Server based on the individual Source Server **Replication Settings**. Source Servers must have identical **Replication Settings** to be considered for consolidation, and must not have [Use dedicated replication instance](#dedicated-replication-server) enabled. For example, DRS does not consolidate Source Servers that have a different **Staging area subnet** specified in their **Replication Settings**. To reduce EC2 usage, we recommend having as many as possible Source Servers have identical **Replication Settings** to one another.
Modifying the **Replication Settings** of an existing Source Server can impact existing replication, depending on the settings configured. Additionally, most **Replication Settings** options can be modified in bulk for multiple Source Servers through the AWS Elastic Disaster Recovery Console:
| Replication Setting | Impact | Bulk Editing |
| --- | --- | --- |
| Staging area subnet | Small pause while reconnecting Source Server to new Replicator. | Supported |
| Replication server instance type | Small pause while reconnecting Source Server to new Replicator. | Supported |
| Dedicated instance for replication server | Small pause while reconnecting Source Server to new Replicator. | Supported |
| EBS encryption | Full Sync may be required. | Supported |
| Data Routing (Private IP) | No impact. | Supported |
| IP Version | Small pause while reconnecting Source Server to new Replicator. | Supported |
| Network Bandwidth Throttling | No impact. | Supported |
| Point in time (PIT) policy | Replication server is disconnected as a safety measure. This ensures proper handling of retention policy changes that might affect replication state. | Supported |
| MAP program tagging | No impact. | Supported |
| Tags | No impact. | Supported |
## Replication server configuration
Replication Servers are AWS EC2 Instances automatically launched by AWS Elastic Disaster Recovery to support Continuous Data Replication from Source Servers.
### Staging area subnet
The **Staging area subnet** setting defines which VPC Subnet that the Replication Server for a Source Server uses. A Source Server must be able to successfully initialize connections to the subnet configured within its **Staging area subnet** setting. The best practice is to create a single dedicated, separate subnet for recovery in 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). Unless [Use private ip](https://docs.aws.amazon.com/) is enabled and valid routing within the VPC exists, Replication Servers must be in a [Public subnet](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-types). By default, a Replication Server assigns itself a [Public IPv4](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-public-addresses) without any additional configuration needed.
------
#### [ DRS Console ]
**Updating the Staging area subnet**
1. Navigate to the AWS Elastic Disaster Recovery Console. In the left navigation pane, select **Source Servers**.
1. Select one or more source servers, then select **Replication**.
1. Select **Edit replication settings**.
1. Navigate to **Replication server configuration**, then select the drop down box under **Staging area subnet**.
1. Select a new VPC Subnet from the drop down box.
1. Save settings by selecting **Save replication settings**.
------
#### [ Command Line ]
**Updating the Staging area subnet**
+ Updating the Staging area subnet via command line
+ [describe-recovery-instances](https://docs.aws.amazon.com/cli/latest/reference/drs/describe-recovery-instances.html) (AWS CLI)
```
aws drs describe-recovery-instances --source-server-id s-123456789abcdefgh --staging-area-subnet-id subnet-123456789abcd
```
+ [Update-EDRSReplicationConfiguration](https://docs.aws.amazon.com/powershell/latest/reference/items/Update-EDRSReplicationConfiguration.html) (DRS Tools for Windows PowerShell)
```
Update-EDRSReplicationConfiguration -SourceServerID s-123456789abcdefgh -StagingAreaSubnetId subnet-123456789abcd
```
------
### Replication server instance type
The **Replication server instance type** determines the EC2 Instance type and size that is used for the launch of a source server's replication server. DRS Replicators only support EC2 Instances with x86\$164 CPU architecture.
By default, AWS Elastic Disaster Recovery utilizes the t3.small instance type, and should work well for most common workloads. We recommend monitoring the Cloudwatch metrics of a replication server, if your Source Server is experiencing frequent Lag or Backlog. Metrics to monitor include EBSWriteBytes or EBSWriteOps, which may indicate the **Replication server instance type** is improperly sized to protect your source server.
AWS Elastic Disaster Recovery supports replicating Source Servers with up to 60 volumes, however the **Replication server instance type** must also support an equal or greater number of EBS Volume attachments. We recommend reviewing the [ Dedicated Amazon EBS volume limit Documentation](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/volume_limits.html#dedicated-limit) to ensure an appropriately sized EC2 Instance Type is selected.
------
#### [ DRS Console ]
**Updating the Replication server instance type**
1. Navigate to the AWS Elastic Disaster Recovery Console. In the left navigation pane, select **Source Servers**.
1. Select one or more source servers, then select **Replication**.
1. Select **Edit replication settings**.
1. Navigate to **Replication server configuration**, then select the drop down box under **Dedicated instance for replication server**.
1. Select **Replication server instance** from the drop down box.
1. Save settings by selecting **Save replication settings**.
------
#### [ Command Line ]
**Modifying Dedicated instance for replication server**
+ Updating the Replication server instance type via command line
+ [update-replication-configuration](https://docs.aws.amazon.com/cli/latest/reference/drs/update-replication-configuration.html) (AWS CLI)
```
aws drs update-replication-configuration --source-server-id s-123456789abcdefgh --replication-server-instance-type m5.large
```
+ [Update-EDRSReplicationConfiguration](https://docs.aws.amazon.com/powershell/latest/reference/items/Update-EDRSReplicationConfiguration.html) (DRS Tools for Windows PowerShell)
```
Update-EDRSReplicationConfiguration -SourceServerID s-123456789abcdefgh -ReplicationServerInstanceType m5.large
```
------
### Dedicated instance for replication server
The **Dedicated instance for replication server** setting specifies whether or not the Source Server can use a Replication Server shared with other Source Servers. By default, AWS Elastic Disaster Recovery attempts to consolidate as many Source Servers as possible onto a single Replication Server, based on a variety of factors. Setting **Dedicated instance for replication server** to **use dedicated replication instance** ensures that only this Source Server replicates data to the Replication Server.
We recommend leaving **Dedicated instance for replication server** as **do not use dedicated replication instance** unless the Source Server is experiencing frequent Lag or Backlog due to sharing a Replication Server with other Source Servers. Using a dedicated replication server may increase EC2 costs associated with protecting a Source Server.
------
#### [ DRS Console ]
**Enabling Dedicated instance for replication server**
1. Navigate to the AWS Elastic Disaster Recovery Console. In the left navigation pane, select **Source Servers**.
1. Select one or more source servers, then select **Replication**.
1. Select **Edit replication settings**.
1. Navigate to **Replication server configuration**, then select the drop down box under **Dedicated instance for replication server**.
1. Select **use dedicated replication instance** from the drop down box.
1. Save settings by selecting **Save replication settings**.
------
#### [ Command Line ]
**Modifying Dedicated instance for replication server**
1. Enabling Dedicated instance for replication server via command line
+ [update-replication-configuration](https://docs.aws.amazon.com/cli/latest/reference/drs/update-replication-configuration.html) (AWS CLI)
```
aws drs update-replication-configuration --source-server-id s-123456789abcdefgh --use-dedicated-replication-server
```
+ [Update-EDRSReplicationConfiguration](https://docs.aws.amazon.com/powershell/latest/reference/items/Update-EDRSReplicationConfiguration.html) (DRS Tools for Windows PowerShell)
```
Update-EDRSReplicationConfiguration -SourceServerID s-123456789abcdefgh -UseDedicatedReplicationServer $true
```
1. Disabling Dedicated instance for replication server via commandline
+ [update-replication-configuration](https://docs.aws.amazon.com/cli/latest/reference/drs/update-replication-configuration.html) (AWS CLI)
```
aws drs update-replication-configuration --source-server-id s-123456789abcdefgh --no-use-dedicated-replication-server
```
+ [Update-EDRSReplicationConfiguration](https://docs.aws.amazon.com/powershell/latest/reference/items/Update-EDRSReplicationConfiguration.html) (DRS Tools for Windows PowerShell)
```
Update-EDRSReplicationConfiguration -SourceServerID s-123456789abcdefgh -UseDedicatedReplicationServer $false
```
------
# Amazon EBS volumes
Set the default Amazon EBS volume type used by the replication servers, whether to use Amazon EBS encryption, and whether to automatically replicate newly added disks.
## Amazon EBS volume type
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 **Auto volume type selection** volume type, unless there is a business need for doing so.
Choose the default **Amazon EBS volume type** to be used by the replication servers for large disks:
+ With **Auto volume type selection** the service dynamically switches between performance/cost optimized volume type according to the replicated disk write throughput.
**Note**
This option only affects disks over 125 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 takes
+ The **Faster, General Purpose SSD (gp2)** and Faster, **General Purpose SSD (gp3)** options utilize 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](disk-settings.md).
## Amazon EBS encryption
Choose your encryption approach:
+ When you choose **Default**, the default key is used. This can be an EBS-managed key or a customer-managed key. This option encrypts your replicated data at rest on the staging area subnet disks and the replicated disks.
+ Choose **Custom** and then enter the ARN or key ID of a customer-managed key from your account or another AWS account in the **EBS encryption key** field. Enter the key, such as a cross-account KMS key, in standard key ID format. For example, KMS key format is `1234abcd-12ab-34cd-56ef-1234567890ab`. This option encrypts your replicated data at rest on the staging area subnet disks and the replicated disks.
+ Choose **Create an AWS KMS key** to be redirected to the Key Management Service (KMS) Console where you can create a new key to use.
Learn more about EBS Volume Encryption in [Amazon EBS encryption](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html).
**Important**
Changing the encryption option after data replication has started causes data replication to start from the beginning.
## Automatic replication of new disks
AWS Elastic Disaster Recovery (AWS DRS) allows you to automatically replicate newly added disks. When you add new disks to your source environment, AWS DRS initiates data replication to the staging area subnet in your AWS account.
Automating replication of new disks assists you in maintaining continuous data replication, saves time and resources, and reduces the risk of data loss in the event of a disruption.
This feature is activated automatically for newly added servers.
To deactivate or reactivate this feature for newly added servers:
+ Under **Settings** on the left-hand navigation menu, choose **Default replication settings**.
+ Select **Edit**.
+ Under **Volumes**, uncheck the **Automatically replicate new disks** checkbox.
To activate or deactivate or reactivate this feature for a specific server:
+ Go to the replication settings.
+ Select **Edit**.
+ Under **Volumes**, uncheck the **Automatically replicate new disks** checkbox.
**Note**
This feature is only supported for new agent versions (version 4.6 or higher). For older versions, you must reinstall your agent to activate automatic replication of new disks.
Auto replication of new disks is not supported with --force-volumes.
It might take up to 10 minutes for new disks to start replicating.
New disks are only replicated once the feature is activated and are not replicated retroactively.
# Elastic Disaster Recovery security groups
A security group acts as a virtual firewall, which controls the inbound and outbound traffic of the staging area. We recommend that you have AWS Elastic Disaster Recovery automatically attach and monitor the default Elastic Disaster Recovery security group. This group opens inbound TCP Port 1500 for receiving the transferred replicated data. When you use the default Elastic Disaster Recovery security group, Elastic Disaster Recovery constantly monitors whether the rules within this security group are enforced, in order to maintain uninterrupted data replication. If these rules are altered, Elastic Disaster Recovery automatically fixes the issue. Choose:
+ Recommended - Select **Always use AWS Elastic Disaster Recovery security group** to allow data to flow from your source servers to the replication servers, and so that the replication servers can communicate their state to the AWS Elastic Disaster Recovery servers.
+ Not recommended - Deselect **Always use AWS Elastic Disaster Recovery security group** option. Then, select the drop-down menu to choose from the list of available security groups. The list of available security groups changes according to the **Staging area subnet** that you selected.
+ To search for a specific security group, use the search box.
+ If you add security groups via the AWS Console, they appear on the Security group drop-down list in the AWS Elastic Disaster Recovery Console. Learn more about AWS security groups in [this VPC article](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html).
+ Any security group that you select is added to the default AWS Elastic Disaster Recovery group, because the default security group is essential for the operation of AWS Elastic Disaster Recovery.
# Data routing and throttling
AWS Elastic Disaster Recovery lets you 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 IPv4 address that was automatically assigned to the replication servers. Transferred data is always encrypted in transit. Choose **Use private IP for data replication...** 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. Data replication does not work unless you have already set up the VPN, AWS Direct Connect, or VPC peering in the AWS Console. 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).
**Note**
If you selected the Default subnet, it is 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 use this option.
You can safely select and deselect **Use private IP for data replication....** even after data replication has begun. This switch causes a short pause in replication, and does not have long-term effects on the replication.
Choosing the **Use Private IP for data replication...** option does not create a new private connection.
When you select the **Use private IP** option, you choose to **Create public IP**. Public IPs are used by default.
## IP version
The **IP version** setting controls the Internet Protocol version that AWS Elastic Disaster Recovery uses for data replication and for communication between your source servers and the staging area. You can choose between **IPv4** (default) and **IPv6**.
When you select **IPv6**, the following changes apply:
+ Data replication from the AWS Replication Agent to the replication server uses IPv6.
+ The replication server receives an IPv6 address and does not receive a public IPv4 address.
+ Communication during drills and recoveries uses IPv6.
**Important**
Before you select **IPv6**, verify the following prerequisites:
Your staging area subnet must have an IPv6 CIDR block.
Your replication server instance type must support IPv6.
There is no automatic fallback to IPv4 for data replication. If IPv6 connectivity between your source servers and the replication servers is unavailable, data replication fails.
**Note**
When you select **IPv6**, other IP-related options (such as **Use private IP** and **Create public IP**) are hidden in the console. Your prior IPv4 configurations are preserved and take effect if you switch back to **IPv4**.
**Note**
The **IP version** setting does not affect recovery instance networking. Recovery instances use the networking configuration defined in your launch settings.
**Note**
If you use the Failback Client for failback to on-premises infrastructure, the Failback Client currently supports IPv4 only. In-AWS failback uses the configured IP version.
The **IP version** setting is separate from the `--dualstack` installer parameter. The `--dualstack` parameter controls which API endpoints the agent uses to communicate with AWS services, and does not change the IP version used for data replication. For more information, see [AWS Replication Agent Installer parameters](installer-parameters.md).
## Throttle network bandwidth
You can control the amount of network bandwidth used for data replication per server. By default, AWS Elastic Disaster Recovery uses all available network bandwidth over five concurrent connections.
Choose **Throttle network bandwidth... ** to control the transfer rate of data sent from your source servers to the replication servers over TCP Port 1500. Enter the bandwidth in Mbps in the bandwidth field
# Point in time (PIT) policy
AWS Elastic Disaster Recovery allows you to select the number of days for which point in time snapshots are retained through the **Point in time (PIT) policy** field.
You can select to save PIT snapshots for 1 to 365 days. Saving PIT snapshots for more days allows you more recovery options, but also results in increased costs. [Learn more about Point in time.](CloudEndure-Concepts.md#point-in-time-faq)
**Important**
The PIT policy must contain exactly three rules: one for MINUTE, one for HOUR, and one for DAY. The snapshot frequency intervals and retention durations for the MINUTE rule (`interval=10`, `retentionDuration=60`) and HOUR rule (`interval=1`, `retentionDuration=24`) are fixed and cannot be modified. Only the DAY rule's `retentionDuration` is configurable, with a value from 1 to 365 days.
------
#### [ DRS Console ]
**Adjusting PIT Retention Rate**
1. Navigate to the AWS Elastic Disaster Recovery Console. In the left navigation pane, select **Source Servers**
1. Select one or more source servers, then select **Replication**.
1. Select **Edit replication settings**.
1. Navigate to **Point in time (PIT) policy**.
1. Enter a new Integer from 1 to 365 in **Snapshot retention (in days)**.
1. Select **Save replication settings**.
------
#### [ Command Line ]
**Adjusting PIT Retention Rate**
+ [update-replication-configuration](https://docs.aws.amazon.com/cli/latest/reference/drs/update-replication-configuration.html) (AWS CLI)
```
aws drs update-replication-configuration --source-server-id s-123456789abcdefgh --pit-policy enabled=true,interval=10,retentionDuration=60,ruleID=1,units="MINUTE" enabled=true,interval=1,retentionDuration=24,ruleID=2,units="HOUR" enabled=true,interval=1,retentionDuration=14,ruleID=3,units="DAY"
```
------
# Elastic Disaster Recovery tags
Add custom **tags** to resources created by AWS Elastic Disaster Recovery in your AWS account. You can add up to 50 tags.
These are resources required to facilitate data replication, drilling and recovery. 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 Elastic Disaster Recovery.
To add new tags:
1. Choose **Add new tag**.
1. Enter a **custom tag key** and an optional tag value.
**Note**
AWS Elastic Disaster Recovery 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
Learn more about AWS tags in [Tag your Amazon EC2 resources.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)
# MAP program tagging
The AWS Migration Acceleration Program (MAP) provides tools that are designed to reduce costs, boost productivity, improve operational resilience and increase business agility.
The DRS MAP program tagging is a feature that allows you to apply MAP program tags to your source servers and replication resources in order to offset the ongoing cost of protecting your servers.
[Learn more about the AWS Migration Acceleration Program (MAP)](https://aws.amazon.com/migration-acceleration-program).
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 the MAP program. Then, specify the MAP tag value that is used in your MAP tagging. Application Migration Service automatically tags 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.
You can choose to add tags to:
+ One or more existing source servers and replication resources
+ All newly added source servers and replication resources
## Adding tags to existing source servers and replication sources
To add tags to one or more existing source servers and replication sources:
+ Select the relevant source servers.
+ Select **Edit replication settings** from the replication drop-down menu
+ Check the box to the left of **Add MAP tag to the source servers and replication resources**.
+ Specify the MAP tag value that is used in your MAP tagging.
DRS automatically tags your source servers and replication resources with the tag key "map-migrated” and the value of the tag that you provide.
## Adding tags to newly added source servers and replication sources
To add tags to all newly added source servers and replication sources:
+ Select **Settings** from the left-hand menu.
+ Select **Edit ** to change the default replication settings.
+ Check the box to the left of **Add MAP tag to the source servers and replication resources** option.
+ Specify the MAP tag value that is used in your MAP tagging.
+ Select **Save changes**.
AWS Elastic Disaster Recovery automatically tags every newly-added source server and replication resources with the tag key “map-migrated” and the value of the tag that you provide.
For more details about the tag value that should be used here, please refer to the MAP tagging guide provided in your MAP term.
# AWS DRS launch settings
The launch settings are a set of instructions that determine how drill or recovery instances are launched in AWS. They include two sections: general launch settings and the EC2 launch template. These settings are created automatically every time you add a source server to AWS Elastic Disaster Recovery. The launch settings can be modified at any time, even before a specific source server has completed its initial sync.
**Topics**
+ [Default AWS DRS launch settings](default-drs-launch-settings.md)
+ [Default Amazon Elastic Compute Cloud (Amazon EC2) launch template](default-ec2-launch-template.md)
# Default AWS DRS launch settings
AWS Elastic Disaster Recovery (AWS DRS) allows you to configure the default launch settings and change them at any time.
The default launch settings apply to any new source server added to AWS DRS. You are prompted to configure your default launch settings upon your first use of AWS DRS.
Launch settings can also be edited manually for individual servers.
# Editing the default AWS DRS launch settings
The default launch settings are applied to every newly launched source server in AWS Elastic Disaster Recovery (AWS DRS). You can change these settings for a single or multiple servers whenever you choose.
To edit these settings, follow these steps:
1. Select **Default launch** from the left-hand navigation menu (under **Settings**).
1. Select **Edit** in the **Default DRS launch settings** section.
1. Change the settings according to your preferences.
1. Select **Save**.
## Launch settings parameters
AWS Elastic Disaster Recovery (AWS DRS) launch settings include:
+ **Instance type right sizing –** Allow the service to automatically update the instance type on the EC2 launch template, based on the CPU and RAM of the source server. If this setting is active (default), any modification you make to the instance type in the EC2 launch template is overwritten by the service.
+ **Start instance upon launch –** Configure how the EC2 recovery instance should be launched – running or in a stopped state.
+ **Copy private IP –** Define whether the private IP should be copied from the source server’s primary network interface to the EC2 launch template. If this setting is on, make sure that the subnet defined in the EC2 launch template includes that IP in its range.
+ **Transfer server tags –** Define if the launched EC2 instance should have the same tags as the source server resource.
+ **Launch into source instance -** Define whether DRS automatically assigns the ID of the source instances to the **Launch into instance ID** field in the Launch Settings of newly added source servers in this region. A source instance is the EC2 instance in this region that was the source of the data before replication was reversed to this region or availability zone. The EC2 instance to launch into must have a tag with key *AWSDRS* and value *AllowLaunchingIntoThisInstance*, and it must be stopped before launching into it. If **Launch into instance ID** is automatically set for a source server, the **Transfer server tags**, and **Copy private IP** settings need to be deactivated for that server, as they cannot apply to an already launched instance.
**Note**
Note that for the instance to appear as a recovery instance in DRS, it needs to have an instance profile that includes the policy **AWSElasticDisasterRecoveryRecoveryInstancePolicy**. The role **AWSElasticDisasterRecoveryRecoveryInstanceRole**, which is added to an account when initializing the service, contains this policy and can be used as an instance profile.
[Learn more about Launch into source instance](https://docs.aws.amazon.com/drs/latest/userguide/default-drs-launch-into-source-instance).
+ **OS** ** licensing – ** Choose the launched instance’s license type for Windows Servers – License-included or Bring Your Own License (BYOL). Linux servers and Windows Home are automatically launched as BYOL. If you launch a Windows Server or Windows Home as BYOL, you must select Dedicated host for the Tenancy setting in the advanced settings of the EC2 launch template.
# Launch into source instance
This setting is only valid when the replication and recovery are done in-AWS, between 2 AWS regions or availability zones. This default setting applies to newly added source servers. Such servers have their **Launch into instance ID** field in the Launch Settings set to the EC2 instance ID of the source instance, that was the source of the data in the same region or availability zone. See the examples below for more details.
## Pre-requisites
**Start reversed replication** or **Protect recovered instance** fails to create a source server if this setting is active and one of these conditions is not met:
1. The instance to launch into must have the required tag with key *AWSDRS* and value *AllowLaunchingIntoThisInstance*.
1. The instance to launch into must have the same operating system platform (Linux or Windows) as that of the recovery instance the **Start reversed replication** or **Protect recovered instance** was called on.
1. If the instance to launch into is Linux, it must have the BIOS boot mode, and if this is Windows, it must have the same boot mode as that of the recovery instance the **Start reversed replication** or **Protect recovered instance** was called on.
1. The instance to launch into must have the x86\$164 architecture, HVM virtualization and an EBS root device.
1. **OS licensing** in **Default DRS launch settings** can only be **Bring Your Own License (BYOL)** if the instance’s platform is Linux or if the instance’s **tenancy** is **dedicated host**.
1. **Transfer server tags** and **Copy private IP** must be deactivated in **Default DRS launch settings**.
## Cross-region
With this setting active, customers who replicate their EC2 instances between two AWS regions, launch in the second region from an instance in the first region, and call **Start reversed replication** to go back to the first region will have their source servers in the first region automatically set **Launch into instance ID** to the instance ID of the instance in the first region they initially launched from.
Using the diagram below as an example, the setting applies to source servers such as Source Server **S1** and automatically sets the **Launch into instance ID** to the instance ID of EC2 instance **EI1** (marked by the dotted green arrow in the diagram).
This only happens if:
1. **Launch into source instance** was set to be active in the **Default DRS launch settings** on region 1.
1. EC2 instance **EI1** (on AWS region 1) replicated into region 2 (replication handled through source server **S2** on AWS region 2), and was launched in AWS region 2 (launch handled through source server **S2** on AWS region 2), creating recovery instance **RI2**.
1. Source server **S1** was created by calling **Start reversed replication** in region 2 on recovery instance **RI2** (marked by the solid green arrow), replicating the data of EC2 instance **EI2**.
![\[AWS multi-region setup with EC2 instances and DRS servers for disaster recovery.\]](http://docs.aws.amazon.com/drs/latest/userguide/images/recover-into-source-instance-cross-regions.png)
## Cross Availability Zone
With this setting active, customers who replicate their EC2 instances into the same region (and if following our recommendation, into a different availability zone within that region), launch in the region (recommended to launch into the other availability zone) from an instance in the first availability zone, and perform **Protect recovered instance** on the source server after this launch, will have the source server automatically set **Launch into instance ID** to the instance ID of the instance in the first availability zone.
Using the diagram below as an example, the setting applies to source servers such as Source Server **S** and automatically sets the **Launch into instance ID** to the instance ID of EC2 instance **EI1** (marked by the dotted green arrow in the diagram).
This only happens if:
1. **Launch into source instance** was set to be active in the **Default DRS launch settings** on this region.
1. EC2 instance **EI1** (on AWS region 1) replicated into availability zone 2 (replication handled through source server **S**), and was launched in availability zone 2 (launch handled through source server **S**), creating recovery instance **RI**.
1. Source server **S** was then updated to protect recovery instance **RI** (marked by the solid green arrow), by calling Protect recovered instance, replicating the data of EC2 instance EI2.
![\[AWS Region diagram showing DRS Source Server S, Recovery Instance RI, and EC2 instances in two Availability Zones.\]](http://docs.aws.amazon.com/drs/latest/userguide/images/recover-into-source-instance-cross-az.png)
# Default Amazon Elastic Compute Cloud (Amazon EC2) launch template
The default Amazon EC2 launch template sets the default values that are copied to EC2 templates created for newly added source servers. This template defines how drill, recovery, or failback instances are launched. If you didn't create any default EC2 template, AWS DRS copies the default values for each setting to EC2 launch templates for newly added servers.
You can usually launch a drill instance without modifying the automatically created EC2 launch template (unless you have removed the default VPC/subnet from your AWS account).
**Topics**
+ [Editing the default EC2 launch template](edit-default-ec2-launch-template.md)
# Editing the default EC2 launch template
To edit the default EC2 launch template, follow these steps:
1. Select **Default launch** from the left-hand navigation menu (under **Settings**).
1. Select **Edit** in the **Default EC2 launch template** section.
1. Change the settings according to your preferences.
1. Select **Save**.
## Amazon EC2 launch template parameters
AWS Elastic Disaster Recovery (AWS DRS) Amazon EC2 launch settings are divided into basic and advanced settings.
The basic settings include:
+ **Subnet –** When you specify a subnet, this field defines where the instance is launched. When selecting a subnet, only the default network interface is updated. If you do not include a subnet, the launched instance uses the Region’s default subnet.
+ **Security groups –** The selected security groups to assign to the instance, applied to the subnet selected for the default network interface. If no security group is selected, there is no default value and no group is used. Security groups can only be selected if a subnet is included.
+ **Instance type –** The default instance type to use when launching. If instance type right-sizing is active, the system disregards this setting. If no instance type is included, a default value is used. You can either select an instance type, or you can specify instance attributes and let Amazon EC2 identify the instance types with those attributes.
+ **EBS volume type –** Applies to all volumes for which this type is relevant. If an unmatching type exists, the default type (GP3) is used instead. Some volume types require setting additional values such as IOPS or throughput.
**Instance type attributes:**
+ **Number of vCPUs:** Enter the minimum and maximum number of vCPUs for your compute requirements. To indicate no limits, mark the no minimum or no maximum checkboxes.
+ **Amount of memory (MiB):** Enter the minimum and maximum amount of memory, in MiB, for your compute requirements. To indicate no limits, mark the no minimum or no maximum checkboxes.
+ Expand **Optional instance type attributes** and choose **Add attribute** to express your compute requirements in more detail. For information about each attribute, see [InstanceRequirementsRequest](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_InstanceRequirementsRequest.html) in the Amazon EC2 API Reference.
+ **Preview matching instance types:** You can preview the instance types that match the specified attributes. To exclude instance types, you can select the instance types you want to exclude from the previewed list of instance types, but only if you did not allow list instance types, as you can either exclude or allowlist instance types but not both.
See more about these attributes here: [How attribute-based instance type selection works](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html#ec2fleet-abs-how-it-works). EC2 uses fleets to launch your instances, and applies price protection to ensure the fleet does not pick expensive instance types for you. We use the default protection settings, so we protect against selecting instance types that are 20% more expensive than the lowest cost instance type. To learn more about price protection using fleets, visit: [Price protection](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html#ec2fleet-abs-price-protection).
To learn more about using instance type attributes in DRS, visit [Flexible Instance Types](https://docs.aws.amazon.com//drs/latest/userguide/flexible-instance-types.html)
Advanced settings include additional parameters that add specific features to the EC2 template. If you choose not to include these parameters in the template, the specific capabilities are not added.
The advanced settings include:
+ **IAM instance profile –** Attach a specific profile to the instance that will be launched. Make sure the instance profile has the AWSElasticDisasterRecoveryRecoveryInstancePolicy IAM policy attached in addition to any other policy.
+ **Auto assign public IP –** Automatically assign a public IP to the launched instance.
+ **Termination protection –** Protect the launched instance from accidental termination using the EC2 console.
+ **Tenancy –** Set tenancy information, such as dedicated host needed in conjunction with setting BYOL for Windows servers and Windows Home.
+ **Capacity reservation –** Apply reservation consideration to the launched instances.
+ **Key pair –** Associate a key pair with launched instances that are based on EC2 instances.
**Note**
AWS DRS only supports major EC2 template parameters. If you want to change values that are not supported by this feature, you can still do so by editing the EC2 launch template via the Amazon EC2 console:
Create a new EC2 template version with the required changes.
Mark it as default.
**Important**
Every time you modify an EC2 launch template on the Amazon EC2 console, a new version is created. AWS DRS uses the version that is marked as the default. If you prefer to use the EC2 launch template you just modified, make sure to mark it as the default. Changes made through the AWS DRS console are automatically set as the default version.
**EC2 launch template tags –** In addition to the basic and advanced settings, you can also add up to 50 tags. These are transferred to EC2 launch template created by AWS Elastic Disaster Recovery (AWS DRS) service.
Learn more about EC2 launch template settings and configuration options in [this EC2 article](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html).
## Amazon EC2 template considerations
1. **Revert to previous version –** The right-sizing mechanism can fix issues such as an incorrect instance type, but other issues may still occur. If you encounter any issues with the launch template, you can quickly address them by choosing the original default launch template that was created by AWS DRS when the agent was installed. Alternatively, you can edit the relevant fields from the AWS DRS console.
1. **IOPS –** If needed, set the number of I/O operations per second that the volume can support via the Amazon EC2 console. You can select any number as long as it matches the Amazon EBS guidelines.
+ Provisioned IOPS SSD (io1): 50 IOPS per GiB of storage
+ Provisioned IOPS SSD (io2): 500 IOPS per GiB of storage
+ General Purpose SSD (gp3): 500 IOPS per GiB of storage
# Configuring the default 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 these 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 are 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 your IAM entities:
**Example**
```
{
"Effect": "Allow",
"Action": [
"ssm:SendCommand",
],
"Resource": "arn:aws:ssm:*:111111111111:document/MyCommand",
"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 SSM documents to run 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-launch 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.
**Systems Manager document name** – Select any Systems Manager document that is available to be used in this account.
**View in Systems Manager** – select to open **Systems Manager** 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** > **Advanced** > **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 considering 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. Instance launches still progress normally regardless of the success of the action.
**Systems 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 **Systems Manager** 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 launched 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 > Advanced > 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:
+ [CreateImage](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 disk 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.