EC2 Pricing: On-Demand, Reserved & Spot

The same EC2 instance (Elastic Compute Cloud, AWS’s rentable virtual servers) can cost you wildly different amounts depending on how you pay for it. AWS sells the exact same hardware four ways: On-Demand, Reserved Instances, Savings Plans, and Spot. Picking the wrong one is one of the most common ways teams overspend on cloud — often paying full price for servers that never turn off. This page explains each option in plain English and gives you a rule of thumb for matching the right purchase model to each workload.

The four ways to pay

Every EC2 instance runs on identical hardware. The price you pay depends purely on the commitment you make. More commitment (or more flexibility you give up) means a bigger discount.

Option	How it works	Typical discount vs On-Demand	Commitment	Can it be interrupted?
On-Demand	Pay per second, no commitment	0% (baseline)	None	No
Reserved Instances (RIs)	Commit to a specific instance config for 1 or 3 years	Up to ~72%	1 or 3 years	No
Savings Plans	Commit to a dollars-per-hour spend for 1 or 3 years	Up to ~72%	1 or 3 years	No
Spot	Bid on spare AWS capacity	Up to ~90%	None	Yes — 2 minutes’ notice

On-Demand: flexible but the priciest

On-Demand means you pay by the second (with a 60-second minimum) and can start or stop whenever you like. There is no contract. It is the most expensive per-hour rate, but the most flexible.

When to use it: short-lived or unpredictable workloads — a server you spin up for a one-week experiment, a CI build runner that only exists during a test, or brand-new traffic you can’t forecast yet. When NOT to use it: a server that runs 24/7 for months. Paying On-Demand for steady, always-on load is the single biggest source of wasted EC2 spend.

Reserved Instances: commit for a discount

A Reserved Instance isn’t a different server — it’s a billing discount you buy in advance by promising to use a certain instance type for 1 or 3 years. You can pay All Upfront (biggest discount), Partial Upfront, or No Upfront.

There are two flavours. A Standard RI locks you to one instance family and gives the deepest discount. A Convertible RI lets you swap instance families later for a smaller discount.

When to use it: stable, predictable baseline load — a database that always runs the same r6i.large. When NOT to use it: if you expect to change instance types often, the rigidity hurts (which is why Savings Plans usually win — see below).

Savings Plans: commit to spend, not to a specific instance

A Savings Plan is the modern, more flexible alternative to RIs. Instead of committing to a specific instance type, you commit to a steady amount of compute spend per hour (for example, “$10/hour for 3 years”). AWS automatically applies the discount to whatever instances you run up to that amount.

There are two kinds. A Compute Savings Plan is the most flexible — the discount applies across any region, instance family, OS, and even AWS Fargate and Lambda. An EC2 Instance Savings Plan gives a slightly bigger discount but locks you to one instance family in one region.

Gotcha: For most teams, Savings Plans now beat classic Reserved Instances. They offer the same discounts but far more flexibility — you can change instance types, sizes, and even regions without losing your discount. Unless you have a very specific, frozen workload, reach for a Compute Savings Plan over a Standard RI.

Spot: cheapest, but it can vanish

Spot Instances let you use AWS’s spare capacity at up to 90% off. The catch: when AWS needs that capacity back, it reclaims your instance with just a 2-minute warning. Your workload must tolerate being interrupted at any moment.

When to use it: fault-tolerant, stateless, or batch work — CI/CD runners, big-data processing, video encoding, machine-learning training with checkpoints, or any worker pool behind a queue. When NOT to use it: a single stateful database or a server that must never go down. (See the dedicated Spot Instances page for handling interruptions.)

A rule of thumb per workload

This is the part most tutorials skip. Match the purchase model to the shape of the workload, not to the instance type.

Workload	Best option	Why
Steady 24/7 baseline (databases, core app servers)	Savings Plan (or RI)	Always on — commit and save up to ~72%
Unpredictable or short-lived (experiments, new features)	On-Demand	No commitment, no risk
Fault-tolerant batch / workers (CI, encoding, ML training)	Spot	Up to 90% off, interruptions are fine
Mixed fleet (Auto Scaling group)	Savings Plan baseline + Spot for the spike	Cover the floor cheaply, burst on Spot

Cost note: The real waste is almost never the instance type — it’s paying On-Demand for a steady, always-on baseline that should be on a commitment plan. A m6i.large running 24/7 for a year costs roughly $840 On-Demand versus about $500 on a 1-year Compute Savings Plan — a ~40% saving for zero engineering effort, just a billing choice.

How to buy a Savings Plan

In the AWS Console

1. Sign in to the AWS Management Console and open the AWS Cost Management console.
2. In the left menu choose Savings Plans -> Purchase Savings Plans.
3. Pick the Savings Plan type (Compute Savings Plan for maximum flexibility), the term (1 or 3 years), and the payment option (No / Partial / All Upfront).
4. Enter the hourly commitment in dollars per hour. Use the recommendations tab — AWS analyses your past usage and suggests a commitment that won’t be under-used.
5. Add to cart and Submit order.

With the AWS CLI

First, ask AWS for a recommendation based on your actual usage so you don’t over-commit:

aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days THIRTY_DAYS

Output:

{
    "SavingsPlansPurchaseRecommendation": {
        "SavingsPlansType": "COMPUTE_SP",
        "TermInYears": "ONE_YEAR",
        "PaymentOption": "NO_UPFRONT",
        "SavingsPlansPurchaseRecommendationSummary": {
            "EstimatedMonthlySavingsAmount": "312.40",
            "EstimatedSavingsPercentage": "38.7",
            "HourlyCommitmentToPurchase": "1.05",
            "CurrencyCode": "USD"
        }
    }
}

Then create the plan using the offering ID from the recommendation:

aws savingsplans create-savings-plan \
  --savings-plan-offering-id "abc12345-6789-0abc-def1-2345678901bc" \
  --commitment "1.05"

Output:

{
    "savingsPlanId": "sp-0a1b2c3d4e5f67890"
}

Checking what you’re spending

To see how much of your committed compute is actually covered (so you’re not leaving discount on the table or paying for unused commitment):

aws ce get-savings-plans-coverage \
  --time-period Start=2026-05-01,End=2026-06-01 \
  --granularity MONTHLY

Output:

{
    "SavingsPlansCoverages": [
        {
            "TimePeriod": { "Start": "2026-05-01", "End": "2026-06-01" },
            "Coverage": {
                "SpendCoveredBySavingsPlans": "742.18",
                "OnDemandCost": "118.55",
                "CoveragePercentage": "86.23"
            }
        }
    ]
}

A coverage well below 100% on steady workloads means money is leaking to On-Demand that a slightly larger commitment would capture.

Best practices

• Put your steady 24/7 baseline on a Compute Savings Plan — never leave always-on servers at full On-Demand price.
• Prefer Savings Plans over classic Reserved Instances unless your instance type is permanently frozen; the flexibility is worth more than the tiny extra RI discount.
• Use Spot for everything fault-tolerant (batch, CI, stateless workers) and design those jobs to survive a 2-minute interruption notice.
• Start with a conservative commitment (cover your known minimum) and increase it later — under-committing wastes a little discount, but over-committing wastes real cash you can’t claw back.
• Check Savings Plans coverage and utilization monthly in Cost Explorer; aim for high coverage on steady load and ~100% utilization on what you committed.
• Keep new or unpredictable workloads on On-Demand until you have a month of usage data, then commit.

Related Topics

• Spot instances
• Instance types & families
• Choosing the right instance type
• Graviton instances
• EC2 monitoring