The same EC2 instance can cost you very different prices depending on how you buy it. Choosing the right purchase model can save you up to 90%. This subsection explains the four main options—On-Demand, Reserved Instances, Savings Plans, and Spot—and when to use each. This is one of the pieces of knowledge that saves the most money in real life.

The central idea: commitment in exchange for a discount

AWS rewards you for committing. The more you commit (to using for a long time, or to accepting interruptions), the bigger the discount you get. The more flexibility you want, the more you pay.

  More flexibility ◄──────────────────────────► More discount
   On-Demand    Savings Plans / Reserved        Spot
   (expensive,   (medium, you commit            (super cheap,
    no strings    to use for 1-3 years)          but interruptible)
    attached)

On-Demand: pay for what you use, no commitment

This is the default model: you pay per second or hour of use, with no commitment. You turn it on when you want, turn it off when you want.

  • Advantage: maximum flexibility, zero commitment.
  • Drawback: it is the most expensive per hour.

When to use it:

  • Unpredictable or short-term workloads.
  • Testing, development, and experiments.
  • When you are starting out and don’t know your usage pattern yet.
  • As a base while you decide whether to commit.

Example: You’re learning AWS and spin up instances for a while to practice. On-Demand is the right choice: you don’t want to commit to anything.

Reserved Instances (RI): commit for 1 or 3 years

You commit to using a specific instance type for 1 or 3 years in exchange for a discount of up to ~72% compared to On-Demand.

  • Advantage: great savings for stable workloads.
  • Drawback: you’re tied to an instance type and a term. Less flexible.

When to use them: constant and predictable workloads that you know will be there for years (for example, a database that is always on).

Note: Reserved Instances are the “classic” model. Today, for most cases, AWS recommends Savings Plans (see below) because they are more flexible with similar savings.

Savings Plans: flexible discount for committing spend

Savings Plans are the evolution of Reserved Instances. Instead of committing to a type of instance, you commit to spending a fixed amount per hour (for example, “at least €10/hour on compute”) for 1 or 3 years. In return, that usage is billed at a big discount (up to ~72%).

  • Advantage: savings similar to RI, but much more flexible: the discount applies even if you change instance type, size, or even region (depending on the plan). Some plans also cover Lambda and Fargate.
  • Drawback: you commit to a minimum spend during the term, whether you use it or not.

When to use them: stable workloads where you want to save but keep flexibility to change instances over time. This is the recommended option today for most constant compute bases.

We’ll look at the strategic decision between Savings Plans and Reserved Instances in detail in Chapter 25 (cost optimization).

Spot Instances: super cheap, but interruptible

Spot Instances use AWS’s spare capacity and sell it at discounts of up to 90%. The catch: AWS can take them back at any time (with about 2 minutes’ notice) if it needs that capacity.

  • Advantage: lowest price by far.
  • Drawback: they can be interrupted without real warning. Not suitable for things that can’t tolerate interruptions.

When to use them:

  • Jobs that can be resumed if interrupted (batch processing, rendering, data analysis).
  • Fault-tolerant systems that spread work across many instances and can handle losing some.
  • Don’t use them for a critical database or a server that can’t go down.

Real example: A company processes thousands of videos overnight. It uses Spot Instances: if AWS takes some away, the work simply continues on others or is retried. They pay a fraction of the normal price for a job that isn’t urgent and doesn’t need to be always available.

Comparative table

Model Discount Commitment Can be interrupted Ideal case
On-Demand 0% None No Testing, unpredictable workloads
Reserved Instances Up to ~72% 1-3 years, fixed type No Stable and predictable workload
Savings Plans Up to ~72% 1-3 years, spend/hour No Stable workload with flexibility
Spot Up to ~90% None Yes Interruption-tolerant jobs

Real strategy: combine them

In practice, companies mix the models to optimize the bill:

Example of a combined strategy:

  • Savings Plans for the base capacity that is always on (base web servers, databases).
  • On-Demand to absorb occasional traffic spikes.
  • Spot for batch jobs that aren’t urgent (overnight processing).

This way they cover their minimum load cheaply and with commitment, scale flexibly, and minimize costs for what can be interrupted.

What you should remember

  • The price of EC2 depends on how you buy: more commitment = more discount.
  • On-Demand: no commitment, most expensive. For testing and unpredictable workloads.
  • Reserved Instances: commit to type + term (1-3 years), high savings. The classic model.
  • Savings Plans: commit to spend per hour (1-3 years), high savings and flexibility. Recommended today for stable workloads.
  • Spot: up to 90% discount, but interruptible. Only for interruption-tolerant jobs.
  • In real life, all four are combined to minimize the bill.

With this, you finish Chapter 4 and master compute in AWS. In Chapter 5 we’ll look at the other major pillar: object storage with S3.

Cloud, AWS & Terraform — From Zero to Expert

Chapter 1 · What is cloud computing

Chapter 2 · The cloud market and major providers

Chapter 3 · Regions, availability zones and edge

Chapter 4 · Compute: EC2

Chapter 5 · Storage: S3

Chapter 6 · Networking: VPC

Chapter 7 · Identity and access: IAM

Chapter 8 · Managed databases

Chapter 9 · Why Infrastructure as Code

Chapter 10 · HCL: the Terraform language

Chapter 11 · Providers and state

Chapter 12 · Your first real infrastructure in Terraform

Chapter 13 · Load balancing and auto scaling

Chapter 14 · Serverless with Lambda

Chapter 15 · Messaging and events

Chapter 16 · Content delivery and DNS

Chapter 17 · Containers on AWS

Chapter 18 · Modules: reuse and composition

Chapter 19 · Workspaces and environment management

Chapter 20 · Remote backends and locking

Chapter 21 · Infrastructure testing

Chapter 22 · Terraform in CI/CD

Chapter 23 · Defense in depth

Chapter 24 · Observability: logs, metrics and traces

Chapter 25 · Cost optimization

Chapter 26 · High availability and disaster recovery

Chapter 27 · AWS Well-Architected Framework

Chapter 28 · Serverless architectures at scale

Chapter 29 · Data platforms on AWS

Chapter 30 · Multi-account and landing zones

Chapter 31 · Platform Engineering and Internal Developer Platform

Chapter 32 · Relevant AWS certifications

Chapter 33 · Projects to consolidate what you've learned

Chapter 34 · Resources and community

© Copyright 2024. All rights reserved