Cloud Strategy for Data and AI

Product terms, prices and regional availability in this article are as of 2 September 2026. INVISOM has no commercial relationship with any cloud provider.

AI did not change the rules of cloud strategy; it raised the stakes

Executives are being told that AI changes everything about cloud. In practice, most of the important questions are the old ones: where your data sits, how much it costs to move, who controls it and how you leave. AI makes each of them more expensive to get wrong.

The evidence from regulators and surveys points the same way. The UK Competition and Markets Authority, in the final decision of its cloud market investigation in July 2025, concluded that AI capabilities currently play a limited role in driving customers' choice of cloud provider, and that infrastructure built on accelerated compute was used mainly by a small number of customers who are AI model developers. Most enterprises consume AI as managed model services, not as rented GPUs. Meanwhile, Flexera's 2026 State of the Cloud survey of more than 750 cloud decision-makers, published in March 2026, found that wasted cloud spend rose to 29%, the first increase in five years, which Flexera attributes largely to surging AI workloads.

The thesis of this article: a cloud strategy for AI should start from data gravity, make the residency-versus-capacity trade-off explicit, and buy portability through data formats and exit plans rather than through abstraction layers. Which cloud has the best model this quarter matters less than it appears. Model rankings change within months; the location of your governed data and your contracts change over years.

Start from data gravity, not from the model

Data gravity is the tendency of applications and services to move toward where large datasets already sit, because moving data is slow, costly and risky. For AI, gravity is stronger than for traditional analytics, for three reasons.

• Retrieval reads data constantly. A retrieval-augmented assistant queries the document store and the warehouse on every request. Putting the model in a different cloud from the data adds latency, transfer cost and a second security perimeter on every call.
• Governance lives with the data. Access policies, classification tags and audit logs are attached to the platform that holds the data. An AI service in another cloud must either replicate those controls or bypass them.
• Embeddings are a second copy. Every document indexed for retrieval becomes a vector representation stored somewhere. That copy needs the same classification and residency treatment as the source.

The practical default is therefore to run AI workloads in the cloud and region where the governed data platform already runs, and to treat any exception as a decision that needs a record. Our comparison of Snowflake and Databricks shows how even within a single platform, AI features can route data differently from storage and SQL.

The residency-capacity trade-off is now explicit

The most important change in cloud AI over the past two years is that hyperscalers have made a trade-off visible in their product menus: the narrower the geography in which your prompts are processed, the less capacity, the fewer models and the higher the price you get.

Microsoft's documentation for its Foundry model deployments is unusually direct about this. Global deployment types may process inference data in any Azure region; data zone types keep it within the US, the EU or Asia Pacific; standard and regional provisioned types keep it within the customer's chosen Azure geography. Microsoft recommends starting with Global Standard because it launches first for new models, has the lowest price and offers the broadest coverage. It states that geography-based deployment types arrive last, have no guaranteed availability date and depend on capacity freed up as older models retire. Batch deployments, which accept a 24-hour turnaround, cost 50% less than Global Standard.

Amazon Bedrock offers a similar choice through cross-region inference profiles. Geographic profiles route requests within a geography such as the US or the EU; global profiles route to any supported commercial AWS region and, according to AWS documentation, cost approximately 10% less. AWS notes that requests stay on its network and are logged in the source region, which helps with audit even when processing happens elsewhere.

Three implications follow for strategy:

1. Residency is a cost line, not a checkbox. Every workload placed on an in-country deployment pays for it in model choice, quota and often price. That is worth paying for restricted data; it is waste for public or internal data.
2. Tier workloads by data classification. Route inference by the classification of the data in the prompt and the retrieval context, not by application. One application can use more than one deployment type.
3. Expect a lag in-region. New models typically appear on global endpoints first. Plan product roadmaps for a gap of months before the newest models are available in a specific country.

Managed AI or self-hosted models

The second strategic choice is how you consume models. INVISOM sees four patterns in practice:

For most enterprises, managed model services from their primary cloud are the right default: they inherit the cloud's identity, network, logging and contractual commitments, and they require no GPU capacity planning. Direct contracts with model labs make sense when a specific model is materially better for a high-value use case and the data classification allows it. Self-hosting open-weight models on reserved GPUs earns its cost only with high, steady volume, strict residency where no managed option exists in-country, or a need to modify the model itself. Our RAG versus fine-tuning comparison covers when changing the model is justified.

The common mistake is to self-host for control before measuring utilization. Reserved GPU capacity bills whether or not it is used; managed services bill per token. The break-even depends on sustained utilization, which most enterprise workloads, with their business-hours peaks, struggle to reach.

FinOps has to cover AI, not just infrastructure

The FinOps Foundation defines FinOps as an operational framework and cultural practice that maximizes the business value of technology and creates financial accountability through collaboration between engineering, finance and business teams. Its framework organizes practice into three phases, Inform, Optimize and Operate, and four domains. The framework's scopes now explicitly include AI alongside public cloud, SaaS, data platforms and data centers.

Flexera's 2026 figures show both progress and the gap. 63% of respondents rely on a FinOps team and 71% have a cloud center of excellence, yet 85% still name managing cloud spend as a top challenge, and waste has risen again as AI workloads grow.

AI breaks some FinOps habits. Token-priced services have no instances to right-size; cost is driven by prompt length, retrieval context, model choice and retries, which are application design decisions. Four practices close most of the gap:

• Tag AI spend to a use case and an owner, not just to a subscription or account. Unit cost per resolved case, document or transaction is the number executives can act on.
• Normalize billing data across providers. The FinOps Foundation's FOCUS specification, now at version 1.4, gives AWS, Azure, Google Cloud, Oracle and platforms such as Snowflake and Databricks a common billing schema.
• Route by need. Use batch and cheaper models where latency and quality allow, and reserve premium models and provisioned capacity for the workloads that justify them.
• Review commitments quarterly. Reserved model capacity and GPU commitments are the AI equivalent of reserved instances, with the same risk of paying for idle capacity.

Plan the exit before you need it

Exit costs have fallen. Google Cloud removed data transfer fees for customers leaving its platform in January 2024; AWS and Microsoft followed in March 2024, each with conditions such as applying to the provider and completing the move within a set window (AWS documents 90 days; Microsoft's window was 60 days until it agreed with the UK regulator in March 2026 to extend it to 180 days for UK customers). The EU Data Act, applicable since 12 September 2025, limits switching charges to the provider's direct costs until 12 January 2027, after which they may no longer be charged at all.

Lower egress fees do not make leaving cheap. Alongside egress fees, the CMA identified technical barriers to switching: differentiated features and interfaces that make services hard to compare or substitute, latency between clouds, and staff skills that do not transfer. The most instructive public example remains 37signals, the company behind Basecamp and HEY: by its own account, moving compute and databases from AWS to owned hardware cut its annual cloud bill from about $3.2 million to $1.3 million, with the remainder being object storage it planned to move next. That is a self-reported case for a stable, predictable workload, not a general rule; but it shows that exit is feasible when the architecture was built to allow it.

The portability that matters for AI comes from four places: open table formats for analytical data, an internal model gateway so applications do not depend on one provider's SDK, embeddings and indexes that can be rebuilt from source documents with a documented pipeline, and infrastructure defined as code. Abstraction layers that try to make every cloud service identical usually cost more than they save, an argument developed in our companion comparison of multi-cloud and concentration strategies.

The Gulf view: new regions, same trade-offs

Saudi Arabia is about to gain two major hyperscaler regions. Microsoft announced on 31 August 2026 that its Saudi Arabia East region, in the Eastern Province with three availability zones, will be available to customers in November 2026. AWS said the same day that its first Saudi region is on track for December 2026, as part of a planned investment of more than $5.3 billion, and that AWS and HUMAIN plan to make up to 50 MW of capacity available in the Kingdom's first AI Zone by 2028.

The new regions change the infrastructure answer for in-country hosting. They do not automatically change the AI answer. Based on how both providers roll out models, the newest models will typically reach global and data zone deployments before any single new region, and in-country processing will start with a narrower catalog and lower default quotas. Platform vendors such as Snowflake and Databricks also add support after a region launches.

For Gulf enterprises the strategic moves are therefore to classify AI workloads by the data they touch, plan for in-country inference for restricted data with the capacity constraints that implies, and revisit placement in 2027 as the regions mature. The legal side of residency in Saudi Arabia and the UAE is covered in our dedicated article on data residency and sovereign cloud, and the NDMO side in our NDMO implementation guide.

What to do in the next 90 days

1. Map data gravity. List where your governed data platforms, document stores and vector indexes run, by cloud and region. That map is your default AI placement.
2. Tier AI workloads by data classification and assign each tier a deployment type: global, data zone or in-country. Write the choice down as an architecture decision.
3. Set a managed-first default for model consumption, with documented criteria for direct lab contracts and self-hosting.
4. Extend FinOps to AI. Tag AI spend to use cases and owners, adopt FOCUS-format billing data, and report unit cost per business outcome.
5. Write an exit plan for the primary cloud, covering data formats, model gateway, index rebuilds and the provider's free-egress process and time window.
6. In the Gulf, schedule a placement review for early 2027 once Saudi Arabia East and the AWS Saudi region are live and their model catalogs are known.

Frequently asked questions

Should we choose our cloud provider based on which has the best AI models?

Rarely. Model rankings change within months, while data platforms and contracts last years. Data gravity, existing governance, residency needs and commercial commitments usually matter more than a temporary model advantage.

Do we need our own GPUs for enterprise AI?

Usually not. Most enterprises consume models as managed services billed per token. Reserved or self-hosted GPUs pay off with high, sustained utilization, strict residency without a managed in-country option, or a need to modify models.

Does keeping data in-country limit our AI options?

Yes, in practice. Microsoft and AWS both offer cheaper, higher-capacity global inference and narrower geographic options. In-country deployments typically get new models later and with lower default quotas, so reserve them for data that requires it.

When will AWS and Microsoft have cloud regions in Saudi Arabia?

Microsoft has said Saudi Arabia East will be available in November 2026, and AWS has said its first Saudi region is on track for December 2026, both as announced on 31 August 2026.

Sources and further reading

• Understanding deployment types in Microsoft Foundry Models, Microsoft Learn, updated August 2026.
• Cross-Region inference in Amazon Bedrock, AWS documentation.
• Cloud services market investigation: final decision report, UK CMA, 31 July 2025.
• Flexera finds cloud value is rising while AI waste grows, Flexera, 18 March 2026.
• FinOps Framework and FOCUS specification, FinOps Foundation.
• Exit fees: Microsoft, as reported by The Register, 13 March 2024; AWS, 5 March 2024; Google Cloud, 12 January 2024; EU Data Act, Regulation (EU) 2023/2854.
• Actions on cloud and business software, UK CMA, 31 March 2026.
• Our cloud exit savings will now top ten million over five years, 37signals, 17 October 2024 (self-reported).
• Microsoft Saudi Arabia East region announcement, Microsoft, 31 August 2026.
• AWS to launch first cloud region in Saudi Arabia by December 2026, Amazon, 31 August 2026.