Autoscaling groups (High Availability and Scalability) Flashcards
the goals of ASG
- scale in (add) or scale out (remove) to match an increased or decreased load
- we can set the minimum and maximum number of machines running
- automatically register new instances to a load balancer (ASG is behind the LB)
ASGs have the following attributes
- a launch configuration
- min size / max size / initial capacity
- network + subnets info (where can instances be created)
- load balancer info (or target group)
- scaling policies
Scaling poicies
what will trigger a scale out
what will trigger a scale in
Autoscaling alarms
it is possible to scale an ASG based on CloudWatch alarms
we configure scaling policies - when to scale in or out - based on alarms
CloudWatch alarms
based on metrics (average CPU) that are computed for the overall ASG instances (averages)
if they go up the alarm goes off - scale out
when they go back down - scale in
Auto Scaling NEW Rules
you can say “I want to have a target average CPU usage of 40% in my ASG” and it will scale in and out to meet this goal
- number of requests on the ELB per instance
- average network in our out
Auto Scaling based on Custom Metric
for ex., number of connected users
- we’ll create this custom metric from our application and send it to CloudWatch (PutMetric API)
- create CloudWatch alarm to react to low or high values
- use the alarm as the scaling policy for ASG
to update an ASG
you must provide a new launch configuration or launch template (newer)
if you attach IAM roles to an ASG
they will get assigned to EC2 instances
ASG payment
ASGs are free, you only pay for the underlying resources being launched, f. ex. EC2 instances, EBS volumes
if an instance in ASG is terminated
ASG will detect this and replace it automatically with a new one
ASG can terminate instances marked as unhealthy by LB and replace them
launch configuration vs launch template (newer)
launch configuration allows you to specify only one instance type
launch template allow you to use spot fleet (of both on demand and spot instances, for ex.)
Target tracking scaling
scaling policy, the easiest to set up
I want the average ASG CPU to stay at around 40%
if it goes over, it will provision more instances, if it goes down - will scale in
scaling policies
- Target tracking scaling
- simple / step scaling
- scheduled actions
simple / step scaling
scaling policy
you set CloudWatch alarm and if it is triggered - you can configure how many instances will be added
For ex., if average CPU over the entire group goes over 70% - add 2 units
if it goes below 30% - remove 1 unit
scheduled actions
scaling policy
anticipate scaling based on known usage patterns
when you know that on certain day or at certain time you have to increase the number of instances
scaling cooldowns
helps to ensure that your ASG doesn’t launch or terminate additional instances before the previous scaling activity taking effect
scaling-specific cooldowns
in addition to default cooldown for ASG we can create cooldowns that apply to a specific simple scaling policy
A scaling-specific cooldown period overrides the default cooldown period
one common use for scaling-specific cooldowns
is with scale-in policy - a pocily that terminates instances based on a specific criteria or metric.
Because this policy terminates instances, EC2 Auto Scaling needs less time to determine whether to terminate additional instances
if the default cooldown period of 300 seconds is too long - you can reduce costs by applying a scaling-specific cooldown period of 180 seconds to the scale-in policy
if your app is scaling up and down multiple times each hour
modify ASG cool-down timers and the CloudWatch alarm period that triggers the scale in
ASG default termination policy
- find AZ which has the most number of instances
- if there are multiple instances in the AZ to choose from, delete the one with the oldest launch configuration
the idea is that ASG tries to balance the number of instances across AZ
Lifecycle hooks
normal life cycle for new instance when it’s added to ASG is
pending (scale out) –> InService –> Terminating (scale in) –> terminated
by adding steps (lifeCycle hooks) pendingWait -> pendingProceed between pending and inService we have the option to configure certain things: install extra software, do extra checks before your instance is declared inService
we can also add terminatingWait -> terminatingProceed between terminating and terminated - to extract information, logs or files out of the instance before it is completely terminated
both launch template and launch configuration allow you
to specify
- the AMI ID of your instances
- the instance type
- key pair
- security groups
- tags
- EC2 user-data
- other parameters to launch EC2 instances
launch configurations are considered
legacy, not recommended to use because you have to recreate them every time you change a parameter
launch templates
are newer and recommended to use
- can have multiple versions
- you create parameter subsets and share them across templates (partial configuration for re-use and inheritance)
- provision using both on-demand and spot instances, or a mix
- can use T2 unlimited burst feature
I have an ASG and an ALB, and I setup my ASG to get health status of instances thanks to my ALB. One instance has just been reported unhealthy. What will happen?
ASG will terminate the instance
Because the ASG has been configured to leverage the ALB health checks, unhealthy instances will be terminated
Your boss wants to scale your ASG based on the number of requests per minute your application makes to your database.
you create a CloudWatch custom metric and build an alarm on this to scale your ASG
The metric “requests per minute” is not an AWS metric, hence it needs to be a custom metric
An application is deployed with an Application Load Balancer and an Auto Scaling Group. Currently, the scaling of the Auto Scaling Group is done manually and you would like to define a scaling policy that will ensure the average number of connections to your EC2 instances is averaging at around 1000. Which scaling policy should you use?
Target Tracking
