A weekend-only batch fleet renders seasonal flood maps and sits idle most weekdays. The steady GIS API tier runs continuously. How should commitment purchases be applied?
Select an answer to reveal the explanation.
Short Explanation
Commitments are for the lights that stay on—the GIS API—not the weekend flood-map sprinters. RI’ing a fleet that naps all week is paying rent on an empty room.
Full Explanation
Commitment purchases should cover predictable continuous usage, not weekend-only peaks that idle all week. For a steady GIS API tier, Reserved Instances or Savings Plans reduce unit cost on forecastable hours; the seasonal flood-map batch fleet that runs weekends should stay on On-Demand or Spot with interruption-tolerant design rather than long-term capacity reservations sized to peak. That split works because commitment value is utilization of prepaid or discounted hours—idle reserved capacity is wasted municipal money. Buying RIs covering 100% of weekend-only batch peak for three years despite weekday idle time fails by paying rent on empty capacity five days a week. Refusing any Savings Plans for the flat, forecastable GIS API fails conceptually by leaving easy baseline discounts on the table. Committing Dedicated Hosts for every ephemeral batch container task regardless of schedule fails as an oversized, inflexible commitment for short-lived work. Exam caveat: if flood season becomes months-long continuous rendering, revisit commitments—purchase instruments follow measured steadiness, not the original project nickname. Operational check: chart hourly vCPU hours for GIS API vs batch tags over 90 days, set Savings Plan coverage for the API baseline percentile you intend to commit, and keep batch ASG or Spot configuration free of matching long-term reservations.