Reserved vs Spot vs On-Demand: A Compute Purchase Decision

Compare AWS compute purchase options using dated quotes, hourly demand, commitment break-even and tested interruption recovery instead of headline discounts.

trigger="A compute commitment is approaching renewal, demand has changed, or a workload may tolerate interruptible capacity." owner="The platform owner validates workload behavior; the finance approver owns any purchase commitment." participants={["Service owner", "Platform engineer", "FinOps owner", "Finance approver", "On-call operator"]} prerequisites={["Hourly billed usage with existing discount coverage", "A rightsizing and migration forecast", "Dated quotes for the exact region and configuration", "Workload recovery objectives and an interruption test environment"]} outputs={["Comparable cost scenarios and break-even assumptions", "A workload-to-purchase-option decision record", "Spot interruption and reconciliation evidence", "An approved purchase or explicit decision to defer"]} doneWhen={["The downside demand scenario is affordable", "A discount is not mistaken for a capacity guarantee", "Interruptible work survives loss without relying on a warning", "The purchase amount, term and approver are recorded"]} />

Separate the financial commitment from the operating model

A discounted compute rate can increase total spend if the team commits to capacity it no longer needs. Cheap interruptible capacity can also become expensive when lost work, retries and missed deadlines are included. Compare the complete workload outcome.

This playbook focuses on AWS EC2 purchasing and relevant compute Savings Plans. It does not quote current prices or cover every AWS discount program. Capture live account-specific terms before a purchase. The worked numbers below are invented solely to explain the arithmetic, not vendor prices or expected savings.

Choose the resource shape with the rightsizing playbook first where practical. Then decide which portion of the resulting demand is stable enough to commit and which workload can tolerate interruption.

1. Classify the workload before comparing rates

The service owner documents demand, deadline, state and recovery behavior. Separate a continuously required API floor from an elastic background queue, even if both currently run in the same cluster.

| Option | Decision it addresses | Condition to verify | |---|---|---| | On-Demand | Avoid a long-term usage commitment | Required capacity is available; quotas and recovery plans are sufficient | | Savings Plans | Commit to eligible hourly spend for a term | Usage remains eligible and consumes the commitment during each hour | | EC2 Reserved Instances | Commit against matching instance attributes | Scope, flexibility, offering class and billing match the forecast | | Spot | Accept interruption in exchange for variable capacity economics | Work survives loss, replacement delays and repeated execution |

Savings Plans require a one- or three-year commitment. “No upfront” changes payment timing, not the existence of a term obligation. If the organization cannot accept a term commitment, a Savings Plan is not the alternative. See the AWS Savings Plans overview.

Keep the capacity decision separate. A regional EC2 Reserved Instance does not reserve capacity; a zonal Reserved Instance reserves capacity in its specified Availability Zone under its matching rules. Verify those rules in AWS's scope documentation. Do not infer recovery-region availability from a billing discount.

Gate: the service owner identifies which work can be delayed, restarted or degraded and which cannot. “Stateless” alone does not prove interruption tolerance: an in-memory queue, a long request or a non-idempotent external call can still lose work.

2. Build an hourly baseline after existing coverage

The FinOps owner exports billed usage and joins it to workload ownership. Keep quantity, effective rate, region, instance attributes, account and existing coverage. Review representative business cycles, deployment changes, scheduled jobs and expected growth. The observation period must cover the workload's behavior; there is no universal number of days that makes a forecast safe.

CPU utilization is a sizing signal, not the amount of eligible hourly spend. A low-CPU instance can still incur a full compute charge. Rightsizing, shutdown schedules and migrations change future eligible usage, so model them before adding a new commitment.

AWS applies relevant Reserved Instance benefits before Savings Plans. Sharing settings and plan eligibility affect where a commitment is consumed. An unused portion of an hourly Savings Plans commitment does not roll into the next hour. Model coverage using the documented application rules, not a monthly average alone.

Produce three forecasts: expected demand, a downside case with lower eligible usage, and a change case with a planned architecture or region shift. State who owns each assumption. A recommendation generated from historical usage is an input to this analysis, not purchase approval.

3. Compare like-for-like costs

Use one currency, tax treatment, period and scope. Record whether a value is cash paid, amortized cost or an allocated internal charge. Avoid adding an upfront payment and its amortized equivalent to the same total.

Scenario cost =
  upfront payment
  + recurring commitment charges across the term
  + usage not covered by the commitment
  + other workload charges
  + incremental operating and recovery cost

Other workload charges may include:
  storage, requests, data transfer, load balancing, licenses and support

Use the current quote for each exact configuration. Different operating systems, tenancy, regions, contract discounts and payment options may change the result. Compare the same accepted throughput and reliability, not merely the same instance count.

For a simplified single-unit commitment, define:

C = total fixed compute commitment across the term
P = comparable On-Demand price per running hour
H = total hours in the term
u = fraction of those hours the unit would otherwise run

On-Demand cost = P × H × u
Break-even utilization = C ÷ (P × H)

Illustrative arithmetic only: if C is 600 currency units, P is 0.10 per running hour and H is 8,760 hours, break-even is 600 / 876, or about 68.5%. At 50% usage, the comparable On-Demand compute cost is 438. At 80%, it is 700.80.

This example excludes financing, taxes, other charges and flexible coverage across workloads. It assumes the commitment fully covers one comparable unit whenever it runs. It is not a Savings Plans billing simulator. For mixed workloads, compute eligible coverage hour by hour under the selected plan's rules.

Gate: the finance approver can see the break-even inputs and downside cost. If the forecast only works under uninterrupted growth, reduce the commitment or defer the purchase.

4. Evaluate Spot by completed work

The platform engineer measures cost per accepted job or transaction, including retries, checkpoint storage, replacement delay and fallback capacity. Do not use a universal Spot percentage or assume an older instance family will be less likely to interrupt.

Select multiple compatible capacity pools where the workload supports them. Validate image, architecture, memory, network and storage constraints for every eligible type. A pool is not useful diversification if the application fails when placed there.

The queue and worker must agree on ownership. Use durable job identity, leases or equivalent coordination, checkpoint progress where useful, and make repeated effects safe. A worker that loses its lease must not continue committing results while a replacement owns the job.

| Workload property | Evidence required before using Spot | |---|---| | Restartable batch work | Loss and retry produce the same accepted business result | | Long-running computation | Durable checkpoints bound lost work under the deadline | | User-facing service | Remaining capacity and routing absorb instance loss | | Stateful component | Replication, durability, fencing and recovery are explicitly tested | | External side effects | Stable operation identity and authoritative reconciliation exist |

A stateful workload is not automatically excluded, but its evidence burden is higher. If the team cannot demonstrate recovery, keep that workload on a capacity model consistent with its objectives.

5. Implement interruption handling as a tested contract

AWS documents best-effort interruption notices. Stop or terminate notices provide a two-minute warning; hibernation begins immediately and does not provide that advance window. Design for loss even if no warning arrives. See Spot interruption notices.

For an instance-local handler, use IMDSv2 and request the documented /latest/meta-data/spot/instance-action item. A nonempty HTTP error body is not a valid interruption signal. The IMDSv2 documentation describes token creation, reuse and expiry.

| Handler observation | Required behavior | |---|---| | Successful response with valid action and time | Record the event once and begin the action-specific drain path | | HTTP 404 from the instance-action item | No notice is present at that moment; continue normal monitoring | | HTTP 401 | Refresh the IMDSv2 token and retry within a bounded policy | | Timeout, service error or malformed response | Mark monitoring degraded; do not treat the body as a valid notice | | Duplicate notice | Continue the existing drain record without duplicating effects | | Instance loss without a notice | Recover from durable job state and leases |

Validate the token request's status before using its body. Apply request timeouts and bounded retry behavior. Never log metadata tokens. Test the chosen metadata access settings and container network path in the actual environment.

"type": "flow", "title": "Interruption recovery does not depend on finishing a drain", "steps": [ ], "caption": "If the instance disappears before checkpointing completes, the replacement starts from the last durable state. A warning improves the recovery opportunity; it is not the durability mechanism." }} />

The test owner injects loss during startup, processing, result commit and external calls. Verify both job completion and the absence of duplicate side effects. Test replacement delay and fallback exhaustion as well as the happy path.

6. Define fallback before changing the fleet

An On-Demand fallback still needs quota, capacity, compatible images and a cost ceiling. Do not assume it can absorb the entire fleet immediately. Decide which jobs wait, which receive fallback capacity and which miss their deadline with an explicit status.

Stop a Spot expansion if the accepted-work cost, deadline misses or recovery errors exceed the workload's approved limits. Route new work to the validated fallback, drain reachable workers and reconcile leases and outputs. Keep durable state until the final outcome is known.

Changing the capacity mix is operationally reversible only within those constraints. Buying a term commitment is a separate financial action. EC2 Reserved Instance purchases cannot simply be canceled; modification, exchange or resale depend on the applicable rules. Check the Reserved Instance overview. Do not base approval on an assumed future exit.

7. Use a purchase and operating decision record

Workload / service owner / finance approver:
Decision date and quote expiry:
Account, region, OS, tenancy, architecture and instance attributes:
Baseline usage source and hours represented:
Existing commitments, sharing and renewal dates:
Rightsizing, migration and shutdown assumptions:
Expected / downside / change-case costs:
Commitment amount, payment option and term:
Capacity reservation requirement and separate plan:
Spot eligibility, interruption test and fallback evidence:
Operational stop conditions and reconciliation owner:
Approved action, approval record and next review trigger:

Require a human purchase approval with the exact amount and term. Keep the analysis and purchase identity together so the next renewal owner can compare the decision with observed usage.

After the change, the FinOps owner checks coverage, unused commitment, uncovered usage and accepted-work cost. The service owner checks latency, deadlines, errors and recovery incidents. Report the savings baseline and exclusions; do not present avoided list-price charges as verified cash savings.

8. Reconcile the economic and service outcomes together

Establish a recurring review for the first representative workload cycles after the change. Finance brings billed usage, effective rates, commitment coverage, unused commitment and unallocated charges. Engineering brings completed work, demand, latency, deadline misses, interruption events, retry volume, fallback use and operating effort. The two views need the same accounts, regions, time windows and workload boundaries.

Normalize cost by an accepted unit of work where practical. A lower bill during a demand decline is not evidence that the capacity decision improved efficiency. A lower compute rate with more retries or missed deadlines may be a worse outcome. State how the denominator is defined and how failed, canceled or duplicate work is counted.

Investigate variance using explicit categories:

forecast demand differed from observed demand;
rightsizing or architecture changed eligible usage;
sharing or purchase scope changed coverage;
Spot interruption and fallback behavior changed completed-work cost;
temporary migration capacity or data transfer was excluded from the model; or
provider pricing, credit or billing allocation changed the comparison.

Do not force unexplained variance into “savings.” Retain the original forecast and append observed results. If a commitment is underused, identify feasible, compatible usage before moving workloads solely to consume it. A sunk commitment should not justify a technically poor placement or a new reliability risk.

9. Exercise a capacity shortfall before broad rollout

Create a controlled scenario in which the preferred Spot pools are unavailable or interrupted while demand is above the ordinary baseline. The operator should identify the shortfall, protect the highest-priority work, activate only the approved fallback, and keep the total cost and downstream load within defined limits.

Include a delayed replacement and an exhausted On-Demand quota. Verify that the system queues, sheds or degrades work according to the service contract rather than retrying without bound. Test that leases and idempotency prevent two workers from committing the same result after ownership changes. For user-facing traffic, verify that overload controls protect shared databases and third-party services.

Record the point at which service objectives cannot be maintained. The correct response may be to miss a low-priority deadline or return a controlled unavailable result. It should not be an undocumented escalation to unrestricted capacity or an unbounded financial exposure.

After recovery, reconcile completed jobs, external effects, fallback charges and any temporary resources. Confirm that drain flags, queue priorities and emergency scaling settings return to their intended state. Assign cleanup owners before ending the exercise.

The failure test is complete when another operator can reproduce the decision using the runbook and evidence. If recovery depends on the person who designed the fleet, the operating model is not ready for broader use.

Set renewal and exit triggers at purchase time

Record who owns the renewal decision and when analysis must begin before the term ends. Rebuild the baseline from current eligible usage rather than rolling the old quantity forward. Recheck application architecture, processor compatibility, region, operating system, tenancy, growth assumptions and provider terms.

Define triggers for reducing or delaying the next commitment: sustained unused coverage, a planned migration, a material decline in demand, a new licensing constraint, or an inability to attribute the covered usage. Define triggers for considering more coverage only after observed stable demand remains after rightsizing and existing commitments.

Keep purchase approval separate from an engineering recommendation. The finance owner accepts the term and downside exposure. The service and platform owners confirm that the forecasted usage is technically compatible and does not depend on an unsafe operating arrangement.

Document the final renewal decision and all current observed evidence behind it.

Acceptance checklist and limitations

"Quotes match the exact configuration and have a recorded date", "Forecasts account for rightsizing, existing commitments and architecture changes", "The downside scenario and break-even arithmetic are reviewable", "Billing discounts and capacity availability are assessed separately", "Spot loss tests cover missing notices, duplicate delivery and unknown effects", "Fallback quota, capacity, deadlines and cost limits have evidence", "The authorized finance owner approved any commitment purchase", "Post-change usage and workload outcomes have an assigned reviewer" ]} />

No portfolio mix is correct for every workload. Pricing, eligibility and contract terms change, and future capacity is uncertain. This guide provides a decision method, not a price quote, financial recommendation or savings guarantee. Bring the completed record to cloud cost optimization before expanding the scope of the change.