12. Deployment & Management

AWS Elastic Beanstalk

AWS Systems Manager

AWS Config

AWS Secret Manager

AWS OpsWorks

AWS Resource Access Manager

RPO, RTO, & DR Strategies

Explore

RPO, RTO, & DR Strategies

Disaster Recovery focuses on one-time recovery objectives in response to natural disasters, large-scale technical failures, or human threats such as attack or error. This is different than availability which measures mean resiliency over a period of time in response to component failures, load spikes, or software bugs.

⁠

Recovery Point Objective (RPO) Defined by the organization.

RPO is the maximum acceptable amount of time since the last data recovery point. This determines what is considered an acceptable loss of data between the last recovery point and the interruption of service. It refers to how much data loss your application can tolerate.

Measurement of the amount of data that can be acceptably lost.

Measured in seconds, minutes, or hours.

Example:

You can acceptably lose 2 hours of data in a database (2hr RPO).

This means backups must be taken every 2 hours.

Achievable RPOs

⁠

Recovery Time Objective (RTO) Defined by the organization.

RTO is the maximum acceptable delay between the interruption of service and restoration of service. This determines what is considered an acceptable time window when service is unavailable.

Measurement of the amount of time it takes to restore after a disaster event.

Measured in seconds, minutes, or hours.

Example:

The IT department expect it to take 4 hours to bring applications online after a disaster.

This would be an RTO of 4 hours.

Achievable RTOs

⁠

When establishing these objectives, keep in mind that recovering an application in 15 minutes (RTO) with less than 1 minute of data loss (RPO) is great, but only if your application actually requires it. This is because having a lower target – faster recovery and/or less data loss – requires additional resources and configuration to accomplish, causing an increase in operational complexity and cost to implement and maintain. Therefore, RTO and RPO targets must be set on an application-by-application basis, and they must be evaluated against the added cost and complexity of the proposed target for each application.

A disaster recovery matrix, like the following, can help you understand how workload criticality relates to recovery objectives. (Note that the actual values for the X and Y axes should be customized to your organization needs).

⁠

Disaster recovery matrix

Disaster recovery matrix

⁠

The preceding image shows how the Recovery Time Objective for an application, along with the acceptable recovery cost, directly influences the recovery options that can be considered. If there are no options when both constraints are applied for your application, then either the RTO needs to be increased, or the additional cost/complexity needs to be justified.

⁠

Use defined recovery strategies to meet the recovery objectives

Define a disaster recovery (DR) strategy that meets your workload's recovery objectives. Choose a strategy such as backup and restore, standby (active/passive), or active/active.

Implementation guidance

A DR strategy relies on the ability to stand up your workload in a recovery site if your primary location becomes unable to run the workload. The most common recovery objectives are RTO and RPO, as discussed in

REL13-BP01 Define recovery objectives for downtime and data loss⁠

A DR strategy across multiple Availability Zones (AZs) within a single AWS Region, can provide mitigation against disaster events like fires, floods, and major power outages. If it is a requirement to implement protection against an unlikely event that prevents your workload from being able to run in a given AWS Region, you can use a DR strategy that uses multiple Regions.

When architecting a DR strategy across multiple Regions, you should choose one of the following strategies. They are listed in increasing order of cost and complexity, and decreasing order of RTO and RPO. Recovery Region refers to an AWS Region other than the primary one used for your workload.

⁠

Disaster recovery (DR) strategies

Disaster recovery (DR) strategies

⁠

Backup and restore (RPO in hours, RTO in 24 hours or less): Back up your data and applications into the recovery Region. Using automated or continuous backups will permit point in time recovery (PITR), which can lower RPO to as low as 5 minutes in some cases. In the event of a disaster, you will deploy your infrastructure (using infrastructure as code to reduce RTO), deploy your code, and restore the backed-up data to recover from a disaster in the recovery Region. Backup and restore is the least complex strategy to implement, but will require more time and effort to restore the workload, leading to higher RTO and RPO. It is a good practice to always make backups of your data, and copy these to another site (such as another AWS Region).

⁠

Pilot light (RPO in minutes, RTO in tens of minutes): Provision a copy of your core workload infrastructure in the recovery Region. Replicate your data into the recovery Region and create backups of it there. Resources required to support data replication and backup, such as databases and object storage, are always on. Other elements such as application servers or serverless compute are not deployed, but can be created when needed with the necessary configuration and application code. With the pilot light approach, you replicate your data from your primary Region to your recovery Region. Core resources used for the workload infrastructure are deployed in the recovery Region, however additional resources and any dependencies are still needed to make this a functional stack. For example, no compute instances are deployed.

⁠

Warm standby (RPO in seconds, RTO in minutes): Maintain a scaled-down but fully functional version of your workload always running in the recovery Region. Business-critical systems are fully duplicated and are always on, but with a scaled down fleet. Data is replicated and live in the recovery Region. When the time comes for recovery, the system is scaled up quickly to handle the production load. The more scaled-up the warm standby is, the lower RTO and control plane reliance will be. When fully scales this is known as hot standby. The warm standby approach involves ensuring that there is a scaled down, but fully functional, copy of your production environment in another Region. This approach extends the pilot light concept and decreases the time to recovery because your workload is always-on in another Region. If the recovery Region is deployed at full capacity, then this is known as hot standby.

⁠

Multi-Region (multi-site) active-active (RPO near zero, RTO potentially zero): Your workload is deployed to, and actively serving traffic from, multiple AWS Regions. This strategy requires you to synchronize data across Regions. Possible conflicts caused by writes to the same record in two different regional replicas must be avoided or handled, which can be complex. Data replication is useful for data synchronization and will protect you against some types of disaster, but it will not protect you against data corruption or destruction unless your solution also includes options for point-in-time recovery. You can run your workload simultaneously in multiple Regions as part of a multi-site active/active strategy. Multi-site active/active serves traffic from all regions to which it is deployed. Customers may select this strategy for reasons other than DR. It can be used to increase availability, or when deploying a workload to a global audience (to put the endpoint closer to users and/or to deploy stacks localized to the audience in that region). As a DR strategy, if the workload cannot be supported in one of the AWS Regions to which it is deployed, then that Region is evacuated, and the remaining Regions are used to maintain availability. Multi-site active/active is the most operationally complex of the DR strategies, and should only be selected when business requirements necessitate it.

⁠

Determine a DR strategy that will satisfy recovery requirements for this workload.

Choosing a DR strategy is a trade-off between reducing downtime and data loss (RTO and RPO) and the cost and complexity of implementing the strategy. You should avoid implementing a strategy that is more stringent than it needs to be, as this incurs unnecessary costs.

For example, in the following diagram, the business has determined their maximum permissible RTO as well as the limit of what they can spend on their service restoration strategy. Given the business’ objectives, the DR strategies pilot light or warm standby will satisfy both the RTO and the cost criteria.

⁠

Loading docs.aws.amazon.com⁠

⁠

Recovery Point Objective (RPO) Defined by the organization.

Achievable RPOs

Recovery Time Objective (RTO) Defined by the organization.

Achievable RTOs

Use defined recovery strategies to meet the recovery objectives

Implementation guidance

Determine a DR strategy that will satisfy recovery requirements for this workload.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.