A retailer knows a sale will start at 09:00 and that the web tier must already be scaled out before traffic arrives. Last time, an operator edited desired capacity during the rush and was late. What should they configure beforehand?
Select an answer to reveal the explanation.
Short Explanation
If you know the crowd arrives at nine, you open the extra registers before nine. You put that on a scheduled scaling action. A note that says someone will type a new desired capacity at nine is how you were late last time.
Full Explanation
A scheduled action changes desired, minimum, or maximum capacity at a time you set, so the web tier is already larger when the sale starts. That matches a known start and the requirement to be ready before traffic. Editing desired capacity at 09:00 depends on a person during the rush, which already failed. A maximum of one removes the ability to scale out at all. CloudFront can absorb cacheable reads and does not add web-tier instances for the dynamic work the stem says must be scaled out. Caveat: schedule the scale-out early enough for instances to pass health checks, and schedule a scale-in for after the sale so you do not leave the peak size in place. Operational check: confirm the scheduled action's time and capacity in the group, and in a drill watch desired capacity rise before the start time without anyone editing it. Put the action a few minutes before 09:00 so new instances can boot and pass the load balancer health check. A second action after the sale can lower the minimum you raised, or the group will not scale in below that floor. The sale date that moves every month should be a new action or an updated cron, not a person editing desired capacity.