AWS Elastic Disaster Recovery Service (DRS) provides scalable, cost-effective application recovery to AWS. AWS DRS is used to protect workloads, whether they are running on-premises, in AWS, or in another hosting or cloud provider. AWS DRS provides robust, non-disruptive continuous replication that can provide RPOs of seconds and RTOs.
Disaster recovery (DR) solutions for workloads that are joined to a domain must take into account several requirements. The workloads expect DNS and security related services (user and machine-based authentication) to be available at launch. Failure to access these services could lead to extended service outages.
In this post, we look into a recovery approach that will allow users to protect workloads and make sure that they have a target for DNS and authentication requests. We will walk through extending AD into an AWS environment over private network connections and ensure AD services are available to AWS DRS replicated instances.
Architecture overview
The following diagram shows the basic architecture of AWS DRS. Replication agents are installed on the source hosts. The source host volumes are block-level replicated to lightweight replication server(s) running inside of the customer’s VPC. For a list of supported operating systems for AWS DRS, see the Supported operating systems guide in the AWS DRS documentation.
Figure 1: AWS DRS Architecture
In this scenario, we perform a failover/recovery into an AWS Region with either a fully-writeable or read-only (RODC) domain controller. An EC2 instance is deployed that will be running self-managed AD. This instance will handle AD authentication and DNS for machines that are launched from the AWS DRS service into the recovery VPC.
Prerequisites
For this walkthrough, you should have the following prerequisites:
AWS Elastic Disaster source server tagging
3. Select your AD server from the list of available source servers. a. Select Actions. b. Then select View server details
4. Navigate to the Tags section. a. Select Manage Tags b. Choose Add new tag
c. Enter in a custom key:value (For our scenario, we choose wave1:True). d. Select Save.
5. Repeat these steps for the application servers. a. For these servers (and further waves) change the tag to wave2:True and so forth.
6. Return to the Source servers tab.
Initiate recovery of servers Now we can filter our servers based on their tags that we just implemented. 1. Use the filter section under the Source servers page heading a. For the filter, enter your tag that you set for your AD server. b. For this post, we use wave1: True.
2. Select that server, and choose Initiate recovery job, then Initiate recovery.
3. Choose the Use most recent data option.
4. Choose Initiate recovery.
Once you have launched your AD server, you can wait until you have validated that the instance has launched via the AWS DRS console or the Amazon Elastic Compute Cloud (Amazon EC2)console. Once that instance has been launched, you can repeat the previous instructions for your application workload (in this example, these will be tagged with wave2:True. These steps can also be automated using other AWS services, as shown in this post.
Preparing AWS and AD In this example, the corporate data center is the source environment that AWS DRS is protecting. We have chosen a disaster recovery region as the target recovery site. Network connectivity from the on-premises data center is provided through AWS Direct Connect or AWS Site-to-Site VPN.
To avoid affecting your production environment during recovery drills, see the post: Avoid affecting your production environment during migration with AWS Application Migration Service. Although this post was written for the AWS Application Migration Service, the same principles also apply to AWS DRS.
Figure 2: Warm site recovery
Procedure 1. Create Amazon Virtual Private Clouds (Amazon VPCs) – this will be known as the recovery VPC. Create at least one staging subnet and one or more subnets to launch recovery instances.
2. Establish network connectivity between the corporate data center and AWS.
3. Configure route tables and network ACLs that will allow for replication network traffic. Create a security group that will allow AD replication traffic from on-premises. This will be applied to the EC2 instance that is running AD. Deploying a domain controller to extend on-premise AD into the VPC created in step 1.
4. Prepare AD: o From PowerShell or the AD Sites and Services MMC, create a new AD site for the recovery VPC created in step 1. New-ADReplicationSite -Name “<site name>”
o Create a new subnet that matches the VPC CIDR range of the recovery VPC. New-ADReplicationSubnet -Name “<Network CIDR Range>” -Site “<site name>” o Move the recovery domain controller into the new AD site. Move- ADDirectoryServer -Identity “<DC name>” -Site “<site name>”
5. Set the DHCP options for the recovery VPC using either the Console or the AWS Command Line Interface (AWS CLI). aws ec2 create-dhcp-options \ –dhcp-configuration \ “Key=domain-name-servers,Values=<DC IP>” \ “Key=domain-name,Values=<domain name>” \ “Key=netbios-node-type,Values=2”
6. Associate the DHCP options to the recovery VPC using either the Console or the AWS CLI. aws ec2 associate-dhcp-options \ –dhcp-options-id <dhcp id> \ –vpc-id <vpc id>
7. Initiate recovery of your application servers to the recovery subnet as defined by your launch settings.
Cleaning up Delete all resources used – these resources could include EC2 instances, EBS volumes, and EBS snapshots. See the Amazon EC2 user guide to terminate an instance, delete an EBS volume, or delete an EBS snapshot.
Conclusion In this post, we walked through disaster recovery of domain-joined workloads. We explored a warm site recovery using DRS and provided the procedures required for implementation.
Ensuring authentication for domain-joined tasks forms a pivotal aspect of every disaster recovery plan. Within this article, you can verify that tasks initiated amidst a disaster occurrence will possess the necessary AD services accessible upon launch. By having the essential AD services set up during such an event, you can securely initiate tasks and additionally minimize downtime throughout the disaster situation.
Further reading More info can be found here: AWS Elastic Disaster Recovery (AWS DRS) AWS Application Migration Service.
"*" indicates required fields
By providing your information to Altron you are providing consent for the processing of your personal information. Refer to the Altron Privacy Policy for details on how Altron collects and uses your personal information.
By ticking the box, you provide consent to receive electronic marketing communication on Altron Solutions and Services and the solutions of our key strategic partners. You may personalize your subscriptions based on your interests.
You can manage your communication preferences or opt-out via the Altron website.
