This course looks at how you can use Recovery Time Objective (RTO) and Recovery Point Objectives (RPO) to determine an AWS disaster recovery strategy. RTO and RPO both fall under the Reliability pillar of the AWS Well-Architected Framework.
- The difference between RTO and RPO
- How to classify your RTO and RPO
- An understanding of 4 recovery strategies, including:
- Backup & Restore
- Pilot Light
- Warm Standby
- Multi-Site Active/Active
- Those who are in a role of an AWS site reliability engineer (SRE)
- Anyone who has a responsibility for and input into maintaining an effective business continuity and/or disaster recovery strategy for your AWS environment
- You should have a basic understanding of the AWS global architecture and understand the concepts and importance of building high availability into your infrastructure.
The final recovery strategy is the most complex and the most costly out of the different recovery strategies available, this being ‘Multi-site active/active’. However with this complexity and cost, it does offer you the lowest RTO and RPO when it comes to defining your DR strategy which is required for those critical applications and solutions that need it.
Whereas with the other recovery options there was an element that required you to provision additional resources within your DR region after the disaster had occurred, however with Multi-site active/active you are effectively deploying your infrastructure across multiple regions at full scale. So this means that there isn’t a designated DR region, instead your customers can access your applications and services from any region they require, and if one region goes down, your applications and data can continue to be accessed from another region, there is no need for any failover events to be triggered.
Let’s take a quick look at how this configuration would look:
As you can see, both regions are actively running operational workloads. Route 53 is being used to route traffic accordingly based on specific routing policies that have been configured which will route traffic to the appropriate region. At this point, the ELB will balance incoming requests between different AZs at the web server layer, which can scale using auto scaling groups. From here, the request will be passed to the application layer where it is then passed to DynamoDB. The DynamoDB data store has replication occurring automatically at this database layer using DynamoDB global tables, in addition to continuous backups of DynamoDB being taken in both regions.
This configuration means should either of the regions fail, your application and services will remain fully functional with no requirement to manually provision additional resources.
However not all problems are mitigated when operating a Multi-Site active/active solution, you do still need to be aware of a few points! Firstly, you must still perform testing of your DR strategy, for example, should a region fail, will the remaining region(s) be able to handle the additional traffic being routed to it? Secondly, you could experience another disaster of data corruption or deletion, which means you might have to restore your databases from a backup, which will take time affecting your RTO.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.