On this page · 10 sections
Summary. On July 30, 2026 Amazon reported that AWS's remaining performance obligations, the signed customer contracts it has not yet delivered, reached $496 billion at the end of the second quarter, up from $364 billion a quarter earlier. That is a $132 billion jump in three months. AWS revenue grew 37% year over year to about $42.2 billion, and Amazon raised 2026 capital spending to about $220 billion, citing higher memory costs. Chief executive Andy Jassy told investors that even at that spend, AWS would not have enough capacity to meet demand, and the company said much of 2027 capacity is already reserved with some of 2028 spoken for. For anyone renewing an AWS commitment in the next year, the use has shifted. This is a FinOps playbook for locking the right commitments before the crunch reaches your renewal.
The plain version: AWS has pre-sold more capacity than it can currently build, so scarce capacity now goes to customers who commit. Waiting for prices to fall or capacity to open up is the weak position. The strong position is a deliberate commitment plan, matched to your real workload, signed before demand prices you out.
What the $496B backlog actually is
Remaining performance obligations, or RPO, is an accounting figure for revenue under signed contracts that a company has not yet recognized. For AWS it is the clearest public measure of pre-sold cloud capacity. At the end of the second quarter of 2026 that number stood at $496 billion, against $364 billion three months earlier, a single-quarter increase of $132 billion (Tech Times). For scale, Alphabet's cloud backlog also grew in the same period, but by roughly $50 billion, a smaller move in dollar terms (Global Data Center Hub).
The demand behind that backlog is not hypothetical. AWS revenue rose about 37% year over year to roughly $42.2 billion in the quarter, its fastest growth in years, and Amazon lifted 2026 capital expenditure guidance to about $220 billion from about $200 billion (CNBC). Jassy said on the earnings call that the backlog is "very substantially continuing to grow," and that even the raised capital plan would not be enough to serve near-term demand (Fortune).
Two facts from that call matter most for planning. Amazon's finance chief said much of 2027 capacity is already reserved and some 2028 capacity is spoken for (CNBC). And the capex increase was driven partly by higher memory costs, the same memory shortage now raising server prices across the industry, which we cover in the 2026 RAM shortage. Scarce, expensive components plus pre-sold capacity is a seller's market.
Why this is a capacity problem, not just a demand story
A backlog by itself is good news for a vendor. The reason it matters to buyers is the pairing: record demand alongside an explicit statement that supply cannot keep up. When a provider tells the market it is capacity-constrained into 2027, three things follow for customers.
Cheap, uncommitted capacity gets rationed first. Providers protect committed customers when supply is tight, so on-demand access to the most contended instance families, especially accelerated computing, becomes least reliable exactly when you most want it. Committed customers move to the front of the line.
List prices and the premium for guaranteed capacity tend to firm up. Higher input costs and pre-sold capacity reduce the pressure to discount. The days of assuming next year's rate card will be cheaper are, for the contended families, over for now.
And renewal use shifts toward the provider. If your enterprise agreement is up for renewal in 2026 or 2027, you are negotiating into a market where the provider has a record backlog and limited spare capacity. That is a weaker spot than the last cycle, and it rewards planning ahead of the clock.
What it means for your cloud bill
Translate the macro into your invoice. If your workload is steady and cloud-native, your risk is paying on-demand rates for capacity you could have committed at a discount, and losing access to preferred instances during contention. If your workload is AI or GPU-heavy, your risk is not price at all, it is availability: you may simply not get the accelerators when you need them without a reservation. If your workload is spiky and unpredictable, over-committing is the risk, because a commitment you cannot use is pure waste.
The through-line is that a commitment is now doing two jobs at once: it lowers your unit price, and it secures capacity you might otherwise be denied. In a slack market those are separate concerns. In the 2026 market they are the same decision.
The AWS commitment toolkit
AWS gives you several instruments, and they are not interchangeable. The most common planning error is treating a Savings Plan as if it guarantees capacity, or buying Reserved Instances for flexible compute that a Savings Plan would cover more cheaply. Here is how the vehicles actually differ.
| Vehicle | What you commit to | Typical discount | Capacity guarantee | Best for |
|---|---|---|---|---|
| Compute Savings Plans | A dollar-per-hour spend, 1 or 3 years | Up to ~72% | No | Flexible EC2, Fargate, Lambda baseline |
| EC2 Instance Savings Plans | Spend within an instance family/region | Up to ~72% | No | Steady workloads on a known family |
| Standard Reserved Instances | A specific instance type in a region | High, less flexible | Yes, in an Availability Zone | Data tier and capacity-sensitive nodes |
| On-Demand Capacity Reservations | Reserved capacity, no term lock | None by itself | Yes | Guaranteeing capacity, paired with a Savings Plan |
| EC2 Capacity Blocks for ML | A future block of GPU capacity | Reservation-based | Yes, for the window | Scheduled AI training and inference |
| Enterprise / private pricing agreement | Multi-year account spend | Negotiated, account-wide | Negotiated | Large, predictable total cloud spend |
Sources: Holori, finops.qa, Finout.
The key distinction is capacity. A Savings Plan is a billing discount with no capacity assurance; it lowers the rate but does not hold a server for you. Only a Reserved Instance or an On-Demand Capacity Reservation reserves capacity in an Availability Zone, and for scheduled GPU work, EC2 Capacity Blocks reserve accelerators for a defined window (Holori). In a constrained market, pairing a Savings Plan for the discount with a capacity reservation for the guarantee is the combination that both saves money and secures the machine.
A FinOps playbook to lock commitments before 2027
You do not need to predict AWS pricing to protect your budget and your capacity. You need to commit deliberately, to the floor of your demand, before the renewal clock forces a worse deal.
Start by measuring your committed-usage coverage and your steady baseline. Pull the last 90 days of usage and separate the always-on floor from the variable top. The floor is what you commit; the top stays on-demand or spot. Most teams discover a large, stable baseline running at on-demand rates, which is the cheapest saving available this year.
Make Compute Savings Plans the default commitment vehicle for that baseline, because they follow you across instance families, regions, and services as your architecture changes, at discounts reported up to about 72% (Finout). Size the commitment to the floor you are confident about, not the peak; you can always add a second plan as confidence grows, but you cannot easily unwind an oversized one.
Separate capacity from discount for anything contended. For GPU and accelerated workloads, book capacity explicitly through On-Demand Capacity Reservations or EC2 Capacity Blocks for ML, and layer a Savings Plan on top for the rate. Do not assume a Savings Plan will find you a GPU during a shortage; it will not. Our analysis of EC2 capacity blocks and GPU pricing covers the booking mechanics in detail.
Sequence your renewal ahead of the crowd. If your enterprise agreement renews in 2026 or 2027, open the conversation early, while you still have alternatives, rather than at the deadline when the provider knows you are locked in. Model the whole commitment against realistic growth, not a best case, and keep an unused-commitment alarm so waste is caught in weeks, not at true-up.
Match the vehicle to the workload rather than buying one instrument for everything. The table below is the short version.
| Workload | Commitment vehicle | Term | Why |
|---|---|---|---|
| Steady baseline compute | Compute Savings Plan | 1-3 years | Best discount, follows architecture changes |
| Known-family steady load | EC2 Instance Savings Plan | 1-3 years | Slightly deeper rate on a fixed family |
| GPU / AI training | Capacity Blocks or ODCR + Savings Plan | Window or 1 year | Secures scarce accelerators, then discounts |
| Data tier (databases, cache) | Reserved Instances | 1-3 years | Capacity guarantee where it matters |
| Uncertain new project | On-demand, then commit later | None yet | Avoid over-committing before the pattern is clear |
For a fuller method on sizing commitments and cutting waste, our guide to cloud FinOps for Indian teams walks through coverage targets, and the AI capex question for cloud budgets explains how hyperscaler spending feeds back into the rates you pay.
India-specific considerations
For Indian teams the commitment decision carries an extra layer. AWS bills in dollars, so a multi-year commitment is also a multi-year currency position; a rupee that weakens over the term raises the real cost of a plan you have already signed. That argues for sizing commitments to a confident baseline and revisiting coverage each quarter rather than locking a large three-year plan in one move.
Data residency also shapes the options. Where personal data must remain in India under the Digital Personal Data Protection Act 2023, your region choice is constrained before economics enter, and capacity in a specific Indian region can be tighter than in larger global regions. For regulated, steady, capacity-sensitive workloads, that strengthens the case for early Reserved Instance or capacity reservations in the required region, and for evaluating domestic alternatives. Our comparison of India GPU cloud rental pricing covers where local capacity is competitive this year.
The workable Indian approach is a hybrid commitment: a Compute Savings Plan sized to the confident baseline, capacity reservations in the required region for regulated or GPU workloads, and a quarterly review that adjusts coverage as the rupee and the workload move.
Common mistakes to avoid
The expensive errors in a constrained market are predictable. Buying a Savings Plan and assuming it guarantees capacity is the most common; it does not, and you can still be denied a contended instance. Over-committing to a three-year plan sized to peak demand rather than the floor turns a discount into stranded spend. Waiting until the renewal deadline to negotiate hands the provider maximum use in a year when it already holds a record backlog. And ignoring the split between baseline and variable load leads teams to either under-commit, paying on-demand for a stable floor, or over-commit, paying for capacity they never use. Each of these is avoidable with a coverage measurement and a plan sized to real usage.
FAQ
How eCorpIT can help
eCorpIT is a senior-led engineering organisation in Gurugram that helps teams plan AWS commitments through a tightening market. We measure your committed-usage coverage, separate steady baseline from variable load, size Savings Plans to a confident floor, book capacity reservations for GPU and regulated workloads, and sequence enterprise renewals before the deadline erodes your use. As a CMMI Level 5 and ISO 27001:2022 certified team, we work to a documented process and design for data residency where it applies. To pressure-test your 2026-27 AWS commitment plan, contact us.
References
_Last updated: August 2, 2026._
