An Auto Scaling group contains a collection of EC2 instances that are treated as a logical grouping for the purposes of automatic scaling and management. By using Auto Scaling Group, we can manage the increased or decreased load by scaling in with more instances or scaling out. We can also make sure that there are always a fixed number of instances running, even if an instance becomes unhealthy. It will automatically register new instances to a load balancer.
Size of the Auto Scaling Group
The actual size of an ASG is based on the number we set as the desired capacity. we can adjust its size by providing the minimum size & the maximum size.
If the request volume is high, additional instances will be added with the desired capacity to meet the demand. It will scale until it reaches the maximum size we provided. If the request volume is low, then it shut down the instances to make sure there is no over usage of the resources. But it will make sure that it will not scale down below the minimum number of instances we provide.
Even if there is some failure in some machines in the group, it will bring up a new machine to always maintain the fixed number of instances running.
So we have to remember these three numbers to define the size of the ASG,
- Desired capacity
- Minimum size
- Maximum size
Scaling by Custom Metric
We can also auto-scale based on custom metrics. For example, we can send a number of logged in customers from our application deployed in EC2 to cloud watch & create an alarm to scale in & scale out based on the high & low value of the metric. We can use the ClosudWatch alarm as the scaling policy for ASG.
Scale using CloudWatch Alarms
We scale the ASG based on the CloudWatch Alarms. Amazon EC2 Auto Scaling publishes data points to CloudWatch about our Auto Scaling groups. An alarm monitors the metric. Based on the alarms, we can create Scale-in or Scale-out policy.
Scaling policies can be on CPU, Network or can even be on Custom metrics or based on schedule. IAM roles attached to an ASG will get assigned to EC2 instances.
Create ASG
ASG use a launch template or a launch configuration to configure Amazon EC2 instances that are launched by your Auto Scaling group. We have to provide the following attributes/configuration to create ASG,
- AMI & Instance Type
- SSH Key Pair
- Security Groups
- EBS Volume
- EC2 User Data
- Min size, Max size & Desired capacity
- Network & Subnet Information
- Load balancer Information
- Scaling Policy
We cannot modify a launch configuration/template once it is created, but we can replace the launch configuration for an Auto Scaling group. AWS is recommending using the launch template.
Scaling options
Amazon EC2 Auto Scaling provides several ways to adjust the scaling,
- Maintain current instance levels at all times
- Scale manually (Manual Scaling)
- Scale based on demand (Dynamic Scaling)
- Scale based on a schedule (Scheduled scaling)
- Predictive scaling
Maintain current instance levels at all times
We can configure to maintain a fixed set of running instances at all times. ASG will do a periodic health check. If it found any instance is unhealthy, it terminates that instance & creates a new one.
Manual Scaling
We can change the size of an existing ASG manually. It is the most basic way to scale. We can only change the maximum, minimum or desired capacity.
Dynamic Scaling
Scale the capacity in response to changing demand. A more advanced way to scale. We can define a scaling policy that dynamically resizes our ASG to meet changes in demand. We can configure ASG to scale dynamically by creating the below policies,
- Target Tracking Scaling Policy
- Step Scaling Policy
- Simple Scaling Policy
A dynamic scaling policy instructs Amazon EC2 Auto Scaling to track a specific CloudWatch metric, and it defines what action to take when the associated CloudWatch alarm is in ALARM.
Target tracking scaling: Increase or decrease the current capacity of the group based on a target value for a specific metric. For example, Based on CloudWatch metric/alarm, we want to always maintain the CPU capacity at around 50%.
Step and Simple scaling: Increase or decrease the current capacity of the group based on scaling adjustment, known as step adjustments For Example, We want to add 2 more instances or remove 1 or 2 instances based on CloudWatch metric/alarm.
Difference between Step & Simple Scaling Policy
Step scaling: Increase or decrease the current capacity of the group based on a set of scaling adjustments
Simple scaling: Increase or decrease the current capacity of the group based on a single scaling adjustment.
Scheduled scaling
We can schedule our scaling to scale in & scale out at a particular time. In this case, we always know when to increase or decrease the number of instances, because we are well aware that when the traffic/load will be high or low.
Predictive scaling
Predictive scaling uses machine learning to predict capacity requirements based on historical data from CloudWatch. If we have regular patterns of traffic increases and applications that take a long time to initialize, we should consider using predictive scaling.
Pricing: ASG is free. we have to pay only for the underlying resources being used.
Scaling cooldowns: Once scaling is done, it waits for a cooldown period. During this period, the ASG will not launch or terminate additional instances.