Streamlining Post-Recovery Processes with Amazon Elastic Disaster Recovery Automation

Overview

In an era where digital infrastructure forms the backbone of most organizations, enhanced disaster recovery (DR) and business continuity planning (BCP) cannot be overstated. These crucial processes ensure businesses can quickly bounce back from unforeseen disasters, minimizing downtime and maintaining the continuity of services. Traditionally, these operations have been laden with manual, complex, and error-prone tasks, especially during the critical post-recovery phase. This introduction leads you into the world of automated disaster recovery, highlighting how Amazon Elastic Disaster Recovery (EDR) is transforming this landscape. Through innovative automation and validation of post-recovery procedures, Amazon EDR is simplifying DR planning and introducing predictability and reliability into the recovery process. In this blog, we will explore how this advanced technology shapes the future of resilient operations, ensuring that businesses stay agile, secure, and continuously operational in the face of adversity.

Prerequisites

AWS Elastic Disaster Recovery Agent: Your source machine must install the AWS Elastic Disaster Recovery Agent.
Service Initialization in Target AWS Region: The AWS Elastic Disaster Recovery service needs to be initialized in your target AWS Region.
AWS Identity and Access Management (IAM) Roles: To use post-launch actions in AWS Elastic Disaster Recovery, specific AWS IAM roles are essential for tasks like running Systems Manager documents. Ensure these roles are in place, especially if Elastic Disaster Recovery was initialized before September 13, 2023. If not, add them through the Elastic Disaster Recovery console.

Go to the AWS Elastic Disaster Recovery console to set up the necessary AWS IAM roles. Choose ‘Default post-launch actions’ from the ‘Settings’ menu, then click ‘Install post-launch AWS IAM roles’.

pre1

2. Click on ‘Confirm’ in the pop-up window that appears.

pre2

Pioneers in Cloud Consulting & Migration Services

Reduced infrastructural costs
Accelerated application deployment

Get Started

Step-by-Step Guide

After ensuring all prerequisites are in place, the next step is to enable the post-launch action functionality. You can activate this feature by default for all newly incorporated source servers, a process we’ll outline in the upcoming steps. You also have the option to enable this feature for a specific source server.

Step 1: Enable Default Post-Launch Actions

Go to the ‘Default post-launch actions’ menu and choose ‘Edit’ from the ‘Post-launch action settings’ section.

step1

Check the box labeled ‘Post-launch actions active’ and click ‘Save’.

step1b

After activating the default post-launch actions, these settings will automatically apply to any new source servers you add.

It’s important to note that the ‘Enable SSM’ action is automatically enabled and cannot be turned off. This action facilitates the installation of the Systems Manager Agent, which is crucial for executing post-launch actions on your recovery instances once they are operational.

step1c

Step 2: Incorporate a New Source Server

Proceed to the ‘Source servers’ menu. In this section, you’ll notice the addition of a new source server. For detailed instructions on adding a source server, refer to the AWS service guide.

step2

Choose the recently added source server and navigate to the ‘post-launch settings’ tab. Observe that the configurations made in the ‘Default post-launch actions’ menu are now applied to this source server.

step2b

From this point, you can activate a predefined AWS action or develop a customized one. We will create a custom action to check file permissions, network connectivity, and application functionalities.

Step 3: Develop an AWS Systems Manager Command Document

Go to the AWS Systems Manager console within the recovery region, and then choose ‘Documents’ from the ‘Shared resources’ menu.

In this demonstration, we will create a Systems Manager command document. Click ‘Create document’, then choose ‘Command or Session’. For the document’s name, enter ‘DR-Failover-Validation Checks’.

---
schemaVersion: "2.2"
description: "This document performs sanity tests for our failover into AWS."
mainSteps:
- action: aws:runShellScript
  name: ValidateLinuxConnectivity
  precondition:
    StringEquals:
      - platformType
      - Linux
  inputs:
    timeoutSeconds: '3600'
    runCommand:
      - |
        #!/usr/bin/env bash
        echo 'Verifying connectivity to amazonaws.com'
        ping -c 1 amazonaws.com
        if [ "$?" -eq '0' ];
        then
            echo 'Connectivity to amazonaws passed'
        else
            echo 'Connectivity to amazonaws failed'
            exit 1
        fi


        echo 'Verifying ec2-user home folder has 'drwx------' permissions'
        ping -c 1 amazonaws.com
        if [[ `ls -ld /home/ec2-user/` == *'drwx------'* ]];
        then
            echo 'ec2-user home folder contains the expected permissions'
        else
            echo 'ec2-user home folder contains the unexpected permissions:'
            echo `ls -ld /home/ec2-user/`
            exit 1
        fi


        echo 'Verifying aws cli is installed'
        which aws
        if [ "$?" -eq '0' ];
        then
            echo 'aws cli is installed'
        else
            echo 'aws cli is missing'
            exit 1
        fi

---

schemaVersion: "2.2"

description: "This document performs sanity tests for our failover into AWS."

mainSteps:

- action: aws:runShellScript

name: ValidateLinuxConnectivity

precondition:

StringEquals:

- platformType

- Linux

inputs:

timeoutSeconds: '3600'

runCommand:

- |

#!/usr/bin/env bash

echo 'Verifying connectivity to amazonaws.com'

ping -c 1 amazonaws.com

if [ "$?" -eq '0' ];

then

echo 'Connectivity to amazonaws passed'

else

echo 'Connectivity to amazonaws failed'

exit 1

echo 'Verifying ec2-user home folder has 'drwx------' permissions'

ping -c 1 amazonaws.com

if [[ `ls -ld /home/ec2-user/` == *'drwx------'* ]];

then

echo 'ec2-user home folder contains the expected permissions'

else

echo 'ec2-user home folder contains the unexpected permissions:'

echo `ls -ld /home/ec2-user/`

exit 1

echo 'Verifying aws cli is installed'

which aws

if [ "$?" -eq '0' ];

then

echo 'aws cli is installed'

else

echo 'aws cli is missing'

exit 1

Step 4: Establish a Post-Launch Action Aligned with the Command Document and Activate it for the Source Server Added in Step 2

Following this, we’ll establish a post-launch action that aligns with the Systems Manager command document we’ve just developed.

Proceed to the Elastic Disaster Recovery console and select the previously mentioned source server from the ‘Source servers’ menu. Then, choose ‘Add Action’ from the ‘Actions’ menu.

step4

Assign a name to the Action. For instance, in this example, we’ll name it ‘DR-Failover-Validation-Checks’.

Keep the ‘Activate this action’ checkbox marked, and choose the Systems Manager document you created earlier. Then click on ‘Add action’.

step4b

By setting the ‘Filter by’ option to ‘Activation status: Active’, we can see that there are now two active Actions for this source server.

step4c

Step 5: Execute a Recovery Drill and Track the Progress of Active Post-Launch Actions

Let’s conduct a recovery drill to observe the post-launch actions in action.

Click on ‘Initiate recovery job’ and select ‘Initiate recovery drill’.

step5

Choose the option ‘Use most recent data point in time’.

step5b

To check the status of the recovery job, go to the ‘Recovery job history’ menu.

step5c

Choose the most recent recovery job.

step5d

Examine the job card and await the recovery job’s status to update to ‘Completed’.

step5e

After completing the recovery job, let’s verify the status of the post-launch actions on the newly launched recovery instance. Go to the ‘Recovery instances’ menu and select the recovery instance that was recently created.

step5f

Within the information panel of the recovery instance, you can view the ‘Post-launch actions’ status in the ‘Overview’ section (point 1). Additionally, the execution results of each action (point 2) and links to related CloudWatch logs for diagnostic purposes (point 3) are also available.

step5g

Conclusion

Amazon Elastic Disaster Recovery’s post-launch action framework, detailing how to enable and use these existing and custom actions. It covers the recovery process, including tracking and assessing post-launch actions.

The framework automates and validates post-recovery procedures, adding predictability to disaster recovery planning. It allows the automation of actions for recovery instances, aiding in validation, testing, and configuration. For comments or questions, please use the comments section.

Drop a query if you have any questions regarding Amazon Elastic Disaster Recovery and we will get back to you quickly.

Making IT Networks Enterprise-ready – Cloud Management Services

Accelerated cloud migration
End-to-end view of the cloud environment

Get Started

About CloudThat

CloudThat is a leading provider of Cloud Training and Consulting services with a global presence in India, the USA, Asia, Europe, and Africa. Specializing in AWS, Microsoft Azure, GCP, VMware, Databricks, and more, the company serves mid-market and enterprise clients, offering comprehensive expertise in Cloud Migration, Data Platforms, DevOps, IoT, AI/ML, and more.

CloudThat is recognized as a top-tier partner with AWS and Microsoft, including the prestigious ‘Think Big’ partner award from AWS and the Microsoft Superstars FY 2023 award in Asia & India. Having trained 650k+ professionals in 500+ cloud certifications and completed 300+ consulting projects globally, CloudThat is an official AWS Advanced Consulting Partner, AWS Training Partner, AWS Migration Partner, AWS Data and Analytics Partner, AWS DevOps Competency Partner, Amazon QuickSight Service Delivery Partner, Amazon EKS Service Delivery Partner, Microsoft Gold Partner, AWS Microsoft Workload Partners, Amazon EC2 Service Delivery Partner, and many more.

To get started, go through our Consultancy page and Managed Services Package, CloudThat’s offerings.

FAQs

1. What is the post-launch action framework in Amazon Elastic Disaster Recovery?

ANS: – It is a feature in Amazon Elastic Disaster Recovery that automates specific tasks after a recovery instance launches, like application checks and configurations, making disaster recovery more efficient.

2. How do you create custom actions in Amazon Elastic Disaster Recovery?

ANS: – You can create custom actions using the AWS Systems Manager to create a command document with specific tasks. Then, you can link it as a post-launch action in the Amazon Elastic Disaster Recovery console. This automates your tasks after a recovery instance launches.

WRITTEN BY Naman Jain

Naman works as a Research Intern at CloudThat. With a deep passion for Cloud Technology, Naman is committed to staying at the forefront of advancements in the field. Throughout his time at CloudThat, Naman has demonstrated a keen understanding of cloud computing and security, leveraging his knowledge to help clients optimize their cloud infrastructure and protect their data. His expertise in AWS Cloud and security has made him an invaluable team member, and he is constantly learning and refining his skills to stay up to date with the latest trends and technologies.