.png)
AWS offers four EC2 pricing models: On-Demand (no commitment, highest per-hour cost), Reserved Instances (1–3 year term, up to 72% savings), Spot Instances (spare capacity auction, up to 90% savings, interruptible with 2-minute warning), and Dedicated Hosts (single-tenant hardware for compliance and BYOL licensing). Most production environments run a blend of Reserved or Savings Plans for steady-state workloads, On-Demand for variable traffic, and Spot for fault-tolerant batch jobs achieving 35–50% blended savings without overcommitting.
Every month, AWS sends your organization a bill. And every month, somewhere between 40% and 60% of that bill is higher than it needs to be because you somehow end up choosing the wrong pricing model for the right workload. And this is one of the most expensive silent mistakes in cloud infrastructure.
AWS gives you four ways to pay for compute. If you pick the wrong one and you're either overpaying on-demand rates for workloads that run 24/7, sitting on unused reserved capacity you can't unwind, or getting your Spot Instance interrupted mid-job because you didn't architect for it. But, if you can pick the right combination, you can routinely cut your EC2 bill by 35–60% without touching a single line of application code.
This guide breaks down all four AWS pricing models, i.e., On-Demand, Reserved Instances, Spot Instances, and Dedicated Hosts with real pricing tables, actual dollar calculations on common instance types, and a decision framework built for FinOps leads and DevOps engineers who need to make the right call.
Here's what you'll walk away with:
AWS doesn't charge a flat rate for compute. Instead, it offers four distinct pricing models, each designed for a different relationship between commitment, flexibility, and cost. Understanding the tradeoffs between them is the foundation of any serious cloud cost strategy.
Here's the full picture at a glance:
On-Demand is AWS's default pricing model. You launch an instance, you pay by the second (minimum 60 seconds), and you stop paying the moment you terminate it. There are no upfront cost, contract, or commitment. Every instance type across every region is available on-demand, and you're never turned away for capacity.
The tradeoff, however, is cost. On-Demand is the most expensive way to run persistent compute on AWS by design. Think of it like hailing a taxi. It is available instantly, convenient, but expensive per mile if you're making the same trip every single day.
Reserved Instances let you commit to a specific instance type in a specific region for one or three years in exchange for a significant discount of up to 72% off On-Demand rates.
There are two types of Reserved Instances:
You can also choose how you pay upfront:
Think of RIs like an annual gym membership. If you commit for the year, you get a better rate per visit, but whether you show up or not, you’ll still need to pay.
Spot Instances give you access to AWS's unused EC2 capacity at discounts of up to 90% off On-Demand pricing. The catch is AWS can reclaim that capacity with just a two-minute warning when demand for On-Demand or Reserved capacity rises.
Spot prices fluctuate in real time based on supply and demand within each Availability Zone. In practice, average Spot prices are relatively stable for most instance types, but the interruption risk is real and must be architecturally accounted for.
Think of Spot like a standby flight seat which is deeply discounted, but the airline can bump you if a full-fare passenger needs your seat. If your job can survive a restart, Spot is almost always the smartest compute spend on AWS.
Dedicated Hosts give you an entire physical server which is exclusively allocated to your account. Dedicated Instances run on hardware dedicated to a single customer but don't give you visibility into the physical host.
Both models exist primarily for two reasons:
Dedicated Hosts carry a meaningful cost premium over standard instances. They should be used precisely where required and nowhere else.
Also read: What Is AWS Billing and Cost Management? The Complete Guide for Cloud Cost Control
Below are verified pricing comparisons for three of the most widely deployed EC2 instance types in us-east-1 (N. Virginia), the AWS region with the largest customer base and most competitive Spot market.
Note: All On-Demand and Reserved Instance prices are sourced from AWS public pricing. Spot prices reflect historical averages and fluctuate in real time. Treat them as directional, not guaranteed.
This is the workhorse of AWS fleets. It is used for web servers, application backends, mid-tier databases, and microservices.
At 50 instances: The difference between running 50 × m5.xlarge On-Demand vs 3-year All Upfront RIs is $52,122 per year, before touching a single workload.
It is built for CPU-intensive workloads with high-traffic web frontends, scientific modeling, video encoding, gaming servers.
At 20 instances: Switching from On-Demand to 1-year All Upfront RIs saves $27,156/year on c5.2xlarge alone, roughly the cost of a junior cloud engineer.
This is the default choice for in-memory databases, real-time analytics, large-scale caching layers, and SAP workloads.
At 10 instances: On-Demand vs 3-year All Upfront RIs = $54,915 saved per year on a single memory-optimized tier.
The Over-Commitment Tax: A Worked Example
Reserved Instances deliver exceptional savings, but only when fully utilized. Here's what happens when they're not.
For example, a fast-growing SaaS company purchases 100 × m5.xlarge 3-year All Upfront RIs to lock in savings across their application fleet. Total commitment is $63,948/year ($639.48 × 100).
Eight months later, the infrastructure team migrates 30 instances to Graviton2 (m6g.xlarge) for better price-performance. Those 30 Standard RIs, locked to the x86 m5 family, cannot be exchanged. They cannot be applied to Graviton instances.
The math on the waste will look something like this:
This is the over-commitment tax which is a silent, compounding cost that shows up not as a line item on your bill, but as the gap between what you're paying for and what you're actually using.
Standard RIs can be listed on the AWS RI Marketplace, but resale typically yields 60–80 cents on the dollar and is restricted to instances with more than a month remaining on the term. Convertible RIs avoid this trap through exchange flexibility, but at the cost of a lower discount ceiling.
The over-commitment tax is why most FinOps teams don't max out their RI coverage.
Knowing when to use each one is what separates a FinOps strategy from a guessing game. The answer always starts with four questions about your workload:
Your answers map directly to a pricing model.
Rule of thumb: If you can't confidently predict what your infrastructure looks like in 6 months, On-Demand is cheaper than a wrong commitment. The flexibility premium is worth it.
Rule of thumb: If the same instance type has run continuously for 6+ months with >80% utilization, you are almost certainly leaving money on the table by staying On-Demand. Every month without a commitment is a month of avoidable overspend.
Here are two rules for running Spot safely:
Rule of thumb: If your job can restart without data loss and finish within a reasonable window even with one interruption, Spot is almost always the right answer. The 70–90% discount is too significant to ignore for fault-tolerant workloads.
Rule of thumb: Dedicated Hosts carry a meaningful cost premium. Use them precisely where required, not as a default for "we want more security." AWS's shared infrastructure is hardened; Remember, Dedicated Hosts are only a compliance and licensing tool.
Also read: Cloud Waste in AWS, Azure, and GCP: Causes, Examples & How to Eliminate It
The real answer is Stop Picking One Model and Start Blending All Three
Mature FinOps teams don't choose. They architect a three-layer coverage model that assigns each workload class to its optimal pricing tier and the savings compound across all three layers simultaneously. Here's how it works in practice.
Layer 1: Committed Foundation (Reserved Instances or Savings Plans)
Cover your predictable, steady-state baseline with commitments. This is your always-on application tier, your database layer, your core infrastructure that hasn't changed shape in 6+ months. Target 60–70% of total compute spend here.
Layer 2: On-Demand Buffer
Handle variable, spiky, or short-tenure workloads without commitment risk. New services, traffic burst handling, staging environments, and anything still finding its steady-state shape. Target 15–25% of total compute spend here.
Layer 3: Spot for Elastic and Batch Workloads
Capture maximum discount on everything fault-tolerant. CI/CD, ML training, batch pipelines, data processing. Target 10–25% of total compute spend here.
Blended savings: ~40% — or $198,750 saved annually on a $500K compute baseline, without changing a single workload or touching application code.
Scale that to a $2M/year AWS bill and the same architecture delivers ~$795,000 in annual savings.
Both deliver RI-level discounts, but the difference is flexibility.
The practical rule: Use Compute Savings Plans for your EC2 and Lambda baseline when your instance mix evolves regularly. Use Reserved Instances for your database tier. RDS, ElastiCache, Redshift, and OpenSearch are the most stable workload class on AWS and benefit most from the deeper RI discount.
You can run both simultaneously as they stack without conflict.
Learn more: AWS Savings Plans vs Reserved Instances: A Practical Guide to Buying Commitments
The blended strategy only works if your commitment coverage stays calibrated to your actual usage. This is where most teams fall down.
AWS Cost Explorer and Trusted Advisor generate RI and Savings Plan recommendations, but those recommendations are point-in-time snapshots. They don't update when your infrastructure changes. They don't account for planned migrations. They don't protect you when you over-commit and your utilization drops.
The result is teams either under-commit (leaving 30–40% savings on the table) or over-commit (paying for capacity they no longer use). Neither is acceptable at scale.
The On-Demand vs Reserved vs Spot decision isn't unique to AWS. Azure and GCP offer structurally identical pricing tiers under different names and the same blended strategy logic applies across all three clouds. If your organization runs workloads on a multi-cloud provider, the optimization playbook is consistent even if the terminology isn't.
Azure's eviction model for Spot VMs differs slightly from AWS. Instead of a fixed 2-minute warning, Azure uses configurable eviction policies (Deallocate or Delete) and eviction rates vary significantly by region and VM size. Architecture for Azure Spot requires the same fault-tolerant design principles as AWS Spot, but the interruption mechanics warrant separate planning.
Also read: Cut Your Azure Bill by 40% in 5 Minutes: The Complete Setup Guide
GCP's Sustained Use Discounts are unique to the market. The longer an instance runs within a billing month, the larger the automatic discount applied, with no commitment required. This makes GCP's effective On-Demand cost lower than AWS's for always-on workloads, even before committing. It doesn't eliminate the value of CUDs, but it changes the baseline math.
The On-Demand vs Reserved vs Spot debate has a clear answer. It's not a choice between them, but it's a question of how intelligently you blend all three.
On-Demand for what you can't predict. Reserved Instances or Savings Plans for what you can. Spot for everything fault-tolerant. Dedicated Hosts precisely where compliance or licensing demands it. That architecture, applied consistently across your fleet, delivers 35–50% blended savings without changing a line of application code.
However, the hard part is maintaining the coverage. Infrastructure changes constantly. Instance families evolve. Teams migrate workloads. Commitments go stale. The 24-hour recommendation refresh problem, where your RI coverage analysis is already outdated by the time your next billing cycle closes, is a real operational cost that compounds silently at scale.
Modern FinOps teams are solving this with commitment automation. Instead of manually analyzing usage, purchasing RIs, and monitoring utilization, Usage.ai handles the entire commitment lifecycle automatically and continuously monitoring real-time usage across AWS, Azure, and GCP, executing commitments on your behalf, and refreshing recommendations every 24 hours so coverage never drifts from reality.
What makes Usage.ai different from simply buying RIs yourself is the financial model underneath it. There is $0 upfront, and fees are charged only on realized savings. It also offers cashback assurance that protects you if a commitment underperforms. You get RI-level and Savings Plan-level discounts around 40–60% on EC2 and Fargate, 20–35% on managed databases, up to 72% on Azure VMs, without carrying the commitment risk yourself.
Book a demo to see how Usage.ai automates your commitment strategy across AWS, Azure, and GCP.
1. What is the difference between On-Demand and Reserved Instances?
On-Demand Instances charge you by the second with no commitment. You pay the full hourly rate and can terminate anytime. Reserved Instances require a 1 or 3-year commitment in exchange for discounts of up to 72% off On-Demand rates. On-Demand is best for unpredictable or short-tenure workloads; Reserved Instances are best for steady-state workloads running continuously for 12 months or longer.
2. When should I use Spot Instances vs Reserved Instances?
Use Spot Instances for stateless, fault-tolerant workloads that can tolerate interruption like batch jobs, ML training, CI/CD pipelines, and containerized workloads. Use Reserved Instances for always-on, predictable workloads where interruption is unacceptable, like application servers, databases, and core production infrastructure. Most production environments benefit from running both simultaneously as part of a blended coverage strategy.
3. Can Spot Instances be used for production workloads?
Yes, with the right architecture. Spot Instances are widely used in production for stateless, containerized workloads running on Kubernetes or ECS, where interrupted pods or tasks are automatically rescheduled. They are not suitable for stateful production workloads, like primary databases, session-dependent application servers, or any service where a 2-minute interruption causes data loss or user-facing downtime.
4. What happens to unused Reserved Instances?
Unused Standard Reserved Instances can be listed for resale on the AWS Reserved Instance Marketplace, typically at 60–80 cents on the dollar with restrictions on remaining term length. Convertible Reserved Instances cannot be sold but can be exchanged for a different instance family, size, OS, or tenancy.
5. What is the difference between a Reserved Instance and a Savings Plan?
Reserved Instances lock a discount to a specific instance type, size, and region, delivering up to 72% savings with the least flexibility. Savings Plans deliver up to 66% savings but apply automatically across instance families, sizes, and regions, making them better suited to evolving compute fleets. Reserved Instances remain the better choice for managed database services like RDS, ElastiCache, and Redshift, which Savings Plans do not cover.
6. How do I choose between a 1-year and 3-year Reserved Instance?
Choose a 1-year RI when you're confident in the workload's stability for the next 12 months but uncertain beyond that. Choose a 3-year RI only for your most stable, mission-critical workloads where the instance type and region are virtually guaranteed not to change.
7. Can I mix On-Demand and Reserved Instances in the same AWS account?
Yes and this is standard practice. Reserved Instance discounts apply automatically to matching On-Demand usage within your account or AWS Organization. If you have 50 Reserved Instances and run 70 instances of the same type, the first 50 instances receive the RI discount rate and the remaining 20 are billed at On-Demand pricing. No configuration is required and the discount is applied automatically at billing time.
8. What is the difference between a Dedicated Instance and a Dedicated Host?
A Dedicated Instance runs on hardware dedicated to a single AWS account but gives you no visibility into or control over the physical host. A Dedicated Host allocates an entire physical server to your account, giving you visibility into sockets, cores, and host-level configuration, which is required for per-socket or per-core BYOL software licensing. Dedicated Hosts are the correct choice for Oracle, Windows Server, and SQL Server BYOL workloads; Dedicated Instances are sufficient for basic multi-tenancy isolation requirements.
Share this post
.svg){kind=icon}
.png)
.png)