Session 1 : Autoscaling(How it works & Components)

AutoScaling in AWS :

• Creating group of ec2 instances that can scale up or down depending on conditions we set
• Scale out means increasing and Scale in means reducing
• Enable elasticity by scaling horizontially(same type and size scaling) through adding or
terminating ec2 instances
• Autoscaling ensures that we have the right number of aws ec2 instances for our needs at all
time
• Autoscaling helps us save cost by cutting down the number of ec2 instances when not needed
and scaling out to add more instances only when it is required

Autoscaling Components :

1.Launch Configuration : Like instance type,AMI,keypair,Security Group

2.Autoscaling Group : Group name,Group Size,VPC,Subnet,Health Check Period
3.Scaling Policy : Metric type(Like Cpu Utilization),Target value

Session 2 : Autoscaling(Balancing,Attach & Detach)

Balancing :

• If autoscaling finds that the number of ec2 instances launched by ASG into subject AZ's is not
balanced(EC2 instances are ot not evenly distributed).Autoscaling do rebalancing activity by itself
• Autoscaling(AS) tries to balance the instances distribution across AZ's
• While rebalancing,ASG launches new ec2 instances where there are less ec2 at present,and
then terminates the instances from the AZ,that had more instances

What causes Imbalancing of EC2 :

☐ If we add or remove same subnet/AZ from ASG

☐ If we manually request for ec2 termination from our ASG
☐ An AZ that did not have enough ec2 capacity now has enough capacity and it is one of our
ASG AZ

Attaching :

• We can attach a ruuning ec2 instances to an autoscaling group by using aws console or CLI,if
the below conditions are met -
☐ Instances must be in running state(not stopped or terminated)
☐ AMI used to lauch the ec2 still exist
☐ Instance is not part of another ASG
☐ Instance is in the same AZ of the same group
☐ If the existing ec2 instances under the autoscaling group,plus the one to be needed,exceed the
max capacity of the autoscaling group,the request will fail,ec2 instance would not be added
Detach :

• We can remove ec2 instances from an ASG using aws console or CLI
• We can then manage the detached instance independently or attach it to another ASG
• When we detach an instance,we have the option to decrement the ASG desired capacity
• If we do not,the autoscaling group will launch another instances to replace the one detached
• When we delete an ASG,its parameters like max,min and desired capacity are all set to
0.Hence,it terminate all its ec2 instances

1/3
• If we want to keep the ec2 istances and manage them independently,we can manually detach
them first,then delete the ASG

How load balancer work with ASG:

• We can attach one or more elastic load balancer to our autoscaling group
• The elastic load balancer must be in the same region as the ASG
• Once we do this,any ec2 instance existing or added to the ASG will be automatically registered
with the ASG defined ELB
• We do not need to register those instances manually on the ASG defined ELB
• Instances and The ELB must be in the same VPC

Health Check :

• ASG classifies its ec2 isntances health status as either healthy or unhealthy
• By default,AS uses ec2 status checks only to determine the health status of an instance
• When we have one or more ELB defined with the ASG,we can configure AS to use both the
EC2 health check and the ELB health check to determine the instances health check
• Health check grace period is 300 sec by default
• If we set zero in grace period,the instance health is checked once it is in service
• Untill the grace period timer expires, any unhealthy status reported by ec2 status checks,or the
ELB attached to the autoscalling group,will not be acted upon

• After grace period expires,ASG would consider an instances unhealthy in any of the following
cases :
☐ EC2 status check report to ASG an innstance status other than running
☐ If ELB health check are configured to be used by the AS,the if the ELB report the instances as
‘out of service’
☐ Unlike AZ rebalancing,termination of unhealthy instances happen first,then AS attempt to
launch new instance to replace the ones terminated
☐ Elastic IP and EBS volumes gets detached from the terminated instances,we need to manually
attach them to the new instances

Session 3 : Types of AWS Autoscaling

On four situation,ASG sends a SNS email Notification :
1.An instance is launched
2.An instance is terminated
3.An instance fails to launch
4.An instance fails to terminate

Merging Autoscaling Groups :

• Can only be done from the CLI(not aws console)

• We can merge multiple,single AZ ASG into single,one multi-AZ ASG
• Scale out means launching more ec2 instances
• Scale in means terminating one or more instances by scaling policy
• It is always recommended to create a scale-in event for each scale-out event we create
• Launch config cant be edited,only copied or deleted

Monitoring :

• AWS ec2 services sends ec2 metrics to cloudwatch about the ASG instances :
☐ Basic monitoring(Every 300 secs enabled by default & free of cost)
☐ We can enable detailed(every 60 sec-chargeable)
• When the launch config is done by AWS cli,detailed monitoring for ec2 instances is enabled by
default
2/3
StandBY state :

• We can manually move an instance from an ASG and put it in standby state
• Instances in standby state are still managed by autoscaling
• Instances in standby state are charged as normal in service instances
• They do not count towards available ec2 instances for workload/APP use
• AS does not perform health check instances in standby state

Auto-Scaling Policy : Manual or Dynamic

• Define how much we want to scale based on defined conditions

• ASg uses alarms and polices to determine scaling
• For simple or step scaling, a scaling adjustment can't change the capacity of the group above
the max group size or below the min group size

Predictive/Scheduled Scaling : It looks at historic pattern and forecast them into the future to
schedule change in the no of ec2 instances.It uses machine learning model to forecast daily and
weekly pattern

Target Tracking Policies : Increase or decrease the current capacity of the group based on a
target value for a specific metric.This is similar to the way that our thermostat maintain the temp
of our home

Step Scaling : Increase or decrease the current capacity of the group based on a set of scaling
adjustment,known as step adjustment,that vary based on the size of the alarm reach
• Does not support/wait for a cool-down times
• Support a warm-up timer time taken by newly launch instance to be ready and contribute to the
watched metric

Simple Scaling : Single adjustment(up or down) in response to an alarm (cooldown timer)-300 sec

Scheduled Scaling :

• Use for predictable change

• We need to configure a schedule action for a scale out at a specific date/time and to a required
capacity
• A schedule action must have a unique date/time
• We cannot configure two scheduled activities at the same time/date

LAB :

Session 4 : AWS Autoscaling Demo

3/3