[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"prev-aws-certified-cloudops-engineer-associate-reliability-business-continuity-scaling-compute-workloads-ec2-auto-scaling-groups-en":4,"lesson-aws-certified-cloudops-engineer-associate-reliability-business-continuity-scaling-compute-workloads-ec2-auto-scaling-groups-en":19,"next-aws-certified-cloudops-engineer-associate-reliability-business-continuity-scaling-compute-workloads-ec2-auto-scaling-groups-en":816},null,{"locked":5,"reason":6,"meta":7,"item":3},true,"paywall",{"title":8,"description":9,"isFree":10,"estimatedMinutes":11,"difficulty":12,"learningObjectives":13},"Route 53 Health Checks and DNS Failover","How Route 53 decides an endpoint is healthy, why alias records use Evaluate Target Health instead of a health check, and how failover routing and zonal shift move traffic away from a failure the load balancer cannot see.",false,26,"intermediate",[14,15,16,17,18],"Explain how Route 53 aggregates its global health checkers into a single healthy or unhealthy verdict","Choose between an endpoint, calculated, and CloudWatch alarm health check for a given resource","Configure active-passive and active-active failover, and explain when to use Evaluate Target Health instead of a health check","Predict the effect of inverting or disabling a health check","Use zonal shift to move traffic away from an impaired Availability Zone",{"locked":10,"reason":3,"meta":20,"item":29},{"title":21,"description":22,"isFree":5,"estimatedMinutes":11,"difficulty":12,"learningObjectives":23},"EC2 Auto Scaling Groups","How an Auto Scaling group holds a fleet at the size you asked for: the three capacity numbers, the health checks that decide what gets replaced, zonal balance, and the rules that pick which instance dies on scale in.",[24,25,26,27,28],"Explain how minimum, desired, and maximum capacity interact, and which one a scaling policy actually changes","Identify the health check sources an Auto Scaling group uses and configure the grace period so slow-booting instances survive startup","Predict how an Auto Scaling group distributes and rebalances instances across Availability Zones","Trace the default termination policy to the specific instance it would terminate","State what instance scale-in protection prevents and what it does not prevent",{"id":30,"title":21,"body":31,"description":22,"difficulty":12,"estimatedMinutes":11,"extension":731,"infographics":732,"isFree":5,"learningObjectives":746,"meta":747,"navigation":5,"path":748,"quiz":749,"seo":813,"stem":814,"__hash__":815},"courses/courses/aws-certified-cloudops-engineer-associate/en/domains/02-reliability-business-continuity/02-scaling-compute-workloads/01-ec2-auto-scaling-groups.md",{"type":32,"value":33,"toc":721},"minimark",[34,38,41,46,49,72,77,80,87,90,94,101,104,111,115,123,205,212,274,281,284,299,309,312,319,323,334,355,362,369,373,380,395,398,401,404,512,515,519,526,529,549,556,563,567,570,674,687,691,714,717],[35,36,37],"p",{},"A media company runs 12 EC2 instances behind an Application Load Balancer. Peak traffic arrives for about 3 hours on weekday evenings. The rest of the week, 3 instances would carry the load with room to spare, but the fleet stays at 12 because nobody wants to be the person who shrank it the week before a launch. Then on a Saturday one instance fills its disk, stops answering, and sits there dead until Monday morning because no health check was wired to anything that could act.",[35,39,40],{},"Those are 2 different failures, and an Auto Scaling group fixes both with the same mechanism. It is a group of EC2 instances that AWS keeps at a size you declare, launching and terminating instances to hold that size, and replacing any instance that stops looking healthy. The scaling policies that make the size move come in the next lesson. This one covers the machinery underneath them, because almost every scaling question that goes wrong in production goes wrong here, not in the policy.",[42,43,45],"h2",{"id":44},"three-numbers-and-a-policy-only-moves-one-of-them","Three numbers, and a policy only moves one of them",[35,47,48],{},"An Auto Scaling group is defined by 3 capacity values.",[50,51,52,60,66],"ul",{},[53,54,55,59],"li",{},[56,57,58],"strong",{},"Minimum capacity"," is a floor. The group never runs fewer instances than this.",[53,61,62,65],{},[56,63,64],{},"Maximum capacity"," is a ceiling. The group never runs more.",[53,67,68,71],{},[56,69,70],{},"Desired capacity"," is the number the group is actually trying to run right now.",[73,74],"infographic",{"alt":75,"slug":76},"A vertical capacity band with minimum capacity as a floor, maximum capacity as a ceiling, and desired capacity as a marker that scaling policies move between them.","asg-capacity-band",[35,78,79],{},"Say you set minimum 2, desired 6, maximum 12. The group launches 6 instances. If a scaling policy later calculates that 15 instances are needed to hold CPU at target, the group goes to 12 and stops, because 15 is above the ceiling. If a scale-in calculation says 1 instance is enough, the group goes to 2 and stops.",[35,81,82,83,86],{},"The sentence worth memorizing: ",[56,84,85],{},"a scaling policy changes desired capacity, and only desired capacity."," Minimum and maximum are clamps that constrain the result. This is where a common misreading lives. Setting maximum capacity to 12 does not mean the group runs 12 instances. It means the group will never run more than 12. A group sitting at its maximum because desired capacity was raised there is a completely different situation from a group sitting at 6 with headroom to 12, and the exam likes stems where the group has already hit its ceiling and the scaling policy appears broken.",[35,88,89],{},"There is also value in a group with no scaling policy at all. With desired capacity fixed at 6, the group still watches those 6 instances and replaces any that fail a health check. Maintaining capacity and scaling capacity are separate features, and the first one is the reason a group is worth creating even for a fleet whose size never changes.",[42,91,93],{"id":92},"the-launch-template-is-the-blueprint","The launch template is the blueprint",[35,95,96,97,100],{},"The group needs to know what to launch. That comes from a ",[56,98,99],{},"launch template",": AMI ID, instance type, key pair, security groups, IAM instance profile, block device mappings, user data, and the rest of the EC2 launch surface.",[35,102,103],{},"Launch templates are versioned. You create version 3 with a new AMI, point the group at it, and every instance launched from that moment uses version 3 while the existing instances keep running whatever they launched with. That version history is what makes the default termination policy and instance refresh work, and both show up later.",[35,105,106,107,110],{},"The older ",[56,108,109],{},"launch configuration"," still exists in old material and old accounts. It is not versioned, it cannot be edited (you replace it), and AWS does not extend it to new EC2 features. Treat \"migrate the group from a launch configuration to a launch template\" as the expected answer whenever a scenario mentions Spot and On-Demand in one group, multiple instance types, or an instance refresh, because none of those work with a launch configuration.",[42,112,114],{"id":113},"health-checks-decide-what-gets-replaced","Health checks decide what gets replaced",[35,116,117,118,122],{},"An instance in an Auto Scaling group starts as ",[119,120,121],"code",{},"Healthy",", and stays that way until something tells the group otherwise. The group listens to several sources:",[124,125,126,142],"table",{},[127,128,129],"thead",{},[130,131,132,136,139],"tr",{},[133,134,135],"th",{},"Source",[133,137,138],{},"What it reports",[133,140,141],{},"On by default",[143,144,145,160,171,181,191],"tbody",{},[130,146,147,151,157],{},[148,149,150],"td",{},"Amazon EC2 status checks",[148,152,153,154],{},"System and instance status check failures, and any state other than ",[119,155,156],{},"running",[148,158,159],{},"Yes",[130,161,162,165,168],{},[148,163,164],{},"Elastic Load Balancing",[148,166,167],{},"The target's health in the attached target group",[148,169,170],{},"No, you enable it",[130,172,173,176,179],{},[148,174,175],{},"VPC Lattice",[148,177,178],{},"Target health for a Lattice target group",[148,180,170],{},[130,182,183,186,189],{},[148,184,185],{},"Amazon EBS",[148,187,188],{},"An attached volume is impaired",[148,190,170],{},[130,192,193,196,202],{},[148,194,195],{},"Custom",[148,197,198,199],{},"Whatever your own code reports with ",[119,200,201],{},"set-instance-health",[148,203,204],{},"Your code calls it",[35,206,207,208,211],{},"That table hides the single most common misconfiguration in this topic, so say it out loud. ",[56,209,210],{},"By default an Auto Scaling group only uses EC2 status checks."," An instance whose application is returning HTTP 500 to every request still passes EC2 status checks, because the hypervisor is fine and the operating system is running. The ALB will notice, mark the target unhealthy, and stop sending it traffic. The Auto Scaling group will not replace it, and you end up with a group reporting 6 healthy instances behind a target group reporting 5 healthy targets, indefinitely. Turning on the Elastic Load Balancing health check for the group is what closes that gap.",[213,214,219],"pre",{"className":215,"code":216,"language":217,"meta":218,"style":218},"language-bash shiki shiki-themes material-theme-lighter github-light github-dark","aws autoscaling update-auto-scaling-group \\\n  --auto-scaling-group-name web-asg \\\n  --health-check-type ELB \\\n  --health-check-grace-period 300\n","bash","",[119,220,221,241,253,264],{"__ignoreMap":218},[222,223,226,230,234,237],"span",{"class":224,"line":225},"line",1,[222,227,229],{"class":228},"sbgvK","aws",[222,231,233],{"class":232},"s_sjI"," autoscaling",[222,235,236],{"class":232}," update-auto-scaling-group",[222,238,240],{"class":239},"s_hVV"," \\\n",[222,242,244,248,251],{"class":224,"line":243},2,[222,245,247],{"class":246},"stzsN","  --auto-scaling-group-name",[222,249,250],{"class":232}," web-asg",[222,252,240],{"class":239},[222,254,256,259,262],{"class":224,"line":255},3,[222,257,258],{"class":246},"  --health-check-type",[222,260,261],{"class":232}," ELB",[222,263,240],{"class":239},[222,265,267,270],{"class":224,"line":266},4,[222,268,269],{"class":246},"  --health-check-grace-period",[222,271,273],{"class":272},"srdBf"," 300\n",[35,275,276,277,280],{},"The ",[56,278,279],{},"health check grace period"," in that command is the second thing to get right. It is the minimum time a newly in-service instance is left alone before an unhealthy verdict can terminate it. Elastic Load Balancing health checks start as soon as the instance is registered, so an application that needs 4 minutes to warm caches would fail its first several checks and be killed for it. The grace period buys that time.",[35,282,283],{},"The defaults are not the same everywhere, and this is a real trap:",[50,285,286,292],{},[53,287,288,289],{},"Console: ",[56,290,291],{},"300 seconds",[53,293,294,295,298],{},"AWS CLI or SDK: ",[56,296,297],{},"0 seconds",", which turns the grace period off entirely",[35,300,301,302,304,305,308],{},"A group created by a CloudFormation template or a CLI script with no explicit grace period will therefore judge instances from the first second, and a slow-booting fleet can land in a loop where every replacement is killed before it finishes booting. One exception applies during the grace period: if the instance leaves the EC2 ",[119,303,156],{}," state, for example because someone stopped it, the group marks it ",[119,306,307],{},"Unhealthy"," and replaces it immediately without waiting.",[35,310,311],{},"Do not solve the problem by pushing the grace period to an hour. A high grace period is dead time in which a genuinely broken instance stays in service. The better fix, covered in the lifecycle lesson, is a launch lifecycle hook that keeps the instance out of service until its bootstrap finishes, which lets you set the grace period low.",[35,313,314,315,318],{},"Two more behaviors worth holding: health check replacement does ",[56,316,317],{},"not"," wait for a cooldown period, and an instance the group has already marked unhealthy skips termination policy evaluation entirely. Unhealthy instances are not chosen, they are simply removed.",[42,320,322],{"id":321},"zonal-balance-comes-before-everything-else","Zonal balance comes before everything else",[35,324,325,326,329,330,333],{},"You give the group subnets, and each subnet lives in exactly one Availability Zone. When the group launches an instance, it picks the enabled zone with the ",[56,327,328],{},"fewest"," instances, and inside that zone the subnet with the most free IP addresses. When it terminates, it looks first at the zone with the ",[56,331,332],{},"most"," instances.",[35,335,336,337,340,341,344,345,348,349,351,352,354],{},"That ordering matters more than it looks. Zonal balance is evaluated ",[56,338,339],{},"before"," the termination policy, always. So a group with 5 instances in ",[119,342,343],{},"us-east-1a"," and 3 in ",[119,346,347],{},"us-east-1b"," will terminate from ",[119,350,343],{}," even if the single oldest instance in the group is sitting in ",[119,353,347],{},". When a scenario says \"the newest instance was terminated and we do not understand why\", zonal imbalance is usually the answer.",[35,356,357,358,361],{},"Groups drift out of balance for ordinary reasons: a zone ran out of capacity for a while and recovered, you changed the enabled zones, you put instances in standby, or a Spot price dropped back under your maximum in a zone that had been priced out. When that happens the group runs an ",[56,359,360],{},"Availability Zone rebalancing"," activity. It launches the new instance first and terminates the old one afterward, so rebalancing never dips your capacity.",[35,363,364,365,368],{},"Launching before terminating creates an obvious problem when the group is already at maximum capacity, and AWS solved it with a documented exception: during a rebalancing activity the group may temporarily exceed maximum capacity by ",[56,366,367],{},"10 percent or one instance, whichever is greater",". The margin lasts only as long as the rebalance, usually a few minutes. If you cannot tolerate even that overshoot, an instance maintenance policy lets you set the healthy percentage range instead.",[42,370,372],{"id":371},"which-instance-dies-on-scale-in","Which instance dies on scale in",[35,374,375,376,379],{},"Once the zone is chosen, the ",[56,377,378],{},"default termination policy"," works through unprotected instances in this order:",[381,382,383,389],"ol",{},[53,384,385,388],{},[56,386,387],{},"Outdated configurations first."," For a group on launch templates, that means instances launched from a launch configuration, then instances launched from a different launch template, then instances on the oldest version of the current launch template.",[53,390,391,394],{},[56,392,393],{},"Closest to the next billing hour."," If several candidates remain, the group picks the one nearest its next billing hour, and breaks a tie at random. This step matters far less than it used to, since most EC2 usage bills per second.",[35,396,397],{},"The design goal is to retire stale configurations naturally as the group scales in, which is why a group that scales up and down through the day slowly converges on the current launch template version without anyone doing anything.",[35,399,400],{},"Mixed instances groups add one step in front. The group first decides whether a Spot or an On-Demand Instance should go, so the fleet trends back toward the ratio you configured, then it checks whether terminating a particular instance improves alignment with your allocation strategy, and only then falls through to outdated configurations and billing hour.",[35,402,403],{},"You can override the policy when the default is wrong for your case:",[124,405,406,419],{},[127,407,408],{},[130,409,410,413,416],{},[133,411,412],{},"Policy",[133,414,415],{},"Terminates",[133,417,418],{},"Use it when",[143,420,421,434,447,460,473,486,499],{},[130,422,423,428,431],{},[148,424,425],{},[119,426,427],{},"Default",[148,429,430],{},"Outdated configuration, then closest to next billing hour",[148,432,433],{},"Almost always",[130,435,436,441,444],{},[148,437,438],{},[119,439,440],{},"OldestInstance",[148,442,443],{},"The longest-running instance",[148,445,446],{},"Rolling the fleet onto a new instance type",[130,448,449,454,457],{},[148,450,451],{},[119,452,453],{},"NewestInstance",[148,455,456],{},"The most recently launched instance",[148,458,459],{},"Testing a new configuration you want rolled back first",[130,461,462,467,470],{},[148,463,464],{},[119,465,466],{},"OldestLaunchTemplate",[148,468,469],{},"Noncurrent templates first, then oldest version",[148,471,472],{},"Phasing out a previous configuration",[130,474,475,480,483],{},[148,476,477],{},[119,478,479],{},"OldestLaunchConfiguration",[148,481,482],{},"The oldest launch configuration",[148,484,485],{},"Migrating off launch configurations",[130,487,488,493,496],{},[148,489,490],{},[119,491,492],{},"ClosestToNextInstanceHour",[148,494,495],{},"Nearest the billing hour boundary",[148,497,498],{},"Hourly-billed instances only",[130,500,501,506,509],{},[148,502,503],{},[119,504,505],{},"AllocationStrategy",[148,507,508],{},"Instances that pull the fleet away from your allocation strategy",[148,510,511],{},"Spot pools or On-Demand priorities changed",[35,513,514],{},"Whatever you choose, zonal balance still wins first. A termination policy only decides which instance inside the selected zone goes.",[42,516,518],{"id":517},"protecting-an-instance-from-scale-in-and-what-that-does-not-buy-you","Protecting an instance from scale in, and what that does not buy you",[35,520,521,522,525],{},"Some instances should not be chosen. A container host mid-job, a build agent 40 minutes into a compile, a node holding a long-running session. ",[56,523,524],{},"Instance scale-in protection"," marks an instance as ineligible for termination by a scale-in event. You can set it on the group so every new instance inherits it, then clear it per instance when the work finishes, which is the pattern container schedulers use.",[35,527,528],{},"The important half of this feature is what it does not do. Scale-in protection does not prevent:",[50,530,531,534,537,540,546],{},[53,532,533],{},"Replacement after a failed health check",[53,535,536],{},"A Spot Instance interruption",[53,538,539],{},"The end of a Capacity Block reservation",[53,541,542,543],{},"Manual termination through ",[119,544,545],{},"terminate-instance-in-auto-scaling-group",[53,547,548],{},"Manual termination from the EC2 console, CLI, or API",[35,550,551,552,555],{},"That last one surprises people. To stop a human from terminating the instance in the EC2 console you need ",[56,553,554],{},"EC2 termination protection",", a separate setting on the instance itself. The two names sound like the same feature and are not.",[35,557,558,559,562],{},"One edge case shows up in real incidents: if every instance in the group is protected and a scale-in event fires, the group decrements desired capacity but cannot terminate anything. The activity history records ",[119,560,561],{},"Could not scale to desired capacity because all remaining instances are protected from scale in",", and the group quietly runs above its own desired capacity until protection is cleared somewhere.",[42,564,566],{"id":565},"turning-parts-of-the-group-off-while-you-work","Turning parts of the group off while you work",[35,568,569],{},"When you need the group to stop acting for a while, suspend individual processes rather than deleting policies:",[124,571,572,582],{},[127,573,574],{},[130,575,576,579],{},[133,577,578],{},"Process",[133,580,581],{},"Suspending it stops",[143,583,584,594,604,614,624,634,644,654,664],{},[130,585,586,591],{},[148,587,588],{},[119,589,590],{},"Launch",[148,592,593],{},"Adding instances for any reason, including warm pool fills",[130,595,596,601],{},[148,597,598],{},[119,599,600],{},"Terminate",[148,602,603],{},"Removing instances for any reason",[130,605,606,611],{},[148,607,608],{},[119,609,610],{},"AddToLoadBalancer",[148,612,613],{},"Registering new instances with the target group",[130,615,616,621],{},[148,617,618],{},[119,619,620],{},"AlarmNotification",[148,622,623],{},"Dynamic scaling policies reacting to their CloudWatch alarms",[130,625,626,631],{},[148,627,628],{},[119,629,630],{},"AZRebalance",[148,632,633],{},"Rebalancing across Availability Zones",[130,635,636,641],{},[148,637,638],{},[119,639,640],{},"HealthCheck",[148,642,643],{},"Marking instances unhealthy from EC2 or ELB signals",[130,645,646,651],{},[148,647,648],{},[119,649,650],{},"ReplaceUnhealthy",[148,652,653],{},"Terminating and replacing already-unhealthy instances",[130,655,656,661],{},[148,657,658],{},[119,659,660],{},"InstanceRefresh",[148,662,663],{},"Instance refresh replacements",[130,665,666,671],{},[148,667,668],{},[119,669,670],{},"ScheduledActions",[148,672,673],{},"Scheduled scaling",[35,675,676,677,679,680,682,683,686],{},"Picking the right one is a diagnosis question. Suspending ",[119,678,590],{}," stops the churn but also blocks a scheduled scale-out you may still want; suspending ",[119,681,650],{}," stops only the replacement loop. And if a group has been failing to launch instances for more than about 24 hours, AWS applies an ",[56,684,685],{},"administrative suspension"," on its own. When someone reports that a group \"just stopped working\", check for suspended processes before checking the policy.",[42,688,690],{"id":689},"exam-tips","Exam tips",[50,692,693,696,699,702,705,708,711],{},[53,694,695],{},"A scenario where the group refuses to grow and the policy looks correct is a maximum capacity question. Read the 3 numbers before reading the policy.",[53,697,698],{},"\"The load balancer shows the target unhealthy but the instance is never replaced\" is always the health check type. The group defaults to EC2 status checks only.",[53,700,701],{},"\"Instances are terminated and relaunched in a loop right after launch\" is the health check grace period, and the give-away is a group created by CLI or CloudFormation, where the default is 0 rather than the console's 300.",[53,703,704],{},"Do not mix up the 2 timers. Health check grace period is how long before health checks can kill a new instance. Default cooldown, 300 seconds, is a pause between simple scaling activities and belongs to the next lesson.",[53,706,707],{},"\"A newer instance was terminated before an older one\" means the zones were unbalanced. Zonal balance outranks the termination policy.",[53,709,710],{},"Anything about Spot plus On-Demand in one group, multiple instance types, or instance refresh rules out launch configurations. The answer needs a launch template.",[53,712,713],{},"Scale-in protection blocks scale-in only. If the stem says health check, Spot interruption, or a person clicking Terminate in the console, protection is the wrong answer.",[35,715,716],{},"The model to carry into the next lesson is narrow and load-bearing: the group has one dial it moves, desired capacity, and a set of rules for how instances get created, judged, and chosen for removal around it. Everything that follows, target tracking, step scaling, predictive scaling, is a different way of deciding what that one number should be.",[718,719,720],"style",{},"html pre.shiki code .sbgvK, html code.shiki .sbgvK{--shiki-light:#E2931D;--shiki-default:#6F42C1;--shiki-dark:#B392F0}html pre.shiki code .s_sjI, html code.shiki .s_sjI{--shiki-light:#91B859;--shiki-default:#032F62;--shiki-dark:#9ECBFF}html pre.shiki code .s_hVV, html code.shiki .s_hVV{--shiki-light:#90A4AE;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .stzsN, html code.shiki .stzsN{--shiki-light:#91B859;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .srdBf, html code.shiki .srdBf{--shiki-light:#F76D47;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":218,"searchDepth":255,"depth":255,"links":722},[723,724,725,726,727,728,729,730],{"id":44,"depth":243,"text":45},{"id":92,"depth":243,"text":93},{"id":113,"depth":243,"text":114},{"id":321,"depth":243,"text":322},{"id":371,"depth":243,"text":372},{"id":517,"depth":243,"text":518},{"id":565,"depth":243,"text":566},{"id":689,"depth":243,"text":690},"md",[733],{"slug":76,"concept":734,"style":735,"aspectRatio":736,"labels":737},"A single vertical capacity axis showing the three Auto Scaling group numbers as a band. A solid floor line at the bottom marks minimum capacity and a solid ceiling line at the top marks maximum capacity, drawn as hard walls. Between them, a moving marker labeled desired capacity sits at the current value, with two arrows pushing it up and down labeled as the scaling policy. Arrows that reach the floor or the ceiling are drawn stopping dead against the wall, and a footer strip carries the rule that policies move only the middle number.","diagram","4:3",[738,739,740,741,742,743,744,745],"Maximum capacity: 12, a hard ceiling the group never crosses","Desired capacity: 6, the number the group is trying to run right now","Minimum capacity: 2, a hard floor the group never drops below","Scale out: policy raises desired capacity","Scale in: policy lowers desired capacity","Request for 15 is clamped to 12","Request for 1 is clamped to 2","A scaling policy changes only desired capacity. Minimum and maximum are clamps, not targets.",[24,25,26,27,28],{},"/courses/aws-certified-cloudops-engineer-associate/en/domains/02-reliability-business-continuity/02-scaling-compute-workloads/01-ec2-auto-scaling-groups",{"passingScore":750,"questions":751},70,[752,761,769,779,787,793,801,809],{"question":753,"type":754,"options":755,"correctAnswer":757,"explanation":760},"An Auto Scaling group has a minimum capacity of 2, a desired capacity of 6, and a maximum capacity of 12. A target tracking policy calculates that 15 instances are needed to hold the metric at target. What does the group run?","single",[756,757,758,759],"15 instances, because the policy overrides the maximum during a scale-out event","12 instances, because the scaling policy cannot raise desired capacity above the maximum","6 instances, because the desired capacity was set manually and a policy cannot change it","13 instances, because the group is allowed a 10% margin above the maximum","A scaling policy changes desired capacity, and desired capacity is clamped to the minimum and maximum you set. The 10% margin is real but it only applies to Availability Zone rebalancing, not to scaling policies, so it does not raise the ceiling here.",{"question":762,"type":754,"options":763,"correctAnswer":766,"explanation":768},"An Auto Scaling group is attached to an ALB target group. A running instance starts returning HTTP 500 to every request and the ALB marks its target unhealthy. The Auto Scaling group leaves the instance running for hours. What is the most likely cause?",[764,765,766,767],"The instance is protected from scale in","The health check grace period has not expired","The group's health check type is EC2 only, so it never reads the load balancer's verdict","The ALB deregistration delay has not expired","By default an Auto Scaling group only uses EC2 status checks, which pass because the instance is running and reachable. You have to turn on the Elastic Load Balancing health check for the group before a failing target is treated as an unhealthy instance. Scale-in protection would not help here anyway, because it does not block health check replacement.",{"question":770,"type":771,"options":772,"correctAnswers":777,"explanation":778},"Which statements about instance scale-in protection are correct? (Choose 2.)","multiple",[773,774,775,776],"It prevents an instance from being terminated by a scale-in event","It prevents an instance from being replaced after it fails a health check","It does not prevent a Spot Instance from being interrupted and terminated","It prevents manual termination from the EC2 console",[773,775],"Scale-in protection covers exactly one thing, termination chosen by a scale-in event. Health check replacement, Spot interruption, the end of a Capacity Block, and manual termination all still terminate the instance. To block manual termination from the EC2 console you need EC2 termination protection, which is a different setting.",{"question":780,"type":754,"options":781,"correctAnswer":784,"explanation":786},"An Auto Scaling group spans us-east-1a with 5 instances and us-east-1b with 3 instances. A scale-in event removes one instance. Where does the group look first?",[782,783,784,785],"Whichever zone holds the instance with the oldest launch template version, regardless of zone","us-east-1b, so the smaller zone is drained first","us-east-1a, because zonal balance is evaluated before the termination policy","Both zones equally, using a random choice","Keeping the zones balanced takes precedence over every termination policy. The group first picks the zone with the most instances that still has at least one unprotected instance, and only then applies the termination policy inside that zone. This is why you sometimes see a newer instance terminated before an older one.",{"question":788,"type":754,"options":789,"correctAnswer":790,"explanation":792},"True or False: an Auto Scaling group with no scaling policies attached still provides value.",[790,791],"True","False","Maintaining a fixed number of instances is core Auto Scaling group behavior and is independent of scaling policies. Even with a static desired capacity, the group replaces instances that fail health checks and rebalances across Availability Zones, which is self-healing you do not get from standalone instances.",{"question":794,"type":754,"options":795,"correctAnswer":797,"explanation":800},"Your instances take about 4 minutes to boot and register with an ALB. The group is created with the AWS CLI and instances are being terminated and relaunched in a loop shortly after launch. Which setting most likely needs changing?",[796,797,798,799],"The default cooldown, which defaults to 0 seconds in the CLI","The health check grace period, which defaults to 0 seconds in the CLI","The deregistration delay on the target group","The termination policy, which is choosing new instances first","The console sets a 300-second health check grace period, but create-auto-scaling-group defaults it to 0, which means health checks start judging the instance immediately. A booting instance fails the ELB check, gets replaced, and the replacement repeats the cycle. The default cooldown is 300 seconds, not 0, and it governs simple scaling policies rather than health check replacement.",{"question":802,"type":754,"options":803,"correctAnswer":806,"explanation":808},"In the default termination policy for a group using launch templates, which instance is evaluated first once the Availability Zone has been chosen?",[804,805,806,807],"The instance closest to its next billing hour","The newest instance in the zone","An unprotected instance that was launched with a launch configuration","The instance with the highest CPU utilization","The default policy removes outdated configurations first, in a fixed order: launch configuration, then a different launch template, then the oldest version of the current launch template. Only when that produces no single candidate does it fall through to the next billing hour tie-breaker.",{"question":810,"type":754,"options":811,"correctAnswer":650,"explanation":812},"Which Auto Scaling process would you suspend to stop the group from replacing instances while you troubleshoot a fleet-wide application bug, without stopping scheduled scaling?",[650,620,630,590],"ReplaceUnhealthy is the process that terminates instances marked unhealthy and launches replacements, so suspending it stops the churn while leaving scheduled actions and scaling policies alone. Suspending Launch would also block scale-out and scheduled growth, and AlarmNotification would silence dynamic scaling instead.",{"title":21,"description":22},"courses/aws-certified-cloudops-engineer-associate/en/domains/02-reliability-business-continuity/02-scaling-compute-workloads/01-ec2-auto-scaling-groups","esEtMPiyNkrnY-m3j7R5BVRWpsfiKemycsTAhvir5j8",{"locked":5,"reason":6,"meta":817,"item":3},{"title":818,"description":819,"isFree":10,"estimatedMinutes":820,"difficulty":12,"learningObjectives":821},"Scaling Policies in Depth","Target tracking, step, simple, scheduled, and predictive scaling: what each one decides, the cooldown and warmup timers that hold them back, and how AWS resolves several policies pointing at the same group.",28,[822,823,824,825,826],"Select the right scaling policy type for a given demand pattern and constraint","Explain how a target tracking policy converts a metric into a desired capacity, and which metrics it cannot use","Build a step scaling policy from step adjustments and predict the resulting capacity changes","Distinguish a cooldown period from an instance warmup and state which policy types use each","Describe what predictive scaling forecasts, what it will and will not do, and how it combines with dynamic scaling"]