Autoscaling in Amazon Web Services: EC2 + CloudWatch

Good day!

Configuring autoscaling based on Amazon EC2 is a very interesting task that I once solved and now I put into practice. There are many possible options, but I will consider the simplest of them: horizontal scaling of one server under one balancer.

Cloud Watch will be the initiator of scaling. The metric will be our custom Load Average metric .
')
So let's start with. The first, as a Linux user, I advise and recommend using the Command Line Tools (CLT) in the configuration of auto-scaling for the following reasons:

• from CLT you can do everything;
• it is more convenient to copy-paste to the console than to click with the mouse.

Prepare for work and set up your terminal by downloading and unpacking the following tools:

• ELB CLT -> / opt / aws / elb
• EC2 CLT -> / opt / aws / ec2
• CloudWatch CLT -> / opt / aws / mon
• Auto Scaling CLT -> / opt / aws / as

Certificates pk - ***. Pem and cert - ***. Pem put in / opt / aws / keys.

Now configure the bash profile by inserting the following lines in .bash_profile:


So, after this list of available commands will expand to the desired number.

1. Let's start by creating a balancer:

 $ elb-create-lb testlb --headers --listener "lb-port=80,instance-port=8080,protocol=http" --listener "lb-port=443,instance-port=8443,protocol=tcp" --availability-zones us-east-1c DNS_NAME DNS_NAME DNS_NAME testlb-1678377526.us-east-1.elb.amazonaws.com 

Here:
testlb - name LB
“Lb-port = 80, instance-port = 8080, protocol = http” - external port LB and internal port of server. With HTTPS, the same situation.

2. We will assume that we have an instance that is already ready for work with ID i-12345678. Install our instance under LB:

 $ elb-register-instances-with-lb testlb --instances i-12345678 INSTANCE_ID i-12345678 

Now the instance is available at LB.

3. Hire the image (Amazon Machine Image - AMI) from the desktop:

 $ ec2-create-image i-12345678 --no-reboot -n 'Image Name' -d 'Image Description' ami-87654321 

4. With the resulting ami create a start-config (Launch Config)

 $ as-create-launch-config testlc -i ami-87654321 --key=keypair --group mygroup --instance-type m1.large OK-Created launch config 

Here:
keypair - a pair of keys with which you log in;
mygroup is a security group in which servers will go up.

5. Create an autospeaking group with the newly created config:

 $ as-create-auto-scaling-group testsg -l testlc --availability-zones us-east-1c --min-size 0 --max-size 2 --load-balancers testlb OK-Created AutoScalingGroup 

Here:
testlc - we have created a config;
us-east-1c - zone in which instances will rise;
0 and 2 are the minimum and maximum group sizes, respectively;
testlb is the name of your balancer, under which the whole group will be raised.

So, the scaling and balance group is ready.

Now you need to configure CloudWatch alarms. Autoscaling based on CloudWatch does not work through the policy - the policy that is set. An example of a policy is to increase the number of injections by 1. That is. first we set the policy, then we create an alarm , which, for example, works when the Load Average is more than 5 for a minute.

6. Well, here's the policy of a scale up:

 $ as-put-scaling-policy ScaleUpPolicy --auto-scaling-group testsg --adjustment=1 --type ChangeInCapacity --cooldown 120 arn:aws:autoscaling:us-east-1:278634951321:scalingPolicy:2f3482d2-ca6c-4653-970c-eb68a593cf26:autoScalingGroupName/testsg:policyName/ScaleUpPolicy 

Here:
--adjustment = 1 - +1 host to group
--cooldown 120 - for 2 minutes all alarms will be ignored and new instances will not be raised

7. Well, the alarm for scale apa:

 $ mon-put-metric-alarm HighLoadAvAlarm --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --metric-name LoadAverage --namespace CustomMetric --period 60 --statistic Average --threshold 5 --alarm-actions arn:aws:autoscaling:us-east-1:278634951321:scalingPolicy:2f3482d2-ca6c-4653-970c-eb68a593cf26:autoScalingGroupName/testsg:policyName/ScaleUpPolicy OK-Created Alarm 

Here:
--comparison-operator GreaterThanOrEqualToThreshold - operator> = than trashhold.
--evaluation-periods 1 - works the first time
--metric-name LoadAverage --namespace CustomMetric - our custom metric
--period 60 - minute to trigger
--statistic average - calculated average
--threshold 5 - Load Average is not more than 5, remember?
- alarm-actions - which policy.

8. Scale Down Policy:

 $ as-put-scaling-policy ScaleDownPolicy --auto-scaling-group testsg --adjustment=-1 --type ChangeInCapacity --cooldown 420 arn:aws:autoscaling:us-east-1:278634951321:scalingPolicy:2f3482d2-ca6c-4653-970c-eb68a593cf26:autoScalingGroupName/testsg:policyName/ScaleDownPolicy 

Here is a cooldown more. After the downscale instance the group does not downscale for at least another 6 minutes. Well, adjustment = -1.

9. Scale Down Alarm:

 $ mon-put-metric-alarm LoLoadAvAlarm --comparison-operator LessThanThreshold --evaluation-periods 1 --metric-name LoadAverage --namespace CustomMetric --period 120 --statistic Average --threshold 3 --alarm-actions arn:aws:autoscaling:us-east-1:278634951321:scalingPolicy:2f3482d2-ca6c-4653-970c-eb68a593cf26:autoScalingGroupName/testsg:policyName/ScaleDownPolicy OK-Created Alarm 

Here the alarm is triggered, if more than 2 minutes, the Load Average was less than 3.

Well that's all. So, now, depending on the load, our scale group can grow to 3 instances and 1 will always be alive. Here is considered the simplest example of autoscaling. Naturally, you can change the conditions and messing with numbers on your own.