Designing for high availability, fault tolerance and cost efficiency
AWS Services That Enable High Availability
The AWS exam guide outlines that 15% of the SysOps Administrator–Associate exam questions could be on the topic of designing highly-available, fault-tolerant, cost-efficient, scalable systems. This course teaches you to recognize and explain the core architecture principles of high availability, fault tolerance, and cost optimization. We then step through the core AWS components that can enable highly available solutions when used together so you can recognize and explain how to design and monitor highly available, cost efficient, fault tolerant, scalable systems.
- Identify and recognize cloud architecture considerations such as functional components and effective designs
- Define best practices for planning, designing, and monitoring in the cloud
- Develop to client specifications, including pricing and cost
- Evaluate architectural trade-off decisions when building for the cloud
- Apply best practices for elasticity and scalability concepts to your builds
- Integrate with existing development environments
This course is for anyone preparing for the Solutions Architect–Associate for AWS certification exam. We assume you have some existing knowledge and familiarity with AWS and are specifically looking to get ready to take the certification exam.
Basic knowledge of core AWS functionality. If you haven't already completed it, we recommend our Fundamentals of AWS learning path. We also recommend completing the other courses, quizzes, and labs in the Solutions Architect–Associate for AWS certification learning path.
This Course Includes
- 11 video lectures
- Detailed overview of the AWS services that enable high availability, cost efficiency, fault tolerance, and scalability
- A focus on designing systems in preparation for the certification exam
What You'll Learn
|Lecture Group||What you'll learn|
Designing for High availability, fault tolerance and cost efficiency
Designing for business continuity
How to combine AWS services together to create highly available, cost efficient, fault tolerant systems.
How to recognize and explain Recovery Time Objective and Recovery Point Objectives, and how to recognize and implement AWS solution designs to meet common RTO/RPO objectives
|Ten AWS Services That Enable High Availability||Regions and Availability Zones, VPCs, ELB, SQS, EC2, Route53, EIP, CloudWatch, and Auto Scaling|
If you have thoughts or suggestions for this course, please contact Cloud Academy at email@example.com.
Let's start by reminding ourselves of the ten AWS components that can enable highly available solutions when they're used together, and how we use each of these AWS components to increase fault tolerance and durability. These AWS services really help us as architects. So it's only fair we give them the star treatment they deserve. So to help you remember, let's count down to naming our number one high availability component. Starting at number ten with AWS Regions. AWS has 15 geographical regions including AWS GovCloud and the China region. Each region is a separate geographical area designed to be completely isolated from the the other Amazon regions. This achieves the greatest possible fault tolerance and stability. Essentially, everything you need to run a service is available in any AWS region. So chose the one closest or best network to your location. You only see the resources tied to the region that you specified. When you store data in a specific region it is not replicated outside that region unless you explicitly request AWS to do so. Which brings us nicely to candidate number nine on the high availability top ten, Availability Zones. Each region has multiple, isolated locations known as Availability Zones or AZs as we call them. AZs allow you to place instances and data in multiple locations. AZs are distinct geographical locations that are engineered to be insulated from failures in other AZs. In short, availability zones are designed for fault isolation. They are connected to multiple internet service providers and different power grids. They are interconnected using high-speed links so applications can rely on local area network connectivity for communication between availability zones within the same region. You may be responsible for selecting the availability zones where your system will reside. Systems can span multiple availability zones and you need to design your systems to survive temporary or prolonged failure of an availability zone in the case of a disaster. By placing Amazon EC2 instances in more than one AZ, an application can be protected from failure at a single location. As an architect, ideally, you want to run independent application stacks in more than one AZ so that if one zone fails, the application in the other zone can continue to run. A few design points to keep in mind when considering global versus regional in the design stage. AWS accounts are global. You can use the same AWS account in all regions. AMIs or Amazon Machine Images are regional so an AMI is tied to the region where its files are located within Amazon S3. You can copy an AMI from one region to another. Elastic IP Addresses are regional. By default, you can have five elastic IP addresses per region. Security Groups are regional. So you can have a maximum of 500 security groups per region. EBS snapshots are stored regionally. It's tied to the region and can only be used to create volumes in that region. You can, however, copy a snapshot from one region to another. EBS Volumes are tied to its Availability Zone and can be attached only to instances in that same Availability Zone. An instance is tied to the Availability Zone in which you launched it. However, do note that the instance ID is tied to the region.
Andrew is fanatical about helping business teams gain the maximum ROI possible from adopting, using, and optimizing Public Cloud Services. Having built 70+ Cloud Academy courses, Andrew has helped over 50,000 students master cloud computing by sharing the skills and experiences he gained during 20+ years leading digital teams in code and consulting. Before joining Cloud Academy, Andrew worked for AWS and for AWS technology partners Ooyala and Adobe.