A planning department runs overnight GIS tile-generation jobs that can restart from checkpoints if a worker stops. Which compute choice best reduces cost?
Select an answer to reveal the explanation.
Short Explanation
GIS overnight jobs that can pick up where they left off are Spot's sweet spot—cheap capacity with the occasional tap on the shoulder. Checkpoint, resume, and stop paying On-Demand rates for batch crunching.
Full Explanation
Amazon EC2 Spot Instances (or Spot via Batch/ECS) with checkpointing is the correct compute choice for overnight GIS tile-generation jobs that can restart if a worker stops, because Spot offers steep discounts on interruptible capacity and checkpoint/resume makes interruptions acceptable. Planning departments commonly run batch cartography overnight where finishing by morning matters more than never being interrupted. On-Demand EC2 only with no Auto Scaling fails because it pays full price for batch capacity and forgoes both Spot savings and elastic scale-out for tile workers. Provisioned DynamoDB capacity for the tile renderer CPUs fails conceptually: DynamoDB is a database service; provisioning its capacity units does not supply CPU for tile rendering compute. AWS Outposts rack capacity reserved exclusively for overnight jobs fails because Outposts targets on-premises/locality requirements at a premium and is not the default cost path for interruptible overnight Regional batch work. Exam caveat: pair Spot with checkpointing for fault-tolerant batch GIS; do not swap in DynamoDB capacity or Outposts as pretend compute discounts. Operational check: implement checkpoints or job restartability; run tile workers on Spot (Batch/ECS/EC2); handle interruption notices; measure overnight completion SLAs; and keep a small On-Demand fallback only if morning deadlines cannot tolerate rare capacity shortfalls.