How EC2 Pricing Actually Works: On-Demand, Reserved, and Spot Explained Simply
Written by: Demola Malomo (opens in a new tab)
One of the first surprises people get when using EC2 is the bill. You launch a few instances, do some testing, forget to shut things down, and suddenly AWS is charging real money.
To use EC2 well, you need to understand how pricing works, because AWS does not charge a single flat rate. Instead, there are different pricing models depending on how predictable your workload is and how flexible you can be.
The three main ones you will see are:
- On-Demand Instances
- Reserved Instances
- Spot Instances
They all give you the same type of virtual machines. The difference is how you pay and how reliable the capacity is.
On-Demand: Pay Only While It Is Running
On-Demand is the simplest option and the default when you launch an EC2 instance.
You start an instance, it runs, and you pay per second (with a minimum of one minute). When you stop or terminate it, billing stops.
No long-term commitment. No upfront payment.
This is perfect for:
- Development and testing
- Short-lived workloads
- New projects where traffic is unpredictable
So if you are building a new API and still figuring out performance and scaling. You can run a few EC2 instances during the day, shut them down at night, and only pay for the hours they are running.
The downside is cost. On-Demand is the most expensive option over time. If your app runs 24/7 for months, you are paying full price every hour.
Reserved Instances: Cheaper, but You Commit
Reserved Instances are for workloads you already know will be running long term.
With Reserved Instances, you commit to using a certain type of EC2 instance for 1 or 3 years, and AWS gives you a significant discount compared to On-Demand pricing.
You can pay:
- All upfront
- Partial upfront
- No upfront (still discounted, but less)
This is best for:
- Production systems that run all the time
- Databases
- Core backend services
A typical example to use this is if your company has an API that runs 24/7 and always needs at least four medium-sized instances. Instead of paying On-Demand prices every hour, you buy Reserved Instances for those four machines and cut costs by a large margin.
Important thing to understand about Reserved Instances
In Reserved Instances, you are not reserving a physical server but getting a billing discounts for specific instance types in a region. If you stop the instance, you are still paying for the reservation.
So Reserved Instances make sense only when you are confident the workload will keep running.
Spot Instances: Big Discounts, but Not Guaranteed
Spot Instances are unused EC2 capacity that AWS sells at very low prices, sometimes up to 70 to 90 percent cheaper than On-Demand.
The trade-off is simple: AWS can take those instances back when they need the capacity.
When that happens, your instance is stopped or terminated with very short notice.
Spot is great for workloads that:
- Can handle interruptions
- Can be restarted easily
- Run in batches or jobs
Common use cases:
- Data processing
- CI/CD jobs
- Video rendering
- Machine learning training jobs
A use case for spot instances is if you run a system that processes thousands of images. You can use it and if some jobs fail because instances are reclaimed, your system just retries them. Using Spot can reduce your compute bill massively for this type of work.
Spot is not a good idea for:
- Web servers handling live traffic
- Databases
- Anything that users rely on continuously
Same EC2, Different Ways to Pay
A key thing many beginners misunderstand is thinking the servers each pricing model gives you are different. They're not.
On-Demand, Reserved, and Spot do not give you different types of servers. They are just different ways of paying for the same EC2 capacity.
An m5.large instance is still an m5.large instance whether it is On-Demand, Reserved, or Spot. The hardware and performance are the same. What changes is:
- Price
- Stability of access
- Commitment level
That is why many real systems use a mix of all three.
How Companies Usually Combine EC2 Pricing Models
Most production setups do not pick just one pricing model.
A common pattern looks like this:
- Reserved Instances for baseline capacity that must always be running
- On-Demand for extra capacity during traffic spikes
- Spot for background jobs and batch processing
For example, if you run an API service like a payment gateway, e-commerce backend, or authentication system, you usually need a minimum number of servers running all the time to handle steady traffic. Those core servers are a good fit for Reserved Instances since they are always on.
When traffic spikes during campaigns, product launches, or peak business hours, Auto Scaling can add extra servers using On-Demand instances so you only pay for that extra capacity when it is needed.
At the same time, background tasks like generating reports, resizing images, sending bulk emails, or processing logs can run on Spot Instances, since those jobs can be retried if they get interrupted.
This setup keeps systems stable while still keeping costs under control.
What About Savings Plans?
You may also hear about Savings Plans, which are similar to Reserved Instances but more flexible.
Instead of committing to a specific instance type, you commit to spending a certain amount per hour on compute. AWS then applies discounts automatically to whatever EC2 usage fits that commitment.
For beginners, it is fine to think in terms of:
- On-Demand for flexibility
- Reserved or Savings Plans for steady workloads
- Spot for cheap, interruptible jobs
The core idea remains the same.
Final Thoughts
EC2 pricing is not complicated once you see the pattern:
- On-Demand (opens in a new tab) gives flexibility at a higher price
- Reserved Instances (opens in a new tab) give lower prices if you commit long term
- Spot Instances (opens in a new tab) give very cheap compute if you can handle interruptions
Before choosing, always ask two questions:
- Does this workload need to run all the time?
- Can this workload survive being stopped suddenly?
Your answers will usually point you to the right pricing model.
Understanding this early saves money, avoids surprise bills, and helps you design systems that scale without breaking your budget.