Choosing Between ECS Instance Families for a Bursty Batch Workload
A genomics team runs a nightly variant-calling pipeline on Alibaba Cloud. Each job is a short-lived, CPU-heavy batch that runs for 12-25 minutes, all cores busy, then terminates. They currently use general-purpose g7 instances. Monthly cost is dominated by compute, and the team reports that jobs often sit in a queue because a fixed fleet of 20 instances is either idle most of the day or overloaded near the deadline. Peak load is roughly 3x the average. The team wants to cut cost without missing the nightly SLA, and they can tolerate a job being interrupted once and re-run. They are debating: (a) buy a larger fixed fleet of g7, (b) move to compute-optimized c7 with a fixed fleet, (c) use a mixed fleet of pay-as-you-go plus preemptible instances with autoscaling driven by queue depth, or (d) commit to a 1-year subscription for the full peak fleet.
1. Which option best matches the workload characteristics, and why? Address the compute profile and the elasticity pattern.
Read the worked answer
Option (c) is the best fit. The workload is CPU-bound with no meaningful memory or I/O bottleneck, so a compute-optimized family (c7) is a better per-vCPU value than general-purpose g7; that argues for c7 as the instance family regardless of the purchasing model. The demand pattern is bursty (peak ~3x average) and the unit of work is short and independently re-runnable, which is exactly the profile that autoscaling plus preemptible capacity serves well. A fixed fleet (a or b) either wastes money at average load or still needs to be sized for peak. A 1-year subscription for the full peak fleet (d) locks in the worst case and pays for capacity that sits idle most of the day.
Key reasoning: match the instance family to the resource bottleneck (CPU), then match the purchasing model to the demand shape (elastic, interruptible) rather than to the average.
2. The team worries that preemptible instances will cause SLA misses. What design must accompany option (c) to make interruption acceptable, and how does autoscaling policy interact with that?
Read the worked answer
Interruption tolerance must be engineered, not assumed. The pipeline already allows one re-run, so the design should: (1) treat each job as idempotent and checkpoint or restart from the last completed stage; (2) put jobs on a queue and have workers pull, so a reclaimed worker only loses its in-flight job, not the batch; (3) keep a baseline of pay-as-you-go (or subscription) capacity sized to the minimum sustainable throughput, and let preemptible capacity absorb the burst above that baseline; (4) scale on queue depth (backlog per worker) rather than CPU utilization, because CPU is pinned at 100% on healthy workers and would not signal the need to scale.
Autoscaling policy interaction: scale-out should be aggressive and scale-in slow, with a cooldown that exceeds job duration (25 min) so a worker is not removed mid-job. The baseline protects the SLA; preemptible burst protects the cost. If preemptible reclaim rate spikes, the queue-depth signal naturally drives more baseline capacity.