When cloud prices stop falling: 'ship now, optimise later' just expired

On Saturday 4 January 2026, AWS raised the price of EC2 Capacity Blocks for NVIDIA H200 GPUs by roughly 15% with no formal announcement. In US West (N. California), the p5e rate went from $43.26 to $49.75 per hour. The Register spotted the change the following day, and the notable part is not the 15%.

The notable part is the direction of the arrow. For about twenty years, cloud compute prices moved essentially one way: down. AWS announced hundreds of price reductions; each hardware generation was cheaper than the last per unit of performance. This is the first time a flagship service has publicly gone the other way.

And it is not alone. OVHcloud's CEO, Octave Klaba, publicly forecast 5–10% increases across all providers between April and September 2026, driven by 15–25% inflation in server hardware costs — RAM and NVMe drives pulled up by demand for AI infrastructure.

The assumption that just broke, and why it matters more than 15%

For fifteen years, every infrastructure plan has rested on an unspoken assumption that almost nobody writes down: prices will get cheaper. That assumption justified an approach that made perfect commercial sense — ship the product first, optimise the cost later. If an architecture costs $10,000 a month today, the same architecture will cost less in two years even if you do nothing at all. The falling price curve was a quiet subsidy on every hasty decision.

When the curve turns, that subsidy disappears — and reverses sign. Waste no longer shrinks by itself over time. It grows. An architecture carrying 30% excess at 2025 prices carries more than 30% in money terms at 2027 prices, with nothing about the system having changed.

This is why this article is not a list of savings tips. Fifteen percent is not large on its own. Losing a self-correcting mechanism that has been running quietly for two decades is the real change.

The invoice does not tell you where the money goes

Industry surveys put average waste in a cloud bill at roughly 28–34% — idle resources, over-provisioned resources, and orphaned resources nobody uses any more. Average budget overrun sits around 17%. Broken down further, three sources are consistently recorded:

• Idle or stopped resources — roughly 10–15% of the monthly bill. The instance still exists and still bills, while serving nothing.
• Over-provisioned compute — a further 10–12%. The instance genuinely runs, but larger than needed, usually because the size was chosen once at build time and never revisited.
• Egress and inter-region data transfer — around 3–6%. Smaller than the other two, and the hardest of the three.

That third one deserves separate treatment, because it is a different kind of thing. The first two are *resources* — visible on a dashboard, switchable, resizable. Data transfer cost is not a resource. It is a direct consequence of where you put your services, and it appears on no utilisation screen. You cannot turn it off. You can only change the design that produced it.

Accumulated storage belongs to the same family: snapshots of instances long deleted, logs kept forever because nobody set an expiry, and copies of real data in test environments. We raised that last one in the article on the personal data protection law from a different angle — as a compliance risk. It turns out to be a line on the invoice too, and one clean-up addresses both.

The first reflex when prices rise is the wrong one

Faced with rising prices, most organisations reach for the same lever: lock in the rate. Buy reserved instances, sign a savings plan, commit for one to three years in exchange for a discount. As a pure financial transaction, that is reasonable.

The problem is that it optimises along the wrong axis. A long-term commitment reduces the unit price of the resources you currently run. It does not ask the more important question: *should that be running at all*. Taking 30% off a cluster that should not exist is still spending money — just more cheaply, and now for three years.

Worse, it freezes exactly what you were trying to change. Once a commitment is signed against a particular infrastructure shape, every re-architecture proposal has to answer "what about the commitment we already paid for?" — and that question usually wins, including when it should not. A variable cost has just been converted into a fixed one, precisely when flexibility matters most.

There is a clear exception: workloads that have run steadily for months, that have been measured, and that sit in no change plan. For those, committing is the right call. The common mistake is committing against the *entire* bill because the discount on the whole looks more attractive.

Zero waste is not the target

A point rarely made in cost-optimisation writing: organisations that have reached the highest maturity in cloud cost management still waste 14–18%, against an average of roughly 27%. They are not heading for zero, and they are not trying to.

The reason is that some of that waste is genuinely buying something. Headroom buys the ability to absorb a spike. An always-warm staging environment buys release velocity. A replica that is never read buys the on-call team a quiet night. Provision exactly to average demand and you have no slack — and you will discover that on the worst possible day.

So the right question is not "how do we get waste to zero" but "what is this line buying me, and what happens if it goes". Whatever answers that is insurance and should stay. Whatever cannot is pure loss — and in practice most of it is a staging environment running 24/7 to serve an eight-hour working day, snapshots of instances that no longer exist, and services belonging to a project that ended last quarter.

This distinction matters because it sets the order of work. A cutting campaign that does not separate the two will cut the slack as well — and the next incident will cost more than everything the campaign saved.

Cost you cannot allocate is cost you cannot reduce

The FinOps Foundation's State of FinOps 2026 report records 50% of practitioners ranking "workload optimisation and waste reduction" as their current top priority. The more interesting detail sits in the commentary: they say the large, obvious waste has already been cleared; what remains is many smaller items that are much harder to capture.

That holds for organisations that have been through a round of optimisation. For most companies that never have, the easy portion is entirely intact — and the reason is rarely a lack of technical understanding. It is intact because nobody owns the number. The invoice goes to finance, which cannot tell which line corresponds to which service. Engineering knows which services are theirs but never sees the invoice.

So the first step is not cutting but assigning ownership: each cost line to a specific business owner. The hardest part — and the part that actually defines maturity — is shared infrastructure: one Kubernetes cluster serving five teams, one database serving twelve services, one message queue used system-wide. Tagging does not solve these; you need an allocation rule the parties can live with, even an imperfect one. For a shared cluster, node pool and per-team quota design is where allocation becomes feasible rather than a spreadsheet estimate.

An approximate allocation rule that everyone has agreed to is worth more than an exact number nobody uses to make decisions.

The fastest-growing front: GPUs

While most cost tooling and process was built for ordinary virtual machines, the fastest-growing line item sits elsewhere. Average GPU utilisation is recorded at around 23% — meaning roughly 77% of paid-for capacity is running nothing.

That figure is not purely an operational failure. GPUs are far harder to share than CPUs: their memory does not stretch the way system RAM does, and a training job occupies the device wholesale for hours. But the gap between 23% and a reasonable figure is wide, and most of it comes from three habits: sizing GPUs to a training job's peak and leaving them that way when the workload shifts to inference, not separating the training queue from the serving queue, and choosing devices by the maximum memory ever required rather than by the actual distribution of demand. We wrote separately about how VRAM and HBM decide the cost of running AI — most of the expensive decisions are made at device selection, before any cost line exists.

Also from State of FinOps 2026: 98% of organisations say they actively manage AI costs, up from 63% in 2025 and 31% in 2024. Yet the top three difficulties they name are seeing the cost, allocating it, and measuring the value it produces.

Read those two sentences together and the real state of things is clear: almost everyone says they are managing something most of them cannot yet see. That is not dishonesty — it is a fair description of a field whose pricing models are still being invented, where tokens, GPU-hours, training and inference are billed differently by every provider.

The Vietnamese context: pressure from two directions

Vietnam's cloud market is estimated at roughly $1.5 billion in 2026, growing at a compound rate of about 20–25% a year over 2023–2028. It is a market expanding quickly, and most of the businesses in it have never been through a cost-optimisation round.

What makes the Vietnamese context distinct is that pressure arrives from two directions at once. One is rising prices from foreign providers — the global trend described above. The other is data localisation requirements, which can force part of a system to move regardless of cost. Domestic press coverage calls this a double squeeze, and additionally relays a Gartner forecast of very steep rises in DRAM and flash memory prices during 2026 — a figure we pass on second-hand, unverified against the original report.

The practical consequence: this is the worst possible moment to sign a three-year commitment against a specific geography. If regulation requires Vietnamese users' personal data to sit in-country, a commitment in a foreign region cannot be relocated — it simply becomes a sunk cost alongside the new one.

The migration toward domestic providers — VNPT, Viettel, FPT — is happening for this reason more than for price. The common arrangement today is to keep foreign services for what only they offer (AI model APIs, international SaaS) and move sensitive data and the core platform onto domestic infrastructure. If you are weighing that step, the hard part is not the cost comparison but moving without stopping the system — that is a dual-write, backfill and cutover problem, not a price-list problem.

Four measurements for one afternoon

• Attribute every invoice line to a business owner. Which product, which team, which customer. Write down the part you cannot attribute — that is the most important part, because cost nobody owns is cost nobody is responsible for reducing.
• For each idle line, ask what it is buying. Spike absorption? Release velocity? The on-call team's sleep? What answers is insurance and should stay. What cannot answer is pure loss and should go first.
• Separate out data transfer and accumulated storage. Neither sits on a utilisation dashboard, because neither is a resource you can switch off. They only shrink when the design changes — and they are where cost grows most quietly over time.
• Re-examine every long-term commitment against two questions. How long has this workload been stable? And if regulation forces a relocation in the next eighteen months, is this commitment still usable? Commit for what answers both well; keep the rest on demand.

Conclusion

AWS raising one GPU line by 15% on a Saturday is not a large event. What is large is what it signals: a self-correcting mechanism that ran quietly for twenty years has stopped.

Through those twenty years, "ship now, optimise later" was a sound strategy — not because engineering teams were careless, but because the falling price curve genuinely paid part of the bill for moving fast. That was borrowed subsidy, and it is running out.

The list of things to do holds no surprises and needs no expensive tooling: know who each dollar belongs to, separate slack from pure loss, measure the two costs that never appear on a dashboard, and do not lock yourself into an infrastructure shape you have not validated. None of it is new. It is only that postponing it is no longer free.

If you want to know what share of your infrastructure bill can actually be allocated — a number that tends to surprise people more than the total does — get in touch to review a specific system, or see KonexForge's Server & Database and Optimization Loop capabilities.