AWS raised EC2 Capacity Blocks 15 percent in January 2026 and another 20 percent in July while On-Demand and Savings Plans rates never moved, because standard price protection language only covers the two SKU classes AWS did not touch
Two increases in six months hit only reservation products, and every one of them sits inside the net spend baseline that retires your EDP commit. That means a Capacity Blocks hike inflates commit burn without buying you one additional GPU-hour. The fix is a five-line scope amendment to the price protection clause, not a rate renegotiation.
Prepared by Redress Compliance · August 25, 2026 · AWS EDP and private pricing advisory. 20 to 25 EDP negotiations benchmarked 2024 to 2026.
Executive summary
AWS repriced the exact SKU class that standard price protection language does not reach, twice in six months: roughly 15 percent on January 4, 2026 and roughly 20 percent effective July 1, 2026.
On-Demand and Savings Plans rates were confirmed unchanged in both events, which tells you the scope boundary was not accidental.
The load-bearing sentence is not in your agreement at all: the public Capacity Blocks pricing page states that reservation prices are updated regularly based on supply and demand trends, which is AWS's unilateral repricing right sitting outside the negotiated document.
Your EDP price protection clause points at rate cards it can protect and says nothing about the ones AWS reserves the right to move.
Because AWS measures EDP and PPA commit retirement on net spend after RI and Savings Plans discounts, a 20 percent Capacity Blocks increase accelerates commit burn while delivering zero additional compute.
If reservation products are 30 percent of a $10M commit, the July increase alone moved roughly $600K of retirement value from compute you use to price you did not agree to.
A strong outcome is not a lower rate, it is a scope amendment: protection extended to all reservation and metered SKUs, both the reservation fee and the separate operating system fee, with a semiannual cap of 5 percent or CPI plus 2, whichever is lower.
AWS concedes scope far more readily than it concedes points of discount, because scope costs the account team nothing against their discount approval envelope.
What your price protection clause actually covers, and the two SKU classes it never reached
Read your own clause before you read AWS's pricing page. The standard EDP and PPA price protection language is drafted against two things AWS publishes and controls tightly: the public On-Demand rate card and Savings Plans rates.
That is not an accident of drafting, it is the surface AWS is willing to freeze because it moves rarely and moves loudly. Reservation products sit outside that perimeter.
Capacity Blocks for ML, Capacity Reservations.
And UltraServer blocks are priced under a unilateral repricing right that AWS states publicly rather than contractually: reservation prices are "updated regularly based on trends in supply and demand," and the rate you pay is the prevailing rate at time of purchase even if the block starts weeks later.
Worse for the buyer, Capacity Blocks is two-part priced, an upfront reservation fee plus a separately metered operating system charge.
A clause that names "the reservation rate" and stops there leaves the metered leg fully exposed, which is the same structural trap buyers hit on Oracle price holds that cap the license line and ignore support uplift.
If your protection language does not enumerate both legs of a two-part SKU, you have bought half a hold.
| SKU class | Who sets the rate | Standard protection reaches it | What moved in 2026 |
|---|---|---|---|
| EC2 On-Demand | Published rate card, AWS-held | Yes, named explicitly | No change, either event |
| Savings Plans | Published SP rates, AWS-held | Yes, named explicitly | No change, either event |
| Capacity Blocks reservation fee | AWS, unilateral, quarterly review | No, outside named scope | Up ~15% January, ~20% July |
| Capacity Blocks OS fee (metered) | AWS, billed separately | No, and rarely even named | Rides the same repricing |
| Capacity Reservations / UltraServers | AWS, unilateral | No | New SKUs priced at will |
The table's real message is not that two lines moved. It is that the two protected rows and the three exposed rows sit in the same monthly invoice and retire the same commit.
AWS did not need to touch a protected SKU to raise your effective GPU cost, because the growth in your AI spend is concentrated in exactly the rows your clause never named.
The January and July 2026 repricing events, read as a sequencing decision
Treat the two events as one decision made twice, because the scope selection is too clean to be supply-driven. January 4, 2026 lifted Capacity Blocks roughly 15 percent and covered P5en, P5e, P5, P4d, and, critically, Trn2 and Trn1 Trainium instances.
The p5e.48xlarge went from $34.61 to $39.80 per hour, p5en.48xlarge from $36.18 to $41.61. July 1 added roughly another 20 percent and the list was Nvidia-only: P6-B300, P6-B200, P5, P5e, P5en, P4de. Draw the inference a negotiator needs.
A redline scoped to "GPU instance families" would have caught everything in July and missed the Trainium leg in January entirely. Scope your protection by SKU class and billing mechanism, not by silicon vendor.
AWS's public framing was supply and demand, that the adjustment "reflects the supply/demand patterns we expect this quarter." The rebuttal is on the invoice. Base rates moved uniformly across every region in both events.
Genuine scarcity is regional and uneven, showing up first where capacity is short.
A flat global step is a policy decision, and you should say exactly that when the account team opens with the capex narrative and the roughly $200 billion 2026 AI infrastructure commitment disclosed on the February earnings call.
Two increases in six months also tells you the review cadence is semiannual, not annual. Anything you negotiate against an annual repricing assumption is already one cycle behind, and market experience says the third step lands around early 2027.
There is one more read worth carrying into the room. Capacity Blocks was chosen first precisely because it is the most flexible surface AWS controls: dynamic rates, quarterly review, no contractual hold. That makes it the proving ground.
Establish that a reservation-product increase draws no meaningful buyer response and the same logic migrates toward the protected surface at renewal, when your discount band is being reset anyway.
The scope gap is not a drafting oversight you inherited, it is the path of least resistance, and it is the same pattern that shows up across the clauses that decide your next three years of AWS spend.
Protect your AWS EDP commit with 6 flexibility clauses
Six flexibility clauses protect an AWS EDP commit: rollover, carryforward, over commit caps, under commit relief, and clean exit ramps.
Get the white paper →Why the excluded SKU still burns your commit: the net spend baseline problem
The rate increase is the visible damage. The structural damage is that AWS sets EDP and PPA retirement on net spend after RI and Savings Plans discounts, which means every dollar of a Capacity Blocks reservation fee counts toward the number you promised to hit.
Read that against the January and July 2026 events and you get a contract where one party holds a unilateral lever on a line item that satisfies the other party's obligation. AWS reprices the SKU upward, its revenue rises, and your commit retires faster.
Neither movement delivers you a single additional GPU-hour. There is no equivalent lever on your side of the paper. You cannot unilaterally reprice anything, and the growth clauses AWS routinely attaches mean the baseline you are burning against is itself climbing.
Work the arithmetic at a $10M annual commit with a 30 percent reservation mix, which is a common shape for an AI-heavy platform team. That is $3M flowing through Capacity Blocks and $7M through protected On-Demand and Savings Plans surfaces.
The January 15 percent move and the July 20 percent move compound to roughly 38 percent on the unprotected third. Hold GPU-hours flat and that $3M becomes about $4.14M, so the same delivered capacity now retires $11.14M of an $10M commit. You hit your number 11 percent early.
That reads as a win until you notice what happens at renewal: AWS prices the next term off demonstrated spend, and if the agreement carries the 20 percent per annum growth floor AWS commonly demands, your year two commit is set off the inflated figure.
The 15 percent EDP discount you fought for is worth roughly $1.5M against a $1.14M unearned burn. Most of your negotiated concession is consumed by a price movement you never agreed to.
The sequencing tells you this was designed, not incidental.
The analyst read at the time was that AWS moved on Capacity Blocks first precisely because it is the most flexible surface.
Dynamically priced with quarterly reviews and a public page that already reserves the right to update rates, with On-Demand and Savings Plans expected to follow in Q2 to Q3 2026 once the precedent normalized.
AWS's own framing was supply and demand. Corey Quinn's rebuttal is the one to carry into the room: the base rates moved uniformly across every region on the same day, which is a policy decision wearing a market costume.
The pressure behind it is structural, not cyclical. Amazon disclosed roughly $200 billion of AI infrastructure capex for 2026 on the February earnings call.
Capital at that scale has to be recovered through the rate card, and the rational sequence is to recover it first where contractual friction is lowest. Reservation products are that place. Expect a third move around early 2027 on the semiannual cadence the two 2026 events established.
This is why the negotiation is about scope, not rate. Arguing the 20 percent down to 12 percent wins you one cycle and leaves the mechanism intact for the next three. Winning the scope definition means the next increase, on any SKU, is either capped or excluded from your baseline.
That is the same structural fight running through the broader set of AWS Private Pricing Agreement clause redlines, and it produces durable value rather than a one-time credit.
The tell is that AWS repriced the one class of SKU that both sits inside your commit baseline and sits outside your protection clause. That is not coincidence, it is the intersection where a price move is pure margin with zero contractual cost.
Any clause you write by enumerating protected SKUs will be obsolete the moment AWS ships the next instance family.
Treat the excluded SKU as the leverage point. AWS will not concede that reservation products are inside protection as a matter of principle, because the whole point of the carve-out is preserving that lever.
It will concede it as a matter of trade, priced against term length or commit size, and that trade is far cheaper than the compounding you are otherwise absorbing.
The redline: five lines that close the scope gap
Draft protection by exclusion, never by enumeration. The clause should read that price protection applies to all AWS-published rates applicable to Customer's consumption, without carve-out for reservation, capacity, dynamically priced, or subsequently introduced products.
Enumerated lists fail structurally: a clause naming P5 and P5e would have missed P6-B300 entirely, and a clause scoped to GPU instances would have missed the Trainium Trn1 and Trn2 families that January hit and July did not. AWS ships new families faster than you amend paper.
Name the two fee components separately. Capacity Blocks pricing is a reservation fee charged upfront at scheduling plus a metered operating system fee billed separately.
A clause protecting the reservation rate leaves the OS charge fully exposed, and AWS's drafters know exactly which of those two words you wrote.
Set the cap against a semiannual review calendar. Two increases in six months, January 4 and July 1, establish the cadence. An annual cap in a semiannual repricing world protects one of every two moves.
Cap cumulative increases across any rolling twelve months at a single figure, market experience suggests 5 percent is achievable at $10M-plus commits, rather than capping each event.
Add a pre-buy right. Reservations book up to eight weeks in advance on windows up to six months, so a bare right to buy at pre-increase rates covers roughly fourteen weeks of exposure.
Extend the booking window contractually to at least six months at the prevailing rate, and require 90 days written notice of any change so the pre-buy right is actually usable.
Close with equivalent substitution: if a protected SKU is retired or renamed, the successor inherits the protected rate on a per-accelerator-hour basis. Without it, AWS retires P5e, ships P6, and your cap protects a SKU nobody can buy.
The same logic drives the substitution language in a properly built Oracle price hold.
What AWS will say, and what it will actually trade
Expect three responses in sequence, and price each one before you walk in.
First.
The supply and demand defense: the account team will repeat the pricing page language that reservation prices "are updated regularly based on trends in supply and demand," and will point at the roughly $200 billion 2026 AI capex figure Jassy disclosed on the February earnings call as the cost basis.
The rebuttal is already public. AWS moved published base rates uniformly across every region in January, which is a policy decision dressed as a market signal, and the July move covered only Nvidia families while January covered Trainium as well.
Uniform global repricing on a semiannual calendar is administered pricing. Say that out loud, because it reframes the conversation from cost pass-through to unilateral repricing right, and unilateral rights are exactly what price protection clauses exist to constrain.
Second, expect the product-classification argument: Capacity Blocks is a dynamic product sitting outside the pricing schedule your protection clause references, so scope extension is architecturally impossible. It is not impossible, it is inconvenient.
The workable answer is a named SKU schedule with a repricing cap rather than a freeze: an annual increase ceiling on the reservation fee (10 percent is a defensible landing zone against observed 15 and 20 percent moves).
The operating system fee named separately so the metered component does not walk through the gap, and a semiannual review acknowledgment so the cap is not silently doubled by two events per year.
Cap language survives internal review at AWS far more often than freeze language, because it preserves the pricing mechanism while bounding it.
Third, and this is where most buyers lose, AWS will offer discount points instead of scope. Take the arithmetic seriously. Observed EDP bands run 5 to 20 percent, stepped by commitment thresholds, and the account team's approval envelope is narrow inside that.
Two more points on total commit is worth less than a 10 percent cap on a SKU class that just moved 15 and 20 percent inside six months, and the points erode with every subsequent hike while the cap compounds in your favor.
Scope language also has a structural advantage: an account manager can often route contract wording through legal without touching the discount envelope, which means scope is cheaper for the vendor to approve than the equivalent economic value in points.
The same asymmetry shows up in Oracle price hold and uplift cap negotiations, where the cap is approved locally and the rate is not.
Watch the substitute concession carefully. EDP and PPA offers arrive as a mix of credits and discounts, and the composition shifts quarter to quarter depending on what AWS is funding internally.
Credits are a one-time offset against a recurring exposure, so a credit package offered in place of a repricing cap is a bad trade at almost any face value. Model it: a $400,000 credit against a SKU line running $6 million annually is neutralized by a single 7 percent increase.
The last trap is term. The observed exchange rate is roughly 4 to 6 points for moving three years to five.
If AWS offers protection scope contingent on a five-year term, you are buying a clause you should get for free with two extra years of growth-floor lock-in on a GPU market that reprices twice a year. Refuse the linkage explicitly. Scope is a drafting fix, not a purchased benefit.
Evidence base and recurring patterns
January 4, 2026 moved p5e.48xlarge from $34.61 to $39.80 per hour; July 1 added roughly 20 percent across P6-B300, P6-B200, P5, P5e, P5en and P4de.
Benchmarked across 20 to 25 EDP negotiations 2024 to 2026, against louder public claims of 25 to 30 percent that do not survive contact with signed agreements.
The sourcing here is a mix of AWS's own pricing page, contemporaneous reporting on both repricing events, and advisory benchmarking. Three patterns repeat across engagements.
First, the protected surface held: AWS confirmed On-Demand and Savings Plans rates were unchanged in both events, which is the cleanest available evidence that the repricing was targeted at the SKU classes standard protection language never reached.
Second, the operative repricing right lives on a public web page, not in your agreement, which is why buyers who scan only their signed documents miss the exposure entirely, a failure mode we also map in the AWS Private Pricing Agreement redline work.
Third, and most costly, buyers who set the net spend baseline before right-sizing lock inflated commit into a three-year structure and then discover that a Capacity Blocks hike burns that commit faster without delivering a single extra GPU-hour.
Two increases in six months implies a semiannual review cycle, and a third move around early 2027 is the reasonable planning assumption. Draft against that cadence.
The scope pattern also matters: January covered Trainium, July did not, so a redline written around "GPU SKUs" would have caught one event and missed the other. Name families, not architectures. The UltraServer carve-outs make the same point from the other direction.
P6e-GB200 blocks cannot be shared across accounts or within your Organization, and instances must be terminated at least 60 minutes before block end.
Those are product-level exceptions that never appear in a master agreement, which is exactly why the SKU schedule needs named carve-outs rather than a general reference to reservation products.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
Your first five moves
- Pull twelve months of reservation-product spend and express it as a share of net commit retirement, separating the upfront reservation fee from the metered operating system charge, because a clause that protects only the reservation rate leaves the second line item repriceable at will.
- Price the January and July events against your own consumption, not the rate card, so you walk in with a single dollar figure: apply the 15 percent January step (p5e.48xlarge moved $34.61 to $39.80, p5en.48xlarge $36.18 to $41.61) and the roughly 20 percent July step across the P4de through P6-B300 families you actually reserved, then state the incremental commit burn that bought you zero additional accelerator-hours.
- Issue the scope amendment as a redline, not a question, naming reservation fees, OS charges, Capacity Blocks, UltraServer Capacity Blocks and Trainium SKUs explicitly, since the January event covered Trn1 and Trn2 while July was Nvidia-only and any clause keyed to "GPU instances" would have missed half the exposure. The same drafting discipline applies across the AWS Private Pricing Agreement clause set.
- Keep discount points and term length out of this trade, because AWS will offer a point or two of headline discount or four to six points for stretching three years to five rather than concede scope; discounts sit in the 5 to 20 percent band regardless, and a wider commitment window costs you more than the clause is worth.
- Buy a semiannual repricing review right with notice and true-up, since two increases in six months establish the cadence and a third around early 2027 should trigger a contractual conversation, mirroring the mechanics behind an enforceable price hold with uplift caps.
Frequently asked questions
Does AWS EDP price protection cover EC2 Capacity Blocks?
In standard form, no. Price protection language in EDP and PPA documents is typically drafted against On-Demand rate cards and Savings Plans rates.
Capacity Blocks pricing is governed by a public pricing page stating that reservation prices are updated regularly based on supply and demand trends, which functions as a unilateral repricing right outside your negotiated agreement.
That is exactly why the January and July 2026 increases landed there and not on On-Demand.
How much did AWS raise Capacity Blocks prices in 2026?
Roughly 15 percent on January 4, 2026, covering P5en, P5e, P5, P4d and the Trainium Trn2 and Trn1 instances, then approximately 20 percent effective July 1, 2026 across P6-B300, P6-B200, P5, P5e, P5en and P4de.
After the July move, per-accelerator rates ran from $2.214 for P4de to $14.04 for P6-B300, with P6-B200 at $12.355. On-Demand and Savings Plans rates were unchanged in both events.
Why does a Capacity Blocks price increase matter if I am under an EDP commit?
Because AWS measures commit retirement on net spend after RI and Savings Plans discounts, and reservation-product spend sits inside that baseline. A 20 percent increase burns your commit 20 percent faster on that line item without delivering any additional GPU-hours.
If reservation products are 30 percent of a $10M annual commit, the July increase alone shifted roughly $600K of retirement value away from delivered compute.
What should the price protection cap actually say?
Cap increases at the lower of 5 percent or CPI plus 2 points, measured against a semiannual review calendar rather than an annual one, because two increases in six months established a roughly semiannual cadence.
Define the protected scope by exclusion, covering all AWS-published rates applicable to your consumption with no carve-out for reservation, capacity, or dynamically priced products.
Name the reservation fee and the separately metered operating system fee, since protecting only the reservation rate leaves the OS charge exposed.
Will AWS agree to extend price protection to reservation products?
Scope concessions are more achievable than incremental discount points. The observed EDP discount band is 5 to 20 percent stepped by commitment threshold, and account teams operate inside a fixed discount approval envelope, so points above that envelope require escalation.
Scope language does not consume that envelope. Expect AWS to counter by offering credits or additional points instead of scope, and treat that as the weaker trade.
Should I extend my term from three to five years to get price protection?
Not for protection alone. Moving from a three-year to a five-year term typically buys 4 to 6 additional points of discount, but it also extends growth-floor lock-in by two years and increases exit exposure, where penalties can exceed 75 percent of remaining unused commit.
Scope protection should be free. Spend term length on discount or ramp flexibility, not on closing a gap AWS created by drafting.
Can I pre-buy Capacity Blocks ahead of a price increase?
Only partially, and the mechanics limit you. Reservations run up to six months, cluster sizes from one to 64 instances, and blocks are bookable up to eight weeks in advance, charged at the prevailing rate at time of purchase even if the block starts after a price update.
That gives you an eight-week hedge, not a year, which is why a contractual cap matters more than a pre-buy strategy. Note that UltraServer Capacity Blocks cannot be shared across accounts or within your AWS Organization.
