Establish private connectivity for AWS Elastic Disaster Recovery using AWS Direct Connect

As the size of an organization’s disaster recovery (DR) implementation grows, we often see the role of the network grow in importance. The relationship between DR and the network should not come as a surprise, as we expect network performance and the ability to replicate data between the source environment and the DR site to directly impact metrics such as the Recovery Point Objective (RPO) and Recovery Time Objective (RTO). This is why we see many users establish a dedicated connection between their on-premises data center and AWS. A private network connection can reduce costs, increase bandwidth, and provide a more consistent network experience than internet-based connections.

AWS Elastic Disaster Recovery provides a scalable and cost-effective solution for DR in the cloud. Elastic Disaster Recovery maintains an up-to-date copy of your source servers on AWS without requiring you to pay for the cost of a full recovery site. When using Elastic Disaster Recovery to protect applications that are hosted in an on-premises environment, it is important to make sure that the network is properly configured and deployed to support the replication traffic that is transmitted between the source server and the staging environment. Many users choose to use AWS Direct Connect to establish private connectivity to meet these requirements.

In this blog, we demonstrate how you can establish a private connection for Elastic Disaster Recovery using Direct Connect. We start by creating a Direct Connect gateway, the required virtual interfaces, and associating them to one another. We then set up Elastic Disaster Recovery for private connectivity and install the agent with the required configuration parameters. Once complete, all Elastic Disaster Recovery control and data plane traffic will transit the Direct Connect and stay private, by avoiding the public Internet.

Solution overview

In this architecture, there are two Direct Connects configured in an active/passive configuration. The Elastic Disaster Recovery replication traffic from the on-premises data center transits over the Direct Connect and through the private virtual interface (VIF). This provides secure connectivity without requiring access to the internet.

When we provision the VIF on the Direct Connect, we have the choice to use a public or private VIF. A private VIF allows you to access your Virtual Private Cloud (VPC) and supported AWS services by using a private IP address. This provides a more secure configuration, as you can limit exposure to certain external threats by not exposing network traffic to the public internet.

Once the Direct Connect is configured with a private VIF, we must create the required interface VPC endpoints for the Elastic Disaster Recovery service. This includes access to Elastic Disaster Recovery, Amazon Elastic Compute Cloud (Amazon EC2), and Amazon S3. VPC endpoints provide access to a specific AWS service without needing to use other gateways (internet gateway (IGW), network address translation (NAT) gateway, virtual private network (VPN) connection, or VPC peering connection). The traffic remains within the AWS private network, and you can restrict access through a VPC endpoint to specific users, actions, and/or resources. Once the interface VPC endpoints are created, you would reference them during the Elastic Disaster Recovery agent installation process.

Figure 1: Connecting corporate data center to AWS Elastic Disaster Recovery with AWS Direct Connect

Prerequisites

For this walkthrough, you should have the following:

• An AWS account.
• An understanding of VPC, VPC endpoints, Subnets, and Security Groups.
• The ability to create VPC endpoints, as well as modify route tables and security groups.
• A live Direct Connect connection (dedicated or hosted), created in your AWS account.
• Permission to the AWS Management Console to create/modify/delete resources such as VPC and initializing services.
• Access to test server(s) to install Elastic Disaster Recovery agent.

Walkthrough

For Elastic Disaster Recovery to work seamlessly with Direct Connect, we need to complete the following steps:

1. Create a Direct Connect gateway.

2. Create the Private VIF for Direct Connect.

3. Associate the Direct Connect gateway with the virtual private gateway of the destination Region.

4. Customize the network setup for Elastic Disaster Recovery Service.

5. Install the Elastic Disaster Recovery Agent with the required configuration parameters.

1. Create a Direct Connect gateway

1. Open the Direct Connect console.

2. Choose Direct Connect gateway and then choose Create Direct Connect gateway.

3. Provide a Name and an Amazon-side Autonomous System Number (ASN) for the gateway.

4. Fill in the information and choose Create Direct Connect gateway.

Figure 2: Creating an Direct Connect gateway

2. Create the private VIF for Direct Connect

1. Select your newly created gateway, and under Virtual interface attachments choose Create virtual interface.

 Figure 3: Creating a Direct Connect VIF

2. Under Virtual interface type, choose Private.

3. Under Private virtual interface settings, do the following:

a. For Virtual interface name, enter a name for the VIF.

b. For Connection, choose the Direct Connect connection that you set up. In this example, I choose “Colt LON/LON/LE-187687 to LHR16”.

c. For Virtual interface owner, choose My AWS account.

d. For Gateway type, select the Direct Connect gateway.

e. For VLAN, enter the ID number for your virtual local area network.

f. For BGP ASN, enter the Border Gateway Protocol Autonomous System Number of your on-premises peer router for the new VIF.

Figure 4: Direct Connect private VIF configuration

3. Associate the Direct Connect gateway with the virtual private gateway of the destination Region

1. Open the Direct Connect console.

2. In the navigation pane, choose Direct Connect gateways and then choose your Direct Connect gateway.

3. Choose View details.

4. Choose Gateway associations, and then choose Associate gateway.

5. For Gateways, choose the virtual private gateways to associate, and then choose Associate gateway.

In this example, I chose the virtual private gateway “VGW-VPC100” in the eu-west-2 Region. Each association takes 2–3 minutes.

Figure 5: Associate Direct Connect gateway with virtual private gateway

For dedicated connections, you can also use a link aggregation group (LAG) to aggregate multiple connections at a single Direct Connect endpoint. You treat them as a single, managed connection. You can aggregate up to four 1- or 10-Gbps connections, and up to two 100-Gbps connections.

To achieve highly resilient network connections between AWS and your data center you can use multiple Direct Connect connections. A broad exploration of hybrid connectivity options is discussed in detail in the AWS Whitepaper “Hybrid Connectivity” and in the reference architecture “Active/Active and Active/Passive Configurations in AWS Direct Connect.”

4. Network configuration for AWS Elastic Disaster Recovery

To make sure of smooth operations with Elastic Disaster Recovery, specific connectivity pathways need to be set up. Here’s a breakdown of these requirements and how to achieve them:

Communication within AWS: Staging area to Regional endpoints

The staging area within AWS acts as a central hub for data replication and recovery. Making sure of robust and secure connectivity in this zone is essential.

To allow private communication for your source servers located in your on-premises environment, we use VPC endpoints. These types of endpoints provide private connectivity between your VPC and supported AWS services by effectively creating a network interface within your VPC. They allow resources within your VPC to connect privately to supported AWS services without exposing the traffic to the public internet. This setup not only enhances security but also makes sure of a more stable and consistent connection.

The staging area subnet should be configured to communicate with the Elastic Disaster Recovery Regional interface endpoint, S3 Regional gateway endpoint, and the EC2 Regional interface endpoint over TCP port 443.

We also create an S3 interface endpoint to allow the AWS Replication Agent installer to communicate with Amazon S3 over TCP port 443.

To create an interface endpoint for an AWS service:

1. Open the Amazon VPC console, and use the left-side navigation pane, to select Endpoints.

2. Select Create endpoint and under Service category, choose AWS services.

3. For Service name, find and select DRS from the list.

Figure 6: Elastic Disaster Recovery VPC interface endpoint

4. In the VPC section, choose the appropriate VPC from which you access the AWS service. Make sure that Enable DNS name is selected under Additional settings.

Figure 7: VPC endpoint configuration

5. Under Subnets, select the staging area subnet.

6. Adjust the security group to allow HTTPS traffic from the staging area. Adjust the policy settings based on your specific needs.

7. Review your configurations and select Create endpoint to finalize.

Repeat the previous steps, but select EC2 and S3 from Step 3.

EC2 endpoint

Creating an EC2 VPC interface endpoint:

Figure 8: EC2 VPC interface endpoint

S3 endpoint

Creating an S3 VPC interface endpoint:

Figure 9: S3 VPC interface endpoint

Create an S3 gateway endpoint that the replication servers can use to download the replication software from Amazon S3.

To create an S3 gateway endpoint:

1. Open the Amazon VPC console, and use the left-side navigation pane, to select Endpoints.

2. Select the Create endpoint and under Service category, choose AWS services.

3. For Service name, find and select S3 with Type: Gateway from the list.

Figure 10: S3 VPC gateway endpoint

4. For VPC, select the VPC in which to create the endpoint.

5. For Route tables, select the route tables to be used by the endpoint. We automatically add a route that points traffic destined for the service to the endpoint network interface.

Figure 11: S3 VPC gateway endpoint configuration

6. For Policy, select Full access to allow all operations by all principals on all resources over the VPC endpoint.

7. Choose Create endpoint.

5. Installing the Elastic Disaster Recovery replication agent with required configuration parameters

To properly register and manage the source servers in Elastic Disaster Recovery, we need to make sure that they can communicate with the Elastic Disaster Recovery regional endpoint of TCP Port 443. This communication is crucial for various operations, ranging from downloading and upgrading the Elastic Disaster Recovery Replication Agent to monitoring server metrics and preparing the servers for recovery drills or actual recovery processes.

Additionally, the Elastic Disaster Recovery Replication Agent installer needs access to the S3 bucket URL for the Region you are operating within for Elastic Disaster Recovery. This access is essential for downloading the Elastic Disaster Recovery software.

To avoid accessing the public application programming interface (API) endpoints of the required AWS services needed for Elastic Disaster Recovery to operate, we specify the private API endpoints as part of the agent installation process. These private API endpoints are the same interface VPC endpoints we created earlier in Step 3 under “Communication within AWS – Staging Area to Regional Endpoints”. We use the endpoint-specific domain name service (DNS) hostname of the VPC interface endpoints created in the staging area subnet to allow the AWS Replication Agent installer to communicate with Elastic Disaster Recovery and S3 regional endpoints.

The data is transferred securely between the source server and staging area subnet over TCP port 1500 through the Direct Connect private VIF. This port facilitates encrypted and compressed data transfer, making sure that data remains protected during its transit from the source infrastructure to the replication servers within the staging area subnet. To support this data transfer, the corporate firewall should allow traffic between the source server and staging area subnet over Port 1500.

The first step in using Elastic Disaster Recovery is to initialize the service using the AWS console. As part of the set up you must make sure to check the Use private IP for data replication option under the Configure additional replication setting in Data routing and throttling, as this allows replicated data to transit through the private connections we set up.

Figure 12: AWS DRS Replication Configuration – Use private IP for data replication

For the Elastic Disaster Recovery Replication Agent to install properly, the correct AWS Identity and Access Management (IAM) roles and permissions need to be set in place. From a security perspective, we recommend leveraging secure token service (STS) (EC2 instances) or Amazon Single-Sign-On (SSO) (on-premises servers). Refer to the post: Securely installing AWS Replication Agent using AWS Security Token Service.

1. After the permissions are set up and the Elastic Disaster Recovery service is initialized, connect through SSH or RDP to your source machine.

2. Download the installer using the regional URL of the installer.

3. Modify the URL of the installer by replacing the .amazonaws.com with the Amazon S3 endpoint-specific DNS name (such as vpce-03e861865ec79195a-st77imi7.s3.eu-west-2.vpce.amazonaws.com).

4. Next you must add the bucket to the URL so that you are able to access it. The URL of the installer becomes https://aws-elastic-disaster-recovery-eu-west-2.bucket.vpce-03e861865ec79195a-st77imi7.s3.eu-west-2.vpce.amazonaws.com/latest/linux/aws-replication-installer-init.

Figure 13: Download Elastic Disaster Recovery replication agent

5. Now that the installer file is downloaded, install the replication agent using the --endpoint to specify the Elastic Disaster Recovery VPC interface endpoint. Use --s3-endpoint to reflect the use of the Amazon S3 VPC interface endpoint.

Figure 14: Installing Elastic Disaster Recovery replication agent

After the agent is successfully installed, navigate to your Elastic Disaster Recovery console and you should start seeing progress of data being replicated in the Initial sync stage.

Figure 15: Initial Sync progress in Elastic Disaster Recovery console

Cleaning up

After you successfully finish the installation of the AWS Elastic Disaster Recovery replication agent, the replication process begins and it creates additional resources in the staging environment such as replication servers and Amazon Elastic Block Store (Amazon EBS) volumes/snapshots. To avoid incurring unwanted AWS costs after performing these steps, delete the AWS resources created. This should include the deletion of any source servers used for the evaluation, which will also delete the staging environment resources which includes EC2 instance and EBS snapshots.

Conclusion

In this blog post, we shared how you can utilize Direct Connect to establish private connectivity, providing a more robust, performant and secure network for Elastic Disaster Recovery. We started by creating and configuring a Direct Connect gateway, followed by the creation of a Private VIF for the Direct Connect, and once completed we associated the Direct Connect gateway with the virtual private gateway of the destination Region. We then customized the network configuration for Elastic Disaster Recovery and installed the Elastic Disaster Recovery Agent with the required configuration parameters. Once complete, we were able to successfully start replication form the source server using the Direct Connect and avoid the public Internet for any control plane or data plane communication.

A DR strategy must be supported by a network that allows you to seamlessly connect and securely replicate data between your source environment and recovery site. When these needs are met, you can have the confidence that your DR strategy can meet your business requirements defined by your RPO and RTO objectives. By using Direct Connect for Elastic Disaster Recovery, you can establish a private network connection, while reducing costs, increasing bandwidth, and providing a more consistent network experience.

To stay up to date on AWS Elastic Disaster Recovery, check out our blogs on the AWS Storage Blog. To learn more about AWS Direct Connect, visit the documentation. We are eager to hear about your journey and results; share your experiences, insights, and questions in the comments.