State of Cloud Computing 2026
Trends and Predictions

Cloud revenue grew again in 2025, and it will grow again in 2026. That number tells you almost nothing about what changed. Underneath it, the composition of spend shifted hard toward accelerated compute, and everything else on the invoice came under a kind of scrutiny it had not faced since the first migrations. Finance functions that never asked about infrastructure in 2019 now ask for cost per tenant, per month, with a variance explanation.

What follows is a practitioner read rather than a market forecast: which architectural defaults have genuinely changed, which trends are far narrower than the discourse around them, and which line items are quietly rewriting design decisions. Where we hold a position, we say so plainly. For roughly ten years the dominant architectural incentive was engineer velocity, under an assumption of cheap capital and effectively unlimited capacity. That produced good things — managed services, elastic scaling, the end of the ticket-driven ops queue — and it produced a habit: buying optionality nobody ever exercised. Three full environments. Five data stores. A service mesh spread across three availability zones. A Kubernetes cluster carrying nine services. An APM contract priced per host, and a warehouse full of events nobody queries.

None of that was irrational at zero interest rates and forty percent growth. It is irrational now. The correction underway is not that anyone is leaving the cloud; it is that the null hypothesis flipped. In 2019 you had to justify not using a managed service. In 2026 you have to justify the second one.

The bill is an architecture document

The most useful shift of the last two years is that cost stopped being a monthly report and became a signal inside the build. Allocation tags enforced in the infrastructure module rather than requested by email. Cost diffs rendered on pull requests. Per-request attribution good enough that an engineer can answer, without booking a meeting, what a feature costs to serve.

The line items that surprise people are remarkably consistent, and almost never the compute:

• Data processing on NAT gateways — on the order of $0.045 per GB on top of the transfer itself. A private subnet pulling container images and calling third-party APIs through one gateway can cost more than the instances behind it.
• Cross-zone traffic, roughly a cent per gigabyte in each direction. A chatty mesh spread across three zones, for availability nobody has measured, is a permanent tax on every internal call.
• Egress at around $0.09 per GB in the first tier, which is why media-heavy products end up on zero-egress object storage or a CDN with committed pricing.
• Observability. Log volume and metric cardinality scale with traffic and with engineer enthusiasm. We have inherited systems where monitoring cost more than the cluster being monitored.
• Idle non-production. Twenty staging databases and a full-size replica of production, running at three in the morning on a Sunday.

The discipline that matters is not a dashboard, it is a unit. Pick the business transaction — an order, a tenant-month, a rendered page, a completed inference — and compute its fully loaded cost, including storage, transfer, observability and third-party calls. Once that number exists, most architecture arguments resolve themselves without anyone having to win a debate about elegance.

Most teams do not have a cloud cost problem. They have a workload nobody has ever measured.

Repatriation is real, and narrower than the discourse

The repatriation story got loud because a small number of teams published real numbers and the numbers were large. They were also specific. The workloads that come back are sustained, predictable, storage- and egress-heavy, and run at a duty cycle high enough that elasticity buys nothing. Move that class onto dedicated hardware and the per-core-hour gap against on-demand instances is genuinely somewhere between three and ten times.

The honest comparison is harder than the headline. Measured against three-year commitments, ARM instances and spot capacity for anything interruptible, the gap narrows to perhaps two to four times. Then subtract the cost of the people who now own a failure domain that used to be somebody else's job: hardware replacement, capacity planning with a lead time measured in weeks, network engineering, and a pager that rings for reasons your team has not encountered in a decade.

Our position: repatriation is the correct answer for one workload class and a fashionable mistake for everyone else. Before anyone models a rack, take the discounts you already qualify for and measure the top three services. In the estates we have reviewed, thirty to fifty percent of spend usually comes out with no architectural change at all — commitment coverage, ARM migration, storage tiering, retention policy, and killing idle non-production. That is less interesting than buying servers. It is also far cheaper, and reversible.

Serverless earned the default

Serverless spent years as a special case: fine for glue, wrong for products, blocked by cold starts and database connections. Both blockers are gone. Snapshot-based initialization and ahead-of-time init have pushed cold starts for typical runtimes into the low hundreds of milliseconds or below. The connection problem was solved twice over — by proxies that pool on your behalf, and by database platforms that speak HTTP instead of a stateful wire protocol with a hard connection ceiling.

The more important change is billing shape. The pathological case for function pricing was always the I/O-bound handler: you paid for wall-clock time while the process sat waiting on a query it did not control. Platforms that bill for active CPU rather than elapsed time, and that pack concurrent invocations onto a single instance, remove that penalty entirely. An endpoint that spends 180 of its 200 milliseconds waiting now costs roughly what it should, which quietly deletes the strongest financial argument against the model.

Where it still does not fit: long-lived stateful connections beyond the platform ceiling, sustained CPU-bound throughput above roughly a third duty cycle, where a reserved instance wins and it is not close, anything GPU-bound, and workloads whose egress dwarfs their compute. Everything else — the CRUD-shaped and event-shaped business software that is most of what actually gets built — should start serverless in 2026. The argument is operational more than financial. Nobody patches it, nobody sizes it, nobody carries a pager for the host.

Managed data services won, and it was not close

Postgres is the default database, and the interesting work is happening in how it is operated rather than in what might replace it. Storage separated from compute. Branching for development environments. Scale-to-zero, which sounds like a rounding error until you notice a staging estate of twenty databases costing nothing between Friday evening and Monday morning. Read replicas provisioned by API call. Point-in-time recovery you did not have to implement, test or explain to an auditor.

The second consolidation is happening inside the database. JSONB absorbed a great deal of document workload, built-in full-text search covers the long tail that Elasticsearch used to own, pgvector with HNSW indexes handles embedding search well past the scale most products reach, and logical replication feeds the warehouse. Each of these is worse than the best specialist tool. All of them together are better than operating five data stores, because the cost of a data store is not its license — it is the backup strategy, the failover runbook, the version upgrade, the schema migration path, and the one engineer who understands it.

The failure mode we see most often is a team adopting a dedicated vector database for two million embeddings. That corpus fits comfortably in the Postgres instance they already back up, replicate and monitor. Specialist stores earn their place at a scale or latency requirement you can state in numbers. If you cannot state it, you do not have it yet.

Kubernetes settles into the niche it deserves

Kubernetes is excellent infrastructure and a poor default, and 2026 is roughly the year that stops being a controversial thing to say. The control plane is not the cost; call it seventy dollars a month. The cost is the second product you now maintain and nobody buys: ingress controller, certificate management, secret injection, policy engine, service mesh, autoscaler, an upgrade cadence of about three minor releases a year with a support window a little over twelve months, and the CRD sprawl that arrives with every operator someone installed to solve a Tuesday.

It earns its place in identifiable situations: a genuine internal platform serving many teams, GPU scheduling and bin-packing where utilization is the entire game, regulated or hybrid environments where the control plane has to live in a specific place, and scale at which a few points of packing efficiency is real money. A company with fifteen engineers and nine services is none of those. Serverless containers give that team ninety percent of the model with a small fraction of the surface area, and the ten percent they give up is almost always something they were not using.

The prediction for 2026 is not about Kubernetes itself. It is that most teams will consume it the way they consume a hypervisor: present, load-bearing, and never directly touched, behind a vendor abstraction or an internal platform that somebody else operates. That is a good outcome. It was always infrastructure rather than a developer experience, and the years spent pretending otherwise were expensive.

Inference is a line item, and line items change architecture

Per-token prices have fallen roughly an order of magnitude per model generation, and it has not helped anyone's bill, because usage grew faster than prices fell. The meaningful change is structural. For a growing share of products, model inference is now a variable cost that scales with usage, sits directly in the request path, and is large enough to appear alongside database and egress in a unit economics model. Once a cost occupies that position, it starts dictating design.

The mechanisms that actually move the number, in rough order of return:

1. 01Prompt caching. Discounts on cached prefix tokens are steep — commonly around ninety percent — which turns prompt layout into an architectural decision. Stable system context and tool definitions first, volatile user content last, and never interpolate a timestamp near the top of a prompt.
2. 02Batch processing. Anything not in front of a waiting human — enrichment, classification, evaluation runs, backfills — belongs on an asynchronous batch path at roughly half price.
3. 03Model routing. A cascade that sends everything to a small model first and escalates on a confidence or validation signal typically ends up serving seventy to ninety percent of traffic on the cheap tier. This is the largest lever most teams have not pulled.
4. 04Doing less model work. A retrieval filter that returns eight good chunks instead of forty mediocre ones is cheaper, faster and more accurate. Context windows grew large enough that teams stopped tuning retrieval, and both quality and cost suffered for it.
5. 05Caching at the boundary. Exact-match and semantic caching for repeated queries, which in support and search workloads covers a larger share of traffic than anyone expects before they measure it.

Latency behaves differently from cost, and you cannot spend your way out of it. A three-step agent loop with a two-second model call per step is a six-second response no matter what you pay, so the architecture has to hide it or avoid it: streaming, optimistic UI, speculative prefetch of the likely next step, or a fundamentally shallower loop. We have rewritten more agent designs for step count than for model quality.

On hardware, the arithmetic is the same as it has always been for capital equipment. Rent until the duty cycle is high and stable — call it above fifty or sixty percent sustained, on a workload you are confident still exists in eighteen months. Below that, reserved GPU capacity is a way of paying for idle silicon at someone else's margin. And most teams should not fine-tune. Prompting, retrieval and routing are cheaper and reversible; a fine-tune is a standing commitment to a model version and to an evaluation pipeline somebody has to keep running.

Adopt now, watch, wait

Adopt now

• ARM as the default instruction set. Graviton-class instances deliver roughly twenty to forty percent better price-performance on typical workloads, and for most stacks the migration is a base image change and a CI matrix entry.
• Commitment coverage and storage lifecycle policy before any re-architecture. Unglamorous, and usually the single largest reduction available.
• Managed Postgres with scale-to-zero for every non-production environment.
• Serverless containers as the default compute for new services, with a documented list of the workload shapes that are allowed to opt out.
• Prompt caching and batch endpoints for every non-interactive model call. This is close to free money and most teams still have not done it.
• OpenTelemetry with an explicit cardinality budget and sampling policy set on day one, not after the first surprising invoice.
• A post-quantum cryptography inventory. Not a migration — an inventory: what uses which algorithm, what is long-lived, and what you do not control. The deadlines are distant; the discovery work is slow and can start now.

Watch

• Durable execution engines. Genuinely good at the problem they solve, and they also introduce a new failure model plus a versioning discipline your team has not practiced. Pilot on one workflow that deserves it before standardizing.
• Confidential computing and TEE-backed inference. Real demand from regulated industries; attestation ergonomics still rough enough to consume a sprint you did not plan.
• Sovereign and EU-region offerings. Procurement pressure in Europe is not going away, and the offerings differ enormously in what they actually guarantee about operator access and jurisdiction. Read the contract, not the landing page.
• eBPF-based observability displacing agent-based APM. The cost profile is attractive and the coverage gaps are real.
• Small self-hosted models for narrow, high-volume tasks such as classification, extraction and routing. The economics are excellent at volume and poor below it, so the threshold question is throughput.
• WebAssembly for compute in the request path. Compelling isolation and startup story, still a thin ecosystem once there is a database behind it.

Wait

• Multi-cloud as a deliberate strategy. Portability costs you the managed services that were the reason to be there in the first place. Accidental multi-cloud after an acquisition is a fact of life; multi-cloud as a negotiating position usually means running everything at the level of the weakest provider.
• Autonomous remediation agents with write access to production. Read-only investigation and proposed diffs: yes, today. Unattended mutation of infrastructure: not yet, and the failure mode is correlated across the fleet.
• Private GPU fleets below a sustained duty cycle you have actually measured rather than forecast.
• Rewriting a working service in a faster language purely for infrastructure cost. Do the measurement first; it is usually a query plan or a retry storm.
• Quantum computing as an engineering concern. The cryptographic implications are worth preparing for. The compute is not a 2026 planning input for ordinary software.

What I would not build today

Trends are easier to state as prohibitions. Given a clean slate and a normal business, these are the things we would decline to build in 2026. The reason in every case is the same: the cost is certain and the benefit is hypothetical.

• A bespoke Kubernetes platform for an engineering organization under about fifty people.
• A self-managed Kafka cluster for throughput that a managed queue and a transactional outbox would handle. Most event volumes described as high sit in the low thousands of messages per second.
• A microservice topology before the domain boundaries are known. A modular monolith on serverless containers costs nothing and preserves the option; splitting early buys organizational independence a fifteen-person team does not need, and charges a network hop for it.
• A separate vector store for a corpus that fits in the primary database.
• Active-active multi-region for a product with a 99.9% target. You are buying a distributed consistency problem in order to solve an availability problem you do not have.
• A fine-tuned model as the first attempt at output quality.
• Authentication. Still.

None of these are absolute. Each becomes correct at some scale, under some constraint, for some team. The point is that the burden of proof sits with the person proposing them, and for most of the last decade it did not.

The through-line

Everything above is one idea applied in different places. The industry spent a decade optimizing for optionality and is now optimizing for cost of ownership, and cost of ownership is dominated by the number of things a team operates rather than the unit price of any one of them. Fewer data stores. Fewer control planes. Fewer bespoke platforms. More managed surface, chosen deliberately, measured in a unit that means something to the business. The teams that will look well-run in 2027 are the ones that can already tell you what a transaction costs.

That bias comes from how we work. Twenty years and more than a hundred projects out of Bucharest, with a small senior core and a wider engineering network, means we inherit as many systems as we start — and inheriting systems teaches you quickly which architectural decisions were load-bearing and which were fashion. So the first question we ask on a cloud engagement is not what to build. It is what the current system costs per transaction, and which three line items account for most of it.