Skip to main content
AWS Cost Optimization

Where AWS Commitment Discounts Do Not Reach

One headline percentage, four different rates underneath it, several services with no coverage at all, and one line where the price moved up 38%.

Mohamed Shehabeldin
Author
Aug 21, 2026
11 min read

Commitment discounts are the least controversial thing in cloud cost work. You promise spend, you get a percentage off. The advice is always the same: raise your coverage.

The part that gets skipped is where coverage cannot go. Every commitment instrument has a boundary, and the boundary is usually a footnote under a headline percentage. If you plan against the headline, you will forecast savings on workloads that were never eligible.

And there is a direction nobody plans for at all: sometimes the published price goes up.

Database Savings Plans: one headline, four rates

AWS announced Database Savings Plans on 2 December 2025. The pitch is up to 35% off in exchange for a committed dollar-per-hour over a one-year term.

Underneath that single number there are at least four different rates:

  • Serverless deployments: up to 35%
  • Instances you size yourself: up to 20%
  • DynamoDB and Keyspaces on-demand throughput: up to 18%
  • DynamoDB and Keyspaces provisioned capacity: up to 12%

So the 35% headline is the serverless rate. If your estate is provisioned DynamoDB capacity, your real ceiling is 12%, which is a third of the number in the announcement. That difference matters when you are sizing a one-year commitment.

The generation floor

This is the one that catches established estates. AWS states that Database Savings Plans offer coverage for Generation 7 and newer instances across all eligible services.

Generation 7 and newer. An r5 is generation 5. An r6g is generation 6. Both fall below the floor and draw no Database Savings Plans coverage at all. Not a reduced rate. Nothing.

Plenty of production database fleets are sitting on r5 and r6g right now, running perfectly well, with no operational reason to move. For those estates the Savings Plan conversation is really a migration conversation, and the discount only starts after the upgrade work is done.

Worth noting the floor applies to instances. Serverless offerings are covered separately with no generation restriction.

Redshift: covered by nothing

AWS offers four Savings Plans types: Compute, Database, EC2 Instance and SageMaker AI. Redshift appears in none of them.

If Redshift is a material line on your bill, no Savings Plan will ever touch it, and a coverage dashboard built around Savings Plans will keep showing that spend as uncovered forever. It is not a gap you can close with the instrument you are already using.

What you buy instead depends on how you run it:

  • Provisioned clusters: reserved nodes, paid No Upfront (monthly over one year), Partial Upfront or All Upfront, on one-year or three-year terms. You are committing to specific node types, not to a dollar amount.
  • Redshift Serverless: a separate instrument again, called Serverless Reservations. AWS says these reduce your compute costs by up to 24% for a one-year term, and up to 45% for a three-year term.

Three different purchase mechanics inside one service. This is the actual complexity of AWS commitment planning, and it is why "increase coverage" is not an instruction anyone can act on directly.

ElastiCache: Valkey only

The ElastiCache entry in the Database Savings Plans list is narrower than the service name suggests. AWS limits coverage to Valkey instances for ElastiCache.

Redis OSS and Memcached are excluded. A fleet on either buys reserved nodes instead, on its own one-year or three-year clock.

The migration detail worth knowing first

If you are weighing a Redis OSS to Valkey migration, check the order of operations, because it works in your favour.

AWS states that Redis OSS reservations automatically apply to Valkey nodes in the same instance family and Region. Same family, an r7g stays an r7g, same region.

So holding Redis OSS reservations and then migrating those nodes to Valkey does not forfeit the discount you already paid for. You do not have to choose between the reservation you own and the engine you want. That removes the usual reason teams defer this kind of migration.

The other direction: GPU Capacity Blocks went up 38%

Every commitment discussion assumes the underlying price is flat or falling. Cloud prices have trended down for so long that "buy later, pay less" is close to instinct. On GPU capacity that instinct is now wrong.

EC2 Capacity Blocks for ML is how you book GPU capacity for a fixed window up front. Take p5e.48xlarge:

  • Before 2026: $34.61/hr ($34.608 precise, in Ohio and the regions matching it)
  • AWS's published rate now: $47.76/hr, in all eleven regions listed

That is up about 38% in the regions that started at $34.61. To be clear about provenance: 47.76/34.61 = 1.3799 is my arithmetic on AWS's published rates. AWS does not state a percentage.

It happened in two moves, and neither was announced to customers

January 2026 was roughly 15%. Reporting at the time noted AWS did not announce the increase to customers; the AWS statement came later, to press. Per-region: Ohio went $34.608 to $39.799, N. California $43.26 to $49.749.

July 2026 was roughly 20%, effective 1 July, covering P5 and P5e. That one checks out cleanly against AWS's own page: 39.799 x 1.20 = 47.7588, and AWS publishes $47.76.

But it was not a uniform 20% everywhere, and this is the part worth being careful about. AWS shows $47.76 for p5e.48xlarge in all eleven listed regions. N. California was $49.749 after January, so it came down about 4%. Measured from before 2026, N. California went $43.26 to $47.76, about +10%, not +38%. No source I could find dates that drop to July specifically.

Eleven regions converging on one rate card is the real story there. Where your capacity sits determines whether this period was a 38% increase or a 10% one.

Two readings of why

AWS's stated reason is that the adjustment reflects the supply and demand patterns expected that quarter. Corey Quinn's counter-reading, reported by InfoQ from a LinkedIn post, is that this was a policy decision, not supply/demand, on the grounds that AWS updated the published base rates on its pricing page rather than letting market rates float.

I do not think you need to resolve that argument to act on it. Either way, a budget that assumes cloud prices only fall is wrong on this line.

October 2026 is already on the pricing page

This is the most actionable thing in this post, and it is sitting in plain sight.

AWS states that reservation prices are updated regularly based on trends in supply and demand for EC2 Capacity Blocks, and then names the next one directly: current prices are scheduled to be updated next in October 2026.

Month given, direction withheld. The page named January 2026 exactly the same way, with no indication of which way it would go. January turned out to be +15%.

Now pair that with this, from the same page:

Your Capacity Block is charged at the prevailing rate at the time of purchase, even if the Capacity Block is scheduled to start after the price is updated.

The purchase date sets the price, not the start date. So if you know you need GPU capacity in Q4 or Q1, buying before the October update locks the current rate for a block that runs later. That is a genuine, documented, dated opportunity, and it is rare to get one this concrete.

It cuts the other way too, of course. If October brings a decrease, buying early costs you. But given January was +15% and July was around +20%, the direction of travel on GPU capacity is not ambiguous right now.

The discount with no commitment attached

Worth ending on the one that requires no forecasting at all. AWS Fargate on ARM/Graviton is roughly 20% cheaper than x86 for the same vCPU-second and GB-second. No term, no commitment, no coverage percentage to manage.

When I moved our own ECS Fargate services to Graviton, the saving was about 20% as advertised. If your images are already multi-arch it is close to a flag flip. Ours were not, and one native dependency with no arm64 build turned out to be the entire migration. That is the honest shape of it: the pricing side is trivial, the build side is where the work hides.

A note on who is advising you

AWS FinOps Agent has been in public preview since 9 June 2026 and was still in preview when I checked. It answers cost questions in plain English and is offered at no additional charge during the preview, which makes it worth using.

Its recommendations come from two complementary sources, Cost Optimization Hub and Compute Optimizer. The documentation lists four categories of opportunity: rightsizing, idle resources, Savings Plans and Reserved Instances, and architecture migration. Graviton migrations and GP2 to GP3 conversions sit in that last one, and those are real cuts to a real bill.

Every category is a move inside AWS, drawn from two AWS catalogues. That is the boundary, and mostly it is an obvious one: nobody expects AWS's own agent to suggest leaving.

The category worth noticing is commitment. The Savings Plans bullet only ever prices additional commitment: current coverage is displayed, and estimated savings are attached to committing more. Reading that page in full on 2026-08-13, no category said "wait", and none said "let coverage lapse".

That absence matters more here than anywhere else, because commitment is the one call where being wrong locks you in for at least a year. No Savings Plans or Reserved Instance instrument offers a term shorter than one year.

This is not a scandal, it is nobody volunteering against themselves. Use it for "what is this charge" and get a second read on "what should I commit to". And apply the same discount to me: I sell a cost scanner, so I carry the mirror image of that bias. Check both against the actual bill.

One caveat on the absence claim above. FinOps Agent is a preview product and its documentation will move. If a defer or lapse category appears later, that paragraph stops being true.

What to check before your next commitment

  1. Break your database spend down by instance generation before modelling a Database Savings Plan. Everything below Generation 7 is ineligible and should be excluded from the commitment sizing entirely.
  2. Split the estate by rate band, not by service. Serverless at 35%, self-sized instances at 20%, DynamoDB provisioned at 12%. One blended number will overstate the saving.
  3. Pull Redshift out of any Savings Plans coverage report. It will never be covered, and leaving it in makes your coverage look permanently broken.
  4. Check which ElastiCache engine you are actually running before assuming the Database Savings Plan applies, and if a Valkey migration is on the roadmap, note that existing Redis OSS reservations carry over.
  5. If GPU Capacity Blocks are on your roadmap for Q4 or Q1, decide before October 2026 whether to buy at today's rate.

Sources

AWS statements are from AWS documentation and pricing pages. The Capacity Block percentages are my arithmetic on published rates, labelled as such above. The January and July increase figures come from press reporting, cited below, and where a single aggregator named additional instance families without corroboration, those were left out.

Topics Covered

AWSSavings PlansReserved InstancesRedshiftElastiCacheGPUFinOps
Found this helpful? Share it with your team.

Ready to Build Something Great?

Our senior engineering pods deliver production-ready solutions using the architectures we write about.

Get Your Free RoadmapMore Articles