AWS Auto Scaling

Before jumping into AWS Auto Scaling, first we need to understand the meaning of scaling in Cloud world.

Scaling means to meet the right (not Less or Extra) computes to handle the workload. With the help of scaling you do not just handle the heavy workload but also saving the cost by reducing the compute if not required.

Fault tolerance, High availability and cost saving are major benefits of Scaling.

we often heard two words in Scaling,

1.       Scale-In:  Means reduce the compute.

2.       Scale-Out: Means increase the Compute.

         Basically Scaling is categorized into two major categories in Cloud.

1.       Vertical Scaling

In this Scaling, we increase/decrease the compute of an existing virtual machine, according the workload. Like Increase/Decrease CPU and memory on virtual machine.

2.       Horizontal Scaling

In this scaling, we create/Delete the virtual machines, according to the workload and distribute the workload between virtual machines.

For Distributing the workload, we can use a Load Balancer etc.

        I.            AWS Auto Scaling:

“AWS Auto Scaling” features work on Horizontal scaling, Means create/Delete the EC2 Instances, according the workload and distribute the workload between EC2 Instances.

a.       Auto scaling ensures that right number (Not less or no Extra) if EC2 Instances are running at all time.

b.       AWS Auto Scaling Compliant with PCI DSS.

c.       It works well with an AWS Cloud watch, CloudTrail and AWS Elastic Load Balancer.

d.       Auto Scaling is region specific and can cannot span across the multiple regions.

e.       Auto Scaling can be span in Multi Availability Zone with in same region and 

You can define the subnet in “Availability Zone” which can be used by Auto scaling to create EC2 instance.

f.        If you have selected Multiple “Availability Zone” in Auto Scaling, Auto Scaling always try to distribute the EC2 Instances evenly, if Auto Scaling fails on one “Availability Zone” then it creates EC2 Instances on other one.

g.       You can send the Notification via AWS SNS service on the below Auto scaling Event.

a)       Instance is launched

b)      Instance is Terminated

c)       Instance is fail to Launch

d)      Instance is fail to terminated

1.       Auto Scaling Components

Auto Scaling has three components.

A.      Launch Configuration

This is the configuration template. which AWS uses to create the EC2 Instance.

1.       Below are the properties which need to define when we create the launch templates.

a.       Name of Launch Configuration Template

b.       AMI (Amazon machine Image)

c.       Instance Type (Like M1. large etc.)

d.       Key pair

e.       User Data

f.        Security Group

g.       IAM Role

h.       Purchase option (On-demand/On-Spot)

2.       You can create Launch configuration using console, API and CLI.

3.       You cannot Edit/Update the Launch configuration once created.

4.       If you create the   launch configuration using the AWS Management Console, then AWS enabled the Basic monitoring by default on EC2 Instances which is created by Auto Scaling group. You can change this.

5.       if you create the   launch configuration using the CLI/API, then AWS enabled the Details monitoring by default on EC2 Instances which is created by Auto Scaling group, you can change this.

6.       You can also use Spot Instance in launch configuration.

7.       You cannot mix on-demand and spot Instance in one launch configuration.

B.      Auto Scaling Group (AS Group)

“Auto scaling group” is the core of Auto Scaling. It is logical grouping of EC2 instances.

1.       Below are the properties which need to define when we create the Auto Scaling group.

a.       Launch configuration Template

b.       Minimum, Maximum and Desired capacity of EC2 Instances

c.       Subnet to Create the EC2 Instance.

d.       Metrics to decide that need to delete/ add EC2 Instances .

e.       Health Check to find out the status of EC2 instance (Healthy /Unhealthy).

2.       Unlike Launch Configuration Template, you can Edit the Auto Scaling group.

3.       If Auto Scaling finds that Number of EC2 instances launch by the Auto Scaling group into multiple Availability Zones is not equal. Then it tries to rebalance the EC2 Instances in all Availability Zone, we call this as Auto Scaling Availability Zone re-balancing.

4.       You can attach the existing EC2 instance to Auto Scaling group, if

a.       EC2 Instance is running state.

b.      AMI used to launch the Instance should exist.

c.       EC2 Instance should not part of any other Auto Scaling Group.

d.      EC2 Instance Should be in same Availability Zone of Auto Scaling Group.

5.       Once EC2 State is terminating state, it cannot be put back into Auto Scaling group.

6.       EC2 Standby State

You can manually move an Instance from an Auto Scaling Group and move it to Standby State. Auto scaling does not perform health checks on Standby State EC2 Instance, also not count as an available instance in the Auto Scaling Group. Means ELB will not transfer load to a Standby EC2 Instance.

7.       Deleting Auto Scaling Group

When you Delete the Auto Scaling group, its parameters Minimum capacity, Maximum Capacity and desired capacity will set to Zero and its terminate all existing Instances. If you want to keep the Instance, you should first detach from Auto scaling group and then delete the Auto Scaling group.

8.       Merging of Scaling Group

You can merge the Auto Scaling group using CLI/API only.

9.       If the Auto scaling failed to launch spot instances in an Availability Zone because of the market price, Then Auto scaling will try to launch Instance into another Availability Zone, if market price is less than or equal from the Bid price.

10.   The AWS service send EC2 Metrics to Cloud watch about the Auto scaling group EC2 Instances. If Launch configuration creates by AWS console, then by default Basic Monitoring will enable and if you create Launch configuration via CLI/API, then by default detail monitoring enabled on EC2 Instance which will created by the Auto Scaling group.

11.   If you want to change the monitoring configuration from Basic to Detail in existing Auto scaling groups, then you have to create new Launch configuration and assign to Auto Scaling group, As Launch configuration cannot editable.

12.   If EC2 instance is Healthy then it called In-service Instance and if EC2 Instance is unhealthy then it called out-Service Instance.

C.      Auto Scaling Policy 

Policies are rules to suggest the Auto Scaling group to meet the desired capacity as per the workload.

            Auto Scaling polices can be divided into three major categories.

1.       Manual Scaling Policies

 In this person need to change the Minimum, Maximum and desired capacity manually in Auto Scaling group according the workload. It helps you to maintain the specific number of Instance and change whenever is required manually.

2.       Cyclic / Schedule Based Policies

 If you have a scenario, where at Specific time, Traffic load on EC2 Instances is become high periodically for a time frame, then you need more instances at that time. In this type of Scenario Cyclic / Schedule Scaling is right choice 

a.       Helpful in predicative load change.

b.      You need to create a Schedule for Scale Out for specific date and time and provide the required capacity.

c.       Schedule can be recurring or one time.

d.      You can update the schedule.

e.       You cannot configure more than one schedule at same time.

 3.       On-demand / Dynamic / Event Based Policies

 In this Scale-out and Scale-In is done based on alarm. You can use Cloud Watch to monitor the Auto scaling group EC2 Instances and generate the alarm.

It is also divided in two categories.

a.       Simple On-demand / Dynamic / Event Based Policies

 Based on alarm received, you can Scale-In or Scale out, but on one alarm there should be one adjustment either Scale-In or Scale-Out.

There is a period which called Cool down, it is the time period after this Auto Scaling will responds the next alarm.

Default Cool Down period is 300 Seconds

b.      Step-up On-demand / Dynamic / Event Based Policies

You can do multiple adjustment based on alarm. It can respond to multiple alarm and initiate the multiple scaling rules based on alarm received.

It does not support Cool Down period. It supports the warm up period. It is the time period where newly launched EC2 instances will be ready to contribute. After this time period Instance is considered In-service and will ready to receive the traffic.