AWS Storage Blog

Automatic network replication with AWS Elastic Disaster Recovery

When developing a disaster recovery strategy, it is important to manage replicating the network configuration from your primary to recovery site, including (but not limited to) things like your access control lists (ACLs) and internet gateways. In many cases, a configuration change in your primary site should be applied to your recovery site. Managing these changes manually can be an error-prone process. When working with network and security resources, misconfigurations can have an outsized negative impact. An improperly configured network can lead to a lack of connectivity, or in the case of a misconfigured firewall or access control list, a major security exposure.

AWS Elastic Disaster Recovery helps manage and orchestrate disaster recovery for Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Elastic Block Store (Amazon EBS) resources. Elastic Disaster Recovery can also automatically replicate and recover AWS networking and security resources for workloads that run in AWS. When combined, this will simplify the disaster recovery strategy for cross AWS Availability Zone (AZ), cross AWS Region, or another AWS account in a different AWS Region use cases.

In this post, we dive into the Elastic Disaster Recovery network replication feature that allows you to automatically replicate and recover your AWS network components and configurations to maintain the readiness and security of your AWS recovery site. These components include subnets, security groups, route tables, internet gateways, and ACLs. By leveraging the network replication feature you can reduces the risk of misconfigurations, enhance security, and simplify operations during recovery.

Network replication overview

The Elastic Disaster Recovery network replication feature allows you to keep track of network changes and perform quick updates. It helps prevent configuration mismatches during recovery, saves time and resources, and provides enhanced security. For example, when a security group is updated, this change is automatically replicated, thereby making sure compliance requirements can be met and preventing potential security risks.

Supported network components include:

  • Amazon Virtual Private Cloud (Amazon VPC)
  • Subnet
  • Security group
  • Route table
  • Internet Gateway (IGW)
  • Network access control list (ACL)

Once you activate replication for a source network, Elastic Disaster Recovery tracks the configuration of the network resources within. Prior to performing a drill or recovery event for your applications, you can recover the source network to the recovery site. When performing a source network recovery action, an AWS CloudFormation stack containing the source network components is automatically generated and deployed to the recovery site. In addition, source servers that represent EC2 instances belonging to the source network have their launch settings automatically configured to use the newly deployed network in the recovery site, preventing the need to configure each server manually.

Prerequisites

To use the network replication feature through the AWS Management Console, the following prerequisites must be in place:

  • Elastic Disaster Recovery source server present in the target AWS Region.
  • Amazon Simple Storage Service (Amazon S3) bucket created in the target AWS Region with versioning enabled, used to store the generated CloudFormation stack.
  • S3 bucket is selected for use within the Elastic Disaster Recovery Source networks menu (see the following figure)

Selecting the S3 bucket that will be used during network recovery

Figure 1: Selecting the S3 bucket that will be used during network recovery

Step by step guide: AWS Management Console

In this section, we go step-by-step through the process of configuring network replication in the AWS Management Console by starting replication for our source networks, initiating a recovery job, and validating the creation of our source network in the target AWS Region.

  1. Once the prerequisites have been met, navigate to the Elastic Disaster Recovery service within the console, and open the Source networks page, source networks that belong to existing source servers will be automatically discovered.

DRS source networks that have been automatically discovered

Figure 2: DRS Source networks that have been automatically discovered

2. Start the replication, select Actions then Start replication.

Selecting Start replication from Source Network Actions

Figure 3: Selecting Start replication from Actions drop down menu on Source networks page

3. Select Start replication from the pop-up prompt.

Starting replication of the source network

Figure 4: Starting replication of the source network

4. Monitor the Replication status, and wait for the initial sync to complete. Allow 15 minutes for any changes to the source network to be fully replicated before initiating a recovery job.

Source network replication has started

Figure 5: Source network replication has started

Wait for the Replication status to report a status of Replicating – protected.

Source network replication now showing protected

Figure 6: Source network now showing protected

5. To recover the source network, select the checkbox next to the source network, then select Initiate recovery job.

Initiate recovery job of the source network

Figure 7: Initiate recovery job of the source network

6. As this is the first time, we are performing a recovery, we select Create a new stack. For subsequent recovery jobs, you can update the existing stack, or if you wish to create another recovered source network to perform some isolated testing, you can select Create a new stack.

Confirm new stack creation during the recovery job

Figure 8: Confirm new stack creation during the recovery job

We can monitor the progress of the recovery job by switching to the Recovery job history page and selecting the latest recovery job card.

Reviewing the recovery progress in the Recovery job log

Figure 9: Reviewing the recovery progress in the Recovery job log

If we switch to the CloudFormation console, we can see that a nested stack that was created under the name AWS-DRS-sn-<SourceNetworkID> and the network components were deployed to the target AWS Region.

CloudFormation stack is created in target AWS region

Figure 10: CloudFormation stack is created in target AWS region

Step by Step: AWS Command Line Interface

In this section, we go step-by-step through the process of updating our Launch Configuration Template, creating a Source Network configuration, starting network replication, and initiating a recovery job for AWS Command Line Interface (AWS CLI).

Note that when configuring this feature programmatically through the AWS CLI or an AWS SDK, you do not need to have an existing Elastic Disaster Recovery Source Server present.

To configure the network replication feature through the AWS CLI, we are required to have a S3 bucket created in the target AWS Region with versioning enabled, in order to store the generated CloudFormation stack.

  1. To get started, we must update the Elastic Disaster Recovery launch configuration template to define our S3 bucket. Replacing <launchConfigurationTemplateID> with the currently active template (you can retrieve this value using aws drs describe-launch-configuration-templates) and <S3BucketARN> with the ARN of the S3 bucket that you wish to use to hold the network configuration templates.
aws drs update-launch-configuration-template --launch-configuration-template-id <launchConfigurationTemplateID> --export-bucket-arn <S3BucketARN>

Command output showing the exportBucketArn

Figure 11: Command output showing the exportBucketArn

2. Next, we must create the Source Network configuration. Replace <AccountID> with the AWS Account ID that contains the source VPC, <Region> with the region where the source VPC resides and <SourceVPCID> with the VPC ID of the source VPC.

aws drs create-source-network --origin-account-id <AccountID> --origin-region <Region> --vpc-id <SourceVPCID>

Note the output value for sourceNetworkID, as we need this in subsequent steps.

Command output showing the sourceNetworkID

Figure 12: Command output showing the sourceNetworkID

3. To start replication for the newly created Source Network, run the following command replacing <sourceNetworkID> with the output value from step 2.

aws drs start-source-network-replication --source-network-id <sourceNetworkID>

4. To initiate a recovery job, run the following command replacing <sourceNetworkID> with the output value from step 2.

aws drs start-source-network-recovery --source-networks sourceNetworkID=<sourceNetworkID>

5. For subsequent recoveries, make use of the —deploy-as-new or —no-deploy-as-new options to either create a new stack or update the existing one.

The following is an example to initiate a recovery job and update the existing stack:

aws drs start-source-network-recovery --no-deploy-as-new false --source-networks sourceNetworkID=< sourceNetworkID >,cfnStackName=< cfnStackName >

Cleaning up

To avoid incurring unwanted AWS costs after performing these steps, delete the AWS resources created. These include the source network replication configuration, deployed source network CloudFormation stack, export S3 bucket, and any EC2 instances created for the purpose of this exercise.

Conclusion

In this post, we covered the Elastic Disaster Recovery network replication feature that allows you to automate the replication of your source network (VPC) configuration to your disaster recovery site. We also provided step by step instructions on how to setup the replication and perform a recovery of your source VPC to your disaster recovery site, using both the AWS Management Console and AWS CLI.

Automating the replication of your source VPC to your disaster recovery site increases the chances of a smooth and rapid recovery and assists in maintaining continuous data replication. It also enhances security, saves time and resources, and reduces the risk of data loss.

Thanks for reading this post. If you have any comments or questions, then don’t hesitate to leave them in the comments section.