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.