Cloud Computing Trends: Four Predictions Worth Planning Around

Cloud trend articles are a cursed genre. Most of them are written by people who sell cloud services and want you to believe the trend is always "buy more cloud." I have been running infrastructure projects long enough to remember when "the cloud" meant renting a dedicated server by the hour, and I can tell you that the direction of travel is not nearly as linear as the blog posts suggest. Here are four trends I think are real, backed by what we actually see in customer budgets and architecture reviews, plus what to do about them.

Trend one: the repatriation wave is real, and it is not small

For about ten years, the party line was "everything goes to the cloud eventually." That is no longer what sophisticated buyers are doing. We have moved a meaningful number of customer workloads off hyperscalers in the past two years — not because the cloud failed, but because the math for steady-state workloads stopped making sense.

The arithmetic is not subtle. A dual-socket Epyc server with 128 cores and 512 GB of RAM costs about $15,000 once, runs for five years, and draws maybe $2,500 a year in power and cooling. The equivalent sustained compute in a hyperscaler — even with three-year reserved instances and committed use discounts — runs multiples of that over the same period. For workloads that are on 24/7 and do not need elasticity, colo is cheaper by a large margin. Once you factor in egress fees, the gap gets worse.

What to plan around: stop treating cloud as a default. Treat it as a deployment option that earns its place. Build workload classification into your architecture reviews. Steady state and predictable — probably private cloud or colo. Bursty, seasonal, regulated with specific compliance certifications, or genuinely cloud-native — public cloud. The days of "lift everything and figure out the bill later" are over for anyone who has seen a FinOps report.

Trend two: AI is eating the GPU supply and distorting everything else

The GPU shortage is the most economically significant thing happening in infrastructure right now, and it has second-order effects that do not get enough attention. Hyperscalers are prioritizing GPU capacity for their largest AI customers. Everyone else waits in a queue. Regional availability for A100s and H100s is tight enough that we routinely see customers deploying training workloads in whichever region has capacity, not whichever region matches their data residency requirements.

The secondary effect is that specialty providers — Lambda, CoreWeave, RunPod, the Nebius-type shops — are eating a real share of AI workloads that two years ago would have gone to AWS or Azure. These providers offer cheaper per-hour pricing, better availability, and fewer of the compliance knobs big enterprises need. That is fine if you are a research team and not fine if you are in healthcare or finance.

The tertiary effect is that RDNA 4 and other AMD GPU options are suddenly credible. I have a Radeon AI PRO R9700 in my own lab running 35B parameter models on Vulkan with llama.cpp, hitting 48 tokens per second on quantized models. This was science fiction a year ago. ROCm has gotten good enough that the moat around CUDA is narrower than Nvidia's market cap suggests.

What to plan around: if your AI strategy depends on capacity you do not yet have, assume it will be slower and more expensive than the vendor roadmap suggests. Consider smaller, quantized models running on AMD or on your own hardware for inference. Treat GPU capacity as a constraint you plan around, not a commodity you buy on demand.

Trend three: egress fees are finally getting attention

For years, egress pricing was the quiet tax that made hyperscaler lock-in real. Move data out of AWS to anywhere else and the bill stung. Regulators in the EU started asking pointed questions, Cloudflare made a lot of noise about bandwidth pricing, and in the past eighteen months the hyperscalers have actually started changing policy. AWS waived egress fees for customers leaving entirely. Google did something similar. Azure is catching up.

The practical effect is that egress cost is no longer a permanent prison. It is still a tax on interconnection and on hybrid architectures, but the all-or-nothing lock-in story is weakening. We have helped customers move tens of terabytes off hyperscalers in the past year that would have been cost-prohibitive two years ago.

What to plan around: build egress cost into TCO models, and stop assuming that a workload in AWS has to stay in AWS forever. The political and pricing climate has shifted enough that migrations that were financially impossible are now merely annoying.

Trend four: sovereignty is reshaping architecture, not just compliance paperwork

Data sovereignty was, until recently, something a compliance officer worried about once a year. It is now an architecture concern that affects where you deploy, which provider you use, and sometimes whether you use a hyperscaler at all. European customers are asking pointed questions about the CLOUD Act. Canadian customers are reviewing Patriot Act exposure. US state and local governments are asking whether their data can be touched by non-US engineers operating support contracts.

Microsoft, AWS, and Google all now offer sovereign cloud variants in various regions, run by local partners, sometimes disconnected from the global control plane. These are not marketing. They are real, expensive, slower to get new features, and the only legal option for a growing list of workloads. In parallel, a generation of national cloud providers — OVH, Hetzner, Scaleway, and a few others — are growing because "run in Europe, owned by Europeans" is a requirement, not a preference.

What to plan around: if you serve customers in multiple jurisdictions, expect that your cloud architecture will need to fork. The days of "one region for the world" are ending for anyone touching personal data, healthcare, financial services, or government workloads. Build multi-provider and multi-region into your roadmap now, because retrofitting it is painful.

What I am not predicting

I am not predicting that Kubernetes adoption will accelerate. It has peaked in most mid-market shops — the ones who needed it have it, the ones who do not are better off with simpler options. I am not predicting that serverless will take over. It has found its niche in event-driven glue code and stayed there. I am not predicting that quantum computing or blockchain or Web3 will change cloud economics in the next five years. They will not, and anyone telling you otherwise is selling something.

The honest trends are less fashionable than the hype cycle suggests. Cost is back. Sovereignty is back. Hardware ownership is back. AI is distorting everything. That is the landscape your 2023 and 2026 infrastructure planning should account for, and it is a lot closer to 2005 than to the "everything is elastic and nothing is fixed" cloud-native story that was in fashion a few years ago.

Plan for workloads that make sense where they run. Plan for capacity constraints you cannot buy your way out of. Plan for jurisdictional variance. And plan for the fact that the right answer is almost always hybrid, even if your vendors hate hearing you say it.