AWS Storage Blog

Cross-Region AWS Elastic Disaster Recovery agent installation in a secured network

Installing a service agent on a server is a straight-forward process in a normal setup. Most agents require an internet connection to connect to the service. However, there are some environments that are tightly secured. Servers in these environments don’t have internet access at all. Installing a service agent in these environments can be a challenge. Customers are looking for ways to install a service agent without compromising their secured environment with internet access.

In this post, we show you how to install the AWS Elastic Disaster Recovery (DRS) replication agent on servers in tightly secured environments without internet access. This includes replicating and protecting an Amazon Elastic Compute Cloud (EC2) instance running in a secured Virtual Private Cloud (VPC). We also use VPC interface endpoints and Amazon Simple Storage Service (S3) Gateway VPC endpoint. Keep in mind that the Elastic Disaster Recovery agent requires Amazon S3 service endpoint to download the agent installer and the replication agent itself. In addition, the replication agent needs connectivity to the Elastic Disaster Recovery console during the installation and during the time the source server is protected.

Background

We’ll start by reviewing VPC endpoints, using Amazon S3 as an example. AWS provides the interface as well as a Gateway endpoint for S3.

A Gateway endpoint is a Gateway that you specify in your route table to access Amazon S3 from your VPC over the AWS network. Endpoint connections can’t be extended out of a VPC. Resources on the other side of a VPN connection, VPC peering connection, transit Gateway, or AWS Direct Connect connection in your VPC, can’t use a Gateway endpoint to communicate with Amazon S3.

On the other hand, interface endpoints extend the functionality of Gateway endpoints. This is done by using private IP addresses to route requests to Amazon S3 from within your VPC, on-premises, or from a VPC in another AWS Region using VPC peering or AWS Transit Gateway. Since the Gateway endpoints can’t be extended out of VPC, we keep the VPC interface endpoints in this post. However, we must create a Gateway endpoint for S3 as well.

Prerequisites

For this walkthrough, you should have the following:

  • Elastic Disaster Recovery service set up and configured in the DR Region.
  • EC2 instances of your choice (Windows or Linux) running to test and install the Elastic Disaster Recovery agent.
  • An understanding of VPC and S3 endpoints, VPC Peering, Subnets, and security groups.
  • Two separate VPCs, with one in each Region with no connection to the internet. Both Regions will be connected via VPC Peering connection.
  • Ability to create VPC endpoints, S3 endpoints, Gateway endpoints, and Security Groups.

Solution overview

For the purposes of this post, the Amazon Elastic Compute Cloud (EC2) instance we replicate and protect is running in a secured VPC in eu-west-1 Region to eu-west-2 Region. The VPC in both Regions is tightly secured and doesn’t have internet access. The two VPCs in this demonstration are connected with a VPC peering connection.

Two VPCs connected with a VPC peering connection

In the example of on-premises infrastructure, the same architecture applies. However, only the connectivity option between the two infrastructures is different, as shown in the following diagram:

Connectivity option is different on-prem

Walkthrough

During the installation, you need connectivity to the Elastic Disaster Recovery regional endpoint. That is all the connectivity needed when installing the agent and during the lifetime of the agent running on the source server. To ensure that the source servers reach the Amazon S3 and Elastic Disaster Recovery regional endpoints, make sure that the security groups attached to the VPC Interface endpoints allow the HTTPS traffic from source VPC CIDR as well as the staging area subnet. As a helpful tip, use a common security group for all the VPC endpoints in staging VPC.

To learn more about how to access the S3 buckets using VPC S3 interface endpoints, refer to this documentation.

Connecting source servers to endpoints

To download the replication installer and the replication agent, you need access to Amazon S3.

  1. Create a VPC S3 Interface endpoint in eu-west-2.
  2. You must modify the URL of the installer and then specify the --s3-endpoint switch during the installation of the agent.
  3. Create a DRS VPC Interface endpoint in the eu-west-2.

Connecting replication servers to endpoints

Now that the source servers are connected to the service endpoints, connect the replication servers to these service endpoints. The replication servers in the staging subnet use the Elastic Disaster Recovery interface endpoint to connect to the regional Elastic Disaster Recovery endpoint. They use the Amazon EC2 interface endpoint to connect to the Amazon EC2 regional endpoint. But what about Amazon S3 regional endpoint connectivity?

To make sure that the replication servers reach S3 and download the replication server software, you must use the VPC Gateway endpoint to access Amazon S3.

In most use cases, applications must use the endpoint-specific DNS names. For example, to download an S3 object index.html from a bucket named aws-drs-london using a wget/curl request, you must modify the object URL https://aws-drs-london/index.html with this: https://aws-drs-london.bucket.<VPC_interface_endpoint_DNS_name>/index.html.

However, the replication servers don’t download the replication software by using the DNS name of an S3 endpoint during launch. You must create an S3 Gateway endpoint in the staging VPC so that the replication server downloads the replication software.

That is all the connectivity needed for the staging area subnet. However, make sure that the security groups attached to these VPC interface endpoints allow the HTTPS traffic from the staging subnet.

Validating the route table

There is a private source server running in the eu-west-1 Region with no internet access. The following is the route table associated with the subnet of this server. In this route table, the subnet can reach two different VPCs via the corresponding VPC Peering connections. The 172.16.0.0/16 CIDR is the VPC CIDR from which you can SSH into this server. The 10.0.0.0/16 CIDR is associated with the VPC in the eu-west-2 Region from which you want to protect this server.

Route table associated with subnet of this server

Similarly, the staging area subnet in the eu-west-2 Region does not have the internet connectivity, as seen in the following route table. This route table shows the peering connection with the source server’s subnet and a route added for the Amazon S3 VPC Gateway endpoint.

Staging area subnet in eu-west-2 Region does not have internet connectivity

Verifying the endpoints

The staging area subnet in the eu-west-2 Region needs connectivity to the regional Elastic Disaster Recovery endpoint and the Amazon EC2 endpoint. For this purpose, VPC interface endpoints are created as shown in the following table. The Amazon S3 interface endpoint is created for the purpose of agent installation only. For the replication server to reach the S3 regional endpoint, an S3 Gateway endpoint is created. This means four VPC endpoints are created in the eu-west-2 Region.

VPC Interface endpoints are created

Verifying the connectivity to VPC endpoints

With the necessary nuts and bolts in place, you can now try to establish a connection against each interface endpoint on port 443. This allows you to confirm that you can connect to the eu-west-2 regional application programming interface (API) endpoints from the eu-west-1 Region. You can resolve the endpoints from anywhere on the internet since the DNS names created from VPC endpoints are publicly resolvable. They resolve to the private IP addresses of the endpoint network interfaces for the enabled Availability Zones (AZ).

Endpoints resolve to the private IP addresses of the endpoint network Interfaces

The connection is established with the regional API endpoints via the interface endpoints. You can now install the Elastic Disaster Recovery replication agent. To install the replication agent on the source server, first download it using the eu-west-2 URL of the installer. However, in theory, you can use the installer of any Region. First, modify the URL of the installer by replacing the .s3.amazonaws.com with the Amazon S3 endpoint-specific DNS name (i.e.,vpce-03e861865ec79195a-st77imi7.s3.eu-west-2.vpce.amazonaws.com). Also, you must add the bucket to the URL as well 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.py.

Add the bucket to the URL so you can access it

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.

Install the replication agent

The Elastic Disaster Recovery replication agent is installed and, with this, the role of the Amazon S3 interface endpoint is complete. As previously discussed, the staging area uses the S3 Gateway endpoint to download the replication software from S3. Therefore, the Gateway endpoint will always be used by the replication subnet.

At this stage, the source server is added to the Elastic Disaster Recovery Console.

Source server added to DRS console

Conclusion

Installing a service agent can be a challenge in an environment without internet access, such as those that are tightly secured. Most agents require an internet connection in order to connect to the service. We showed you how to install the Elastic Disaster Recovery replication agent on servers that are in tightly secured environments without internet access, without compromising the security of your environment.

We did this using VPC interface and Gateway endpoints. We showed how AWS PrivateLink for AWS services can provision interface VPC endpoints (i.e., interface endpoints) in a VPC environment. These endpoints are directly accessible from applications that are on-premises over VPN and AWS Direct Connect, or in a different AWS Region over VPC peering. In reference to the Elastic Disaster Recovery service, we used the Elastic Disaster Recovery interface endpoint, EC2 interface endpoint and Amazon S3 interface, and Gateway endpoints to access the service privately over PrivateLink. These endpoints help to protect the workload and configure cross-Region disaster recovery with Elastic Disaster Recovery.

Thank you for reading this post. If you have any comments or questions, you can enter them in the comments field below.

Ken Sze

Ken Sze

Based in the Boston area, Ken is a Solutions Architect on the AWS CloudEndure team. Ken joined AWS in 2019 as part of the CloudEndure acquisition. He has been working with customers for over 10 years as an IT professional, helping them design backup and disaster recovery solutions. Outside of work, he enjoys riding his motorcycle and finding good places to eat.

Aamir Dar

Aamir Dar

Aamir is a Cloud Support Engineer with AWS Premium Support, based in Dublin. In his role, Aamir enjoys helping customers solve complex issues around EC2, Application Migration Service and Elastic Disaster Recovery Service. He enjoys spending time with his family and taking beach walks when he is not working.