A newly added baggage-tracking microservice at Cascade Regional Airlines receives bursts of requests only when flights are actively boarding, and sits completely idle overnight and between flights. The team wants to avoid paying for idle compute during those quiet periods while still scaling out automatically during boarding bursts. Which compute option best supports scaling down to zero instances during idle periods?

Azure Container Apps supports scaling replicas down to zero when there is no incoming traffic or triggering event, meaning the microservice consumes no compute resources — and incurs no corresponding compute cost — during idle overnight periods, then automatically scales out again in response to HTTP requests or other event-driven triggers such as queue messages when boarding bursts begin. A Virtual Machine Scale Set with a minimum instance count of one guarantees at least one VM is always running, which directly conflicts with the goal of avoiding idle compute cost during quiet periods. Azure Kubernetes Service with a fixed node pool sized for peak traffic keeps that capacity running at all times regardless of actual load, which is the opposite of scaling to zero and would be the most expensive option of those listed for a bursty, mostly-idle workload. App Service with Always On enabled is specifically designed to keep the app loaded and running continuously, which prevents it from idling down and is meant to solve a different problem — cold-start latency — rather than eliminating idle cost. As an operational check, review Container Apps' scale rule configuration to confirm the minimum replica count is set to zero and that the HTTP or event-driven scale trigger correctly detects the start of a boarding-related traffic burst quickly enough to avoid noticeable cold-start delay for the first requests.