Designing for Multi-account Scenarios Using AWS DR Service

By Stuart Lupton, specialist solutions architect for disaster recovery, AWS,

and Joydipto Banerjee, solutions architect, AWS, currently working with financial services and insurance customers.

Disaster recovery (DR) plays an important role in the overall business continuity strategy of an organization. When implementing a DR solution, you must understand business drivers along with any governance, security, and operational requirements that influence the final solution. For example, organizations may have a requirement to maintain different accounts for security isolation, control cost allocation, or meet governance requirements. In other situations, there may be a need to have multiple recovery accounts for the purposes of isolated testing, such as DR drills or conducting post-cyber event forensics. These business, governance, security, and operational requirements can significantly impact the overall DR strategy and implementation.

Click to enlarge

AWS Elastic Disaster Recovery is a service that reduces downtime and data loss with fast, reliable recovery of on-premises and cloud-based applications to Amazon Web Service (AWS). It can decrease your RPO to seconds and RTO to minutes. You can quickly recover operations after unexpected events, such as software issues or data center hardware failures. Elastic Disaster Recovery supports the use of multiple accounts to separate the staging account, where data is replicated and maintained, from the target account, where an actual recovery is done. Multiple accounts are recommended when scaling the use of Elastic Disaster Recovery to protect more than 300 source servers. However, we can also use multiple accounts for security and isolation, simplifying management and improving operations by allowing any single source server to be recovered into into multiple target accounts for testing, development, and production.

In this post, we introduce the multi-account capabilities of Elastic Disaster Recovery and we demonstrate how users can design and implement DR solutions that meet their unique needs while ensuring business continuity and data protection.We review three use cases for using the multi-account capabilities of the Elastic Disaster Recovery service. The 1st demonstrates how users can separate staging resources from the source and target accounts in order to provide greater isolation and security to meet compliance and regulatory mandates. The 2nd shows how to promote operational best practices by providing separate recovery accounts to support experimentation, DR drills, and audits. The last scenario covers how users can have a centralized view of all their Elastic Disaster Recovery resources when using multiple accounts in order to simplify operations.

Overview of multiple accounts in AWS Elastic Disaster Recovery
Elastic Disaster Recovery organizes resources into two main categories: staging and recovery. The staging resources, which include replication servers and staging volumes, are typically placed into a unique staging subnet, but they can also be separated into their own unique AWS accounts, known as staging accounts. The recovery resources, which include the recovery instances and their volumes, can also be separated into unique accounts known as target accounts. When using the multi-account capabilities of Elastic Disaster Recovery, we introduce a new concept, referred to as an extended source server.

This new functionality allows you to extend any single replicating source server into multiple target accounts. Extending a source server into a different target account creates a logical version of the source server that is configured with its own unique launch configurations. This would allow you to recover to different AWS accounts and maintain separate launch settings for the purpose of running a DR drill, performing sandbox testing or conducting forensics. The concept of extending a source server can also be used to create a consolidated view of many source servers into a single AWS account, to create a centralized view for operational teams to view replication status across all Elastic Disaster Recovery source servers.

Benefits of using multi-account feature of Elastic Disaster Recovery include following:

• Isolation and security: By maintaining distinct staging accounts users can ensure a higher level of isolation and security of the staged data. This separation helps minimize the risk of accidental or malicious data deletion in the event the source environment is compromised.
• Compliance and governance: Many organizations have regulatory or industry-specific requirements that necessitate the validation of DR failover readiness. Using multiple target accounts allow users to more easily demonstrate their compliance with these regulations and make sure that their DR infrastructure aligns with their overall governance and security policies.
• Cost visibility and allocation: Having separate AWS accounts for different business units or departments allows users to easily track and allocate the DR costs associated with each business. This provides better cost transparency, which allows the organization to understand the expenses incurred by specific teams, projects, or services.

Common considerations
The following is a list of common considerations that should be taken into account for all three scenarios.

1. Centralized governance of multiple AWS accounts using AWS Organizations, which allows users to implement consolidated billing and enforce security through service control policies (SCPs). Furthermore, tools such as AWS Control Tower can help automate account creation and make multi-account operations more efficient.
2. When adopting a multi-account strategy, you must follow best practices for AWS Virtual Private Cloud (VPC), including secure network routing between accounts. AWS services such as AWS Transit Gateway and AWS VPC Peering can help establish private, secure, and scalable network connections.
3. Encryption keys used to encrypt the staged resources must be shared to all target accounts when extending source servers to different target accounts
4. You can’t extend source servers between AWS partitions. This means that Commercial AWS accounts can only be extended to other Commercial AWS accounts and AWS GovCloud (US) accounts can only be extended to other AWS GovCloud (US) accounts.

In the following sections we review some common multi-account scenarios and illustrative examples.

Scenario 1: Separate staging resources from source and target environment
This scenario covers how users using Elastic Disaster Recovery can separate staging resources from the source and target accounts. Using separate staging accounts for their source and recovery environments allows Elastic Disaster Recovery users to benefit from enhanced security, meet compliance mandates, and provide improved management of resources and their associated costs. Ultimately this improves the overall effectiveness and reliability of their DR strategy.

Architecture
As shown in the following Figure 1, we use multiple staging accounts to align with the organization hierarchy defined by business units (BU). This this allows for separation based on application type or environment such as Production/Development. This account separation allows for a more granular operational control of the DR resources at a BU level. Furthermore, it also allows users to have greater control of cost allocation as replication resources are maintained in a BU specific account.

To achieve this account separation, source servers are deployed into separate staging accounts and the extended source server function of multi-account is used to extend all source servers into a single recovery account. The architecture for this scenario is shown for an on-premises environment, but this could also be valid where the source environment is within AWS.

Figure 1: Staging resources separated from the source and recovery environment
Click to enlarge

Scenario 2: Extend source servers into multiple target accounts for isolated recovery purposes
This scenario helps promote operational best practices by providing separate recovery accounts in support of experimentation, running DR drills, or for conducting forensics. These isolated recovery environments can also provide greater flexibility by providing broader access to AWS services while using guardrails, which would not be possible in production recovery accounts. Having a separate recovery account for these activities can enable operational teams to move faster by reducing dependencies on application teams and minimize the risk of business impact during an actual DR event.

This scenario also helps if you choose to build custom workflows that need to be triggered during your DR process. You can create workflows in a target account that scans for malware after a successful recovery and before promoting to production.

Architecture
In this architecture, we depict an AWS account called AWS Source Account 1, which has source severs in Region A that are replicating to Region B in the same AWS account, as shown in the following Figure 2. In the event of a disaster, resources would be recovered into the Recovery Subnet in Region B using the defined the Amazon Elastic Compute Cloud (Amazon EC2) launch settings configured in this account.

The source servers in AWS Source Account 1 have also been extended using multi-account to AWS Account 2 (Isolated Recovery Drill Account) and AWS Account 3 (Isolated Cyber Forensic Account). This extension is logical only, which means that the replicated data remains in AWS Source Account 1, and an extended copy of the source server is created in each target account. This extended source server copy has unique EC2 launch settings that are configured as per the required use case, which allows recovery into each AWS Account.

Figure 2: Source servers extended into multiple target accounts
Click to enlarge

Scenario 3: Extend source servers to create a centralized view for operational teams
This scenario allows users to have a centralized view of their source servers across multiple AWS accounts for business or security reasons. Similar to the previous scenario, we have a source, staging, and recovery environment in a single AWS account. However, this setup is repeated across multiple accounts in a distributed manner. We then extend the source servers from each source account to a centralized management account, which allows you to manage the source servers from within a single account. This feature makes DR setup, implementation, and monitoring easier and more efficient, especially for large-scale deployments.

Architecture
In this scenario, there are multiple AWS Accounts that use Elastic Disaster Recovery to protect EC2 instances for cross-Region disaster recovery. Each source server is managed from the respective AWS account from the Elastic Disaster Recovery console, as shown in the following Figure 3.

A separate management account is created and source servers from each account are extended to this centralized account. These extended source servers aren’t used for recovery purposes, but instead for operational purposes such as centralized reporting and management of the replication status, or to gather insights using workflows built on services such as Amazon CloudWatch or Amazon EventBridge.

Figure 3: Extended source servers to create a centralized view for operational teams
Click to enlarge

Conclusion
In this post, we demonstrated that when building a business continuity plan and implementing a DR solution with Elastic Disaster Recovery, it is crucial to understand the business drivers, as well as the governance, security, and operational requirements. Elastic Disaster Recovery supports the use of multiple accounts to provide flexibility to meet a wide range of requirements. This includes designing for scale, managing cost allocation, meeting governance needs, or improving operations. The ability to extend source servers to multiple recovery accounts also enables advanced workflows for isolated testing, DR drills, and cyber event forensics, which are crucial for making sure of business continuity and data protection.

When using the multi-account feature of Elastic Disaster Recovery you can design and implement DR solutions that meet the unique needs of your business while ensuring business continuity and data protection. The benefits include greater isolation and security to meet compliance and regulatory mandates, improved operations to support experimentation, DR drills, and audits, and centralizing operations to simplify management of your DR environment.

Thank you for reading this post.

Resources:
Learn more about using multiple staging accounts with Elastic Disaster Recovery in our documentation.
To stay up-to-date on Elastic Disaster Recovery, check out our posts on the AWS Storage Blog channel.