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*.
# FAQ
Use this section to find answers to many frequently asked questions.
**Topics**
+ [General questions](General-Questions-FAQ.md)
+ [Agent related](Agent-Related-FAQ.md)
+ [Agentless replication related](Agentless-Replication-Related-FAQ.md)
+ [Replication related](Replication-Related-FAQ.md)
+ [AWS related](AWS-Related-FAQ.md)
+ [Does AWS MGN work with...?](does-mgn.md)
+ [Post-launch actions related](Post-Launch-Actions-FAQ.md)
# General questions
This section contains answers to general questions about AWS Application Migration Service.
**Topics**
+ [Can AWS Application Migration Service protect or migrate physical servers?](#Can-CloudEndure-Protect-Migrate-Servers)
+ [What data is stored on and transmitted through Application Migration Service servers?](#What-Data-Stored)
+ [What should I consider when replicating Active Directory?](#What-Active-Directory)
+ [Does AWS Application Migration Service work with LVM and RAID configurations?](#Does-LVM-RAID-Work)
+ [What is there to note regarding SAN/NAS support?](#SAN-NAS-Support)
+ [Does AWS Application Migration Service support Windows License migration?](#Does-Windows-License-Migration)
+ [Can you perform an OS (Operating System) upgrade with AWS Application Migration Service?](#Can-OS-Upgrade)
+ [What are the AWS Application Migration Service quota limits?](#MGN-service-limits-faq)
+ [What are the Private APIs used by AWS MGN to define actions in the IAM Policy?](#mgn-apis)
+ [Which post-launch scripts does AWS MGN support?](#mgn-post-launch)
+ [What happens if I use a custom DNS?](#custom-DNS)
+ [Can I use AWS Application Migration Service to migrate servers from VMware Cloud on AWS (VMC) to Amazon EC2?](#vmc)
+ [When should I use AWS Elastic Disaster Recovery (AWS DRS) for migration?](#using-drs)
## Can AWS Application Migration Service protect or migrate physical servers?
Because AWS Application Migration Service works at the OS layer it can protect and migrate not only virtual servers but physical ones as well.
## What data is stored on and transmitted through Application Migration Service servers?
AWS Application Migration Service store only configuration and log data on the AWS Application Migration Service console's encrypted database. Replicated data is always stored on the customer’s own cloud VPC. The replicated data is encrypted in transit.
## What should I consider when replicating Active Directory?
There are two main approaches when it comes to migrating Active Directory or domain controllers from a disaster:
1. Replicating the entire environment, including the AD server(s) – in this approach it is recommended to launch the test or cutover AD servers first, wait until it's up and running, and then launch the other test or cutover instances, to make sure the AD servers are ready to authenticate them.
1. Leaving the AD server(s) in the source environment – in this approach, the test or cutover instances will communicate back to the AD server in the source environment and will take the source server's place in the AD automatically.
In this case, it is important to conduct any tests using an isolated subnet in the AWS cloud, so to avoid having the test or cutover instances communicate into the source AD server outside of a cutover.
## Does AWS Application Migration Service work with LVM and RAID configurations?
Yes, AWS Application Migration Service works with any such configuration.
## What is there to note regarding SAN/NAS support?
If the disks are represented as block devices on the machine, as most SAN are, AWS Application Migration Service will replicate them transparently, just like actual local disks.
If the disks are mounted over the network, such as an NFS share, as most NAS implementations are, the AWS Replication Agent would need to be installed on the actual NFS server in order to replicate the disk.
## Does AWS Application Migration Service support Windows License migration?
AWS Application Migration Service conforms to the [Microsoft Licensing on AWS](https://aws.amazon.com/windows/resources/licensing/) guidelines.
## Can you perform an OS (Operating System) upgrade with AWS Application Migration Service?
Yes. AWS Application Migration Service allows you to [perform an OS upgrade](predefined-post-launch-actions.md#predefined-windows-upgrade) using a predefined action. The action will clone your machine and upgrade the clone. After the upgrade, verify that the cloned machine is working well, and then you can begin using it.
## What are the AWS Application Migration Service quota limits?
The following are the AWS Application Migration Service service quota limits:
| Name | Default | Description |
| --- | --- | --- |
| Concurrent jobs in progress | Each supported AWS Region: 20 | Launching a test or cutover instance, or a cleanup action is considered a "job". This parameter is the maximum number of Jobs that can be run concurrently. Jobs that are Completed are not counted against this quota. |
| Max active source servers | Each supported AWS Region: 150 | The maximum number of servers that can be actively replicating at any time. For larger migrations contact Support. |
| Max non-archived source servers | Each supported AWS Region: 4,000 | This parameter is used for agentless migrations. This is the max number of servers that can be managed by MGN, in non-archived state. This includes the servers that are actively replicating, as well as any servers whose replication has not yet started. The number of actively replicating servers is controlled by the parameter Max active source servers. |
| Max source servers in a single job | Each supported AWS Region: 200 | Launching a test or cutover instance, or a cleanup action is considered a "Job". If you select multiple servers, and perform one of these actions, they are grouped into a single job. This is the maximum number of servers that can be grouped into a single Job. |
| Max source servers in all jobs | Each supported AWS Region: 200 | Launching a test or cutover instance, or a cleanup action is considered a "Job". This is the maximum total number of servers that can be configured in all active Jobs. Jobs that are Completed are not counted against this quota. |
| Max total source servers per AWS account | Each supported AWS Region: 50,000 | This parameter is the maximum total servers, both active and archived, that can be migrated in a single account in each AWS Region. Servers that are deleted, are not counted against this quota. |
| Max concurrent jobs per source server | Each supported AWS Region: 1 | Launching a test or cutover instance, or a cleanup action is considered a "Job". This is the maximum number of active Jobs, that can be configured per server. Jobs that are Completed are not counted against this quota. |
You can learn about the AWS Application Migration Service limits in the [AWS General Reference](https://docs.aws.amazon.com/general/latest/gr/mgn.html).
## What are the Private APIs used by AWS MGN to define actions in the IAM Policy?
MGN utilizes the following Private API resources as actions in the IAM Policy. [Learn more about Actions, resources, and condition keys for MGN. ](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapplicationmigrationservice.html)
+ BatchCreateVolumeSnapshotGroupForMgn – Grants permission to create volume snapshot group.
+ BatchDeleteSnapshotRequestForMgn – Grants permission to batch delete snapshot request.
+ DescribeReplicationServerAssociationsForMgn – Grants permission to describe replication server associations.
+ DescribeSnapshotRequestsForMgn – Grants permission to describe snapshots requests.
+ GetAgentCommandForMgn – Grants permission to get agent command.
+ GetAgentConfirmedResumeInfoForMgn – Grants permission to get agent confirmed resume info.
+ GetAgentInstallationAssetsForMgn – Grants permission to get agent installation assets.
+ GetAgentReplicationInfoForMgn – Grants permission to get agent replication info.
+ GetAgentRuntimeConfigurationForMgn – Grants permission to get agent runtime configuration.
+ GetAgentSnapshotCreditsForMgn – Grants permission to get agent snapshots credits.
+ GetChannelCommandsForMgn – Grants permission to get channel commands.
+ NotifyAgentAuthenticationForMgn – Grants permission to notify agent authentication.
+ NotifyAgentConnectedForMgn – Grants permission to notify agent is connected.
+ NotifyAgentDisconnectedForMgn – Grants permission to notify agent is disconnected
+ NotifyAgentReplicationProgressForMgn – Grants permission to notify agent replication progress.
+ RegisterAgentForMgn – Grants permission to register agent.
+ SendAgentLogsForMgn – Grants permission to send agent logs.
+ SendAgentMetricsForMgn – Grants permission to send agent metrics.
+ SendChannelCommandResultForMgn – Grants permission to send channel command result.
+ SendClientLogsForMgn – Grants permission to send client logs.
+ SendClientMetricsForMgn – Grants permission to send client metrics.
+ UpdateAgentBacklogForMgn – Grants permission to update agent backlog.
+ UpdateAgentConversionInfoForMgn – Grants permission to update agent conversion info.
+ UpdateAgentReplicationInfoForMgn – Grants permission to update agent replication info.
+ UpdateAgentReplicationProcessStateForMgn – Grants permission to update agent replication process state.
+ UpdateAgentSourcePropertiesForMgn – Grants permission to update agent source properties.
+ CreateVcenterClientForMgn – Grants permission to create a vCenter client.
+ GetVcenterClientCommandsForMgn – Grants permission get a vCenter client.
+ SendVcenterClientCommandResultForMgn – Grants permission to send vCenter client command result.
+ SendVcenterClientLogsForMgn – Grants permission to send vCenter client logs.
+ SendVcenterClientMetricsForMgn – Grants permission to send vCenter client metrics.
+ NotifyVcenterClientStartedForMgn – Grants permission to notify vCenter client started.
+ IssueAgentCertificateForMgn – Grants permission to send certificate signing request.
## Which post-launch scripts does AWS MGN support?
MGN can run scripts on a launched test or cutover instance. This is done by creating the following folder on the source server and placing the scripts within that folder.
**Linux**: /boot/post\$1launch (any files that are marked as executable)
**Windows**: C:\$1Program Files (x86)\$1AWS Replication Agent\$1post\$1launch\$1 (any .exe, .cmd, or .bat files)
Once you put these scripts in the above folders on the source server, the folder will be replicated to the test or cutover instance and be executed once after the instance boots for the first time.
**Note**
Post-launch scripts on Windows run under the Local System context. Post-launch scripts on Linux run under the 'root' user.
### Uninstalling VMTools from Windows
The following script can be utilized to uninstall VMTools post migration from Windows. This is a powershell script. It needs to be wrapped by a .CMD file, as powershell scripts are not run automatically by the post\$1launch.
```
$regpath = "HKLM:\Software\Microsoft\Windows\CurrentVersion\uninstall"
Get-childItem $regpath | % {
$keypath = $_.pschildname
$key = Get-Itemproperty $regpath\$keypath
if ($key.DisplayName -match "VMware Tools") {
$VMwareToolsGUID = $keypath
}
MsiExec.exe /x $VMwareToolsGUID /qn /norestart
}
```
## What happens if I use a custom DNS?
Custom DNS settings can cause issues in the replication servers.
Therefore, if you are using a custom DNS, you will need to add a TCP port 53 to the security group outbound rules, for replication and conversion servers.
## Can I use AWS Application Migration Service to migrate servers from VMware Cloud on AWS (VMC) to Amazon EC2?
Yes, you can. For migrations of source servers from [VMC](https://aws.amazon.com/vmware/) to EC2 you have two options. You can install the agentless appliance in your VMC environment, and migrate your servers using [agentless replication](agentless-mgn.md), or install the [AWS replication agent](agent-installation.md) on each of your source servers, and use agent-based replication for your migration.
## When should I use AWS Elastic Disaster Recovery (AWS DRS) for migration?
In cases that DRS supports a feature that does not exist in MGN, DRS can be used for migration. You can install the DRS replication agent on your source servers. Following replication, you can launch recovery instances in your target environment, to complete the migration.
DRS can be used for migration, as the DRS and MGN services use shared technology for performing block level replication. Both MGN and DRS have a replication agent, for replicating servers into a staging area in AWS. MGN supports launching test and cutover instances from the staging area. DRS supports launching recovery instances from the staging area. The technology used by both of these services for launching instances in AWS is very similar. DRS also has the capability to failback to the source environment, after the source environment has recovered. This capability does not exist in MGN.
Note that you cannot install the DRS and MGN agents on the same server at the same time. If you already installed the MGN agent on a server, and want to use DRS for migration, you must uninstall the MGN agent before installing the DRS agent.
Note that there are costs associated with using the DRS service. For DRS pricing information see [AWS Elastic Disaster Recovery pricing](https://aws.amazon.com/disaster-recovery/pricing/).
# Agent related
This section contains answers to questions about the AWS Replication Agent.
**Topics**
+ [What does the AWS Replication Agent do?](#What-Agent-Do)
+ [What kind of data is transferred between the agent and the AWS Application Migration Service?](#What-Data-Transferred)
+ [Can a proxy server be used between the source server and the AWS Application Migration Service console?](#Can-Proxy-Used)
+ [What are the prerequisites needed to install the AWS Replication Agent?](#What-Pre-Requisites-Agent)
+ [What ports does the AWS Replication Agent utilize?](#What-Ports-Agent)
+ [What privileges does the AWS Replication Agent require?](#Agent-privileges)
+ [Is it possible to install the agent on servers running operating systems that are not listed as supported?](#Agent-installation-on-unsupported-operating-system)
+ [What kind of resources does the AWS Replication Agent utilize?](#What-Resources-Agent)
+ [Can AWS Application Migration Service migrate containers?](#Can-Containers)
+ [Does the AWS Replication Agent cache any data to disk?](#Does-Agent-Cache-Data)
+ [How is communication between the AWS Replication Agent and the AWS Application Migration Service secured?](#How-Communication-Secured)
+ [Is it possible to change the port the AWS Replication Agent utilizes from TCP Port 1500 to a different port?](#Can-Change-Port-TCP)
+ [How do I manually uninstall the AWS Application Migration Service agent from a server?](#How-Manually-Uninstall-Agent)
+ [When do I need to reinstall the agent?](#When-Reinstall-Agent)
+ [How much bandwidth does the AWS Replication Agent consume?](#How-Much-Bandwidth)
+ [How many disks can the AWS Replication Agent replicate?](#How-Many-Disks-Agent-Replicate)
+ [Is it possible to add a disk to replication without a complete resync of any disks that have already been replicated?](#What-mgn-Agent-Services)
+ [Is the AWS Replication Agent installed on launched test and cutover instances?](#agent-transfer-instance)
+ [How do temporary credentials work?](#temporary-credentials-operation)
+ [Which Windows and Linux OSs support no-rescan upon reboot?](#agent-no-rescan)
## What does the AWS Replication Agent do?
The AWS Replication Agent performs an initial block-level read of the content of any volume attached to the server and replicates it to the replication server. The agent then acts as an OS-level read filter to capture writes and synchronizes any block level modifications to the AWS Application Migration Service replication server, ensuring near-zero RPO.
## What kind of data is transferred between the agent and the AWS Application Migration Service?
The AWS Replication Agent sends the following types of information to the Service Manager of AWS Application Migration Service:
+ Monitoring metrics of the agent itself
+ Replication status (started, stalled, resumed)
+ Backlog information
+ OS and hardware information
When an Agent is installed on a source server, it collects the following information on the machine:
+ Host name and ID
+ List of CPUs including models and number of cores
+ Amount of RAM
+ Hardware and OS information
+ Number of disks and their size – in Windows, disk letters; in Linux, block device names
+ Machine's Private IP address
## Can a proxy server be used between the source server and the AWS Application Migration Service console?
Yes. The proxy is configured using an environment variable prior to the install.
https\$1proxy=https://PROXY:PORT/
For example: https\$1proxy=https://10.0.0.1:8088/
Make sure the proxy has a trailing forward slash.
Ensure that you have allowlisted the [MGN IPs and URLs](preparing-environments.md#TCP-443) for both SSL Interception and Authentication.
## What are the prerequisites needed to install the AWS Replication Agent?
The installation requirements for source server depend on the type of OS that the server runs – either Linux or Windows.
Prerequisites [can be found here](installation-requirements.md).
## What ports does the AWS Replication Agent utilize?
The Agent utilizes TCP Port 443 to communicate with the Service Manager of Application Migration Service and TCP Port 1500 for replication to AWS.
## What privileges does the AWS Replication Agent require?
The AWS Replication Agent installer requires root privileges or the use of the sudo command during installation. It creates an "aws-replication" group and user, and attempts to add the "aws-replication" user to the "sudoers" file to grant necessary permissions. Ensure that the user running the installation has sufficient privileges to modify the "sudoers" file. If the installation fails due to insufficient permissions, you may need to manually add the "aws-replication" user to the "sudoers" file before attempting the installation again.
## Is it possible to install the agent on servers running operating systems that are not listed as supported?
The agent is designed and tested to work on the officially supported operating systems listed in the documentation. Installing the agent on other unsupported operating systems may be possible but is not recommended. Any installation or replication issues encountered when using unsupported operating systems will need to be handled through your own troubleshooting or support channels, as the AWS engineering team will be limited in their ability to assist. We advise using the agent only on supported OS versions to ensure the best experience. Please refer to [Supported operating systems](Supported-Operating-Systems.md).
## What kind of resources does the AWS Replication Agent utilize?
The AWS Replication Agent is lightweight and nondisruptive. The agent utilizes approximately 5% CPU and 250 MB of RAM.
## Can AWS Application Migration Service migrate containers?
AWS Application Migration Service (AWS MGN) only supports the replication of full servers. Nevertheless, AWS MGN replicates on a server level and therefore any containers within the selected servers will be replicated.
## Does the AWS Replication Agent cache any data to disk?
AWS Application Migration Service does not write any cache or do any sort of journalling to disk. The Agent holds a buffer which is large enough to map all volume's blocks \$1250 MB in memory.
The agent then acts as a sort of write filter and will replicate changed blocks directly from memory to the Replication Server. In cases where the data is no longer in memory, the agent will read the block from the volume directly. This is the case where you may see backlog in the AWS Application Migration Service console. The cause of this is the volume of change is greater than the bandwidth available.
## How is communication between the AWS Replication Agent and the AWS Application Migration Service secured?
All communication is encrypted using SSL. In addition, each Agent is assigned a key during installation which is used to encrypt all traffic. All keys are unique and are not shared across multiple agents.
## Is it possible to change the port the AWS Replication Agent utilizes from TCP Port 1500 to a different port?
No. The AWS Application Migration Service Agent can only utilize TCP Port 1500 for replication.
## How do I manually uninstall the AWS Application Migration Service agent from a server?
Follow the steps in the [Uninstalling the Agent](uninstalling-agent.md) section.
## When do I need to reinstall the agent?
Typically, you need to reinstall the Agent after any major upgrade to the source server.
**Linux**
+ Any kernel upgrade
+ After adding new volumes
**Windows**
+ Any OS upgrade (for example, Windows Server 2012 to Windows Server 2016)
**Note**
If you [upgrade using a post-launch action](predefined-post-launch-actions.md#predefined-windows-upgrade), an agent upgrade is not required.
+ After adding new volumes
## How much bandwidth does the AWS Replication Agent consume?
The AWS Replication Agent opens up to five connections and will attempt to maximize available bandwidth.
Throttling can be activated via the AWS Application Migration Service console by either selecting a specific server and clicking the **Replication settings** tab or by changing the **Replication template** (in this case the change will only affect newly added servers).
## How many disks can the AWS Replication Agent replicate?
The agent can replicate up to 50 disks from a single server. Ensure that the replication server instance type supports at least the number of disks being replicated.
## Is it possible to add a disk to replication without a complete resync of any disks that have already been replicated?
When you are adding a disk to a source server, AWS Application Migration Service will not automatically identify this disk and add it to the **Disk settings** section in the console.
The only way to get this disk to replicate is to reinstall the agent. Before reinstalling, you can note the current **Total replicated storage**. When you reinstall the agent, you will notice the value of replicated storage changes.
You will also notice an additional progress bar appear, which indicates that we are rescanning the original volumes. This is not a resync, but a scan, to verify that all the blocks on the source still match the blocks on the replication side. This process is significantly quicker than a resync, as there is no actual block data transferred, unless there is a difference. This is needed, as a reinstall results in the driver which performs the IO tracking being unloaded and reset, so we have no way of being certain of the sync status. Whilst the rescan on the original volumes is happening, the agent is also ensuring that the initial sync of the new volume is being completed in parallel.
## Is the AWS Replication Agent installed on launched test and cutover instances?
During the launch process, either upon test or cutover instance launch, the AWS Replication agent is removed from the test or cutover instance, and will not run on it.
## How do temporary credentials work?
The temporary credential mechanism was developed specifically to provide an easy and secure way to install AWS MGN Agents. The main flow of the temporary credentials' creation process relies on generating an x509 certificate per agent and then using this x509 certificate to receive temporary IAM credentials. This process utilizes a similar mechanism to the one used by [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html).
## Which Windows and Linux OSs support no-rescan upon reboot?
A shutdown (from the OS menu or CLI) of any supported Linux or Windows source server no longer causes a rescan in AWS MGN once the source server is restarted.
A rescan means that the agent on the source server rereads all blocks on all replicated disks and transmits blocks that are different from the previously replicated data. A rescan is similar to the initial sync but is faster because only blocks that are different need to be transmitted.
Rescans can still happen following a hard reboot, crashes, or when you add or remove disks to or from the source server.
Supported OSs include:
**Windows Server**
+ 2012r1
+ 2012r2
+ 2016
+ 2019
+ 2022
**Linux**
+ CentOS 6–8
+ Oracle 6–8
+ RHEL 6–9.7, 10, 10.1
+ Rocky 8–9.7, 10, 10.1
+ SLES 12 and 15
+ Debian 9–11
+ Ubuntu 16, 18, 20, and 22
+ Amazon Linux 2
+ AlmaLinux 9.6, 9.7, 10, 10.1
**Note**
For Linux, no-rescan on reboot is supported only on environments that use initramfs.
# Agentless replication related
This section contains answers to questions about agentless replication.
**Topics**
+ [In which situations would you recommend using agentless replication (snapshot shipping)?](#faq-agentless-situations)
+ [In which situations would you recommend using agent-based replication?](#faq-agentless-situations-agent)
+ [How does agentless replication work?](#faq-agentless-work)
+ [Does agentless replication require installing any component in the customer's source data center?](#faq-agentless-component)
+ [Is the agentless feature available in all Regions that AWS MGN service supports?](#faq-agentless-regions)
+ [Does agentless replication support the same source operating systems that are supported by agent-based replication?](#faq-agentless-os)
+ [Is the agentless feature supported in CloudEndure migration?](#faq-agentless-cloudendure)
+ [Which virtualization environments are supported by the agentless feature?](#faq-agentless-virtualization)
+ [On which operating systems can the MGN vCenter Client be installed?](#faq-agentless-os-client)
+ [Do I need to generate special credentials to install the MGN vCenter Client?](#faq-agentless-credentials)
+ [What are the agentless replication prerequisites?](#faq-agentless-credentials-prereques)
+ [How do I install the MGN vCenter Client?](#faq-agentless-how-install)
+ [Can a proxy server be used between the source server and the AWS Application Migration Service console?](#faq-agentless-proxy)
## In which situations would you recommend using agentless replication (snapshot shipping)?
Agentless replication best serves customers whose company's security policies do not allow installing an agent on each of their source servers, or for operating systems that are only supported by agentless replication. This solution is only available for data centers using vCenter version 6.7, 7.0 and 8.0.
## In which situations would you recommend using agent-based replication?
Agent-based replication is our default recommendation for all use cases, except when your company's security policies prevent you from using this method or if the OS is not supported. Using agent-based replication provides Continuous Data Replication, and ensures a cutover window of minutes . When using agentless replication, the data is transferred using snapshot shipping. Upon cutover, you may need to wait to have a fully updated snapshot, and your cutover window may be longer.
## How does agentless replication work?
You can learn more about how agentless replication works and see a high-level diagram of the agentless replication framework in the [agentless replication documentation](agentless-mgn.md).
## Does agentless replication require installing any component in the customer's source data center?
Yes. In order to use agentless replication, customers must install the MGN vCenter Client in their source data center. The client discovers the source servers and replicates their data to AWS.
## Is the agentless feature available in all Regions that AWS MGN service supports?
Yes. Both agent-based and agentless replication is supported in AWS Application Migration Service (AWS MGN) in all Regions.
## Does agentless replication support the same source operating systems that are supported by agent-based replication?
Agentless replication supports all of the [supported Windows operating systems](Supported-Operating-Systems.md#Supported-Operating-Systems-Windows) and [supported Linux operating systems](Supported-Operating-Systems.md#Supported-Operating-Systems-Linux) of agent-based replication.
## Is the agentless feature supported in CloudEndure migration?
No. This feature is only available on AWS Application Migration Service.
## Which virtualization environments are supported by the agentless feature?
The agentless replication feature is available for vCenter versions 6.7, 7.0 and 8.0. Other virtualization environments are not supported.
## On which operating systems can the MGN vCenter Client be installed?
The MGN vCenter Client can be installed on the following 64 bit Linux versions:
+ Ubuntu 18.x\$1 (64 bit) - 22.04
+ Amazon Linux 2
+ RHEL 8.x
## Do I need to generate special credentials to install the MGN vCenter Client?
Yes. In order to use the AWS MGN vCenter Client, you must first generate the correct IAM credentials. Learn more in the [agentless replication documentation](vcenter-credentials-mgn.md).
## What are the agentless replication prerequisites?
The only prerequisite for agentless replication is to ensure that you have initialized AWS Application Migration Service.
## How do I install the MGN vCenter Client?
You can learn more about installing the MGN vCenter Client as well as installation requirements in the [agentless replication documentation](installing-vcenter-appliance-mgn.md).
## Can a proxy server be used between the source server and the AWS Application Migration Service console?
Yes. You can configure transparent proxy either by using an environment variable prior to the installation (Linux and Windows), or by using the --proxy-address flag in the Linux installer:
+ Using the installer: ./aws-vcenter-client-installer-init.py --proxy-address http://PROXY:PORT/
+ Using environment variable: export https\$1proxy=http://PROXY:PORT/; ./aws-vcenter-client-installer-init.py
Make sure the proxy has a trailing forward slash (/).
# Replication related
This section contains answers to questions about data replication.
**Topics**
+ [What is the lifecycle of the snapshots and volumes automatically created during migration?](#What-Lag-data-Backlog-Mean)
+ [What do Lag and Backlog mean during replication?](#What-Lag-Backlog-Mean)
+ [What is Continuous, Block level data replication?](#what-is-continuous-block-replication)
+ [What are the Replication initiation Steps?](#what-are-replication-initiation-steps)
+ [Is the replicated data encrypted?](#Is-Replication-Encrypted)
+ [How is the Replication Server provisioned and managed in the Staging Area?](#How-Replication-Server-Staging)
+ [What type of replication server is utilized in the AWS Application Migration Service staging area?](#What-Replication-Server-Type-Staging)
+ [Can we set specific IP addresses for the replication server or conversion server in the AWS Application Migration Service staging area?](#Use-of-specific-ip-for-replicators-converters)
+ [Does AWS Application Migration Service compress data during replication?](#Does-Data-Compress)
+ [Are events that are generated by the AWS Application Migration Service servers logged in Cloudtrail in AWS?](#Are-Events-Logged-Cloudtrail)
+ [How many snapshots does AWS Application Migration Service create?](#How-Many-Snapshots)
+ [Does AWS Application Migration Service delete snapshots?](#Does-Delete-Snapshots)
+ [How much capacity is allocated to the staging area?](#How-Much-Capacity-Staging)
+ [Why is 0.0.0.0:1500 added to inbound rules in the staging area?](#Why-Inbound-Rules-Staging-IP)
+ [Can AWS Application Migration Service replicate Oracle ASM?](#Can-Replicate-Oracle-ASM)
+ [How long does a rescan take?](#How-Long-Rescan)
+ [How can I control the bandwidth used for replication?](#Can-Control-Bandwidth-Used-For-Replication)
+ [Are migrations performed by Application Migration Service crash consistent?](#Is-Replication-Crash-Consistent)
+ [How can I perform an SSL connectivity and bandwidth test?](#perform-connectivity-bandwidth-test)
## What is the lifecycle of the snapshots and volumes automatically created during migration?
For each source block device, we create a corresponding EBS volume. On occasion if there is an issue with the agent on the source machine being able to send data to a volume, we may create a new volume to replace the old one. Our workflow does not necessarily delete the old volume straight away, and it may remain present for around 10 minutes after the replacement volume comes online. But this is going to be rare, if your network connection is stable.
With regards to the snapshots, we take regular snapshots, so that we can take advantage of the incremental nature of snapshots. If we were for example to take a snapshot once every 6 hours, the snapshot would contain 6 hours worth of snapshots, and could potentially take a long time to complete. By taking them more frequently, we shorten the time taken to create the actual snapshot. This in turn means that when you trigger a test or cutover instance, the time taken to get the process started is not delayed unnecessarily by waiting for EBS snapshots to complete. We would generally keep 5–6 snapshots of a volume, to be sure that there is at least one that is completed when we need it for launch. EBS snapshot creation time has no SLA, and sometimes can be delayed significantly. EBS snapshot creation is also not guaranteed. A snapshot creation can fail (Not the API call, but the actual creation process). Hence we keep the additional snapshots, just in case something more recent actually failed.
## What do Lag and Backlog mean during replication?
During replication you may see a server falls out of Continuous Data Protection (CDP) mode. This may occur for various reasons, typically related to the network throughput or interruption.
+ **Lag** – The amount of time since the server was last in CDP mode.
+ **Backlog** – The amount of data that was written to the disk and still needs to be replicated in order to reach CDP mode.
+ **ETA** – The estimated time remaining to return to CDP.
## What is Continuous, Block level data replication?
During continuous block-level replication, the replication agent continuously monitors disk input/output (IO) activity on the protected disks. It then replicates all WRITE operations, which involve modifying or adding data, to the Replication Server, ensuring that the data is duplicated and kept up-to-date on the replication server.
## What are the Replication initiation Steps?
The following replication steps are involved in the automatic creation of the replication server in the staging area and initiation of data transfer over TCP port 1500:
+ Create security groups - Creating EC2 security groups with inbound TCP port 1500 allowed. This security group will be attached to replication server.
+ Launch Replication Server - AWS EC2 instance is launched based on the replication configuration set.
+ Boot Replication Server - The EC2 instance completes boot process which will now function as a replication server.
+ Authenticate with service - Using the user data scripts and the EC2 instance configuration, the instance (replication server) will authenticate with AWS Application Migration Service using service/vpc endpoint.
+ Download replication software - The Replication Server downloads replication software from S3. This replication software will write the incoming replicated data to the Replication Server disks.
+ Create staging disks - The Replication Server creates replication disks to store the incoming replicated data. The number of replication disks that are created depends on the size of the replicated data.
+ Attach the staging disks – In the previous step, the replication disks were created independently, without being attached to a specific Replication Server. Now, they are attached to a Replication Server.
+ Pair the Replication Server with AWS Replication Agent – Until this stage, the AWS Application Migration Service managed the communication between the Agent on the Source infrastructure and the Replication Server on the Target infrastructure. Now, the AWS Application Migration Service knows that all the initiation steps have been completed successfully. Therefore, it provides the Agent and the Replication Server information about each other, so that they could start communicating with each other directly.
+ Connect AWS Replication Agent to the Replication Server – The Agent and the Replication Server begin communicating with each other directly.
+ Start data transfer - Replication begins from source server to Replication Server over TCP 1500.
## Is the replicated data encrypted?
AWS Application Migration Service encrypts all the data in transit.
## How is the Replication Server provisioned and managed in the Staging Area?
AWS Application Migration Service provisions the Replication Server(s) and automatically manages the addition and removal of the servers as necessary.The AWS Application Migration Service automatically replaces the replication server on a periodic basis. This ensures the replication server is using the latest public Amazon Machine Image (AMI) available for MGN. The latest AMI contains the most up-to-date patches, security updates, and bug fixes. Regularly updating the replication server AMIs allows MGN to maintain the replication servers with the newest components and protections. Customers do not need to take any action to receive new replication server AMIs. MGN will automatically replace the existing replication server as needed when new AMIs are released. This helps keep the replication process secure and up-to-date without any additional effort from users.
## What type of replication server is utilized in the AWS Application Migration Service staging area?
AWS Application Migration Service provisions a t3.Small server. The typical ratio of volumes to replication servers is 15:1.
## Can we set specific IP addresses for the replication server or conversion server in the AWS Application Migration Service staging area?
No, you cannot specify or assign static IP addresses for the replication server or conversion server in AWS MGN. These servers are managed and maintained by the MGN service itself. The IP addresses for these servers are dynamically assigned from the available pool of IP addresses in the Virtual Private Cloud (VPC) that you specify during the MGN setup process. It's important to note that while you cannot control the specific IP addresses assigned to these servers, you can control the VPC and subnet in which they are deployed. This allows you to configure network access controls and security policies according to your organizational requirements.
## Does AWS Application Migration Service compress data during replication?
Yes, AWS Application Migration Service utilizes LZ4 compression during transit resulting in 60–70% compression depending on the type of data.
## Are events that are generated by the AWS Application Migration Service servers logged in Cloudtrail in AWS?
Yes, AWS Application Migration Service generates standard AWS API calls that are visible in CloudTrail.
## How many snapshots does AWS Application Migration Service create?
5–7 for each disk. Frequency and exact number depend on various factors, such as change rate on the source server and network stability.
There is currently no mechanism for users to adjust the frequency and number of snapshots.
## Does AWS Application Migration Service delete snapshots?
AWS Application Migration Service automatically deletes snapshots that are no longer used (such as those left over after source servers have been removed from the AWS Application Migration Service console).
## How much capacity is allocated to the staging area?
A volume is created for each volume in the source infrastructure of the same size.
## Why is 0.0.0.0:1500 added to inbound rules in the staging area?
AWS Application Migration Service uses TCP Port 1500 for replication between the Source Agents and the replication server. The connection is open for all IPs and can be managed by ACLs or networks controls to limit inbound IPs.
## Can AWS Application Migration Service replicate Oracle ASM?
Replication of Oracle with ASM is supported. AWS Application Migration Service also fully supports the use of the Oracle ASM Filter Driver.
## How long does a rescan take?
The rescan time will vary depending on the size of the source disks. The time depends on the performance of the disks (linear read),staging area disk performance, and the rate of write operations on the source server (which are sent in parallel with the rescan). The rescan is functioning normally as long as it is moving forward and is not "stuck".
## How can I control the bandwidth used for replication?
We recommend you do not limit the bandwidth used for replication. If you have business reasons to require replication to use less bandwidth, you can temporarily use the throttling feature to limit the bandwidth. This will cause lag, that will automatically recover once you remove the throttling.
## Are migrations performed by Application Migration Service crash consistent?
Yes, MGN's services are crash-consistent. This means that the data retrieved by MGN when the server becomes available is the data on the server at the moment before it shut down.
## How can I perform an SSL connectivity and bandwidth test?
**Note**
This tool is designed for AWS only.
You can use our SSL bandwidth tool to check for replication bandwidth availability.
1. In your target region, launch a c5.large test server using the public AMI named CE-ssl-speedtest.
1. Select the same subnet as the subnet used in the replication settings of your source machine.
1. Make sure that the security group allows TCP Port 1500 inbound access.
1. On the source machine, browse to https://\$1test\$1server\$1ip\$1:1500/speedtest
1. Click **Start**.
**Note**
Browse to the web page using the test server **public** or **private** IP according to what you defined in your replication settings.
The following are the AMI details per region:
ami-00b38c08ab3506ea7 – US East (N. Virginia)
ami-0bd8423a4d80563fc – US East (Ohio)
ami-00b7159e9c985a8da – US West (N. California)
ami-033a4924b13126a7b – US West (Oregon)
ami-0bf60b09675c8d9b6 – Africa (Cape Town)
ami-0f01375b50763621b – Asia Pacific (Hong Kong)
ami-0b1aeb50834102c18 – Asia Pacific (Mumbai)
ami-0b1aeb50834102c18 – Asia Pacific (Hyderabad)
ami-044fa8034a31d7578 – Asia Pacific (Tokyo)
ami-08b042df0d4c458ea – Asia Pacific (Seoul)
ami-0971e46306691cd68 – Asia Pacific (Osaka)
ami-0afd42552b236f9dd – Asia Pacific (Singapore)
ami-04e7cc6b5d9e8ffa1 – Asia Pacific (Sydney)
ami-02f31943dfd88549d – Asia Pacific (Jakarta)
ami-033db317ada5abd55 – Asia Pacific (Melbourne)
ami-01c24408802db503d – Canada (Central)
ami-0b8643189a66159c9 – Europe (Stockholm)
ami-0dd5a09d2ae8f46b3 – Europe (Ireland)
ami-097fb47f3a1c2bf7e – Europe (London)
ami-0a3f9008725d0b4d1 – Europe (Paris)
ami-0c65965703bb0e541 – Europe (Milan)
ami-01b6fcc2337f6420d – Europe (Spain)
ami-07b7defb87a46bb48 – Europe (Frankfurt)
ami-01b3e93b3ac0e1340 – Europe (Zurich)
ami-016edc078b48f370b – Israel (Tel Aviv)
ami-0c90e298af7a2e563 – Middle East (Bahrain)
ami-0f7c14e62ef760768 – Middle East (UAE)
ami-0edd5ecfc56804583 – South America (São Paulo)
ami-00eb76deb85085b3e – AWS GovCloud (US-West)
ami-0ba277e7ced412965 – AWS GovCloud (US-East)
Ensure that the security groups are configured to permit connectivity on inbound port 1500.
# AWS related
This section contains answers to questions about AWS and AWS Application Migration Service.
**Topics**
+ [What does the AWS Application Migration Service Machine Conversion Server do?](#What-Conversion-Server-Do)
+ [What boot modes are supported by the AWS Application Migration Service?](#Supported-boot-mode)
+ [How can we encrypt an unencrypted AWS Application Migration Service base snapshot?](#encrypt-base-snapshot)
+ [How do I change the server AMI on AWS after Migration?](#How-Change-Server-AMI)
+ [Which AWS services are automatically installed when launching a test or cutover instance?](#Which-AWS-Services-Automatically-Installed-Target)
+ [How long does it take to copy a disk from the AWS Application Migration Service staging area to production?](#How-Long-Copy-Disk-Staging)
+ [What are the differences between conversion servers and replication servers?](#What-differences-Conversion-Servers-Replication-Servers)
+ [Can I prevent AWS Application Migration Service from cleaning up test instance resources in AWS?](#Can-Prevent-Clean-Up-Target-Resources)
+ [Why are my Windows server disks read-only after launching the test or cutover instance?](#Why-Windows-Server-Disks-Read-Only)
+ [What impacts the conversion and boot time of test and cutover instances?](#What-Impacts-Conversion-Boot-Time-Target)
+ [Why do I observe EBS volume performance issues while using test or cutover instances?](#EBS-performance-hit-after-instance-launch)
+ [How is the AWS Licensing Model Tenancy chosen for AWS Application Migration Service?](#How-Licensing-Model-Tenancy)
+ [How does AWS Application Migration Service interact with Interface VPC Endpoints?](#mgn-and-vpc)
+ [How do I use MGN with CloudWatch and EventBridge dashboards?](#mgn-and-monitoring)
## What does the AWS Application Migration Service Machine Conversion Server do?
The machine conversion server converts the disks to boot and run on AWS.
Specifically, the machine conversion server makes bootloader changes, injects hypervisor drivers and installs cloud tools.
## What boot modes are supported by the AWS Application Migration Service?
The agent supports systems using either BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface) boot modes. BIOS is the traditional boot mode that initializes hardware and bootstraps the operating system. UEFI is a more modern boot firmware that provides additional boot configurations and security features over BIOS. Both boot modes are fully supported by the agent, giving users flexibility to choose the mode that best fits their systems and requirements. Users can install the agent on servers using either UEFI or legacy BIOS firmware.
## How can we encrypt an unencrypted AWS Application Migration Service base snapshot?
The encryption status of AWS Application Migration Service base snapshots is determined by the default EBS (Elastic Block Store) encryption setting for the respective AWS region. Encryption Scenarios:
+ Default EBS Encryption Enabled:
If the default EBS encryption is enabled for the region, the base snapshots created by MGN will be encrypted.
+ Default EBS Encryption Disabled:
If the default EBS encryption is not enabled, the base snapshots will be unencrypted.
+ Encrypting Existing Unencrypted Base Snapshots -
To encrypt an existing unencrypted base snapshot, follow these steps:
1. Delete the unencrypted base snapshot from the snapshots console.
1. Enable default EBS encryption for the AWS region where the MGN source environment is located.
1. Initiate a new test or cutover migration in MGN. During this process, MGN will create a new encrypted base snapshot based on the default EBS encryption setting for the region.
**Note**
Enabling default EBS encryption at the region level will encrypt all newly created EBS volumes and snapshots in that region.
## How do I change the server AMI on AWS after Migration?
After the machine has been launched by AWS Application Migration Service switching the AMI can be done by launching a vanilla machine from the required AMI, stopping that machine, detaching all the disks (including the root) and then attaching the disks from the test or cutover instance created by AWS Application Migration Service.
## Which AWS services are automatically installed when launching a test or cutover instance?
AWS Application Migration Service automatically installs EC2Config. After installation, EC2Config automatically installs the SSM EC2 Configuration Service.
CloudWatch, AWS Powershell or CLI are not automatically installed. This can be done by the combining the AWS Application Migration Service APIs and the AWS APIs – you can use the AWS Application Migration Service APIs to determine the EC2 instance IDs of the machines and then use AWS API/CLI to turn on the detailed monitoring. An alternative approach would be to do it via AWS API only based on the tags you associate with the machine. A third approach would be to do so from the post-launch script.
AWS Application Migration Service installs EC2Launch (Windows 2016 only). You will need to configure EC2Launch based on [these specific requirements](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2launch.html#ec2launch-config). This configuration step needs to be performed post Migration using the wizard in C:\$1Program Data\$1Amazon\$1EC2-Windows\$1Launch\$1Settings\$1Ec2LaunchSettings.exe on the test or cutover instance.
## How long does it take to copy a disk from the AWS Application Migration Service staging area to production?
AWS Application Migration Service uses internal cloud provider snapshots. This process typically takes less than a minute and the size of the volume does not impact the time.
## What are the differences between conversion servers and replication servers?
Replication servers run on Linux and conversion servers (for Windows machines) run on Windows.
The conversion is done by AWS Application Migration Service (AWS MGN) automatically bringing up a vanilla Windows conversion server machines in the same subnet with the replication servers as part of the launch job.
Both conversion and replication servers have public IPs.
The conversion servers will use the same security groups as the Replication Server.
The conversion server must be able to access the AWS MGN's service manager.
The conversion server machines, just like the Replication servers are managed automatically by AWS Application Migration Service. Any attempt to disrupt their automated functionality will result in failed conversions.
## Can I prevent AWS Application Migration Service from cleaning up test instance resources in AWS?
AWS Application Migration Service will, by default, removes any resources created during the test process either when requested by the user or when a new Test instance is launched.
To prevent this in AWS, you can [activate Termination Protection](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#Using_ChangingDisableAPITermination) for the test or cutover instance, and the resources will not be removed upon a new instance launch.
## Why are my Windows server disks read-only after launching the test or cutover instance?
When launching test or cutover instances Windows Server may boot with all the disks as read-only.
This a common issue that occurs when detaching and attaching data disks. This issue can be resolved using steps in [this Microsoft TechNet article](https://blogs.technet.microsoft.com/askcore/2011/06/02/my-disk-is-read-only-help/).
## What impacts the conversion and boot time of test and cutover instances?
Prior to launching the test or cutover instance, AWS Application Migration Service goes through a machine conversion server process on the boot volume. The conversion process is fairly quick.
While the actual conversion process itself is quick, the time to boot the test or cutover instance varies depending on many factors unrelated to any AWS Application Migration Service processes. Some of these are controllable and should be taken into account when recovery or cutover times are of importance.
+ Operating system – The amount of time required to boot the operating system is dependent on the OS itself. While Linux servers typically boot quickly, Windows servers may take additional time, due to the nature of the Windows OS. If opportunity permits, test the boot time of the source server. If Linux OS takes a long time to boot ensure to check that dhclient (Dynamic Host Configuration Protocol Client) is installed and the system so it can pull an IP.
+ Scheduled Windows Updates – If the Windows server has pending patches, ensure those are installed prior to launching the test or cutover instance. If pending patches remain, the boot time in the cloud may be severely impacted as the patch process may commence upon the initial boot.
+ Boot volume type – Depending on services/applications, boot time may be impacted by disk performance. It is recommended that boot volumes be tested with a higher performance SSD and even by provisioning IOPs to ensure throughput. This may be more critical during the first initial boot of the server in the cloud, as all initial settings are applied. In many cases, the boot volume type may be scaled back after the initial boot and should be tested.
**Note**
The first boot of Windows machines on AWS may take up to 45 minutes due to Windows adjusting to the AWS virtual hardware.
## Why do I observe EBS volume performance issues while using test or cutover instances?
The EBS volumes attached to the test or cutover instances are created from snapshots of convertered volumes. For any volume type that were created from snapshots, the storage blocks are pulled down from Amazon S3 and written to the volume before accessed by you. This process may take significant time and varies based on the EBS volume type. For additional details and EBS initialization options, refer to [Initialize Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-initialize.html)
## How is the AWS Licensing Model Tenancy chosen for AWS Application Migration Service?
AWS Application Migration Service conforms to the [Microsoft Licensing on AWS](https://aws.amazon.com/windows/resources/licensing/) guidelines.
## How does AWS Application Migration Service interact with Interface VPC Endpoints?
If you use Amazon Virtual Private Cloud (Amazon VPC) to host your AWS resources, you can establish a private connection between your VPC and AWS Application Migration Service. You can use this connection to allow AWS Application Migration Service to communicate with your resources on your VPC without going through the public internet.
Amazon VPC is an AWS service that you can use to launch AWS resources in a virtual network that you define. With a VPC, you have control over your network settings, such the IP address range, subnets, route tables, and network gateways. With VPC endpoints, the routing between the VPC and AWS services is handled by the AWS network, and you can use IAM policies to control access to service resources.
To connect your VPC to AWS Application Migration Service, you define an *interface VPC endpoint* for AWS Application Migration Service. An interface endpoint is an elastic network interface with a private IP address that serves as an entry point for traffic destined to a supported AWS service. The endpoint provides reliable, scalable connectivity to AWS Application Migration Service without requiring an internet gateway, network address translation (NAT) instance, or VPN connection. For more information, see [What is Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/) in the *Amazon VPC User Guide*.
Interface VPC endpoints are powered by AWS PrivateLink, an AWS technology that allows private communication between AWS services using an elastic network interface with private IP addresses. For more information, see [AWS PrivateLink](https://aws.amazon.com/privatelink/).
For more information, see [Getting Started](https://docs.aws.amazon.com/vpc/latest/userguide/GetStarted.html) in the *Amazon VPC User Guide*.
## How do I use MGN with CloudWatch and EventBridge dashboards?
You can monitor AWS Application Migration Service using CloudWatch, which collects raw data and processes it into readable, near real-time metrics. AWS Application Migration Service sends events to Amazon EventBridge whenever a source server launch has completed, a source server reaches the READY\$1FOR\$1TEST lifecycle state for the first time, and when the data replication state becomes stalled or when the data replication state is no longer Stalled. You can use EventBridge and these events to write rules that take actions, such as notifying you, when a relevant event occurs.
You can see MGN in CloudWatch automatic dashboards:
![\[CloudWatch cross-service dashboard showing Application Migration Service and EC2 metrics.\]](http://docs.aws.amazon.com/mgn/latest/ug/images/cw1.png)
![\[AWS Application Migration Service dashboard showing various performance metrics over a 3-hour period.\]](http://docs.aws.amazon.com/mgn/latest/ug/images/cw2.png)
MGN events can be selected when defining a rule from the EventBridge console:
![\[Event pattern form showing AWS services dropdown with MGN options and event JSON input area.\]](http://docs.aws.amazon.com/mgn/latest/ug/images/EB-cw3.jpg)
[Learn more about monitoring MGN](monitoring-overview.md).
# Does AWS MGN work with...?
This section contains answers to questions about what AWS Application Migration Service works with.
## Does AWS MGN work with Microsoft Windows Failover Clustering?
Yes.
## Does AWS MGN work with Bitlocker encryption?
AWS Application Migration Service does not support OS-based disk encryption features such as BitLocker. These should be deactivated before using AWS MGN.
# Post-launch actions related
This section contains answers to questions about post-launch actions.
**Topics**
+ [What operating systems does the post-launch actions framework support?](#What-OS-Post-Launch-Actions)
+ [What version of AWS Systems Manager Agent will be installed on my instance?](#What-Version-SSM)
+ [Why is the AWS Systems Manager Agent not executing my post launch actions?](#SSM-Agent-Not-Discovered)
## What operating systems does the post-launch actions framework support?
Verify that your operating systems [are supported by AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/prereqs-operating-systems.html).
## What version of AWS Systems Manager Agent will be installed on my instance?
AWS Application Migration Service uses the latest [AWS Systems Manager Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) version available in your instance's region.
## Why is the AWS Systems Manager Agent not executing my post launch actions?
+ By default, [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/index.html) doesn't have permission to perform actions on your instances. Grant access by using an AWS Identity and Access Management (IAM) instance profile. You can create an instance profile for AWS Systems Manager by attaching one or more IAM policies that define the necessary permissions to a new role or to a role you already created. You can use the managed policy `AmazonSSMManagedInstanceCore` which allows an instance to use AWS Systems Manager service core functionality or create a custom policy. For more information, see [ Create an IAM instance profile for AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html).
+ The instances you connect to must also allow HTTPS (port 443) outbound traffic to the following endpoints:
```
ec2messages..amazonaws.com
ssm..amazonaws.com
ssmmessages..amazonaws.com
```
You can connect to the required endpoints by using interface endpoints. For more information, see [Creating VPC endpoints for AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html#sysman-setting-up-vpc-create).
Alternatively, you can use public IP addresses for communication between your instances and the internet.
+ Another reason might be that the managed instance has limited available CPU or memory resources. Although your instance might otherwise be functional, if the instance doesn't have enough available resources, you can't establish a session. For more information, see [Troubleshooting an unreachable instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-console.html).