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 firstname.lastname@example.org.
So here we are at number one on my Top Ten List of AWS Services that enable us to design highly available fault-tolerant solutions. And my winner is Auto Scaling! Auto Scaling is a core component of increasing durability and availability on AWS. Auto Scaling enables you to provision based on actual demand rather than on estimated demand. Auto Scaling has health checking built in and it can drop EC2 Instances that are not responding and replace them with newly spun up healthy versions. All of this functionality works across multiple Availability Zones within a region helping you achieve high availability with minimal manual intervention. Auto Scaling should be used when you want to ensure that you have at least say one EC2 Instance running at all times, or perhaps one or two EC2 Instances in one or two of your availability zones always running. Another important use case is when you need to scale based on increased demand or when you know of an up and coming event where your EC2 Instances may be under a heavy workload. You can also ensure you scale back down to a normal EC2 presence and not waste money on idle resources. Auto Scaling makes Horizontal Scaling easy based on demand or pre-determined schedules. You can increase or decrease the number EC2 Instances running based on Cloudwatch Metrics. In the example on my screen, the Auto Scale policy will add an instance if the average CPU utilization equals or exceeds 70% for more than 300 seconds, which is five minutes. And the other part of the policy will remove instances from the Auto Scale group if the average CPU for the group equals or is less than 20% for five minutes. Core Components of Auto Scaling. The Launch Configuration, your group uses a Launch Configuration as a template for its EC2 Instances. When you create a Launch Configuration, you can specify information such as the AMI ID, Instance Type, Keep Here, Security Groups, and Block Device Mapping for your instances. And all that Auto Scaling Group enables you to specify minimum, maximum and desired number of EC2 instances in their group. A Scaling Plan tells Auto Scaling when and how to scale. You can base a Scaling Plan on the occurrence of specified conditions, Dynamic Scaling for example. Consider an Auto Scaling group that has two Availability Zones. A desired capacity of two instances and scaling policies that increase and decrease the number of instances by one when certain thresholds are met. When the threshold for the Scale Out Policy is met, the policy takes effect and Auto Scaling launches a new instance. The Auto Scaling group now has three instances. When the threshold of the scaling policy is met, the policy takes effect and Auto Scaling terminates one of the instances. If the group does not have a specific Termination Policy assigned to it, Auto Scaling uses the default Termination Policy. Auto Scaling selects the Availability Zone with two instances and terminates the instance launched from the oldest Launch Configuration. If the instances were launched from the same Launch Configuration, then Auto Scaling selects the instance that is closest to the next billing hour and terminates that. This helps you maximize the use of your EC2 Instances while minimizing the number of hours you have billed for Amazon EC2 usage. If there is more than one unprotected instance closest to the next billing hour, Auto Scaling selects one of these instances at random. All right. So how about creating your own Termination Policy? You have the option of replacing the default policy with a customized one. When you customize a Termination Policy, Auto Scaling first assesses the Availability Zones for any imbalance. If an Availability Zone has more instances than other Availability Zones that are used by the group, then Auto Scaling applies your specified Termination Policy on the instances from the imbalanced Availability Zone. If the Availability Zones used by the group are balanced, then Auto Scaling applies the Termination Policy that you specified. Now by default, Instance Protection is disabled. Instance Protection does not protect Auto Scaling instances from manual termination through the Amazon EC2 console. Terminate Instances command all the Terminate Instances API. Let's test our Auto Scaling knowledge with a CloudAcademy Quiz Question. The question reads, A user has defined an Auto Scaling Termination Policy to first delete the instance with the nearest billing hour, so this is a custom policy. Auto Scaling has launched three instances in the US-East-1A region and two instances in the US-East-1B region. One of the instances in the US-East-1B region is running nearest to the billing hour. Which instance will Auto Scaling terminate first when executing the termination action? A. Random instance from US-East-1B. Nope, it only uses random policies when none of the other logic can be completed. B. Random instance from US-East-1A. Nope. C. Instance with the nearest billing hour in US-East-1B. Mmm, now that's what the policy says, however remember it chooses based on which AZ has the most number of instances. So answer D. is instance with the nearest billing hour in the US-East-1A which is correct. So even though the user has configured the Termination Policy as a custom policy, before Auto Scaling selects an instance to terminate, it first identifies the Availability Zone that has more instances than the other Availability Zones used by the group. Within the selected Availability Zone, it identifies the instance that matches the specified termination policy.
About the Author
Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe. His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.