The RAM Shortage Is Now a Line Item on Your Cloud Bill

The RAM Shortage Is Now a Line Item on Your Cloud Bill#

For most of the last decade, memory was the boring part of an instance. You picked a shape, you got the RAM that came with it, and the price drifted down every year. That has reversed. According to TrendForce, DDR4 contract prices climbed 158% and DDR5 climbed 307% between September 2025 and mid-2026, and cloud providers have started repricing hardware accordingly. This is not a spot-market blip that waits you out. It changes which instance shapes are economical, and it makes memory right-sizing the highest-value FinOps work available to most teams this year.

What actually happened#

Memory manufacturers did not lose capacity. They redirected it. High-bandwidth memory for AI accelerators earns roughly two to three times what conventional DDR5 earns per wafer, so fab capacity moved toward HBM while demand for ordinary server DRAM kept growing. Supply for the memory that goes into normal compute instances got squeezed from the side, by a more profitable product line rather than by a shortage of fabs.

The numbers providers are publishing are unusually candid. OVHcloud projects RAM costs rising 250% to 300% by the end of 2026 against a September 2025 baseline, and says it does not expect prices to stabilize before 2028. It has chosen to absorb part of that, targeting an average 9% to 11% increase across Public Cloud, Private Cloud and Bare Metal for hardware deployed between 2026 and 2028. Others moved harder and faster: Hetzner raised prices 30% to 37% in some regions, with later adjustments pushing some VPS lines considerably higher.

On the hardware side the effect is blunt. A server refresh that budgeted roughly $800 to $1,200 for 256 GB of DDR5 ECC RDIMM in early 2025 now faces something closer to $2,000 to $3,500 for the same specification.

Why this one is structural#

Memory has always been cyclical. Prices spike, fabs add capacity, prices collapse, capacity gets idled. The reason this cycle behaves differently is that the demand pulling capacity away is not a normal demand spike, it is a permanently more profitable use of the same production line. As long as HBM out-earns consumer and server DDR5 by that margin, a rational memory maker keeps steering wafers toward it. New capacity is being built, but fab timelines run in years, which is why the provider guidance points at 2028 rather than next quarter.

The practical consequence for planning: do not model this as a temporary surcharge you can wait out with a six-month reservation. Model it as a step change in the price of a resource you have probably been over-provisioning for years.

Where it reaches your bill#

It arrives in three places, and only one of them is obvious.

Instance pricing on renewal. Providers reprice hardware as they deploy it, so the increase reaches you when you move to a newer instance family or when a reservation comes up for renewal, not on your next invoice. Expect cloud infrastructure cost increases in the 5% to 10% range through 2026, with the exact number depending on how much of the component cost your provider absorbs.

Memory-heavy shapes specifically. The premium is on the memory, not on the compute, so it lands unevenly. The gap between a general-purpose shape and a memory-optimized one widens, which changes decisions that were previously close calls. Caching tiers, in-memory analytics, large JVM heaps and Elasticsearch or OpenSearch nodes are where this shows up first.

Kubernetes requests you set years ago. This is the expensive one. Memory requests reserve capacity on a node whether or not the workload touches it, so every over-provisioned request is now buying a more expensive resource. Clusters that were mildly wasteful at 2024 memory prices are meaningfully wasteful at 2026 prices, and nothing in the cluster will tell you.

What actually reduces memory spend#

Start by measuring the gap between what pods request and what they use. On a cluster with metrics-server installed:

$ kubectl top pods --all-namespaces --sort-by=memory | head -20
$ kubectl get pods -A -o custom-columns=\
NS:.metadata.namespace,POD:.metadata.name,\
REQ:.spec.containers[*].resources.requests.memory,\
LIM:.spec.containers[*].resources.limits.memory

Anything requesting a gigabyte and using 150 MB is now a direct cash cost. The usual finding on a first pass is that aggregate requests exceed aggregate usage by two to three times, because requests were set once from a guess and never revisited.

Two corrections are worth making carefully. First, set requests from observed usage plus headroom rather than from round numbers, and keep the limit above the request for anything with bursty allocation. Second, remember that the kernel enforces the limit, not the request, and that a container exceeding its memory limit is killed rather than throttled. The mechanics of that enforcement are worth understanding before you tighten limits aggressively, since an overly tight limit trades a cost problem for an availability problem. Our notes on what cgroup v2 limits actually constrain cover the failure modes.

For workloads where usage genuinely varies, vertical autoscaling recommendations are a better source of truth than any human estimate, with the caveat that the vertical and horizontal autoscalers conflict when pointed at the same metric. We wrote up the thresholds and the conflict in tuning HPA and VPA from production.

The decision, concretely#

• Running Kubernetes with requests you have not reviewed in a year? Start there. It is the single largest pool of memory you are paying for and not using, and the fix costs a pull request.
• Planning a hardware refresh or a reservation renewal in the next two quarters? Price it against current memory costs, not last year's, and check whether your provider absorbs component increases or passes them through.
• Running memory-optimized shapes for a workload that is actually CPU-bound or IO-bound? Re-benchmark. The premium for memory-optimized shapes grew, so a shape choice that was marginal before may now be clearly wrong.
• Buying long reservations to escape the increase? Only for capacity you are certain of. The guidance points at 2028 for stabilization, which is longer than most reservation terms, so this hedges the timing rather than the price. Our guide to reserved, savings plans and spot covers where each commitment actually pays.

The call we'd make#

Treat memory as the constrained resource it now is, and do the right-sizing pass before you do anything clever with commitments. Most teams will find more savings in a week of reviewing Kubernetes requests than in a quarter of negotiating instance discounts, because the waste compounded quietly while memory was cheap and nobody had a reason to look. Then reprice your capacity plan against the 2028 outlook rather than hoping for a return to 2024 prices, because the economics that moved those wafers are not going to reverse on their own.