AWS Spot, Reserved, and Savings Plans: Cost Guide

AWS pricing is a maze on purpose. The more complicated the options, the more likely you are to give up and pay on-demand rates, which is exactly what Amazon wants.

But if you understand three pricing models (spot, reserved, and Savings Plans) you can cut your AWS bill by 40–72% without changing what you run. This guide explains all three in plain terms, with real numbers and a clear framework for deciding which to use.

No enterprise budgets assumed. This is for solo operators and small teams spending €10–200/month on AWS.

The baseline: on-demand pricing

On-demand is the default. You pay per hour (or per second for Linux instances), no commitment. It’s the most expensive option, but it’s the simplest: use it, stop it, pay for what you used.

AWS lists prices in US dollars per hour, per instance type and region; look up current figures on the EC2 pricing page or in the AWS Pricing Calculator. A month is usually counted as 730 hours.

Every discount model below is measured against this on-demand baseline.

Spot instances: up to 90% off, but interruptible

How they work

Spot instances use AWS’s spare capacity. When demand is low, prices are cheap. When demand spikes, AWS can reclaim your instance with 2 minutes notice.

Think of it like standby flights. You get the same seat for a fraction of the price, but the airline can bump you if the flight fills up.

Pricing

Spot prices fluctuate by instance type, region and availability zone. AWS advertises discounts of up to 90% against on-demand; what you actually get varies. Check the current price before launching:

aws ec2 describe-spot-price-history \
  --instance-types t3.small \
  --product-descriptions "Linux/UNIX" \
  --start-time "$(date -u +%Y-%m-%dT%H:%M:%S)" \
  --query 'SpotPriceHistory[*].[AvailabilityZone,SpotPrice]' --output table

When to use spot

• Batch processing: jobs that can be interrupted and resumed (data processing, CI/CD builds, video transcoding)
• Burst GPU compute: AI inference sessions where you launch, work, and terminate (see the Ollama spot instance guide)
• Dev/test environments: if it goes down for 10 minutes, nobody cares
• Stateless web servers behind a load balancer, traffic shifts to other instances during interruption

When to avoid spot

• Databases: losing your database server for even 2 minutes causes data consistency issues
• Single-server setups: if you only have one instance and it gets reclaimed, your service is down
• Long-running, non-resumable jobs: if 4 hours of work is lost when the instance terminates, the savings aren’t worth it

Interruption rates

AWS’s Spot Instance Advisor shows the interruption frequency band (for example under 5%, or 5–10%) and typical savings for each instance type and region. Check it for the types you plan to use; it changes over time, and less popular instance types or sizes are often interrupted less.

For workloads that can restart, interruptions are usually manageable; for anything that must not stop, use on-demand or a commitment.

Best practices for spot

# Always check current spot pricing before launching
aws ec2 describe-spot-price-history \
  --instance-types t3.small t3.medium \
  --product-descriptions "Linux/UNIX" \
  --start-time "$(date -u +%Y-%m-%dT%H:%M:%S)" \
  --query 'SpotPriceHistory[*].{Type:InstanceType,AZ:AvailabilityZone,Price:SpotPrice}' \
  --output table

• Be flexible on AZ: prices vary significantly between eu-central-1a, 1b, and 1c
• Be flexible on instance type: m5.large and m5a.large are functionally identical but priced independently
• Use spot instance interruption notices: the 2-minute warning is enough to gracefully save state
• Don’t set a max price: just use the current spot price; setting a cap often means your request sits unfilled

Reserved Instances: up to 72% off, with commitment

How they work

You commit to using a specific instance type in a specific region for 1 or 3 years. In exchange, AWS gives you a significant discount. You pay whether you use the instance or not. It’s a lease: cheaper monthly rate, but you’re locked in for the full term.

Pricing tiers

For a t3.small in eu-central-1:

AWS advertises Reserved Instance discounts of up to 72% against on-demand. The discount grows with a 3-year term and with paying more upfront (no upfront < partial upfront < all upfront). Get exact numbers for your instance type and region from the EC2 Reserved Instances pricing page.

The absolute savings grow with instance size, so commitments matter more for larger instances that run all the time.

Standard vs. Convertible

• Standard Reserved Instances: locked to a specific instance type (e.g., t3.small). Cheapest option. Can be sold on the Reserved Instance Marketplace if you no longer need it.
• Convertible Reserved Instances: can be exchanged for a different instance type, family, or OS during the term. Slightly more expensive (about 5–10% less discount) but more flexible.

For a homelab operator running a single small instance long-term, Standard is usually the right choice. You know what you need and it’s not going to change dramatically.

When to use reserved instances

• Always-on workloads you’ve been running for 3+ months and expect to continue, if it’s been on-demand for a quarter and you haven’t turned it off, commit and save
• Predictable baseline compute: your VPS that runs Caddy, Uptime Kuma, and a few services 24/7
• Databases: RDS reserved instances follow the same model and offer similar savings

When to avoid reserved instances

• New workloads you’re still sizing: don’t commit to a t3.medium before you’ve confirmed a t3.small isn’t enough
• Instances you stop regularly: reserved pricing applies whether the instance runs or not
• Short-term projects: if the workload will end in 6 months, reserved doesn’t save enough to justify the inflexibility

Savings Plans: the modern alternative

How they work

Savings Plans are AWS’s newer, more flexible answer to reserved instances. Instead of committing to a specific instance type, you commit to a dollar amount of compute per hour. AWS applies the discount automatically to whatever instances you run, giving you the best rate available for whatever compute you’re actually using.

Two flavors

Compute Savings Plans:

• Discount applies across all instance families, regions, and even Fargate/Lambda
• Most flexible option
• Slightly lower discount than instance-specific (typically 5–8% less)

EC2 Instance Savings Plans:

• Locked to an instance family (e.g., t3) in a specific region
• Still flexible across sizes within the family (t3.micro → t3.large)
• Highest discount, comparable to Standard Reserved Instances

Pricing example

Savings Plans are also advertised at up to 72% off. Compute Savings Plans are more flexible (any instance family, region, also Fargate and Lambda) and give a somewhat smaller discount; EC2 Instance Savings Plans are tied to an instance family in a region and give a bigger one. The AWS console’s Savings Plans recommendations calculate a commitment from your actual usage.

Any usage above your committed amount is billed at on-demand rates.

When Savings Plans beat Reserved Instances

• Multiple instance types: if you run a t3.small and a t3.micro, a Savings Plan covers both with one commitment
• Likely to change instance types: upgrading from t3.small to t3.medium mid-year? A Savings Plan adjusts automatically
• Using Lambda or Fargate: Compute Savings Plans cover serverless too
• Simpler mental model: “I’ll spend at least €X/hour on compute” is easier to reason about than “I need this exact instance type for 3 years”

The decision framework

Here’s how to choose for a typical small AWS setup:

Step 1: Categorize your workloads

Your AWS workloads
├── Always-on (24/7)
│   ├── VPS / Docker host → Reserved or Savings Plan
│   ├── Database → Reserved Instance
│   └── DNS / monitoring → Free tier or minimal cost (not worth committing)
│
├── Predictable schedule
│   ├── Dev environment (weekdays 9–5) → Spot + auto-scaling schedule
│   └── Nightly batch jobs → Spot
│
└── Burst / occasional
    ├── GPU compute → Spot
    ├── CI/CD → Spot
    └── One-off experiments → On-demand (simplicity wins)

Step 2: Apply the right pricing model

Workload pattern	Best pricing	Typical savings
24/7 for 1+ years, known instance type	Reserved Instance (Standard)	40–55%
24/7 for 1+ years, might change size/type	Savings Plan (EC2 Instance)	35–55%
24/7 across mixed workloads	Savings Plan (Compute)	30–50%
Interruptible, flexible timing	Spot Instance	60–90%
Short-term or experimental	On-demand	0% (but no commitment)

Step 3: Start small

If you’re spending less than €20/month total, the savings from committing are small in absolute terms. A 50% discount on €20 saves you €10/month: real money, but not worth agonizing over.

My recommendation for a typical homelab-to-cloud setup:

1. Run on-demand for the first 2–3 months while you figure out what you actually use
2. Look at your billing dashboard and identify which instances run 24/7
3. Buy a 1-year EC2 Instance Savings Plan covering your baseline always-on compute
4. Use spot for everything burst-oriented (GPU, CI/CD, batch processing)
5. Leave everything else on-demand

Don’t start with 3-year commitments. A 1-year plan captures most of the savings with a fraction of the risk.

Monitoring your costs

AWS can surprise you with charges. Set up a billing alarm on day one:

# Enable billing alerts (must be done in us-east-1)
aws cloudwatch put-metric-alarm \
  --region us-east-1 \
  --alarm-name "monthly-billing-alarm" \
  --metric-name EstimatedCharges \
  --namespace AWS/Billing \
  --statistic Maximum \
  --period 21600 \
  --threshold 15 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --dimensions "Name=Currency,Value=EUR" \
  --alarm-actions "arn:aws:sns:us-east-1:YOUR_ACCOUNT_ID:billing-alerts"

Also check the AWS Cost Explorer monthly. It shows:

• Which services cost the most
• Usage trends over time
• Savings Plan recommendations based on your actual usage (after 30+ days of data)

# Quick CLI cost check for the current month
aws ce get-cost-and-usage \
  --time-period "Start=$(date +%Y-%m-01),End=$(date +%Y-%m-%d)" \
  --granularity MONTHLY \
  --metrics "BlendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE \
  --query 'ResultsByTime[0].Groups[*].{Service:Keys[0],Cost:Metrics.BlendedCost.Amount}' \
  --output table

Common mistakes

Buying reserved instances too early. Don’t commit until you’ve run the workload on-demand for at least a month. You might discover you don’t need it, or you need a different size.

Ignoring data transfer costs. EC2 compute is often not the biggest line item. Data transfer out of AWS (after the first 100GB/month free across AWS, internet egress from EU and US regions starts at around $0.09/GB) adds up fast if you’re serving files or streaming.

Reserving instances you stop at night. A reserved instance costs the same whether it’s running or not. If you stop your dev server every evening, you’re paying for 16 hours of unused capacity daily. Use spot or on-demand with a schedule instead.

Forgetting about public IPv4 addresses. Since February 2024 AWS charges $0.005 per hour (about $3.65/month) for every public IPv4 address, attached or not. Release Elastic IPs you don’t use, and consider IPv6 or a single entry point (load balancer, reverse proxy, tunnel) instead of a public IP per instance.

Not setting billing alerts. A misconfigured auto-scaling group or a forgotten GPU instance can generate hundreds in charges before you notice.

Quick reference

Model	Commitment	Flexibility	Savings	Best for
On-demand	None	Total	0%	Experiments, variable workloads
Spot	None	Must tolerate interruption	60–90%	Batch, CI/CD, GPU bursts
Reserved (Standard)	1 or 3 year	Locked to instance type	40–55%	Known, stable workloads
Reserved (Convertible)	1 or 3 year	Can change instance type	35–50%	Stable but evolving needs
Savings Plan (EC2)	1 or 3 year	Flexible within family	35–55%	Baseline compute, may resize
Savings Plan (Compute)	1 or 3 year	Any instance, any region	30–50%	Mixed workloads, multi-service

Next in the series

• A Minimal AWS Stack: the baseline setup these savings apply to
• Running Ollama on GPU Spot Instances: spot pricing in action for AI workloads
• Terraform for Homelab Users: codify your infrastructure so you can reproduce it after any pricing change

Understanding AWS pricing isn’t glamorous, but it’s the difference between a €10/month cloud extension and a surprise €80 bill. Spend an hour with the Cost Explorer after your first month and you’ll know exactly where to optimize.