AWS Compute Cost Playbook: Savings Plans, RIs & Spot

TL;DR

You are paying full price for AWS compute, and there is no reason to.

• Savings Plans: Commit to a $/hour spend for 1 or 3 years. Flexible across instance types. Best for predictable baseline workloads.
• Reserved Instances (RIs): Commit to a specific instance type in a specific region. Deeper discounts than Savings Plans but zero flexibility. Best for databases and stateful services.
• Spot Instances: Use AWS spare capacity at up to 90% off. Can be reclaimed with 2 minutes notice. Best for stateless, fault-tolerant workloads.
• The Verdict: The winning strategy is a layered approach — RIs for your database layer, Savings Plans for your baseline compute, and Spot for everything that can tolerate interruption.

Not sure which pricing model fits your infrastructure? Book a free 15-minute review and I'll tell you where to start, or get the $250 fixed-price AWS Cost Audit for written findings based on your actual usage.

The On-Demand Tax

If you are running your AWS workloads entirely on On-Demand pricing, you are paying the retail sticker price for every second of compute. AWS sets On-Demand as the default because it is the most profitable option — for them.

For a rough figure on what that's costing you, the AWS cost waste calculator estimates it from your compute spend and average utilization.

For a growing startup running a moderate production infrastructure (a few EKS worker nodes, an RDS cluster, some batch processing), the difference between On-Demand and optimized pricing easily runs into thousands of dollars a month.

That is not a rounding error. Over a year, it can be a hire. Or three months of marketing budget. Or the difference between extending your runway and a down round.

Let's break down every pricing model so you can make an informed decision.

Option 1: Savings Plans

What it is: You commit to spending a minimum $/hour on compute for 1 or 3 years. In exchange, AWS gives you a discount on those hours: up to 66% for Compute Savings Plans, with the deepest rates reserved for 3-year, All Upfront commitments.

Key advantage: Compute Savings Plans are flexible. If you commit to $10/hour of compute, that commitment applies automatically across EC2, Fargate, and Lambda regardless of instance family, size, operating system, or region. (EC2 Instance Savings Plans trade that flexibility for a deeper discount, up to 72%, tied to one instance family in one region.)

When to Use Savings Plans

• Your compute usage is predictable and you have at least 6 months of AWS Cost Explorer data showing a consistent baseline.
• You run a mix of instance types and expect to change them over the commitment period (e.g., migrating from x86 to Graviton).
• You want to keep operational flexibility while still getting meaningful discounts.

When NOT to Use Savings Plans

• You are a very early-stage startup (less than 3 months on AWS) and your usage patterns are still volatile.
• You are planning a major re-architecture (e.g., moving from EC2 to serverless) within the commitment period.

The Decision Matrix

The maximums apply to 3-year, All Upfront terms. A 1-year, No Upfront commitment earns less; the exact rate per instance type is on AWS's Savings Plans pricing page and Reserved Instances pricing page.

My recommendation for startups: Start with a 1-year, No Upfront Compute Savings Plan. It gives you meaningful savings with zero upfront cash risk and monthly payments that align with your cash flow.

Option 2: Reserved Instances (RIs)

What it is: You commit to a specific instance type (e.g., db.r6g.xlarge) in a specific region for 1 or 3 years. The discount is deeper than a Compute Savings Plan because you are giving AWS more certainty.

Key advantage: Standard RIs reach the deepest commitment discount AWS offers, up to 72% off On-Demand.

Key risk: If you change instance types, move regions, or reduce usage during the commitment period, you are stuck paying for capacity you don't use. RIs are not flexible.

When to Use Reserved Instances

• Production databases (RDS/ElastiCache). Your database instance type rarely changes. You know you will run db.r6g.2xlarge for the next year. This is the ideal RI candidate.
• Stable, long-running stateful services. If you have an Elasticsearch cluster or a Kafka broker that has been the same instance type for 6+ months, lock in the savings.

When NOT to Use Reserved Instances

• Anything stateless. Web servers, API gateways, and worker processes should use Savings Plans or Spot instead.
• Anything you might migrate. If there is any chance you will switch database engines (e.g., from RDS PostgreSQL to Aurora), an RI on the old instance type becomes a wasted commitment.

New Since December 2025: Database Savings Plans

For years, databases were RI-only territory. At re:Invent 2025 AWS added Database Savings Plans: a $/hour commitment, like Compute Savings Plans, that applies across RDS, Aurora, ElastiCache, DynamoDB and other managed databases. They are 1-year only, and the discount is smaller than an RI (roughly 12% to 35% depending on the service, with the top end on serverless options).

The trade is flexibility. If you might move from RDS to Aurora, change instance sizes, or go serverless in the next year, a Database Savings Plan follows you; an RI does not. If the database will sit on the same instance type all year, the RI still wins on price.

Option 3: Spot Instances

What it is: You use AWS's unused spare compute capacity at up to a 90% discount. The catch: AWS can reclaim your instance with a 2-minute warning whenever they need the capacity back.

Key advantage: The discount is the largest of the three. AWS states up to 90% off On-Demand; the real figure varies by instance type, region and hour, so check the Spot price history in the EC2 console for the types you plan to use.

When to Use Spot

• Kubernetes worker nodes running stateless microservices. Configure node affinity so that pods with graceful shutdown handlers land on Spot nodes.
• CI/CD build runners. Your GitHub Actions or GitLab CI runners don't need to be persistent. Spin up a Spot instance, run the build, and terminate.
• Batch processing and data pipelines. ETL jobs, ML training runs, and video transcoding are perfect Spot candidates.

When NOT to Use Spot

• Production databases. Never put a database on Spot. The 2-minute reclamation window is not enough time to safely shut down a database with open transactions.
• Singleton services without failover. If your architecture has a single instance handling critical traffic with no automatic failover, Spot reclamation causes an outage.

Surviving Spot Reclamation

The 2-minute warning is not optional — your application must handle it:

import signal
import sys
import time
import requests
 
 
IMDS = "http://169.254.169.254/latest"
 
 
def check_spot_interruption():
    """Poll the EC2 metadata endpoint (IMDSv2) for interruption notices."""
    try:
        # IMDSv2: fetch a session token first. Many accounts enforce v2,
        # and a plain GET without the token header returns 401.
        token = requests.put(
            f"{IMDS}/api/token",
            headers={"X-aws-ec2-metadata-token-ttl-seconds": "60"},
            timeout=2,
        ).text
        response = requests.get(
            f"{IMDS}/meta-data/spot/instance-action",
            headers={"X-aws-ec2-metadata-token": token},
            timeout=2,
        )
        if response.status_code == 200:
            return response.json()
    except requests.exceptions.RequestException:
        pass
    return None
 
 
def graceful_shutdown(signum, frame):
    """Handle SIGTERM from Spot interruption."""
    print("Received SIGTERM. Draining connections...")
    # Stop accepting new requests
    # Wait for in-flight requests to complete
    # Flush buffers and close database connections
    time.sleep(5)
    print("Graceful shutdown complete.")
    sys.exit(0)
 
 
signal.signal(signal.SIGTERM, graceful_shutdown)

In Kubernetes, the AWS Node Termination Handler automates this entirely. When a Spot reclamation notice arrives, it automatically cordons the node, drains running pods, and allows the Kubernetes scheduler to place them on another node — all within the 2-minute window.

Savings Plans vs Reserved Instances: The Break-Even Math

Discount tables only tell half the story. The other half is how much of the commitment you will actually use, because you pay for it every hour whether you use it or not.

The break-even rule: a commitment with discount d beats On-Demand only if the committed capacity is in use for more than 1 − d of the hours in the term.

That is why RIs suit databases (in use 100% of hours) and why Spot, with no commitment at all, suits spiky work.

A Worked Example

Savings Plans are committed in discounted dollars per hour, which trips people up. Take a startup whose Cost Explorer shows a steady baseline of $10/hour of On-Demand-equivalent compute, running 24/7 (about $7,300/month). Assume an illustrative 28% Compute Savings Plan discount (check the Savings Plans pricing page or Cost Explorer for your real rate):

• Commit to 80% of the baseline, not 100%: $8/hour of On-Demand usage × 0.72 = a $5.76/hour commitment.
• Monthly cost: $5.76 × 730 h = $4,205 for the covered part, plus the uncovered $2/hour at On-Demand = $1,460. Total ≈ $5,665, about $1,635 (22%) less than $7,300.
• If usage later drops 30% (to $7/hour, say after rightsizing): On-Demand would cost $5,110; your commitment still costs $4,205 and covers all of it. You are still ahead.
• If usage drops to $5/hour: On-Demand would cost $3,650, but you still pay $4,205. Now the commitment costs you money.

The break-even point is the commitment itself: as long as your On-Demand-equivalent usage stays above $5.76/hour, the plan pays off. That is why the 80% rule matters, and why you should do the architectural fixes (rightsizing, Graviton, idle shutdown) before you commit, not after.

Let AWS do the first pass for you. Cost Explorer's recommendation API uses your real usage history:

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 SIXTY_DAYS

Treat the output as a ceiling, then commit to around 80% of it.

The Layered Strategy (Putting It All Together)

The optimal approach is not choosing one pricing model. It is layering all three:

┌─────────────────────────────────────────────────────┐
│                 Your AWS Compute Bill                │
├─────────────────────────────────────────────────────┤
│                                                     │
│  Layer 1: Reserved Instances (RIs)                  │
│  ├── RDS Production (db.r6g.2xlarge)                │
│  ├── ElastiCache (cache.r6g.xlarge)                 │
│  └── Kafka brokers (m6g.2xlarge)                    │
│                                                     │
│  Layer 2: Compute Savings Plan                      │
│  ├── Baseline EKS worker nodes                      │
│  ├── Lambda functions                               │
│  └── Fargate tasks                                  │
│                                                     │
│  Layer 3: Spot Instances                            │
│  ├── Stateless microservices                        │
│  ├── CI/CD runners                                  │
│  └── Batch processing                               │
│                                                     │
│  Layer 4: On-Demand (Last Resort)                   │
│  └── Only for unpredictable burst traffic           │
│                                                     │
└─────────────────────────────────────────────────────┘

AWS publishes the ceilings: Savings Plans save up to 72% and Spot up to 90% off On-Demand. What you actually get depends on term, payment option, region and instance type, so price your own workloads in the AWS Pricing Calculator before committing.

The percentages above are illustrative upper ends; your actual rates depend on instance, region, term and payment option.

Layer 1 (RIs) covers your fixed, predictable database and stateful layer. Maximum discount, zero flexibility needed. If the database layer is still changing, a Database Savings Plan is the flexible alternative.

Layer 2 (Savings Plans) covers your baseline compute that runs 24/7 but might change instance types as you optimize (e.g., migrating to Graviton). I cover the Graviton migration in my AWS Cost Optimization Guide.

Layer 3 (Spot) covers everything that can tolerate interruption. This is where the dramatic savings happen for compute-heavy workloads.

Layer 4 (On-Demand) is your safety net for traffic spikes and unexpected bursts. On a well-optimized stack, On-Demand should account for less than 10% of your total compute spend.

The Decision Framework

Before committing to any pricing model, ask these four questions:

1. Is the workload stable? (Same instance type for 6+ months → RI)
2. Is the workload predictable? (Consistent baseline usage → Savings Plan)
3. Is the workload stateless and fault-tolerant? (Can survive interruption → Spot)
4. Is the workload unpredictable and critical? (Burst traffic → On-Demand)

The Operational Reality

• Commitment risk. A 3-year All Upfront RI on a large database instance like a db.r5.4xlarge costs tens of thousands of dollars upfront. If you migrate to Aurora Serverless six months in, that money is gone. Start with 1-year No Upfront commitments until your architecture stabilizes.
• Savings Plan coverage gaps. AWS recommends Savings Plan amounts based on a 7, 30 or 60-day lookback of your usage. If your usage drops (e.g., you optimize your infrastructure), your Savings Plan commitment becomes wasted spend. Always commit to 80% of your baseline, not 100%.
• Spot availability varies by region. Some instance types in popular regions (us-east-1) are reclaimed frequently. Diversify across multiple instance types and availability zones to reduce interruption rates.

The Payoff

A startup paying On-Demand for all of its compute is paying the highest price AWS charges. Layering RIs, Savings Plans and Spot lowers that price with little application change (Spot needs graceful shutdown handling; commitments need none). The worked example above shows how to size the commitment so the saving holds even if usage drops.

That is not optimization. That is free money sitting on the table, waiting for someone to pick it up.

Commitments are the last step, not the first. Fix the architecture first with the seven fixes in my AWS cost optimization playbook, then commit to the smaller, cleaner baseline that is left.

The right mix of Savings Plans, RIs, and Spot saves money every hour. The wrong commitment locks in waste for a year. Look at your real usage before you sign anything.

Frequently Asked Questions