AWS Auto Scaling Explained

AWS Auto Scaling -provides Scalibility and Fault tolerance.
AWS Auto Scaling is done between Availibility zones within a region.

Features of AWS Auto Scaling groups are:

• Creates group of EC2 instances that can scaleup or down depending on conditions you set.
• Enables elasticity by scaling horizontally through adding or terminating EC2 instances.
• AWS Auto Scaling ensures that you have the right number of AWS EC2 instances for your needs at all the times.
• AWS Auto Scaling helps you to 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.
• Predictive Scaling : – AWS Auto Scaling automates capacity management for various AWS services, including Amazon EC2, by tracking capacity utilization. Now, you can use Predictive Scaling in AWS Auto Scaling to scale your Amazon EC2 capacity in advance of traffic changes. Auto Scaling enhanced with Predictive Scaling delivers faster, simpler, and more accurate capacity provisioning, resulting in lower cost and more responsive applications.

AWS Auto Scaling components:
Launch configuration: Types of instance you want to launch, selct AMI, select Security group etc.
Auto Scaling group: All the EC2 instances will be grouped within the instances. Need to select group name, group size, VPC, Subnet, health check period. Note, you can change existing AWS Auto Scaling group.

• If AWS Auto Scaling finds out that the number of EC2 instances launched by ASG into AZs is not balanced, AWS Auto Scaling do rebalancing by itself.
• AWS Auto Scaling always tries to balance the Instances distribution across AZs.
• While Rebalancing, ASG launches new EC2 instances where there are less EC2 instances at present and then terminates the instances from from the AZ, that had more instances.

• What causes imbalaning of EC2 :
• If we add or remove some subnets/Az from AWS Auto Scaling group.
• If we manually request for EC2 termination from ASG.
• An AZ does not have enough EC2 capacity and it is one of our AWS Auto Scaling group.

We can attach running EC2 instances to an AWS Auto Scaling group by using AWS console or CLI, if the below conditions are met:
1.Instances must be in running state (not terminated or stopped).
2.AMI used to launch the EC2 still exists
3.Instances are not part of other AWS Auto Scaling group. An instance can be part of only one AWS Auto Scaling group at a time.
4.Both EC2 instance and ASG should be in the same Availability zone. Instance is in same AZ of the same group.
5.If the existing EC2 instances under the AWS Auto Scaling group, plus the one to be needed, exceed the maximum capacity of the AWS Auto Scaling group, the request will fail, EC2 instance will not be added.

• You can manually remove EC2 instances from an AWS Auto Scaling group using AWS console or CLI.
• You can manage the detached instances independently or attach it to another AWS Auto Scaling group.

• When you detach an instance , you have the option to decrement the AWS Auto Scaling group desired capacity.If you do not , the AWS Auto Scaling group will lauch another instance to replace the one detached.
• When you delete an ASG, its parameters like maximum, minimum and desired capacity wik set to Zero.Hence it termintes all EC2 instances.
• If you want to keep the EC2 instances and manage them idependently, then can detach them first, then delete the ASG.

• How Elastic Load Balancer works with ASG:
• We can attach one or more Elastic load balancer to ASG
• The Elastic Load Balancer must be in the same region as ASG.
• Once you do this, any EC2 instance existing or added by the AWS Auto Scaling group will be automatically registered with the AWS Auto Scaling group defined ELB.
• You do not need to register those instances manaually which have ASG defined ELB.
• Instances and the ELB must be in same VPC.

• Health checks by ASG:
• AWS Auto Scaling classifies its EC2 instances health status as either healthy or unhealthy.
• By default ASG uses EC2 status checks only to determine the health status of an Instance.
• When you have one or more ELB defined with ASG, tou can configure ASG to use both the EC2 health check and ELB health check to determine the instance 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 AWS Auto Scaling group , will not be acted upon.

After Grace period expires, ASG would consider an instance unhealthy in any of the following cases:
1.EC2 status check report to ASG an instances status other than running.
2.If ELB health check are configured to be used by the ASG, then if ELB Report the instance as “Out of Service”.
3.Unlike AZ Rebalancing, termination of Unhealthy instance happen first, then ASG attempt to launch new instance to replace the ones terminated.
4.Elastic IP and EBS Volume gets detached from the terminated instances you need to manually attach them to new instances.

AWS Auto Scaling policies:
In 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 Autscaling groups:
• Can be done from the CLI only.
• You can merge multiple, single AZ AWS Auto Scaling group into a single one Multi Az AWS Auto Scaling group.

Launch configuration–You cannot edit existing Launch configuration,Only can change it or delete it.
AWS Auto Scaling groups can be edited.

• Monitoring of ASG:
• Cloudwatch monitors ASG every 5 mins .
• Console–Monitoring time every 5 mins.Is not detailed monitoring but only basic monitoring.
• CLI-Monitoring time is 1 mins for detailed monitoring(enabled by default) and is chargeable.

Standby State:
1.You can manually move an instance from an ASG and put it in standby state.
2.Instances in standby state are still managed by ASG.
3.They do not count towards available EC2 instances for workload or app use.
4.AWS Auto Scaling do not perform health check on instances in standby mode.

Auto Scaling Policies;
Auto Scaling policies are of two types-Manual and Dynamic.
Manual-You set the Minimum, Maximum and Desired EC2 instances.
Dynamic–Target Tracking, Simple Scaling policy and Step Scaling policy.

Dynamic Scaling policies explained:

Scaling based on high demand at peak times = Dynamic Scaling

Target Tracking Policy: Scaling changes based per the target parameter set eg CPU utilization etc. Will apply its own logic to revolve around the set target.
Simple Scaling policy--Whenever threshold level is reached, will scale based on particular instructions set, will not apply its own logic.
Eg CPU utilization between 50%-60 %, Add 1 instances.
Step Scaling Policy–Can set different steps for AWS Auto Scaling based on range of parameters. Cooldown period does not works in Step Scaling policy. Eg CPU utilization between 50%-60 %, Add 1 instances.
60 % to 70 %- Add 2 instances.
70 % to 80 %–Add 3 instances.

Scheduled Scaling: Works based on fixed schedule or past historic pattern and will scale accordingly.

Steps based on which instance is terminated in Auto Scaling:

1.Determine which Availability Zones have the most instances, and at least one instance that is not protected from scale in.
2. Determine which instances to terminate so as to align the remaining instances to the allocation strategy for the On-Demand or Spot Instance that is terminating. This only applies to an Auto Scaling group that specifies allocation strategies.
For example, after your instances launch, you change the priority order of your preferred instance types. When a scale-in event occurs, Amazon EC2 Auto Scaling tries to gradually shift the On-Demand Instances away from instance types that are lower priority.
3. Determine whether any of the instances use the oldest launch template or configuration:
a. [For Auto Scaling groups that use a launch template]
Determine whether any of the instances use the oldest launch template unless there are instances that use a launch configuration. Amazon EC2 Auto Scaling terminates instances that use a launch configuration before instances that use a launch template.
b. [For Auto Scaling groups that use a launch configuration]
Determine whether any of the instances use the oldest launch configuration.
4. After applying all of the above criteria, if there are multiple unprotected instances to terminate, determine which instances are closest to the next billing hour. If there are multiple unprotected instances closest to the next billing hour, terminate one of these instances at random.
Note that terminating the instance closest to the next billing hour helps you maximize the use of your instances that have an hourly charge. Alternatively, if your Auto Scaling group uses Amazon Linux or Ubuntu, your EC2 usage is billed in one-second increments

Also Refer:

https://www.thetechcurious.com/aws-s3-explained/

https://www.thetechcurious.com/aws-vpc-and-its-components-explained/

https://www.thetechcurious.com/aws-elastic-load-balancer-summary/

https://www.thetechcurious.com/aws-security-identity-compliance-explained/

https://www.thetechcurious.com/amazon-aws-solution-architect-aws-databases-summary/

https://www.thetechcurious.com/amazon-ebs-summary-notes/

https://www.thetechcurious.com/elasticache-notes-on-memachedredis-and-exam-tips/

https://www.thetechcurious.com/aws-analytic-services-explained/

https://www.thetechcurious.com/aws-management-tools/

https://www.thetechcurious.com/aws-migration-services/

https://www.thetechcurious.com/aws-lambda-explained/

https://www.thetechcurious.com/aws-sqs-and-sns-summary/

https://www.thetechcurious.com/aws-cloudfront-summary/

https://www.thetechcurious.com/ecs-in-aws-explained/