Designing for Failure
Managing RTO and RPO for AWS Disaster Recovery
Designing for high availability, fault tolerance and cost efficiency
High Availability in RDS
High Availability in Amazon Aurora
High Availability in DynamoDB
The course is part of this learning path
This section of the Solution Architect Associate learning path introduces you to the High Availability concepts and services relevant to the SAA-C03 exam. By the end of this section, you will be familiar with the design options available and know how to select and apply AWS services to meet specific availability scenarios relevant to the Solution Architect Associate exam.
Want more? Try a lab playground or do a Lab Challenge!
- Learn the fundamentals of high availability, fault tolerance, and back up and disaster recovery
- Understand how a variety of Amazon services such as S3, Snowball, and Storage Gateway can be used for back up purposes
- Learn how to implement high availability practices in Amazon RDS, Amazon Aurora, and DynamoDB
Aurora can be configured with a single read/write master instance - and multiple read replicas. A single master instance can be configured with up to 15 read replicas when using Aurora. Replication of data is performed asynchronously in milliseconds - fast enough to give the impression that replication is happening synchronously.
Read Replicas share the same underlying storage layer connected to the master.
Read replicas can be deployed in different availability zones within the same VPC or if required can be launched as cross region replicas. Read replicas allow you increase the overall read throughput while also offloading database reads from the master instance - allowing the master to focus on serving writes. In the event of the master instance going down, any one of the read replicas can be promoted to take over the role of being master.
Each read replica can be tagged with a label indicating priority in terms of which one gets promoted to the role of master in the event of the master going down. The master can be rebooted in 60 or less seconds.
This type of cluster supports being stopped and started manually in its entirety - that is when you stop and start a cluster, all underlying compute instances are either stopped or started. When stopped the cluster remains stopped for up to 7 days, after which it will automatically restart itself.
Daily backups are automatically performed with a default retention period of 1 day and for which can be adjusted up to a maximum retention period of 35 days. You have the capability of specifying a window of time in which backups are automatically taken. Additionally, on-demand manual snapshots can be performed on the database at any time. Manual snapshots are stored indefinitely until you explicitly choose to delete them. Restores are performed into a new database.
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.