A seasonal snow-removal dispatch app is idle most of the year and busy only during storms. Which pricing approach best fits that pattern at fundamentals depth?
Select an answer to reveal the explanation.
Short Explanation
Snow season is short and bursty, not year-long marathon. You shouldn't pay for always-busy capacity when roads are clear most months. You want flexible pay-as-you-go pricing that scales with storm spikes and drops when season ends.
Full Explanation
The snow-removal dispatch app that is idle most of the year and busy only during storms needs pricing flexibility more than year-long peak commitment. The flexible pay-as-you-go style model that can scale with storm spikes without long idle commitments lets capacity and cost rise during storms and fall when roads are clear, aligning OpEx with seasonal reality instead of paying peak rates through quiet months. The flat yearly subscription sized for worst blizzard, with unused storm capacity expiring each period, wastes money on unused committed capacity left running empty. Approaches that allow only CapEx server purchases because seasonal apps cannot use cloud pricing models deny that cloud pricing models exist for bursty loads. The pricing model that requires paying peak capacity fees twelve months in advance with no flexibility describes the opposite of good seasonal fit. Exam caveat: even with pay-as-you-go, leaving oversized VMs running just in case all summer recreates idle waste—elasticity only helps if the city scales in and out (or uses serverless or on-demand patterns) rather than parking peak-sized machines year-round. Operational check: define storm runbook that scales dispatch tier up when weather alerts trigger and scales it down after the event; review Cost Analysis by week through winter versus summer to prove spend tracks storm activity rather than flat reserved peak bill.