Amazon Just Raised Its 2026 Capex to $220B and AWS's Backlog Is Booked Into 2028. Here's What That Actually Signals for Your Cloud Bill.
Amazon reported Q2 2026 earnings on July 30: total revenue of $200.6 billion, up 20% year over year, and AWS revenue of $42.2 billion, up 37% (the fastest AWS growth in eighteen quarters). On the same call, Amazon raised its 2026 capital expenditure guidance to $220 billion, up from a prior estimate of roughly $200 billion, citing rising memory costs among the drivers. AWS's backlog (contracted work not yet delivered) hit $496 billion, and management said data center capacity for 2027 is already largely reserved, with some 2028 capacity spoken for too. If your product runs on AWS, in any form, the company building your infrastructure just told its investors it can't build fast enough to meet demand.
The numbers behind the headline
AWS is now a $169 billion annualized revenue run rate business, and its operating margin came in at 39% for the quarter (a genuinely strong number for a division that's also scrambling to add capacity). The $220 billion capex figure isn't a routine adjustment; it's a real increase from what Amazon had guided to previously, and management specifically flagged higher memory costs as part of what pushed the number up. That detail connects directly to a story I've already covered on this blog: RAM prices are up roughly 89% this year because AI datacenters are eating global DRAM supply. Amazon's own capital plan just became visible evidence of the same squeeze showing up on the buyer side, not just the component-price side.
The backlog number is the part that should actually get a solo operator's attention, more than the revenue growth. $496 billion in contracted-but-not-yet-delivered work means large customers have locked in capacity that hasn't been built yet, and Amazon is telling investors that some of that capacity reservation already stretches into 2028. That's not marketing language about growth: it's an operational admission that supply is tight enough that the company is pre-selling infrastructure years out.
What tight capacity actually does to smaller accounts
I want to be precise about the mechanism here rather than just gesture at "prices might go up," because that's not usually how a capacity crunch shows up first. When a cloud provider is capacity-constrained, the earliest visible effect on smaller accounts historically hasn't been a sticker-price increase on standard on-demand pricing. It's been things that are easier for a provider to quietly adjust: slower provisioning on certain instance types, less aggressive discounting on reserved instances or savings plans for accounts below a certain committed-spend threshold, and priority given to large committed customers when a specific instance family or region runs short. Big customers with multi-year committed spend agreements get provisioning priority almost by contractual design; everyone else gets whatever's left, which is usually fine until it isn't.
For a solo operator running a typical stack (Lambda functions, an RDS instance, S3 storage, maybe an EC2 box or two), none of this is a five-alarm fire today. It's a signal worth tracking, not an emergency worth acting on this week. The place I'd actually watch is anything you're running on specialized or high-demand instance types (GPU instances especially, given the same AI-driven demand pulling on both compute and memory), where constrained supply shows up first and hardest.
The honest counter-take
Amazon has said versions of "we're capacity-constrained" before during prior demand surges, and standard on-demand and free-tier pricing didn't move as a direct result. There's a real structural reason for that: the entry-level and standard tiers are how AWS acquires the next generation of customers who eventually become the large committed accounts the company actually wants. Squeezing small accounts on price during a capacity crunch would be a strange way to protect a growth pipeline that depends on those same small accounts scaling up over time. It's entirely possible this capex raise and backlog story plays out almost entirely in enterprise contract negotiations and specialized-instance availability, with zero visible change to what a solo operator on standard pricing actually pays over the next year.
I also want to flag that I haven't seen evidence connecting Amazon's capex increase directly to any near-term pricing action on standard tiers: that's my inference from how capacity constraints have historically played out, not something Amazon has said or done yet. Treat the "watch specialized instance types" recommendation as a reasonable hedge based on pattern, not a confirmed forecast.
What I'd actually do
If your product's unit economics assume today's AWS pricing holds flat for the next two years, that's the assumption worth stress-testing now, before a renewal or a capacity crunch forces the question. Concretely: check whether any part of your infrastructure runs on GPU instances or another currently high-demand instance family, since that's where tightness shows up first if it shows up at all. If you're on standard compute and storage (Lambda, S3, standard EC2), this is a "note it and move on" story, not a "change your architecture" story. And if you haven't looked at your actual AWS bill's instance-type breakdown in the last six months, that's a better use of twenty minutes than reading capex speculation, including this article.
Author
Lukas
@lukcombinator