- Creating group of EC2 Instance that can scale up or down depending on conditions you set.
- Enable Elasticity by scaling horizontally through adding or terminating EC2 instance.
- Autoscaling ensures that you have the right number of AWS EC2 instance. When you not needed and scaling out to add more instance only when it is required.
*Auto scaling components*
- Launch configuration like instance type, AMI, key pair, security group, Auto scaling group, Group name, Group Size, VPC, Subnet, Health check period.
- Scaling Policy.
- metric type, target value.
* CPU utilisation*
- If Autoscaling finds that the number of EC2 instances launched by ASG into subject AZ is not balanced EC2 instance are not evenly distributed. Auto scaling do rebalancing activity by itself.
- As always tries to balance the instances distribution across AZ's
- While rebalancing, ASG launched new EC2 instance, where there are less EC2 at present, and this terminates the instance from the AZ, that had more instance.
* What causes imbalance of EC2 *
- If we add or remove some subnet/ AZ from auto scaling group.
- If we manually request for EC2 terminate from our ASG.
- An AZ that did not have enough EC2 capacity now has enough capacity and it is one of our autoscaling group.
- We can attach running EC2 instance to an autoscaling group by using AWS console or CLI, if the below conditions are not-
- Instance must be running state not terminated or stopped.
- AMI used to launch the EC2 still exist.
- Instance is not part of auto scaling group.
- Instance is in the same AZ of the same group.
- If the existing EC2 instance 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.
- You can manually remove EC2 instance from an autoscaling group using AWS console or CLI.
- You can mange the detected instance independently or attach it to another autoscaling group.
- When you detach on instance, you have the option to decrement the auto scaling group desired capacity.
- If you do not the autoscaling group will launch another instance to replace the one detached.
- When you delete autoscaling group its parameters like maximum, minimum and desired capacity are all set to zero. Hence it terminated all its EC2 instance.
- If you want to keep the EC2 instances and manage the independently, you can manually detach them first, then delete the 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 auto scaling group.
- Once you do this any EC2 instance existing or added by the autoscaling group will be automatically registered with the autoscaling group defined ELB.
- You do not need to register those instance manually on the autoscaling group defined ELB.
- Auto scaling classifies its EC2 instances health status as either healthy or unhealthy.
- By default, As uses EC2 instance status checks only to determine the health status of an instances.
- When you have one or more ELB defined with the autoscaling group. You can configure autoscaling to use both the EC2 health check and the ELB health check to determine the instance health check.
- Health check grace period is 300sec by default.
- If we set zero in grace period the instance health checked once it is service.
- Until the grace period timer expires any unhealthy status reported by EC2 status check or the ELB attached to the autoscaling group, will not be acted upon.
- After grace period expires autoscaling group would consider an instance unhealthy in any of the following cases.
- EC2 instance status check report to autoscaling group on instance status other than running.
- If ELB health check are configured to be used by the autoscaling then if the ELB report the instance as out of service.
- Unlike AZ rebalancing, termination of unhealthy instances happen first, then auto scaling attempt to launch new instance to replace the once terminated.
- Elastic IP and EBS volumes gets detached from the terminated instances you need to manually attach them to the new instances.
- In four situations ASG send a SNS email notification.
1) An instance is launched
2) An instance is terminated
3) An instance fails to launched
4) An instance fails to terminated
* Merging Autoscaling Group*
- Can only be done from CLI not AWS console.
- You can merge multiple, single AZ autoscaling group into a single, one multi AZ auto scaling group.
- Scale out means launching more EC2 Instance.
- Scale in means terminating one or more EC2 instance by scaling policy.
- It is always recommended to create a scale in event for each scale out event you create.
- AWS EC2 services sends EC2 metrics to cloud watch about the ASG instance.
- Basics monitoring every 300secs enabled by default and free of cost.
- You can enabled detailed every 60 sec chargeable.
- When the launch configuration is done by AWS CLI, detailed monitoring for EC2 instance is enabled by default.
* Stand by State*
- You can manually move an instance from an ASG and put it in standby state.
- Instance in stand by state are still managed by autoscaling.
- Instance in stand by state are charged as normal, in service instance.
- They do not count towards available EC2 Instance for workload/app use.
- Autoscaling does not perform health check in instance in standby state.
* Scaling Policy *
- Define how much you want to scale based on defined conditions.
- Autoscaling group uses alarms and policies to determine scaling.
- For simple or step scaling a scaling adjustment cant change the capacity of the group above the max group size or below the min group size.
- Productive scaling it looks at historic pattern and forecast them into the future to schedule change in the number of EC2 instances. If uses machine learning module 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 your thermo state maintain the temperature of your home.
- Step scaling increase or decrease the current capacity of the group based on a set of scaling adjustment known as step adjustment that is vary based on the size of the alarm breach.
- Does not support / wait for a cool down timer.
- Support a warm up timer time taken by nearly launch instance to be ready and contribute to the watched metric.
- Simple scaling is single adjustment up to down in response to an alarm cool down timer 300 sec default.
- Schedule Scaling for predictable load change.
- You need to configure a schedule action for a scale act at a specific date and time to required capacity.
- A schedule action must have a unique date and time. You cannot configure two schedule activities at the same time/date.