A citizen portal has steady baseline EC2 demand all year, while a monthly batch job spikes briefly and can tolerate interruption. How should purchasing options be matched?
Select an answer to reveal the explanation.
Short Explanation
The always-on front desk gets a season pass; the once-a-month cleanup crew can take surplus tickets. Savings Plans for the steady portal, Spot for the interruptible batch spike.
Full Explanation
A citizen portal with year-round steady EC2 demand should cover that baseline with Savings Plans or Reserved Instances, while a monthly batch job that spikes briefly and can tolerate interruption belongs on Spot. Matching purchasing options to workload characteristics cuts On-Demand spend for predictable civic front doors without exposing interruptible analytics or cleanup jobs to capacity reclamation risk. Steady portal compute pays for continuity; interruptible batch harvests surplus capacity.
Buying only Spot for the entire portal, including synchronous citizen checkouts, puts latency-sensitive transactions on reclaimable capacity and risks failed payments or form submissions. Running everything as On-Demand with no Savings Plans for the known baseline forgoes documented discount mechanisms SAP-C02 expects architects to apply. Purchasing a three-year dedicated host solely for a one-hour monthly batch over-commits specialty capacity to a tiny window and is rarely cost-efficient versus Spot or short On-Demand bursts.
Exam caveat: separate capacity-type decisions by criticality and interruptibility; do not treat Spot as a universal discount. Operational check: size Savings Plans coverage from trailing baseline utilization for the portal ASG, place the monthly batch on a Spot-friendly queue or Spot ASG with checkpointing, run a Spot interruption drill on batch only, and confirm checkout SLOs never depend on Spot.