FinOps · AWS EC2

EC2 Cost Plans, Without the Marketing

On-Demand, Savings Plans, Reserved Instances, Spot, and the Dedicated options. What each one actually discounts, what it quietly locks you into, and how to layer them so one bill uses all of them at once.

EC2 has one compute product and seven ways to pay for it. For the identical instance the rates differ by more than three times, so how you buy often matters more than what you pick. Every discount is sold in exchange for something: a commitment, a constraint, or the right to take the machine back. AWS leads with the discount. Below, each option leads with what it costs you.

The discount ladder

Start with what AWS itself advertises as the ceiling for each option. These are maximums under ideal conditions, not what a normal bill achieves — but they set the shape of the decision.

Horizontal bar chart of maximum advertised discount off On-Demand: Spot Instances 90%, EC2 Instance Savings Plans 72%, Standard Reserved Instances 72%, Dedicated Host Reservations 70%, Compute Savings Plans 66%, SageMaker AI Savings Plans 64%, On-Demand 0%.
Maximum advertised discount, per AWS. Click to open full size

One number there gets misquoted constantly. Compute Savings Plans cap at 66%, not 72%. The 72% belongs to EC2 Instance Savings Plans, which are the less flexible product.

The confusion comes from AWS itself. Its overview page says "up to 72%" for Savings Plans generally; the detail page then splits it into Compute 66%, EC2 Instance 72%, SageMaker AI 64%, Database 35%. So when a blog promises 72% while keeping full flexibility, it has quoted the headline and skipped the breakdown. You cannot have both numbers at once.

No commitment

On-Demand: the baseline

You pay by the second for running instances, with no commitment and no capacity guarantee. Every other option is defined as a discount off this rate, so it is worth knowing its exact mechanics.

Mechanics
Billing granularityPer second, with a 60-second minimum. You pay only for seconds in the running state.
CommitmentNone. Stop or terminate whenever you like.
CapacityNot guaranteed — a launch can fail with an insufficient capacity error (ICE).
QuotasMeasured in vCPUs per family group per Region, not instance count. GPU families (P, G, Trn, Inf) default to 0.
The quota trap. Accelerated-compute quotas start at zero on a new account. If a launch plan depends on GPU instances, request the quota increase days before you need it, not on the morning of the training run. A stopped or hibernated instance does not count toward the quota — but an unused Capacity Reservation does.
Use it for short-lived, irregular, or unpredictable work that cannot be interrupted, and any workload too new to know its steady-state size. Also the correct place to leave the spiky top slice of a workload permanently.
Commitment · AWS's default recommendation

Savings Plans: commit to money, not machines

You commit to spending a fixed number of dollars per hour, for one or three years. Usage up to that amount gets discounted rates. Anything above it falls back to On-Demand. Note what you are not committing to: an instance type. That is the whole difference from a Reserved Instance.

AWS does not hedge about which one to prefer. Its Reserved Instances documentation opens by recommending Savings Plans instead, calling them "the easiest and most flexible way to save money on your AWS compute costs." When a vendor steers you away from its own older product, that is worth taking at face value.

The four types

Three things that are easy to miss. Savings Plans do not apply to Spot usage, and Spot spend does not draw down your commitment. The per-Region Dedicated Instance fee is not discounted by them either. And for Kubernetes: the EKS control-plane charge is not covered, though the underlying EC2 instances are.
Where it belongs: under any steady baseline. Size a Compute Savings Plan to the floor of your usage rather than the average. Under-commit and you leave discount on the table. Over-commit and you pay real money for capacity you never use.
Commitment · the older model

Reserved Instances: commit to a configuration

An RI is not a physical instance; it is a billing discount applied to On-Demand instances that match a set of attributes. Four attributes determine the price: instance type, Region, tenancy, and platform (the operating system). Term is one or three years, with the longer term discounting more.

Offering classes and payment

RIs do not auto-renew — and that is where the money leaks. When one expires, nothing breaks and nothing alerts you: the instance keeps running and silently reverts to On-Demand rates. A purchase also cannot be cancelled, though it may be modified, exchanged, or sold on the Reserved Instance Marketplace. Put the expiry dates in a calendar the day you buy.
Narrower than it used to be. Reach for an RI when you need a zonal capacity reservation as well as the discount, or when a workload really is pinned to one configuration. Otherwise take AWS's own advice and buy a Savings Plan.
Spare capacity

Spot Instances: the deepest discount, with a catch

Spot is AWS selling you the servers nobody else booked. Up to 90% off. In return they can take the machine back on two minutes' notice.

A lot of people still think Spot is an auction you bid in. It was, years ago. EC2 sets the price itself now and moves it slowly with supply and demand, so any bidding-strategy advice you find is describing a system that no longer exists.

Timeline of a Spot interruption: a rebalance recommendation signals elevated risk with no guaranteed lead time, followed by a two-minute interruption notice, followed by termination, stop, or hibernation according to the configured behaviour.
The two signals before a Spot interruption. Click to open full size

Two signals arrive before an instance disappears, and both are catchable in code via instance metadata or EventBridge. The rebalance recommendation warns that the instance is at elevated risk, with no guaranteed lead time. The interruption notice then gives a hard two-minute warning. Whether the instance is terminated, stopped, or hibernated depends on the behaviour you configured.

Do not set a maximum price. Setting one feels like the responsible thing to do, and it backfires: AWS states that specifying a maximum price gets your instances interrupted more often than leaving it alone. The default already caps you at the On-Demand rate, so the field buys you nothing and costs you uptime.
Use it for anything that can be interrupted and retried: batch jobs, data processing, CI runners, rendering, stateless web capacity behind a load balancer. It is also very good for Kubernetes worker nodes, provided your workloads are replicated and drain cleanly.
Isolation · licensing

Dedicated Hosts, Dedicated Instances, and Capacity Blocks

These are not really cost-optimization tools. Two of them cost more than standard On-Demand — you buy them to satisfy a licence agreement or a compliance clause, and the saving is on software licensing rather than compute.

Dedicated Hosts vs Dedicated Instances

Both run your instances on hardware dedicated to you, and AWS states there is no performance, security, or physical difference between them. The difference is visibility and billing.

Capacity Blocks for ML

The newest option, and the one worth knowing if you touch GPUs. You reserve accelerated instances — P4d, P5, P6, Trn — for a defined window, with a start date up to eight weeks out, and pay only for the reserved time. Instances are placed in EC2 UltraClusters for low-latency interconnect. Up to 64 instances per block, 256 across blocks.

Capacity Block sharp edges. Cancellations are not allowed, blocks end at 11:30 UTC with termination beginning at 11:00 UTC on the final day, and instances must explicitly target the reservation ID or they will not use it. Plan the job to finish before that window closes.
Dedicated Hosts when a licence is bound to physical cores or sockets, or an auditor wants single-tenant hardware. Capacity Blocks when a training run needs guaranteed GPUs on a known date and you would rather not pay for them sitting idle either side of it.

How they combine on one bill

The options are not alternatives to choose between — a well-run account uses three of them simultaneously, matched to the shape of demand rather than picked once.

Stacked area chart across one day: a flat committed baseline covered by a Savings Plan, a daytime On-Demand peak layered above it, and an overnight Spot batch window.
Commit to the flat part, burst on On-Demand, batch on Spot. Click to open full size

Find the floor of your usage, meaning the level it never drops below, and cover that with a Savings Plan. It is guaranteed to be consumed, so the discount is guaranteed to land. Leave the variable peak on On-Demand: committing to capacity you use six hours a day wastes more than the discount saves. Anything interruptible goes on Spot.

Where people get this wrong is committing to the average instead of the floor. It looks reasonable on a spreadsheet and it loses money at both ends. Everything below the floor stays under-discounted, and everything above it gets paid for on the hours it does not run.

Decision flowchart: can the work be interrupted, use Spot; otherwise is usage steady for 1 to 3 years, if not use On-Demand; if yes, lock one instance family for an EC2 Instance Savings Plan or stay flexible with a Compute Savings Plan; dedicated hardware or BYOL licensing leads to Dedicated Hosts; Capacity Blocks are a special case for GPU training.
Which option for which workload. Click to open full size

Comparison: the whole set, side by side

Maximum advertised discount, what you commit to, and what you give up.

Option Max discount You commit to Flexibility Capacity guarantee Best for
On-Demand 0% (baseline) Nothing Total No Spiky, short-lived, or not-yet-understood workloads
Compute Savings Plan Up to 66% $/hour for 1 or 3 years Any family, size, Region, OS, tenancy; plus Fargate and Lambda No The steady baseline, when architecture may still change
EC2 Instance Savings Plan Up to 72% $/hour + one family in one Region Size, OS, tenancy within that family No A settled workload on a family you will not leave
Standard Reserved Instance Up to 72% A specific instance configuration Modify only. No exchange Yes, if zonal When you need a zonal capacity reservation too
Convertible RI Below Standard A configuration you can swap Exchangeable for another Convertible RI Yes, if zonal Long commitment with an expected hardware refresh
Spot Up to 90% Nothing Total, but reclaimable on 2 minutes' notice No. The opposite Batch, CI, rendering, replicated stateless capacity
Dedicated Hosts Up to 70% (host reservation) A physical host Host affinity and placement control Yes. The host is yours Per-socket / per-core BYOL and single-tenancy audits
Capacity Blocks for ML n/a. A reservation, not a discount A fixed GPU window, up to 8 weeks ahead None. Cannot be cancelled Yes, for the window Training runs that need guaranteed GPUs on a date

Discount ceilings are AWS's published maximums. What you actually realise depends on term, payment option, instance family, and Region — model it against your own usage before committing.

Sources

Every mechanic, percentage, and constraint in this post comes from AWS's own documentation, listed below. Pricing pages change frequently — treat the figures as of the verification date, not as permanent.

Last verified against AWS documentation on 4 August 2026.

The single highest-return move in most accounts is not a smaller instance type — it is noticing that a permanently-running baseline has been billed at On-Demand rates for two years. That is a purchasing decision, it takes an afternoon, and it needs no code change.

FinOps is included in every KubeCube engagement for exactly this reason: commitment coverage, Spot adoption where it is safe, and finding the expired reservation nobody was alerted about.

If the workloads you are pricing are GPU-bound, the companion piece walks through the five ways to run AI infrastructure on AWS — where the same purchasing decisions land very differently.

Book a free cloud audit
← Back to all posts