DevOps line
Auto scaling
Two cooks stay on the line until a rule calls two more, and the new two cannot serve until they pass a check.
Stops explain each step. The film plays the whole ride.
- An order, or a call for help
- Queued message
- Cooks joining the line
- Too busy, or sent back
Two cooks take the order
Your order reaches the gate, then the two cooks already on the line. Both are under the mark, so nothing new is called.
Next stop: The line crosses the mark
All stops
The everyday version
A lunch counter works the same way. The rule can write a bigger number before the new cooks are allowed to take an order.
- Nabilais the Requests
The orders that keep arriving, busy line or not.
- Faridis the Load balancer
The gate that shares each order with cooks who are serving.
- Rumi and Taniais the In service
The cooks already on the line, taking orders before anyone new arrives.
- The ruleis the Scaling policy
A written mark. Cross it, and two more names go on the shift list.
- Lima and Borhanis the Launching
New cooks getting ready. Wanted is not the same as serving.
- The checkis the Health check
The look that decides whether a new cook may step up and take an order.
Interview questions
Say the short answer first. Go deeper only if they ask.
What is the difference between desired capacity and in service?
Desired is how many you want. In service is how many have joined and can take traffic.
A scaling policy changes desired capacity. The group then launches or terminates instances until the running set matches. A new instance stays out of service while it boots, registers with the load balancer, and passes health checks. The load balancer keeps sending work to the ones already in service.
Saying the fleet tile “4 running” means four servers are already taking traffic.
What does a step scaling policy actually do?
A CloudWatch alarm fires it, and it adds or removes a number that depends on how far the metric crossed the mark.
You own the alarm and the step adjustments. “CPU over 70, add two” is one step. A bigger breach can be a bigger step. Step policies can scale out again without waiting for the simple-policy cooldown. New instances have a warmup, and while warmup is in progress a scale-in from step or target tracking waits.
Treating the reel’s 66, 66, 75 and 45 second chips, or its 4:00, as AWS defaults.
How is that different from target tracking, predictive scaling, and a warm pool?
Target tracking chases a metric. Predictive schedules ahead from past load. A warm pool boots less because instances are already prepared.
Target tracking sets desired capacity to hold a metric, such as average CPU, near a target you choose. AWS recommends it when the metric moves opposite to capacity. Predictive scaling uses history to change capacity before the spike. A warm pool keeps initialized instances outside the serving count. None of them make a new instance serve before it joins and passes health checks. Ending near 50% CPU after a step of “add two” is the after picture, not proof of target tracking.
Calling the second frame target tracking because CPU settled near 50%.
Why can users still see failures while the new instances exist?
Because existence is not in service. Only healthy instances behind the load balancer take requests.
Until the new instances register and pass checks, every request still goes to the original ones. If those are saturated, the load balancer can fail requests even while the group is launching capacity. The count of those failures in the reel is a story prop, not a formula.
Saying a launched instance is helping as soon as the policy fires.
What is the 300 second cooldown, and when does it apply?
It is the default cooldown for simple scaling. Step and target tracking scale out without waiting for it.
The console and the CLI both default the group cooldown to 300 seconds. Simple scaling uses it between activities. Step and target tracking use instance warmup instead, and they may start another scale-out immediately. Replacing an unhealthy instance does not wait for cooldown. A manual desired-capacity change also does not wait, unless you ask it to honor cooldown.
Quoting 300 seconds, or the reel’s 4:00, as the wait for every scaling policy.
Cheat-sheet
Commands you will actually type.
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names web --query 'AutoScalingGroups[0].{wanted:DesiredCapacity,min:MinSize,max:MaxSize}'Read the wanted number, and the minimum and maximum around it.
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names web --query 'AutoScalingGroups[0].Instances[].{id:InstanceId,state:LifecycleState,health:HealthStatus}'See who is InService and who is still launching.
aws autoscaling set-desired-capacity --auto-scaling-group-name web --desired-capacity 4Set the wanted number yourself. A manual change does not wait for cooldown.
aws autoscaling update-auto-scaling-group --auto-scaling-group-name web --health-check-type ELB --health-check-grace-period 300Also trust the load balancer check. The CLI grace default is 0, not 300.
aws autoscaling describe-policies --auto-scaling-group-name web --query 'ScalingPolicies[].{name:PolicyName,type:PolicyType}'See if a policy is StepScaling, TargetTrackingScaling, or SimpleScaling.
aws cloudwatch describe-alarms --alarm-names web-cpu-high --query 'MetricAlarms[0].{period:Period,eval:EvaluationPeriods,threshold:Threshold}'Read the alarm you attached. Its period is not a fixed 66 seconds.