Balancing in Autoscaling
If Autoscaling finds that the number of EC2 instances launched by AutoScaling Group (ASG) into subject AZs is not balanced (EC2 instances are not evenly distributed) then Autoscaling does the rebalancing activity itself.
Autoscaling always tries to balance the Instances distribution across Availability Zones (AZs)
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 the Imbalance of EC2
If we add or remove some subnets/AZ from the autoscaling group.
If we manually request EC2 termination from our ASG
An AZ that did not have enough EC2 capacity now has enough capacity and it is one of our autoscaling group AZ.
How to attach the EC2 to ASG
We can attach a running EC2 instance to an Autoscaling group by using AWS console or CLI if the below conditions are met:-
Instances must be in Running State (Not terminated or stopped)
AMI used to launch the EC2 still exists.
The instance is not part of another autoscaling group.
An 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, and the EC2 instance would not be added.
What happens when you remove EC2 instances from ASG
You can manually remove EC2 instances from an autoscaling group using an AWS console or CLI.
You can then manage the detached instances independently or attach them to another ASG.
When you detach an instance, you have the option to decrement the ASG desired capacity.
- If you do not, the ASG will launch another instance to replace the one detached.
When you delete an ASG, its parameters like max, min, and desired capacity are all set to Zero. Hence, it terminates all its EC2 instances.
If you want to keep the EC2 instances and managed them independently, you can manually detach them first, then delete the ASG.
How ELB works with ASG
We can attach one or more Elastic Load Balancers (ELBs) to our ASG.
The Elastic Load Balancer (ELB) must be in the same region as the ASG.
Once you do this, any EC2 instance existing or added by the ASG will be automatically registered with the ASG-defined ELB.
You do not need to register those instances manually on the ASG-defined ELB.
Instances and ELB must be in the same VPC.
How Health check of EC2 instances in ASG is done
Autoscaling classifies its EC2 instance health status as healthy or unhealthy.
By default, as uses EC2 status checks only to determine the health status of an Instance.
When you have one or more ELBs defined with the ASG, you can configure AS to use both the EC2 health check and the ELB health check to determine the instances' health check.
The health check grace period is 300 sec by default.
If we set 'Zero' in the grace period, the instance health is checked once it is in service.
Until the Grace period timer expires any unhealthy status reported by EC2 status checks or the ELB attached to the Autoscaling group, will not be acted upon.
After the Grace period expired, ASG would consider an Instance unhealthy in any of the following cases
EC2 status checks report to the AutoScaling group an instance status other than running.
If the ELB health check is configured to be used by the Autoscaling then if the ELB reports the instance as 'Out of Service'.
Unlike AZ rebalancing, termination of unhealthy instances happens first, then Autoscaling attempts to launch a new instance to replace the ones terminated.
Elastic IP and EBS volumes get detached from the terminated instances you need to manually attach them to the new instances.