Batch GIS rendering can stop if capacity is reclaimed and restart later, and the city wants deep discounts for that flexibility. Which instance model fits?
Select an answer to reveal the explanation.
Short Explanation
Spot capacity is the clearance bin: cheap, but the store might yank the shelf mid-job. Fine for batch GIS that can pause and resume. Keep the always-on crown jewels off that aisle.
Full Explanation
Spot or interruptible instances offer deep discounts in exchange for the provider’s right to reclaim capacity with little notice. Batch GIS rendering that can stop, checkpoint, and restart later is an ideal municipal workload for that trade-off because unfinished tiles or frames can resume when capacity returns without harming interactive citizen services. Mission-critical always-on reserved VMs that must never be interrupted are the wrong model for reclaimable batch and cost more without needing that guarantee. Dedicated hosts purchased solely to guarantee zero preemption for batch frames overspend relative to the flexibility the city is willing to accept. SaaS email mailboxes billed per user do not render GIS tiles and are unrelated to compute pricing for batch rendering fleets. Exam caveat: never place stateful citizen-facing primary systems solely on spot without a highly available on-demand or reserved backbone—Cloud+ expects interruptibility awareness and appropriate workload selection. Operational check: design GIS jobs to checkpoint progress frequently, consider mixed on-demand and spot pools when deadlines are firm, handle interruption notices cleanly, retry safely without corrupting outputs, and compare realized savings against missed batch windows after each large rendering run.