The cloud first era is over. AI, regulation, and cost pressure are driving a shift to control first. Learn what changed and how open infrastructure fits.
For the better part of a decade, "cloud first" was the governing principle of enterprise IT. Need compute? Cloud. Need storage? Cloud. New project, new team, new initiative? Cloud first, ask questions later.
It worked. For web applications, SaaS platforms, and general purpose workloads, public cloud delivered on its promise: speed, elasticity, and no procurement cycles.
Then AI happened. And the default stopped making sense.
This shift toward private AI is pushing IT organizations away from a "public cloud first" mindset and toward a "control first" model for AI adoption. IDC FutureScape 2026 projects that 40% of large enterprises will move meaningful AI workloads toward private or hybrid environments by 2028, driven by data governance, sovereignty, and compliance requirements.
The shift isn't anti-cloud. Public cloud still makes sense for burst capacity, experimentation, and workloads where elasticity matters most. But the automatic assumption that every workload belongs in a hyperscaler environment, that's over.
What's replacing it is a more deliberate model. One where infrastructure decisions start with control: control over data, cost, compliance, and architecture. The deployment environment follows from there, not the other way around.
This is what "control first" means. And open infrastructure built on OpenStack and Kubernetes is how organizations are making it operational, providing many of the same capabilities as hyperscaler platforms, but on infrastructure they own, audit, and govern.
This post breaks down what changed, why it changed, and what the new default actually looks like.
§1 What "Cloud First" Actually Meant
"Cloud first" was never a bad strategy. For the problems it was designed to solve, it was the right one.
Before cloud, provisioning infrastructure meant months of procurement, capital expenditure approvals, rack and stack in a data center, and operational overhead that slowed every team down. Public cloud eliminated that friction. Need a server? Spin one up in minutes. Need to scale? Add capacity on demand. Need to experiment? Pay by the hour and shut it down when you're done.
For web applications, databases, SaaS platforms, and development environments, this model was transformative. Teams moved faster. CapEx shifted to OpEx. Infrastructure became someone else's problem, and for most workloads, that was fine.
"Cloud first" also came with an implicit assumption: that public cloud was the right default for nearly everything. The convenience was so significant that most organizations stopped evaluating alternatives. The question wasn't "where should this workload run?" It was "which cloud provider should we use?"
That assumption held for a long time. General purpose workloads are relatively portable. They don't generate extreme data gravity. Their compliance requirements are manageable. Their cost profiles are predictable enough.
Then organizations started running workloads that didn't fit that description. Workloads that were heavier, stickier, more regulated, and more expensive than anything "cloud first" was designed for.
AI changed the requirements. And the default that worked for the last decade is now being re- examined. For a closer look at how this shift is playing out in practice, read Private Cloud Repatriation: Why Workloads Are Coming Home and How to Do It Right.
§2 Why AI Broke the "Cloud First" Model
"Cloud first" assumed workloads were lightweight, portable, and reasonably predictable. AI workloads are none of those things.
They're heavy. Training runs consume dozens or even hundreds of GPUs for days or weeks at a time. Datasets span terabytes. Checkpoints, embeddings, artifacts, and logs accumulate rapidly. These workloads create massive data gravity that ties infrastructure, storage, and compute together.
They're sticky. Once AI pipelines become integrated with a provider's storage architecture, networking stack, identity systems, managed services, and ML tooling, moving elsewhere stops being a migration and starts becoming a re architecture effort. Every proprietary dependency increases the cost and complexity of leaving.
They're difficult to budget. GPU pricing changes quickly. Data transfer fees scale with usage. Idle GPU capacity burns money between workloads. AI infrastructure costs are often volatile enough that forecasting becomes difficult, especially once experimentation turns into production.
They're strategically sensitive. Training data, model weights, prompts, embeddings, and inference logs are increasingly treated as critical business assets. In regulated industries, they can also become compliance and sovereignty concerns. Running those workloads entirely on infrastructure outside your control introduces risks that did not exist with traditional web applications or SaaS platforms.
Most importantly, AI workloads are not generic infrastructure consumers. Performance depends on storage throughput, network latency, GPU locality, scheduler behavior, and resource contention. Infrastructure architecture directly impacts model training efficiency, inference latency, and cost.
"Cloud first" worked well when workloads behaved like commodities. AI workloads do not. They are high value, high cost, operationally demanding, and deeply tied to the infrastructure underneath them.
This does not mean public cloud is wrong for AI. Public cloud still makes sense for experimentation, burst capacity, and elastic demand. But it is no longer automatically the right answer by default.
That shift in thinking is what "control first" is really about. For a deeper look at how GPU dependency creates platform dependency, read GPUs Are the New Lock-In Strategy.
§3 Regulation Is Accelerating the Shift
Even without AI's technical demands, regulation alone is pushing organizations toward greater infrastructure control.
The EU AI Act, DORA, NIS2, and the Data Act all increase requirements around data governance, resiliency, auditability, portability, and operational transparency. Together, they make infrastructure visibility and exit flexibility far more important than they were during the early cloud era.
These are no longer abstract policy discussions. Under the EU AI Act alone, penalties can reach €35 million or 7% of global annual turnover.
What these regulations share is a common expectation: control. Control over where data resides. Control over access. Control over operational resilience. Control over the ability to move workloads without losing continuity or governance.
"Cloud first" assumed those questions could largely be delegated to providers. Regulators are increasingly expecting organizations to prove those controls themselves.
For regulated industries, the implication is becoming difficult to ignore. If infrastructure cannot be audited, data residency cannot be guaranteed, or portability depends entirely on a vendor's terms, then the platform itself becomes part of the risk model.
For a detailed breakdown of how these regulations converge on infrastructure decisions, read Sovereign by Architecture: Building AI Infrastructure for the EU AI Act.
§4 The Cost Reality Is Catching Up
For years, cloud economics favored hyperscalers. Avoid upfront infrastructure costs. Pay as you go. Scale on demand. For general purpose workloads, the model worked well.
AI changed the economics.
GPU infrastructure is expensive. Long training runs generate massive compute bills. Storage costs grow as datasets and artifacts accumulate. Data transfer fees add up quickly. And committed use contracts often lock organizations into spending long before workloads stabilize.
At the same time, cloud costs are rising. Hardware, energy, and AI infrastructure demand are pushing prices upward across the industry.
Meanwhile, open infrastructure has become far more practical. Open source platforms have matured, operations are easier to manage, and the economics improve significantly for workloads that run continuously.
Public cloud still makes sense for burst capacity and experimentation. But for persistent AI workloads, "cloud first" increasingly becomes "most expensive first."
"Control first" means evaluating that tradeoff intentionally, before it shows up on the invoice. For a closer look at the real cost comparison, read The Real Cost of Running AI on Hyperscalers vs. Open Infrastructure.
§5 What "Control First" Actually Looks Like
"Control first" isn't a rejection of cloud. It's intentional placement: the right workload on the right infrastructure for the right reasons.
In practice, it means starting every infrastructure decision with a set of questions that "cloud first" never asked: Who controls the data? Who controls the hardware? Can we audit every layer? Can we leave without re-engineering? What does this actually cost over three years?
The answers determine where the workload belongs, not the other way around.
OpenStack controls the infrastructure layer: compute, GPU allocation, storage, networking, and identity through open APIs. You decide where resources live, how they're configured, and who governs them. No proprietary control planes. No hidden abstractions.
Kubernetes controls the workload layer: scheduling, scaling, and portability through upstream, CNCF certified Kubernetes. Workloads move between environments because the orchestration is open, not vendor locked. Training jobs, inference endpoints, and data pipelines can shift between on premise and cloud without re architecture.
Hybrid by design. "Control first" doesn't mean "private only." It means building an architecture where public cloud is an option, not a dependency. Burst to hyperscalers when elasticity matters. Run sustained workloads on infrastructure you control. Move between environments as business needs, regulations, or costs change. The architecture supports all of it because the foundation is open.
The result is infrastructure where every decision, where to deploy, when to scale, how to comply, when to move, starts with what the organization needs, not what the provider offers.
For more on how this architecture comes together, read OpenStack, Kubernetes, and AI: What 2025 Taught Us About the Future of Cloud.
§6 How Atmosphere Enables the "Control First" Model
Atmosphere by VEXXHOST makes this operational not as a concept, but as a production-ready platform.
The foundation is upstream OpenStack and CNCF-certified Kubernetes. No proprietary forks. No vendor-specific extensions. Every component is auditable, replaceable, and aligned with upstream projects. What runs on Atmosphere runs on open standards.
For AI workloads, the platform delivers GPU passthrough, MIG, and vGPU with NUMA-aware placement. High-performance networking with SR-IOV and DPDK.
Ceph for scalable, egress-free storage deployed alongside compute. The capabilities teams expect from hyperscaler infrastructure, without the lock-in, pricing complexity, or loss of control.
Deployment adapts to where control demands it. On-premise for full sovereignty. Colocation for performance with ownership. Hosted for managed operations without giving up architectural control. The platform is the same across every model. The support is the same. The openness is the same.
For teams that need "control first" infrastructure without building a dedicated ops team, Atmosphere offers a fully managed model, VEXXHOST handles operations, upgrades, and monitoring while your team focuses on the workloads that matter.
"Cloud first" gave organizations speed. "Control first" gives them speed and ownership. Atmosphere delivers both.
For a complete look at the managed model, read The Complete Guide to Managed OpenStack with Atmosphere.
Conclusion
"Cloud first" was the right strategy for its era. It gave organizations speed and agility when that's what mattered most.
The era has changed. AI workloads, regulatory pressure, and cost reality demand something more: control over where data lives, how infrastructure operates, and what the exit path looks like.
"Control first" isn't anti-cloud. It's pro-ownership. The organizations that control their infrastructure will control their AI future.
Explore Atmosphere — cloud infrastructure built for the "control first" era.
