

# Elastic Disaster Recovery replication network requirements
<a name="preparing-environments"></a>

Before activating AWS Elastic Disaster Recovery, ensure that your environments are prepared and set accordingly. These preparations include setting the correct network settings, defining network requirements, and opening the correct ports. This documentation guides you through preparing network settings in the AWS Elastic Disaster Recovery Service Manager and user console, opening TCP Port 443 and TCP Port 1500 connections, setting firewall rules, using a proxy, and solving common networking issues. 

**Topics**
+ [Elastic Disaster Recovery network diagrams](Network-diagrams.md)
+ [Elastic Disaster Recovery network setting preparations](Network-Settings-Preparations.md)
+ [Elastic Disaster Recovery network requirements](Network-Requirements.md)

# Elastic Disaster Recovery network diagrams
<a name="Network-diagrams"></a>

AWS Elastic Disaster Recovery supports the following source infrastructure types:
+ **On-premises to AWS** – Protect physical or virtual servers in your data center by replicating to an AWS Region.
+ **AWS to AWS (cross-Region)** – Protect Amazon EC2 instances by replicating from one AWS Region to another. Cross-Region replication is recommended for disaster recovery to help protect against Region-level events.
+ **AWS to AWS (cross-Availability Zone)** – Replicate Amazon EC2 instances to a different Availability Zone within the same AWS Region. For comprehensive disaster recovery protection, we recommend cross-Region replication.
+ **VMware to AWS** – Protect VMware vSphere environments, including both on-premises vSphere and VMware Cloud on AWS. See [Disaster recovery for VMware Cloud on AWS using AWS Elastic Disaster Recovery](https://aws.amazon.com/blogs/storage/disaster-recovery-for-vmware-cloud-on-aws-using-aws-elastic-disaster-recovery/).
+ **Other clouds to AWS** – Protect workloads running on other cloud providers such as Microsoft Azure or Google Cloud. See [Building a disaster recovery site on AWS for workloads on Microsoft Azure](https://aws.amazon.com/blogs/storage/building-a-disaster-recovery-site-on-aws-for-workloads-on-microsoft-azure/).
+ **AWS to on-premises (failback)** – After a disaster recovery event, fail back from AWS to your original source environment.

The following are the network diagrams for AWS Elastic Disaster Recovery :

## General Architecture - On-Premises to AWS
<a name="Network-diagrams-onprem-general"></a>

 This diagram shows the general architecture of DRS protecting source servers located in an on-premises environment. 

![\[AWS Elastic Disaster Recovery architecture showing data flow from on-premises to AWS Cloud for replication and recovery.\]](http://docs.aws.amazon.com/drs/latest/userguide/images/drs-general-arc.png)




## On-Prem to AWS
<a name="Network-diagrams-onprem-network"></a>

 This diagram shows the network architecture of DRS protecting source servers located in an on-premises environment. 

![\[Network architecture showing on-premises servers replicating to AWS Cloud via DRS, EC2, and S3 services.\]](http://docs.aws.amazon.com/drs/latest/userguide/images/drs-network-arc.png)






## AWS Cloud to AWS Cloud via VPC Peering
<a name="Network-diagrams-aws-vpc-peering"></a>

This diagram shows the network architecture of AWS DRS protecting source servers located in an AWS VPC. Data replication between the source VPC and the target staging area, along with communication with the AWS DRS service, flows through a VPC peering connection.

![\[alt text not found\]](http://docs.aws.amazon.com/drs/latest/userguide/images/drs-vpc-peering-communication.png)






## On-Prem to Outposts
<a name="Network-diagrams-onprem-outpost"></a>

 This diagram shows the network architecture of DRS protecting source servers located in an on-premises environment. The staging and recovery are both located on AWS Outposts. [Find out more about protecting source servers using Outposts.](https://docs.aws.amazon.com/drs/latest/userguide/outposts.html) 

![\[AWS Elastic Disaster Recovery architecture using AWS Outposts for staging and recovery in a separate data center.\]](http://docs.aws.amazon.com/drs/latest/userguide/images/drs-networkrequirements-outpost1.png)






## AWS to Outposts
<a name="Network-diagrams-aws-outpost"></a>

 This diagram shows the network architecture of DRS protecting source servers located in AWS. The staging and recovery are both located on AWS Outposts. [Find out more about protecting source servers using Outposts.](https://docs.aws.amazon.com/drs/latest/userguide/outposts.html) 

![\[AWS Elastic Disaster Recovery architecture showing replication between main and recovery data centers using AWS Outposts.\]](http://docs.aws.amazon.com/drs/latest/userguide/images/drs-networkrequirements-outpost2.png)






## On-Premises to AWS Local Zone
<a name="Network-diagrams-On-premises-to-local-zones"></a>

 This diagram shows the network architecture of DRS protecting source servers located in an on-premises environment. The staging area is located in an AWS Region and the recovery is in an AWS Local Zone.

![\[Network architecture diagram showing DRS protecting on-premises servers with AWS Cloud staging and recovery areas.\]](http://docs.aws.amazon.com/drs/latest/userguide/images/On-premises-to-local-zones.png)




## AWS Local Zone to Region
<a name="Network-diagrams-local-zone-to-region"></a>

 This diagram shows the network architecture of DRS protecting source servers located in an AWS Local Zone. The staging and recovery environment are both located in an AWS Region.

![\[AWS DRS architecture with source servers in Local Zone and staging/recovery in Region.\]](http://docs.aws.amazon.com/drs/latest/userguide/images/local-zone-to-region.png)




## AWS Local Zone to AWS Local Zone
<a name="Network-diagrams-local-zone-to-local-zone"></a>

 This diagram shows the network architecture of DRS protecting source servers located in an AWS Local Zone. The staging environment is located in an AWS Region and the recovery environment is in another AWS Local Zone.

![\[Network architecture diagram of DRS protecting source servers in AWS Local Zones and Region.\]](http://docs.aws.amazon.com/drs/latest/userguide/images/local-zone-to-local-zone.png)




## AWS Failback to On-Prem
<a name="Network-diagrams-onprem-failback"></a>

 This diagram shows the network architecture of DRS performing Failback to an on-premises environment after performing a recovery into AWS. 

![\[AWS DRS failback replication architecture showing data flow between AWS Cloud and on-premises data center.\]](http://docs.aws.amazon.com/drs/latest/userguide/images/drs-failback-arc.png)




# Elastic Disaster Recovery network setting preparations
<a name="Network-Settings-Preparations"></a>

**Topics**
+ [Staging area subnet](#Staging-Area)
+ [Network requirements](#Setting-Up-Network)
+ [Operational subnets](#Operational-Subnet)

## Staging area subnet
<a name="Staging-Area"></a>

Before setting up AWS Elastic Disaster Recovery (AWS DRS), you should create a subnet which will be used by AWS DRS as a staging area for data replicated from your source servers to AWS. You must specify this subnet in the replication template. You can override this subnet for specific source servers in the replication settings. While you can use an existing subnet in your AWS account, the best practice is to create a new dedicated subnet for this purpose. Learn more about [replication settings](https://docs.aws.amazon.com/drs/latest/userguide/replication-settings.html). 

**Note**  
 When planning to recover into an AWS Local Zone, we recommend setting the staging area subnet within the AWS Region, and not the AWS Local Zone. This ensures optimal launch conditions for the replication servers and conversion servers involved in the recovery process. However, if your recovery requirements necessitate the use of the AWS Local Zone for the staging area subnet, we recommend performing recovery drills to validate that you can replicate and recover your production workloads without any issues. 

## Network requirements
<a name="Setting-Up-Network"></a>

The replication servers launched by AWS Elastic Disaster Recovery in your staging area subnet need to be able to send data over TCP port 443 to the AWS Elastic Disaster Recovery API endpoint at https://drs.\$1region\$1.amazonaws.com/. Replace “\$1region\$1” with the AWS Region code you are replicating to, for example “us-east-1” . 

The source servers on which the AWS Replication Agent is installed need to be able to send data over TCP port 1500 to the Replication Servers in the staging area subnet. They also need to be able to send data to AWS DRS's API endpoint at https://drs.\$1region\$1.amazonaws.com/. Replace “\$1region\$1” with the AWS Region code you are replicating to, for example “us-east-1” . 

## Operational subnets
<a name="Operational-Subnet"></a>

Drill and recovery instances are launched in a subnet you specify in the Amazon EC2 launch template associated with each source server. The Amazon EC2 launch template is created automatically when you add a source server to AWS Elastic Disaster Recovery. Learn more about launching [drill](quick-start-guide-gs.md#launching-test-gs) and [recovery](quick-start-guide-gs.md#launch-recovery-gs) instances. Learn more about [Amazon EC2 launch templates](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html).

# Elastic Disaster Recovery network requirements
<a name="Network-Requirements"></a>

To prepare your network for running Elastic Disaster Recovery, set these connectivity settings: 

**Note**  
All communication is encrypted with TLS.

 **Communication over TCP Port 443:** 

**Topics**
+ [Communication over TCP port 443](#TCP-443)
+ [Communication between the source servers and Elastic Disaster Recovery over TCP port 443](#Source-Manager-TCP-443)
+ [Communication between the staging area subnet and AWS Elastic Disaster Recovery over TCP port 443](#Communication-TCP-443-Staging)
+ [Communication between the source servers and the Staging Area Subnet over TCP port 1500](#Communication-TCP-1500)

 **Communication over TCP Port 1500:** 
+ Between the Source Machines and the staging area Subnet

## Communication over TCP port 443
<a name="TCP-443"></a>

Add these IP addresses and URLs to your firewall:

The Elastic Disaster Recovery AWS Region-specific Console address:
+ (drs.<region>.amazonaws.com *example: drs.eu-west-1.amazonaws.com*) 

Amazon S3 service URLs (required for downloading AWS Elastic Disaster Recovery software)
+ The AWS Replication Agent installer should have access to the S3 bucket URL of the AWS Region you are using with Elastic Disaster Recovery. 
+ The staging area subnet should have access to S3.
+ Allow these S3 buckets:

  ```
  https://aws-drs-clients-<REGION>.s3.<REGION>.amazonaws.com/
  https://aws-drs-clients-hashes-<REGION>.s3.<REGION>.amazonaws.com/
  https://aws-drs-internal-<REGION>.s3.<REGION>.amazonaws.com/
  https://aws-drs-internal-hashes-<REGION>.s3.<REGION>.amazonaws.com/
  https://aws-elastic-disaster-recovery-<REGION>.s3.<REGION>.amazonaws.com/
  https://aws-elastic-disaster-recovery-hashes-<REGION>.s3.<REGION>.amazonaws.com/
  https://al2023-repos-<REGION>-de612dc2.s3.<REGION>.amazonaws.com/
  ```

**Note**  
Agent installation and replication server components require an Amazon S3 bucket for service functionality.
Ensure the relevant VPC endpoint policy includes access to all the required Amazon S3 buckets.

When using an S3 VPC Endpoint, you must provide sufficient permissions for service functionality. See example policy for replicating to us-east-1:

------
#### [ JSON ]

****  

```
{
	"Version":"2012-10-17",		 	 	 
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
				"AWS": "*"
			},
			"Action": "s3:GetObject",
			"Resource": [
				"arn:aws:s3:::aws-drs-clients-us-east-1/*",
				"arn:aws:s3:::aws-drs-clients-hashes-us-east-1/*",
				"arn:aws:s3:::aws-drs-internal-us-east-1/*",
				"arn:aws:s3:::aws-drs-internal-hashes-us-east-1/*",
				"arn:aws:s3:::aws-elastic-disaster-recovery-us-east-1/*",
				"arn:aws:s3:::aws-elastic-disaster-recovery-hashes-us-east-1/*"
			]
		}
	]
}
```

------

 **AWS specific** 

The staging area subnet requires outbound access to the [Amazon EC2 endpoint of its AWS Region.](https://docs.aws.amazon.com/general/latest/gr/rande.html) 

TCP port 443 is used for two communication routes:

1. Between the source servers and Elastic Disaster Recovery.

2. Between the staging area subnet and AWS Elastic Disaster Recovery.

## Communication between the source servers and Elastic Disaster Recovery over TCP port 443
<a name="Source-Manager-TCP-443"></a>

Each source server that is added to AWS Elastic Disaster Recovery (AWS DRS) must continuously communicate with AWS DRS (DRS.<region>.amazonaws.com) over TCP port 443. 

These are the main operations performed through TCP port 443:
+ Downloading the AWS Replication Agent on the source servers.
+ Upgrading installed Agents.
+ Connecting the source servers to the AWS DRS Console and displaying their replication status. 
+ Monitoring the source servers for internal troubleshooting and the use of resource consumption metrics (such as CPU, RAM). 
+ Reporting source server-related events (for example, a removal or resizing of a disk). 
+ Transmitting source server-related information to the AWS DRS Console (including hardware information, running services, installed applications and packages, and more). 
+ Preparing the source servers for drill or recovery.

**Important**  
Make sure that your corporate firewall allows connections over TCP port 443.

### Solving communication problems over TCP port 443 between the source servers and AWS Elastic Disaster Recovery
<a name="Solving-Problems-TCP-443"></a>

If there is no connection between your source servers and AWS Elastic Disaster Recovery, make sure that your corporate firewall facilitates connectivity from the source servers to AWS Elastic Disaster Recovery over TCP Port 443. If the connectivity is blocked, activate it. 

#### Enabling Windows Firewall for TCP port 443 connectivity
<a name="Enabling-Windows-Firewall-TCP-443"></a>

**Important**  
The information provided in this section is for general security and firewall guidance only. The information is provided on "AS IS" basis, with no guarantee of completeness, accuracy or timeliness, and without warranty or representations of any kind, expressed or implied. In no event will AWS and/or its subsidiaries and/or their employees or service providers be liable to you or anyone else for any decision made or action taken in reliance on the information provided here or for any direct, indirect, consequential, special or similar damages (including any kind of loss), even if advised of the possibility of such damages. AWS is not responsible for the update, validation or support of security and firewall information. 

**Note**  
Enabling Windows Firewall for TCP port 443 connectivity allows your servers to achieve outbound connectivity. You may still need to adjust other external components, such as firewall blocking or incorrect routes, in order to achieve full connectivity. 

**Note**  
These instructions are intended for the default OS firewall. Consult the documentation of any third-party local firewall you use to learn how to enable TCP port 443 connectivity. 

1. On the source server, open the **Windows Firewall** console. 

1. On the console, select the **Outbound Rules** option from the tree.   
![\[Outbound Rules table showing network configurations, with BranchCache entries highlighted.\]](http://docs.aws.amazon.com/drs/latest/userguide/images/network-requirements-1-re.png)

1. On the **Outbound Rules** table, select the rule that relates to the connectivity to Remote Port - 443. Check if the **Enabled** status is **Yes**.   
![\[Outbound Rules table showing network rules with Enabled status highlighted.\]](http://docs.aws.amazon.com/drs/latest/userguide/images/network-requirements-2-re.png)

1. If the Enabled status of the rule is **No**, right-click it and select **Enable Rule** from the pop-up menu.   
![\[Outbound Rules table with BranchCache Hosted Cache Client rule highlighted and Enable Rule option.\]](http://docs.aws.amazon.com/drs/latest/userguide/images/network-requirements-3-re.png)

#### Enabling Linux Firewall for TCP port 443 connectivity
<a name="Linux-Firewall-TCP-443"></a>

1. Enter this command to add the required Firewall rule:

    *sudo iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT * 

1. To verify the creation of the Firewall rule, enter these commands:

   sudo iptables -L

    *Chain INPUT (policy ACCEPT)* 

    *target prot opt source destination* 

    *Chain FORWARD (policy ACCEPT)* 

    *target prot opt source destination* 

    *Chain OUTPUT (policy ACCEPT)* 

    *target prot opt source destination* 

    *ACCEPT tcp -- anywhere anywhere tcp dpt:443* 

## Communication between the staging area subnet and AWS Elastic Disaster Recovery over TCP port 443
<a name="Communication-TCP-443-Staging"></a>

The replication servers in the staging area subnet must continuously communicate with Elastic Disaster Recovery over TCP port 443. The main operations that are performed through this route are: 
+ Downloading the replication software by the replication servers.
+ Connecting the replication servers to AWS Elastic Disaster Recovery, and displaying their replication status. 
+ Monitoring the replication servers for internal troubleshooting use and resource consumption metrics (such as CPU, RAM). 
+ Reporting replication-related events.

  

**Note**  
The staging area subnet requires S3 access.

### Configuring communication over TCP port 443 between the staging area subnet and AWS Elastic Disaster Recovery
<a name="Configuring-Communication-TCP-443-Staging"></a>

You can establish communication between the staging area subnet and AWS Elastic Disaster Recovery over TCP port 443 directly.

There are two ways to establish direct connectivity to the Internet for the VPC of the staging area, as described in the [VPC FAQ](https://aws.amazon.com/vpc/faqs/). 

1. [Public IP address \$1 Internet gateway](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html) 

2. [Private IP address \$1 NAT instance](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html) 

## Communication between the source servers and the Staging Area Subnet over TCP port 1500
<a name="Communication-TCP-1500"></a>

Each source server with an installed AWS Replication Agent continuously communicates with the AWS Elastic Disaster Recovery replication servers in the staging area subnet over TCP port 1500. TCP port 1500 is needed for the transfer of replicated data from the source servers to the staging area subnet. 

The replicated data is encrypted and compressed when transferred over TCP port 1500. Prior to being moved into the Staging Area Subnet, the data is encrypted on the source infrastructure. The data is decrypted after it arrives at the staging area subnet and before it is written to the volumes. 

TCP port 1500 is primarily used for the replication server data replication stream.

Elastic Disaster Recovery uses TLS 1.2 end to end from the agent installed on the source server to the replication server. Each replication server gets assigned a specific TLS server certificate, which is distributed to the corresponding agent and validated against on the agent side. 

### Establishing communication over TCP port 1500
<a name="Establishing-Communication-TCP-1500"></a>

**Important**  
To allow traffic over TCP port 1500, make sure that your corporate firewall enables this connectivity. 

### Required bandwidth between the source servers and the staging area subnet
<a name="Required-bandwidth"></a>

 Replicated data is transferred from the source servers to the staging area over the network. For replication to succeed, your average network bandwidth must be higher than the write rate on the source servers. If you attempt to conduct a replication of a write intensive source server under low bandwidth conditions, it will likely lag. 