Commitment Discounts in 2026: Read the Exclusion List First

Every commitment discount is sold as a percentage. Up to 72%, up to 66%, up to 90%. Those numbers are real and they are also the least useful thing on the page, because they describe the best case for a slice of your bill rather than the bill.

The number that decides what you actually pay is the scope. Which services the discount reaches, which ones it silently skips, and which line items sit permanently outside every commitment you can buy. That is where the surprises live, and this year both major providers moved the boundary: Azure stopped selling reservations for a list of VM series on 1 July 2026, and AWS shipped EKS charges that no Savings Plan will ever discount.

Prices and policy below came off the vendor documentation on 22 August 2026. Pull your own rates before you commit money.

AWS: three instruments, and one of them is not a commitment

Savings Plans are a pledge to spend a fixed dollar amount per hour for one or three years. You do not pick instances. You pledge, say, $5 an hour of compute, and AWS applies the discount to whatever eligible compute you run up to that amount. Compute Savings Plans span instance family, size, OS, tenancy, and region. EC2 Instance Savings Plans lock to one family in one region and pay more for the rigidity.

Reserved Instances are the older shape: a specific instance type, size, platform, and region. Standard RIs pay deepest with almost no flexibility, Convertible RIs let you swap mid-term for less.

Spot is not a commitment at all. It is the leftover-capacity market, sold at a discount AWS advertises as up to 90% off On-Demand, reclaimable with a two-minute warning whenever AWS wants the hardware back.

The AWS comparison table puts the trade in one line: Compute Savings Plans and Convertible RIs top out around 66%, EC2 Instance Savings Plans and Standard RIs around 72%. Six points is the price of flexibility, and for most teams it is worth paying, because over three years your instance mix will change. You will move to Graviton, you will resize, you will push work onto Fargate. A Standard RI on an m5.xlarge becomes dead weight the day you migrate to m7g. A Compute Savings Plan follows the spend.

What the AWS discount does not reach

Here is the part people find out in month four. Savings Plans are eligible on exactly three services: EC2, Lambda, and Fargate, plus SageMaker AI under its own separate plan. That is the whole list.

RDS, ElastiCache, Redshift, and OpenSearch are not on it. If you want a discount on your data tier, Reserved Instances are the only instrument that offers one, which makes RIs load-bearing rather than legacy. Teams that read “Savings Plans replaced RIs” and cancelled their RDS reservations are the ones with a mystery on the next invoice.

Two more exclusions worth knowing, both stated in the AWS docs. Savings Plans do not apply to Spot usage or to usage already covered by an RI, so double-covering a baseline wastes commitment rather than stacking discounts. And Savings Plans are not a capacity reservation. They lower the price of capacity you can get, not your odds of getting it.

Spot, and how scary the reclaim actually is

The fear is the two-minute notice. In practice AWS publishes historical interruption rates in the Spot Instance Advisor in buckets, under 5% through over 20%, so you can pick instance types that are both cheap and stable before you commit a workload to them. Spot Placement Score gives a near-real-time 1 to 10 signal on whether a request will succeed in a given region or AZ. Neither tool promises anything. Spot is capacity AWS does not currently need, and “currently” is doing the work in that sentence.

What changed the risk profile is not the tooling but the schedulers. Karpenter and EC2 Auto Scaling with mixed instance policies diversify across dozens of instance types automatically, so when one pool dries up the cluster shifts to another. That is what moved Spot from “scary” to “default for anything fault-tolerant” over the last few years.

Which still means: batch jobs, CI runners, stateless tiers behind an autoscaler, data processing that checkpoints. Not your single stateful database, and not a long-running job with no checkpoint. The discount is compensation for interruptibility. Spend it on things that actually tolerate interruption.

Layer by certainty, never by average

The mental model that ties the three instruments together is a usage graph with three bands. A flat floor you always run, a middle that floats around predictably, and spikes on top.

The floor is your safest commitment territory. For the data tier that means Reserved Instances, because nothing else covers those services. For the compute floor it means deciding between deeper and rigid or shallower and flexible, and if you cannot honestly promise an instance family will still be right in three years, take the flexible one.

The float goes on a Compute Savings Plan, where the discount lands wherever the spend goes, Fargate and Lambda included. The spikes go on Spot.

The principle underneath: commit to the trough, not the average, and never to the peak. You can always buy a second tranche once you have watched the pattern for a month. You cannot unwind a three-year plan.

Azure took an instrument off the table

On 1 July 2026 Microsoft stopped selling and renewing Reserved VM Instances for a long list of series. Nothing turned off. No VM rebooted. Reservations you already hold keep applying right up to their expiry, and then on some unremarkable Tuesday your three-year Esv3 reservation lapses and those instances start billing at pay-as-you-go. The auto-renew toggle is still in the portal. For these series it no longer does anything.

The transition guide splits it into two lists, and the asymmetry is the interesting part. One-year RIs are gone for Av2, Amv2, Bv1, D, Ds, Dv2, Dsv2, F, Fs, Fsv2, G, Gs, Ls, and Lsv2. Both one-year and three-year RIs are gone for Dv3, Dsv3, Ev3, and Esv3. So you can still buy a three-year reservation on Dsv2, and you can buy nothing at all on Dsv3, a newer series. Microsoft is steering the v3 general-purpose fleet toward savings plans rather than propping up instance-locked commitments on a generation it wants to age out.

The VMs themselves are not retired. This is a finance event wearing an infrastructure costume, and the gap between the retirement date and the day your particular reservation expires is the entire story. It might be next month. It might be 2029. Sort your reservations by expiration date, and put a named person on every one of them.

The Azure exclusion list, and a door closing in February

Azure savings plan for compute covers Virtual Machines, App Service, Functions premium plan, Container Instances, Dedicated Host, Container Apps, and Spring Apps for Enterprise. The overview page then says the thing worth writing on a whiteboard: savings plan for compute “doesn’t cover software, networking, or storage charges.”

There is now a separate savings plan for databases, one-year only, covering SQL Database, SQL Managed Instance, PostgreSQL, MySQL, Cosmos DB, and SQL Server hourly licenses. Which means the AWS gap and the Azure gap are not in the same place, and a multi-cloud FinOps model that assumes they are will mis-price one side.

Two mechanics decide whether a savings plan saves you anything. Unused hourly commitment expires and does not roll over, so committing at your average rather than your trough burns cash every hour you run below it, for three years. And savings plan purchases cannot be cancelled or refunded at all. Reservations can, capped at USD 50,000 of cancelled commitment per rolling twelve months per billing profile, with Microsoft noting it is not charging an early termination fee today and might charge one later.

Then the change most coverage of the July retirement missed. From 1 February 2027, reservations purchased after that date are not eligible for exchange at all if the service is covered by savings plans, which includes Virtual Machines, App Service, and SQL Database. Reservations bought before that date keep the right to one final exchange. Exchanges are how you move an instance-locked commitment onto modern hardware without eating a refund, so if that is your plan, it now has a deadline attached and a single use.

The bill lines no commitment reaches

EKS is the clearest example of charges that sit outside every discount instrument, which is why teams who did the commitment work still get surprised.

The control plane is $0.10 per cluster per hour under standard support, which is 14 months from a Kubernetes version’s release. After that the version rolls into a 12-month extended support window and the same control plane costs $0.60 per hour. Same cluster, same workload, six times the price, triggered by a date passing rather than anything you did. Twenty clusters drifting past EOL together move from roughly $1,460 to $8,760 a month in control plane fees. No Savings Plan touches it. The only lever is upgrading, which makes the version calendar a cost deadline rather than a maintenance chore.

EKS Auto Mode is the other one, and the pricing page is explicit: the Auto Mode fee is charged in addition to the EC2 instance price and is “independent of the EC2 instance purchase option.” Read that as: your Savings Plan discounts the instance and never the management fee. The fee runs around 12% of On-Demand for typical instance types, so against compute you are already buying at 60 cents on the dollar, the effective surcharge is closer to 20%. Auto Mode can still beat running Karpenter and node lifecycle yourself, which costs engineer-hours instead of dollars. Just do the subtraction against your discounted rate rather than list.

The 2025 additions are worth an audit if you turned them on to try. Provisioned Control Plane reserves dedicated control plane capacity on top of the standard cluster fee, at $1.65 an hour for XL through $13.90 for 8XL, which is about $10,000 a month for a control plane. It earns that when you are hammering the Kubernetes API and it is pure waste on a normal web app. Managed Capabilities bill in two parts, a base rate plus per-resource usage: Argo CD at $0.03 per capability-hour plus $0.0015 per application-hour, ACK and KRO at $0.005 plus $0.00005 per resource-hour. Small per unit, which is exactly how 500 Argo CD applications turn into a few hundred dollars a month for a tool you could self-host on a node you already pay for.

And then networking, which no commitment covers on either cloud. NAT gateways bill hourly plus per GB processed, so image pulls on every scale-up event run into real money, and a VPC endpoint for S3 or ECR takes that traffic off the NAT path entirely. Cross-AZ pod-to-pod traffic bills in both directions, and Kubernetes schedules pods wherever it likes unless you turn on topology-aware routing. A Service of type LoadBalancer per microservice gives you a wall of load balancers, each with its own hourly charge.

Where to start this week

If you have never committed to anything, the first move on AWS that pays back fastest is still a one-year, no-upfront Compute Savings Plan sized to the conservative floor of your EC2 spend. It is flexible, it covers Lambda and Fargate, and no upfront means no big check. Then move fault-tolerant batch and CI to Spot, and add RIs on the data tier once you know its steady size.

On Azure, open Reservations, filter product type to Virtual Machines, and sort by expiration date. Roughly half the teams that do this find something lapsing sooner than they assumed, and the ones who find a v3 series reservation have a decision that got harder in July and gets harder again in February.

Either way, before you buy anything, go read the exclusion list for the instrument you are about to sign. Group your bill by usage type and find the lines the discount will never touch. On most clusters I have looked at, those lines are bigger than the percentage argument you were about to have.