EC2 Auto Scaling policies: target tracking, step, predictive

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

1. An Auto Scaling group has two target tracking policies: average CPU utilization at 50% and request count per target at 1,000. In the evening, CPU utilization falls to 15% while request count per target stays near 1,000, and the group never scales in. The company must let the group scale in when CPU utilization is low, and must keep the request count policy's scale-out behavior unchanged. Which solution meets these requirements?

   Right. In the game that’s Renown for your Design Resilient Architectures building.

   Not that one: C is right. In the game your Design Resilient Architectures building would lose a little Renown, and this question would come back later.

   Your answerA.Delete the request count policy, and scale the group on the CPU utilization policy alone from then on.Deleting the request count policy removes its scale-out behavior, which the company must keep unchanged.Your answerB.Lower the CPU utilization policy's target value from 50% to 30%, so that the CPU policy asks the group to scale in sooner in the evening.The CPU policy is already ready to scale in. The group scales in only when every policy with scale-in enabled is ready, and the request count policy is not.The answerC.Disable the scale-in portion of the request count policy, so that only the CPU utilization policy decides when the group scales in.Scale-in needs agreement from every policy that is allowed to scale in. The target tracking page says: "It will scale out the Auto Scaling group if any of the target tracking policies are ready to scale out. It will scale in only if all of the target tracking policies (with the scale in portion enabled) are ready to scale in."Your answerD.Raise the request count policy's target value to 2,000, so that the request count policy is ready to scale in during the evening.A higher request count target makes that policy scale out later, which changes the scale-out behavior the company must keep.

   Show the full explanation and doc quotes

   Disabling scale-in on the request count policy takes it out of that vote, so the CPU policy alone decides scale-in, while the request count policy still scales out.

   Written from docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html

2. An application spends most of its twenty-minute startup loading a large reference dataset into memory. The team wants a warm pool that removes that startup from a scale-out event, while paying as little as possible for the instances that are waiting. The instances use an Amazon EBS volume as their root device and meet the hibernation prerequisites. Which approach will meet these requirements?

   Right. In the game that’s Renown for your Design Resilient Architectures building.

   Not that one: B is right. In the game your Design Resilient Architectures building would lose a little Renown, and this question would come back later.

   Your answerA.Keep the warm pool instances in the Running state, so that the reference dataset stays in memory and each instance is ready to serve traffic immediately.Costs the most of the three states. Running instances in a warm pool are "highly discouraged to avoid incurring unnecessary charges", because you pay for the instances themselves.The answerB.Keep the warm pool instances Hibernated, so RAM is saved to the EBS root volume and reloaded on start.Hibernation is the state that keeps the work already done. When an instance is hibernated, "this signals the operating system to save the contents of your RAM to your Amazon EBS root volume. When the instance is started again, the root volume is restored to its previous state and the RAM contents are reloaded." That is exactly the twenty minutes the team wants to skip, because the startup cost here is loading memory rather than writing disk. It is not free - "you pay only for the EBS volumes, including storage for the RAM contents, and the Elastic IP addresses attached to the instances" - but it is far below the price of a Running warm pool, where the instances themselves are billed. Stopped is cheaper still and gives back the startup, which defeats the purpose.Your answerC.Keep the warm pool instances in the Stopped state, and have the application reload the reference dataset each time an instance starts.Cheapest per waiting instance, and it puts the twenty minutes back into the scale-out event, which is what the warm pool was for.Your answerD.Use an Auto Scaling group across three Availability Zones with no warm pool, and raise the desired capacity ahead of expected demand.Over-provisions the group, which is the practice warm pools exist to replace.

   Written from docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html

3. An application in an Auto Scaling group behind a load balancer can enter a state where it answers the load balancer's health path correctly while its background queue worker has died. The team must have the group replace instances in that state, and must not let the load balancer's own checks start failing for healthy instances. Which approach will meet these requirements?

   Right. In the game that’s Renown for your Design Resilient Architectures building.

   Not that one: C is right. In the game your Design Resilient Architectures building would lose a little Renown, and this question would come back later.

   Your answerA.Raise the Auto Scaling group's desired capacity so that a dead worker on one instance is covered by the others.Leaves the broken instances in service and pays for more capacity around them, so the queue backlog keeps growing on the dead worker.Your answerB.Change the load balancer's health path so that it also exercises the queue worker and fails whenever that worker is dead.Is the near miss and it works, at a cost the stem rules out: a health path that exercises the worker makes the load balancer take the instance out of service on any worker blip.The answerC.Use a custom health check that calls SetInstanceHealth when the worker dies, and leave the load balancer's health path as it is.Both C and B get the group to replace an instance whose worker has died, and the deciding behaviour is which layer acts on the signal.Your answerD.Replace the Auto Scaling group with a scheduled instance refresh that rebuilds every instance in the group nightly.Bounds how long a failure can persist to one day, which is not replacement on failure, and rebuilds healthy instances to catch broken ones.

   Show the full explanation and doc quotes

   AWS lists "custom health checks that you define" among the notification sources, alongside Amazon EC2, Elastic Load Balancing, VPC Lattice and Amazon EBS, and states the consequence: "When Amazon EC2 Auto Scaling determines that an InService instance is unhealthy, it replaces it with a new instance to maintain the desired capacity of the group." A custom check reports unhealthy directly to the group, so replacement happens without changing what the load balancer measures. Folding the worker into the load balancer's health path couples two decisions - who gets traffic, and who exists - so a transient worker failure also drains the instance.

   Written from docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-health-checks.html