What your cloud strategy got right, and what it never had to solve
The cloud strategy most enterprises built between 2016 and 2022 was optimized for a world that no longer exists. That strategy answered questions like: how do we move off capex to opex, how do we get elastic scale for web traffic spikes, how do we spread workloads across multiple providers instead of one data center.
AI workloads break the assumptions underneath those answers. Inference at scale behaves nothing like a web request. It’s GPU-bound, not CPU-bound. Cost per unit of work doesn’t fall the way storage and compute did over the last decade.
This is where multi-cloud, as most organizations built it, starts to work against them. A strategy built on lowest-common-denominator features, so workloads stay portable across providers or run on-premises, doesn’t scale to AI, because GPU capacity, model hosting, and inference tooling are exactly where providers differentiate the most. If your team spent the last three years building a pristine Kubernetes and Terraform abstraction layer to stay portable, you built a beautiful, expensive way to be last in line for the newest silicon.
When OpenAI or Anthropic drops a new model, or a provider ships a native fine-tuning optimization, it ages that abstraction layer overnight. Every orchestration tool adopted specifically for cross-cloud consistency was a bet that it could track each provider’s roadmap, and few of those bets accounted for AI’s release cadence. I see architecture review boards every week still trying to force AI workloads through an infrastructure pipeline built for 2019.
Chasing portability across every provider is a losing game.
Data gravity has also flipped the logic. The old rule was move compute to where the data sits. Now, model quality depends on proximity to proprietary data, much of which sits in SaaS platforms and on-prem systems never designed to feed a model pipeline. The architecture question is no longer just where do we run workloads, but where our data actually lives relative to where training and inference happen.
That strategic problem shows up as a concrete tactical one. AI agents call the model on every single interaction, but don’t necessarily touch on-prem data with the same frequency. The real design question becomes how often you cross the network between on-prem data and cloud inference, versus how often the model itself gets called. Every hop shows up directly in cost and latency.
None of this means the old cloud strategy was wrong. It means it was solving last decade’s constraint.
The obvious objection: giving up on multi-cloud reintroduces the lock-in finance spent five years steering the org away from, and not just for negotiating leverage. Regulations like the EU AI Act, and data sovereignty requirements in financial services and healthcare, are real constraints, not excuses. Native data residency and multi-region failover from providers has narrowed this gap that existed in 2016.
Even so, compute lock-in and capability lock-in carry different weight. Frontier capability has moved past being purely a model question: what separates a good AI product from a mediocre one now sits as much in inference infrastructure and native orchestration tooling as in which foundational model you picked. Compute lock-in limits pricing and redundancy. Capability lock-in limits what you can actually build.
If the old strategy was about spreading bets and minimizing infrastructure cost, the new one has to prioritize AI capability first. In practice:
Choose depth over portability. Pick your primary provider based on native access to top-tier silicon and advanced orchestration layers, and build directly into platforms like Microsoft Foundry instead of trying to abstract them away.
Co-locate data and inference wherever possible. Where the data still sits on-premises for an existing app, work out what subset the model actually needs for inference and bring that closer to the model, rather than assuming the whole dataset has to move, or re-architect if that isn’t enough.
Retire tools that can’t keep pace: if your cross-cloud middleware can’t support the native AI features, be it GPU access, models, fine-tuning APIs, evaluations, or orchestration tooling, a provider shipped last Tuesday, it isn’t an abstraction layer anymore. It’s a bottleneck.
Bifurcate rather than flatten the architecture, accepting strategic lock-in for high-value AI, data, and inference workloads, while keeping multi-cloud portability strictly for commoditized and compliance-bound workloads where it still earns its cost.
Integrate, don’t reinvent. Plug AI platforms into the observability, monitoring, and governance tooling your IT teams already run, rather than standing up a parallel operating model for AI alone. IT keeps one set of practices to maintain, developers still get access to the newest platform features, and the business sees value land faster because nobody is waiting on a second stack to mature.
Worth asking in the next architecture review: is our cloud strategy still optimized for the bill, or for the full stack that makes the model useful.
