Using Spot Instances with On-Demand Fallback for Batch Processing

A company runs a batch processing job every Saturday for 3 hours. The job can be interrupted and resumed at any point. The SysOps administrator wants to minimize compute costs for this workload. Which EC2 purchasing option should the administrator use?

⚠ Common exam trap

A common mix-up: candidates choose Reserved Instances because the workload runs weekly, but they overlook the fact that Reserved Instances require a long-term commitment and are not cost-effective for a short, interruptible batch job, whereas Spot Instances are specifically designed for such fault-tolerant, transient workloads.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Spot Instances

Spot Instances are ideal for fault-tolerant, interruptible workloads like batch processing that can be resumed. They offer significant cost savings (up to 90% compared to On-Demand) because they use spare EC2 capacity, which can be reclaimed by AWS with a 2-minute interruption notice. Since the job runs only 3 hours weekly and can be interrupted and resumed, Spot Instances minimize compute costs effectively.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
On-Demand Instances
Why it's wrong here
On-Demand Instances are billed per second (or per hour) with no upfront commitment and no volume discounts, making them flexible but costly for workloads that are inherently interruptible. For a 3-hour weekly batch job, you would pay the full on-demand rate for every run, whereas Spot pricing is typically 60–90% cheaper. While on-demand gives you immediate availability and no interruption risk, that operational simplicity is not worth the premium when your job can be stopped and restarted without data loss.
✗
Reserved Instances
Why it's wrong here
Reserved Instances require a 1-year or 3-year commitment and are designed for steady-state, always-on workloads. This batch job runs for only 3 hours out of a 168-hour week, meaning you would pay for the instance capacity during the other 165 hours while it sits idle, effectively making the cost per used hour far higher than On-Demand or Spot. Unless you have other workloads to consistently fill the reservation, committing to a Reserved Instance for this sparse weekly schedule is financially wasteful and lacks the elasticity needed for a short, periodic job.
✓
Spot Instances
Why this is correct
Spot Instances offer access to spare EC2 capacity at discounts of up to 90% off On-Demand prices, which makes them the most cost-effective choice for a batch job that runs for only 3 hours every Saturday. The key trade-off is that Spot capacity can be reclaimed with a 2-minute warning, so the workload must be fault-tolerant—for example, using checkpoints or saving results to S3 and restarting on new Spot capacity. Because the job is batch-oriented and resumable, interruption is not a blocker; you can also use a Spot Fleet with multiple instance types and Availability Zones to improve the odds of maintaining capacity.
✗
Dedicated Hosts
Why it's wrong here
Dedicated Hosts provide a physical server fully dedicated to your use, which is necessary for scenarios involving per-socket or per-core licensing (e.g., Windows Server, SQL Server, or Oracle) or strict compliance and regulatory controls. However, you are charged an hourly fee for the entire host regardless of how many instances you run on it, so running a 3-hour weekly batch job would mean paying for a physical host that stays idle the vast majority of the time. This makes Dedicated Hosts the most expensive option here and completely inappropriate for a short-lived, interruptible batch workload.

Go deeper

Using Spot Instances with On-Demand Fallback for Batch Processing

Why each option matters

Option-by-option breakdown

Related to this question