Every AWS bill hides a choice most engineers never actually make on purpose: whether to pay full price for compute or not. Amazon Web Services sells the same virtual machine four different ways, and the gap between the cheapest and most expensive option can run past 90%. Yet a 2024 ProsperOps analysis found that 53% of AWS organizations were not using any commitment-based discount at all, according to the firm’s Effective Savings Rate benchmarking report. That means over half of AWS customers pay On-Demand rates for workloads that could run dramatically cheaper under Reserved Instances, Savings Plans, or Spot capacity.
This guide breaks down AWS EC2 pricing as it stands in October 2026: On-Demand, Reserved Instances (Standard and Convertible), Savings Plans (Compute and EC2 Instance), and Spot Instances. It compares the discount ceilings AWS actually publishes, stacks them against Azure and Google Cloud equivalents, and walks through a migration path for teams still paying sticker price. The goal is a clear verdict backed by sourced numbers, not a vendor pitch.
What AWS EC2 Pricing Models Mean for Your Cloud Bill in 2026
AWS EC2 pricing in 2026 breaks into two broad categories: pay-as-you-go and commitment-based. On-Demand and Spot Instances fall into the first group, where you pay for capacity as you consume it with no contract attached. Reserved Instances and Savings Plans fall into the second, where you trade a one- or three-year commitment for a lower hourly rate. AWS layers a third dimension on top of both groups: payment timing, split into No Upfront, Partial Upfront, and All Upfront options that shift more of the discount toward the buyer willing to pay sooner.
Each of these pricing models targets a different failure mode. On-Demand protects against over-commitment. Reserved Instances and Savings Plans protect against overpaying for workloads you already know you’ll run for a year or more. Spot Instances protect against paying full price for anything that can tolerate getting interrupted. The trick is matching the workload to the model instead of defaulting to whatever EC2 charges when you launch an instance without thinking about it, which is On-Demand by default.
AWS also runs separate Savings Plan products for Database (RDS, Aurora, DynamoDB, ElastiCache) and SageMaker AI, offering up to 35% and 64% off respectively. Those are distinct products from the Compute and EC2 Instance Savings Plans this guide focuses on, and they’re easy to confuse when comparing documentation across AWS’s pricing pages.
On-Demand Instances: The Default, Most Expensive Option
On-Demand is the baseline every other AWS EC2 pricing model gets measured against. You pay by the hour or second, with no upfront payment and no commitment. AWS’s EC2 pricing page treats this rate as the reference point for every discount percentage it publishes elsewhere, and it’s the rate you get automatically if you spin up an instance through the console without selecting a purchasing option.
On-Demand makes sense when workload duration is unknown, when capacity needs to appear immediately without a purchasing decision attached, or when the workload is too variable to justify a commitment. It’s also the fallback rate for usage that exceeds a Savings Plan’s committed hourly spend, since AWS bills anything above the commitment at standard On-Demand pricing. That detail matters for budgeting: a Savings Plan doesn’t cap your bill, it only discounts the portion you committed to.
The tradeoff is straightforward. On-Demand costs the most per hour of any EC2 pricing model, and for steady-state workloads, that gap compounds every month. A team running the same fleet size for a year on On-Demand instead of a Savings Plan is leaving a predictable, measurable amount of money on the table, and the size of that gap is exactly what the next few sections quantify.
Reserved Instances: Standard vs Convertible Explained
Reserved Instances (RIs) are AWS’s oldest discount mechanism, predating Savings Plans by several years. They come in two flavors. Standard RIs offer the deeper discount, up to 72% versus On-Demand according to AWS’s current reserved instance pricing page, but lock you into a specific instance family, Region, operating system, and tenancy for the full term. Convertible RIs trade some of that discount, capped at up to 66% on the same pricing page, for the ability to exchange the reservation into a different configuration if your workload changes.
Both types come in 1-year and 3-year terms, and both support three payment structures: No Upfront, Partial Upfront, and All Upfront. AWS confirms the discount depends on both term length and payment choice, with longer terms and larger upfront payments generally producing bigger savings, though the exact premium varies by instance type and Region rather than following one universal percentage.
There’s a wrinkle worth flagging. AWS’s own documentation isn’t fully consistent on Convertible RI savings: the current reserved instance pricing page lists up to 66%, while AWS’s EC2 purchasing-options decision guide separately lists Convertible RI savings at up to 54%. That gap likely reflects different baseline assumptions (instance family, term, payment option) rather than a contradiction, but it’s a reminder to check the AWS pricing calculator for your specific configuration before committing capital to a 3-year reservation.
Reserved Instances fit workloads where the Region, instance family, and operating system are already locked in and unlikely to shift, such as a database tier that’s been running the same way for two years. They’re a worse fit for teams still migrating between instance generations or re-architecting services, where a Savings Plan’s flexibility usually wins.
Savings Plans: Compute vs EC2 Instance Options
AWS introduced Savings Plans in 2019 to fix Reserved Instances’ biggest weakness: rigidity. Instead of committing to a specific instance configuration, a Savings Plan commits to a consistent hourly spend, in dollars, for one or three years. AWS then applies the discount automatically to any usage that matches, regardless of instance size, Availability Zone, Region, operating system, or tenancy.
Compute Savings Plans offer up to 66% off and apply across the widest surface area: EC2, AWS Fargate, and AWS Lambda all draw against the same committed spend. That makes them the right default for teams whose workloads move between EC2 and serverless compute, or who expect their instance mix to change over the commitment period.
EC2 Instance Savings Plans offer a deeper discount, up to 72%, matching Standard RIs. The tradeoff is a narrower commitment: you commit to a specific instance family within a Region, such as M5 usage in US East, though you retain flexibility to change instance size, operating system, and Availability Zone within that family. AWS’s Savings Plans pricing page confirms this is the mechanism behind the higher ceiling, trading breadth for depth exactly like Standard versus Convertible RIs do.
Datadog’s 2024 State of Cloud Costs report found that 59% of organizations used Savings Plans for at least some of their EC2 costs, while only 15% used Reserved Instances, a finding published on Datadog’s State of Cloud Costs page. That gap suggests the market has largely moved past RIs in favor of Savings Plans’ simplicity, even where the maximum discount is identical.
Spot Instances: Up to 90% Off, With a Catch
Spot Instances sell AWS’s spare EC2 capacity at a steep discount, up to 90% off On-Demand according to AWS’s EC2 Spot pricing page. There’s no commitment, no upfront payment, and no payment-option menu. You request capacity, AWS fills it from whatever’s idle, and you pay the Spot rate for as long as that capacity stays available to you.
The catch is reclamation. AWS can take Spot capacity back when it needs it for On-Demand or committed customers, and it gives a two-minute interruption notice before doing so. There’s no single published interruption rate that applies everywhere. Frequency varies by Region, Availability Zone, and instance type, depending on how much spare capacity exists at any given moment. That makes the 90% figure a ceiling, not a guaranteed effective savings rate once you account for retries, checkpointing overhead, or capacity that simply isn’t available when you ask for it.
Savings Plans and Reserved Instances don’t apply to Spot usage. The two discount mechanisms are independent, which means a team can stack a Compute Savings Plan on its steady-state fleet and run Spot separately for batch jobs without the two programs interacting.
Spot works best for batch processing, containerized jobs that can restart cleanly, stateless services spread across multiple capacity pools, CI/CD runners, and machine learning training jobs designed around checkpoints. It works poorly for anything stateful that can’t tolerate a two-minute notice to shut down, which rules out most primary databases and session-holding application tiers.
AWS EC2 Pricing Models Compared: Full Specs Table
The table below lines up every major EC2 pricing model against its closest Azure and Google Cloud equivalents, using the maximum discount percentage each provider currently publishes. These are ceiling figures, not guaranteed savings, and actual results depend on Region, instance family, operating system, and utilization.
| Pricing Model | Max Discount vs On-Demand | Commitment Term | Payment Options | Flexibility | Interruption Risk |
|---|---|---|---|---|---|
| AWS On-Demand | 0% | None | Pay-as-you-go | Highest | None |
| AWS Standard Reserved Instance | Up to 72% | 1 or 3 years | No / Partial / All Upfront | Low (fixed configuration) | None |
| AWS Convertible Reserved Instance | Up to 66% | 1 or 3 years | No / Partial / All Upfront | Medium (exchangeable) | None |
| AWS Compute Savings Plan | Up to 66% | 1 or 3 years | No / Partial / All Upfront | Highest (EC2 + Fargate + Lambda) | None |
| AWS EC2 Instance Savings Plan | Up to 72% | 1 or 3 years | No / Partial / All Upfront | Medium (instance family) | None |
| AWS Spot Instance | Up to 90% | None | Pay-as-you-go | Low (reclaimable) | 2-minute notice |
| AWS Database Savings Plan | Up to 35% | 1 or 3 years | No / Partial / All Upfront | Medium (RDS, Aurora, DynamoDB, ElastiCache) | None |
| AWS SageMaker AI Savings Plan | Up to 64% | 1 or 3 years | No / Partial / All Upfront | Medium (ML workloads) | None |
| Azure Reserved VM Instance | Up to 72% | 1 or 3 years | Varies by agreement | Low-Medium | None |
| Azure Savings Plan for Compute | Up to 65% | 1 or 3 years | Varies by agreement | Medium | None |
| Google Cloud Resource-Based CUD (3-year) | Up to 70% (memory-optimized) | 1 or 3 years | N/A | Medium | None |
| Google Cloud Spot VM | Up to 91% | None | Pay-as-you-go | Low | Reclaimable |
Two things stand out. First, Google Cloud’s Spot VM ceiling (91%) edges out AWS Spot (90%), though both are maximums rather than typical real-world results. Second, Azure’s Reserved VM Instance ceiling matches AWS’s Standard RI at 72%, while Azure’s Savings Plan ceiling (65%) sits a notch below AWS’s Compute Savings Plan (66%). The three major clouds have converged on remarkably similar discount structures, which suggests none of them is winning on raw discount depth alone.
Illustrative Pricing: What Each Model Costs at a $1.00/Hour Baseline
AWS doesn’t publish one universal per-instance dollar rate that applies across every Region and instance family, so the table below uses a hypothetical $1.00-per-hour On-Demand baseline and applies each model’s published maximum discount percentage. Treat this as a ratio exercise, not a quote for any specific instance type. Run your own numbers through the AWS Pricing Calculator for a real figure.
| Pricing Model | Discount | Effective Hourly Cost | Monthly Cost (730 hrs) | Annual Cost |
|---|---|---|---|---|
| On-Demand | 0% | $1.00 | $730.00 | $8,760.00 |
| Convertible Reserved Instance / Compute Savings Plan | 66% | $0.34 | $248.20 | $2,978.40 |
| Standard Reserved Instance / EC2 Instance Savings Plan | 72% | $0.28 | $204.40 | $2,452.80 |
| Spot Instance | 90% | $0.10 | $73.00 | $876.00 |
At the $1.00/hour baseline, moving a single always-on instance from On-Demand to a 72% commitment plan saves roughly $6,307 a year. Moving the same workload to Spot, if it can tolerate interruption, saves close to $7,884 a year. Multiply that across a fleet of 50 or 500 instances and the ProsperOps finding that 53% of AWS customers skip commitment discounts entirely starts to look less like a rounding error and more like a line item worth a finance team’s attention.
Real instance rates scale this same ratio up or down depending on size and family rather than changing the underlying percentage. A large memory-optimized instance running continuously might carry an On-Demand rate several times higher than a small general-purpose instance, but the 66%, 72%, and 90% discount tiers apply proportionally in both cases. That’s the useful part of thinking in percentages first: the commitment decision is about workload shape and duration, not about the specific dollar figure on any one instance type.
Benchmarks: Discount Percentages From Three Sources
Pulling discount figures from three independent publishers, rather than relying on a single vendor’s marketing page, is the only way to sanity-check these numbers. Here’s how AWS, Microsoft, and Google’s own pricing documentation compare, alongside third-party adoption data.
| Source | AWS Figures | Azure Figures | Google Cloud Figures |
|---|---|---|---|
| AWS official pricing pages (Oct. 2026) | Standard RI / EC2 Instance SP: up to 72%; Spot: up to 90% | Not applicable | Not applicable |
| Microsoft Azure pricing pages | Not applicable | Reserved VM Instances: up to 72%; Savings Plan: up to 65% | Not applicable |
| Google Cloud pricing page | Not applicable | Not applicable | Resource-based CUD: up to 70% (3-year); Spot VM: up to 91% |
| CRN, citing Flexera’s 2026 State of the Cloud survey | 40% of orgs use Savings Plans; 29% use Spot Instances | 40% use Reserved Instances; 35% use Savings Plans | Not broken out separately |
The Flexera-sourced adoption figures, reported by CRN, also show Azure Reserved Instance and Savings Plan usage each climbed four percentage points year over year, alongside separate usage of Azure’s Enterprise Agreement discounts (43%), Hybrid Use Benefit (22%), and negotiated discounts (19%). None of that is a discount percentage. It’s evidence that discount programs across all three clouds are getting more adoption, not less, as FinOps practices mature.
Which AWS Services Each Pricing Model Covers
Not every pricing model reaches every AWS service, and the differences matter for teams running mixed workloads. Compute Savings Plans are the broadest: AWS’s Savings Plans pricing documentation confirms the discount applies automatically across EC2, Fargate, and Lambda usage under the same hourly commitment. EC2 Instance Savings Plans and both Reserved Instance types stay narrower, applying only to EC2 and, for RIs, only to the underlying EC2 nodes behind a service like EKS rather than EKS’s control plane itself.
Spot pricing is specific to EC2 Spot capacity. Other AWS services can consume that same Spot capacity underneath the hood, for example EKS worker nodes or Fargate Spot tasks, but those arrangements don’t carry a Savings Plan-style discount of their own. They inherit the EC2 Spot economics instead.
This is also where the Database and SageMaker Savings Plans earn their separate names. RDS, Aurora, DynamoDB, and ElastiCache draw against the Database Savings Plan (up to 35%), not the Compute Savings Plan, and SageMaker AI training and inference workloads draw against their own plan (up to 64%). Teams budgeting across EC2, managed databases, and ML infrastructure need three separate commitment strategies, not one.
How AWS Compares to Azure Reserved VM Instances and Google Cloud CUDs
Azure’s closest match to a Standard Reserved Instance is the Reserved VM Instance, which Microsoft’s pricing documentation caps at up to 72%, identical to AWS’s ceiling. Microsoft also publishes an estimated range of 36% to 72% depending on Region, VM family, operating system, and term, a wider spread than AWS discloses for its own RIs. Azure Savings Plans for compute, the rough equivalent of AWS Compute Savings Plans, cap at 65% with an estimated 11% to 65% range depending on usage pattern.
Google Cloud takes a slightly different structural approach. Its resource-based Committed Use Discounts reward three-year terms on memory-optimized machine types with up to 70% off, while other machine families top out around 55%. One-year resource-based commitments cap at 37%, a lower ceiling than AWS or Azure offer for their shortest committed term. Google’s documentation didn’t specify a single universal percentage for spend-based CUDs in the pricing page reviewed for this piece, so that figure needs to be checked per workload.
Where Google pulls ahead is Spot. Google Cloud’s Spot VMs advertise up to 91% off, a single point above AWS Spot’s 90% ceiling. Both are maximums tied to current spare-capacity conditions rather than guaranteed rates, so the practical difference for most teams will come down to interruption frequency and regional capacity rather than the headline percentage.
The takeaway across all three providers: discount ceilings have converged within a few percentage points of each other. Choosing a cloud based purely on advertised maximum discount is no longer a strong signal, since AWS, Azure, and Google Cloud are all clustered between roughly 65% and 91% depending on the model and term.
5 Real-World Use Cases for Choosing a Pricing Model
Matching workload shape to pricing model is the entire game. Here’s how five common engineering patterns typically map to the models above.
- Steady-state web application backend. A fleet that runs the same instance count around the clock, month after month, is the textbook case for an EC2 Instance Savings Plan or Standard RI. The workload is predictable enough to justify the deeper 72% ceiling, and the instance family rarely changes.
- Batch ETL and overnight data processing. Jobs that run on a schedule, can retry on failure, and don’t hold long-lived state are strong Spot candidates. A two-minute interruption notice barely matters when the job checkpoints every few minutes anyway.
- Machine learning training pipelines. Training jobs built around checkpointing can absorb Spot interruptions with minimal lost work, while steady-state inference endpoints often fit better under a SageMaker AI Savings Plan, which AWS caps at up to 64% off.
- Multi-tenant SaaS platform mid-migration. A platform actively moving between instance families, or splitting workloads between EC2 and Fargate, benefits from a Compute Savings Plan’s breadth rather than a Standard RI’s rigidity, trading a few points of discount for the freedom to keep re-architecting.
- CI/CD build and test runners. Ephemeral, stateless, and tolerant of being killed mid-job, build runners are close to the ideal Spot workload. Pair them with a small On-Demand or Savings Plan buffer for jobs that must finish on a deadline regardless of Spot availability.
- Disaster-recovery standby capacity. A warm standby fleet that only needs to scale up during a regional failover rarely justifies a 3-year RI, since it sits mostly idle. On-Demand, paired with a small Compute Savings Plan covering the baseline monitoring instances that do run continuously, usually beats locking capital into a reservation for capacity you hope never to use at full scale.
What the Adoption Data Shows
Industry data tells a consistent story: most AWS customers under-use commitment discounts, and when they do commit, they increasingly prefer Savings Plans over Reserved Instances. ProsperOps’ 2024 benchmarking analysis found that in a sample of AWS organizations, Savings Plans were used by 38% while Standard Reserved Instances were used by only 18%, according to the firm’s Effective Savings Rate report. That’s more than double the adoption for the newer, more flexible product.
Datadog’s independently gathered figures point the same direction. Its State of Cloud Costs report found 59% of organizations used Savings Plans for at least part of their EC2 spend in 2024, against just 15% for Reserved Instances. Two different analytics vendors, pulling from different customer bases, landed on the same conclusion: Savings Plans have become the default commitment vehicle, and RIs are fading into a legacy option kept mainly for workloads locked into a specific configuration.
The flip side of that data is the ProsperOps finding that opened this article: 53% of AWS organizations in its sample used no commitment-based discount whatsoever. Put the numbers together and a clear pattern emerges. The organizations that do commit are shifting toward Savings Plans, but a slim majority of AWS customers still haven’t made any commitment decision at all, leaving the On-Demand rate as their default by inertia rather than by design.
Pros and Cons of Each EC2 Pricing Model
On-Demand
- Pros: zero commitment risk, instant capacity, no financial planning required
- Cons: highest hourly rate of any model, no discount ever applied automatically
Reserved Instances (Standard and Convertible)
- Pros: deepest published AWS discount tier (up to 72% for Standard), predictable budgeting
- Cons: locked configuration for Standard RIs, lower ceiling for the flexibility Convertible RIs offer, and AWS’s own documentation isn’t fully consistent on Convertible RI savings percentages
Savings Plans (Compute and EC2 Instance)
- Pros: automatic application across changing instance types, Compute Savings Plans extend to Fargate and Lambda, adoption data shows the market trusts this product over RIs
- Cons: usage above the committed hourly spend reverts to full On-Demand pricing, and the commitment is a dollar amount you must forecast accurately
Spot Instances
- Pros: the deepest discount ceiling of any EC2 model (up to 90%), no commitment required, can be combined with Savings Plans on other parts of the same fleet
- Cons: two-minute interruption notice, no guaranteed availability, unsuitable for stateful or latency-sensitive services
Common Mistakes Teams Make Choosing an EC2 Pricing Model
The math behind EC2 pricing models is simple enough that most of the real-world losses come from process failures, not misunderstanding a percentage. The first and most expensive mistake is sizing a commitment to peak usage instead of baseline usage. A team that commits a Compute Savings Plan to its busiest hour of the month ends up paying the committed rate around the clock, including the long stretches where actual usage sits well below that peak, which erases a chunk of the discount the plan was supposed to deliver.
The second mistake is treating a 3-year Standard RI as a safe first move. It’s the deepest discount on paper, but it’s also the least forgiving if the workload changes, migrates to a different instance family, or gets decommissioned entirely before the term ends. Teams that have never run a commitment before are better served starting with a shorter term and a more flexible product, then stepping up to RIs once usage patterns have proven stable across at least one full commitment cycle.
A third, quieter mistake is ignoring Spot for workloads that are obviously interruption-tolerant simply because nobody owns the decision. CI/CD runners and nightly batch jobs sit on On-Demand for years in some organizations, not because Spot is a bad fit, but because migrating them requires someone to add retry logic and test the interruption path, and that work never makes it onto a sprint board without a FinOps push behind it. The gap between what a workload could cost on Spot and what it actually costs on On-Demand often goes unmeasured until someone runs a Cost Explorer report specifically looking for it.
Finally, teams frequently forget that Savings Plans and Reserved Instances are Region-specific and, for RIs, configuration-specific. A Standard RI purchased for us-east-1 does nothing for identical workloads running in eu-west-1, and a commitment sized for one instance family provides no benefit if a later migration shifts the fleet to a different family. Reviewing commitments against actual deployed infrastructure, not just the original purchase intent, catches this drift before it compounds across a full contract term.
How FinOps Teams Track and Automate This Decision
Picking the right EC2 pricing model once is straightforward. Keeping that choice accurate as a fleet grows, shrinks, and shifts between instance families is the harder, ongoing problem that FinOps practices exist to solve. AWS Cost Explorer is the starting point for almost every team: its Reserved Instance and Savings Plans utilization and coverage reports show, in percentage terms, how much of current usage is actually covered by an existing commitment and how much of a purchased commitment is being used.
Coverage and utilization are different numbers and both matter. Coverage measures how much of your total EC2 usage sits under a commitment. Utilization measures how much of the commitment you purchased is actually being consumed. A team can have 90% utilization (barely wasting any of what it bought) while still running at 40% coverage (leaving 60% of its fleet on uncommitted On-Demand rates). Tracking both numbers side by side, on a recurring cadence rather than a one-time setup, is what separates teams that capture the discount percentages in this guide from teams that calculate them once in a spreadsheet and never revisit the decision.
Third-party platforms including Datadog, CloudHealth, and ProsperOps build dashboards on top of this same billing data, often adding automated commitment-rebalancing that buys and sells Convertible RIs or adjusts Savings Plan commitments as usage shifts, without a human manually re-running the calculation every quarter. Whether a team builds this process by hand with Cost Explorer or buys a platform to automate it, the underlying discipline is the same: measure actual usage against committed spend regularly, and treat the On-Demand rate as a cost to actively eliminate rather than a default to accept.
Migration Guide: Moving From On-Demand to a Committed Discount Strategy
Teams sitting on the On-Demand default, which the ProsperOps data suggests is a slim majority of AWS customers, can move to a mixed pricing strategy in a controlled sequence rather than a single risky commitment.
- Pull 90 days of Cost Explorer data broken out by instance family, Region, and hourly usage pattern, so the commitment decision is based on actual history rather than a guess.
- Separate workloads into three buckets: always-on and stable, variable but predictable in aggregate, and genuinely interruptible.
- Start with a Compute Savings Plan sized to your lowest-observed hourly spend over the trailing 90 days, not your peak, to avoid committing to capacity you might not use.
- Layer in an EC2 Instance Savings Plan or Standard RI only for instance families you’re confident won’t change for the full term, capturing the deeper 72% ceiling where it’s safe to do so.
- Move the interruptible bucket to Spot, starting with CI/CD runners and batch jobs where a two-minute notice carries no real cost, then expanding to training workloads once the team has validated checkpointing behavior.
- Choose 1-year terms before 3-year terms on a first commitment, accepting a smaller discount in exchange for the flexibility to re-evaluate sooner as usage patterns settle.
- Re-run Cost Explorer monthly for the first two quarters after the change, checking actual utilization against the committed spend to catch over- or under-commitment early.
- Reassess annually as 1-year commitments expire, shifting toward 3-year terms only for workloads that have proven stable across the first commitment cycle.
This sequence avoids the two most common mistakes: committing to a 3-year RI before usage patterns are proven, and leaving genuinely interruptible workloads on On-Demand because nobody built a Spot fallback into the deployment pipeline.
The Verdict: Which EC2 Pricing Model Wins in 2026
There’s no single winner, and that’s the honest answer backed by the data above. Spot Instances offer the deepest discount ceiling at up to 90%, but only for workloads built to survive interruption. EC2 Instance Savings Plans and Standard Reserved Instances tie at up to 72%, the best available rate for anything that has to stay running continuously, with Savings Plans holding a clear adoption edge over RIs according to both ProsperOps (38% vs. 18%) and Datadog (59% vs. 15%).
For most teams, the practical verdict looks like a blend: a Compute Savings Plan sized to the stable floor of usage, a smaller EC2 Instance Savings Plan or Standard RI layer for instance families that truly won’t change, and Spot handling anything genuinely tolerant of a two-minute shutdown notice. On-Demand should shrink to the role it’s actually suited for, covering short-term spikes and newly launched workloads that haven’t built up enough usage history to commit against, rather than serving as the default for over half of AWS’s customer base, which is where the data says most organizations currently sit.
Against Azure and Google Cloud, AWS doesn’t hold a meaningful discount-depth advantage anymore. Azure matches AWS’s 72% ceiling on Reserved VM Instances, and Google Cloud edges past AWS on Spot at 91% versus 90%. The real differentiator in 2026 isn’t which cloud publishes the biggest discount percentage. It’s which team actually uses the discount programs available to them instead of defaulting to full price by inertia.
Frequently Asked Questions
What is the biggest discount available on AWS EC2 in 2026?
Spot Instances carry the deepest published ceiling at up to 90% off On-Demand pricing, according to AWS’s EC2 Spot pricing page. Standard Reserved Instances and EC2 Instance Savings Plans tie for the deepest committed-discount ceiling at up to 72%.
Should I choose Savings Plans or Reserved Instances in 2026?
Adoption data from both ProsperOps and Datadog shows the market has moved toward Savings Plans, which matched RIs on maximum discount while adding automatic flexibility across instance types, Fargate, and Lambda. Reserved Instances still make sense for a fixed, unchanging configuration, but most teams starting fresh choose Savings Plans first.
What happens if I use more than my Savings Plan commitment?
Usage above your committed hourly spend bills at standard On-Demand rates. A Savings Plan discounts a dollar amount of usage, not a hard cap on your fleet size, so overshooting the commitment doesn’t block capacity, it just stops getting the discount past that point.
How often are Spot Instances actually interrupted?
AWS doesn’t publish one universal interruption rate because frequency depends on Region, Availability Zone, and instance type at any given moment. AWS guarantees a two-minute interruption notice before reclaiming capacity, but the frequency of interruptions themselves varies with current spare-capacity conditions.
Do Reserved Instances or Savings Plans apply to Spot usage?
No. Spot pricing is independent of both discount programs. A Compute Savings Plan or Reserved Instance can run alongside Spot capacity on the same account, but neither discounts Spot usage itself, and Spot’s own discount doesn’t stack on top of a commitment plan.
Is Azure or Google Cloud cheaper than AWS for committed discounts?
Published ceilings are close across all three. Azure’s Reserved VM Instance tops out at 72%, matching AWS’s Standard RI. Google Cloud’s three-year resource-based CUD caps at 70% for memory-optimized machines, slightly below AWS, while Google’s Spot VM ceiling of 91% edges past AWS Spot’s 90%. None of the three holds a decisive advantage once terms and payment options are matched.
Can Compute Savings Plans cover services other than EC2?
Yes. AWS’s Savings Plans pricing documentation confirms Compute Savings Plans apply automatically across EC2, AWS Fargate, and AWS Lambda under a single hourly commitment, making them the broadest commitment product AWS offers for general compute.
Why do so many AWS customers still pay On-Demand rates?
ProsperOps’ 2024 analysis found 53% of AWS organizations in its sample used no commitment-based discount at all. The likely drivers are uncertainty about future usage, lack of FinOps tooling to analyze historical spend, and simple inertia from never revisiting the default pricing model after initial deployment.