AWS Auto Scaling allows you to automatically adjust the capacity of your infrastructure in response to varying workloads. Auto Scaling Group (ASG) in AWS ensures that you have the right number of Amazon EC2 instances available to handle the load for your application. You can define various policies to tell the ASG when to scale in (reduce the number of instances) or scale out (increase the number of instances).
Auto Scaling Policies
Here are the main types of Auto Scaling policies:
Target Tracking Scaling Policy:
- This policy adjusts the number of instances based on a specific target value for a specific metric. For example, you can set a target to maintain the average CPU utilization of the ASG at around 70%. The ASG will then automatically adjust the number of instances to maintain this target.
Step Scaling Policy:
This policy increases or decreases the capacity based on a set of scaling adjustments, depending on the size of the alarm breach.
For instance, if CPU utilization is greater than 80% for a specific duration, you might want to add 2 instances, but if it’s above 90%, you might want to add 3 instances. Conversely, you can reduce instances when the utilization drops below a certain threshold.
Simple Scaling Policy:
This policy increases or decreases the desired capacity of the group based on a single scaling adjustment.
For example, if CPU utilization is more than 75%, increase the number of instances by 1. The main difference between this and step scaling is the simplicity: you have one alarm and one action.
Scheduled Scaling:
Allows you to scale your application in anticipation of known demand changes.
For example, if you know that every day at a specific time the demand increases or decreases, you can set scheduled actions to adjust the capacity accordingly.
When you're setting up these policies, it's often advised to:
Use cooldown periods: To prevent the ASG from adding or removing instances before the previous scaling activity takes effect, you can set a cooldown period. For example, if your instances take 5 minutes to start up and become operational, you might set a cooldown period of 5 minutes to prevent further scaling actions within that timeframe.
Use aggregated metrics: When monitoring metrics across multiple instances, you can choose to aggregate these metrics. For example, instead of triggering a scale-out event when a single instance hits 80% CPU, you can trigger the event when the average CPU of all instances in the ASG reaches 80%.
Remember, the key to effective auto-scaling is setting the right thresholds and metrics, ensuring that you’re not over-scaling (which can lead to unnecessary costs) or under-scaling (which can lead to poor application performance). Regularly reviewing and adjusting your policies as your application's behavior changes is a good practice.
Workshop: Use Target Tracking Scaling Policy for CPU utilization
Let's walk through a hands-on workshop where you'll create an Auto Scaling Group (ASG) and then set up a Target Tracking Scaling Policy based on the average CPU utilization of your EC2 instances.
Prerequisites:
An AWS account.
AWS CLI installed and configured with the necessary permissions.
Steps:
Launch EC2 Instances with ASG:
a. First, create a Launch Configuration. This will define the properties for the instances in the ASG.
aws autoscaling create-launch-configuration \ --launch-configuration-name my-lc \ --image-id ami-0f34c5ae932e6f0e4 \ # This is an example Amazon Linux 2 AMI. Ensure you choose an appropriate one for your region. --instance-type t2.micro \ --key-name DemoKeyPair \ # This is SSH Key Pair name used to access EC2 instances in ASG --security-groups sg-0123456789abcdef0 # Specify your SG IDb. Now, create an Auto Scaling Group with that Launch Configuration.
aws autoscaling create-auto-scaling-group \ --auto-scaling-group-name my-asg \ --launch-configuration-name my-lc \ --min-size 1 \ --max-size 5 \ --desired-capacity 1 \ --availability-zones us-east-1b # Replace with your desired AZ.
Set Up Target Tracking Scaling Policy:
a. Create the policy targeting 50% CPU utilization:
aws autoscaling put-scaling-policy \ --auto-scaling-group-name my-asg \ --policy-name my-target-tracking-policy \ --policy-type TargetTrackingScaling \ --target-tracking-configuration "PredefinedMetricSpecification={PredefinedMetricType=ASGAverageCPUUtilization},TargetValue=50.0"With the above command, AWS will try to maintain an average CPU utilization of 50% across all instances in the ASG.
Test the Policy:
a. Connect to one of the instances in the ASG.
b. Generate CPU load using the
stresstool:sudo yum install -y stress stress --cpu 1 --timeout 300This command will generate 100% CPU load on one of the cores for 5 minutes.
c. Go to the AWS Management Console -> EC2 Dashboard -> Auto Scaling Groups. Monitor your ASG named
my-asg.
d. After a few minutes, you should notice that AWS is launching additional instances in an attempt to bring the average CPU utilization back to 50%.
Clean Up (Important):
Don't forget to clean up resources after your test to avoid incurring unwanted charges.
a. Delete the scaling policy:
aws autoscaling delete-policy \ --auto-scaling-group-name my-asg \ --policy-name my-target-tracking-policyb. Delete the Auto Scaling Group:
aws autoscaling delete-auto-scaling-group \ --auto-scaling-group-name my-asg \ --force-deletec. Delete the Launch Configuration:
aws autoscaling delete-launch-configuration \ --launch-configuration-name my-lc
Note: This workshop uses AWS CLI. If you're more comfortable with the AWS Management Console, you can use the GUI to achieve the same results. Adjust the parameters like the instance type, AMI ID, SSH Key Pair Name, Security Groups, and availability zones as per your needs. Ensure you're monitoring costs and not leaving resources running longer than necessary.