A GIS processing fleet is packaged as containers and sees bursty CPU demand. The city wants to avoid oversized always-on EC2 fleets. Which compute approach fits?
Select an answer to reveal the explanation.
Short Explanation
Bursty map crunching likes containers that appear when the work appears—Fargate (or similar) scales the package without babysitting fat EC2 boxes 24/7. Laptop cron farms and browser GIS for city batches are not resilient production designs.
Full Explanation
A GIS processing fleet packaged as containers with bursty CPU demand should run on Amazon ECS with AWS Fargate (or a comparable managed container platform such as EKS with appropriate compute). Fargate starts tasks when work arrives and scales capacity with the burst without maintaining oversized always-on EC2 fleets for peak map-processing season. Municipal GIS batches benefit from paying for container capacity during storm damage assessment spikes rather than year-round idle hosts.
Pinning one oversized bare-metal host for every container forever wastes budget and still caps concurrency at that host. Running containers only on developers’ laptops overnight is not production-grade availability or security. Converting all GIS jobs to client-side JavaScript in citizen browsers cannot replace authoritative city batch processing of large geospatial datasets.
Exam caveat: Fargate vs EC2 launch type—pick Fargate when the stem emphasizes avoiding EC2 fleet management for containers. Operational check: define ECS task definitions for GIS workers, autoscale on queue depth or CPU, run a burst test that scales out/in, and confirm no long-lived oversized ASG remains the primary capacity plan.