AWS or Azure for AI workloads: how to choose

The AWS or Azure question often arrives as a debate: one account team makes its case, an engineer has a preference, and someone forwards a benchmark. For an IT or operations leader, a narrower question is more useful. Where will this AI workload be easiest to secure, connect and operate, given the systems and people you already have? This article works through the factors that usually decide it, without pretending there is a universal winner.

Does the choice of cloud still matter for AI?

Less than many people assume, at least for model access. Amazon Bedrock and Microsoft Foundry (formerly Azure AI Foundry) are both managed services that host models from several providers under one service and one bill. As of September 2026, the Bedrock catalog includes models from Amazon, Anthropic, OpenAI, Meta, Mistral AI, DeepSeek and others. Foundry offers Azure OpenAI models, models sold by Azure from providers such as DeepSeek, Meta, xAI and Mistral, and Anthropic's Claude models through partner offers.

The cloud still matters, because the model is a small part of a production system. Identity, data location, networking, logging, security review and contracts all sit with the cloud, and they are much harder to move than a model call. Our guide to running AI in production on AWS and Azure covers that full architecture.

One idea explains most good decisions here: data gravity, the pull that large or sensitive datasets exert on where applications run. Moving data between clouds is slower, riskier and needs its own security review, so AI usually belongs near the data it reads.

What should decide between AWS and Azure for AI?

Where your identity and Microsoft 365 estate live

If employees sign in with Microsoft Entra ID and your documents live in SharePoint and Teams, Azure keeps an AI workload inside the same identity and access model. Foundry supports keyless authentication with Entra ID and role-based access, which removes API keys from the picture. AWS can still work well in a Microsoft-centered company: IAM Identity Center can federate with Entra ID through SAML and SCIM. That federation is one more integration to configure, monitor and audit.

Where your applications and data already run

If your core applications, data warehouse and engineers are already on AWS, Bedrock sits alongside them, inside the IAM, logging and network controls your team already operates. Sending that data to another cloud to reach a model adds a network path, a second set of permissions and a new security boundary to review. The same logic runs in reverse for an estate built on Azure.

Which specific models you need

Provider names are no longer enough. Check four things for the exact model you plan to use:

• Availability in your region and deployment type, not just in the catalog.
• Hosting. Claude models in Foundry come in two versions: some run on Azure infrastructure end to end, others on Anthropic's infrastructure outside Azure.
• Data retention. On Bedrock, some newer models require AWS to retain inputs and outputs for up to 30 days for human review as a condition of access.
• Lifecycle. Generally available models on Foundry retire 18 months after launch, or 12 months for models from Anthropic, DeepSeek, Fireworks and Mistral AI. On Bedrock, models launched from September 7, 2026 get a Legacy notice period of 6 months or 45 days before end of life.

Where prompts and data can be processed

Selecting a region does not by itself fix where inference happens. On Azure, Global deployment types may process prompts in any Azure region, Data Zone types stay within the US, EU or Asia Pacific zone, and Standard types stay within your chosen geography. Microsoft also notes that new models arrive in Global deployments first and in geography-based deployments last, with no guaranteed date. On AWS, geographic cross-Region inference keeps processing within a geography such as the US or EU, while global inference can route to any supported commercial Region. If you have strict residency requirements, confirm that the model you want is offered in a compliant deployment option today.

What your compliance scope already covers

If your security team has already reviewed one cloud, with policies, logging and audit evidence in place, adding AI there reuses that work. A second cloud usually means a second review. Whichever you choose, confirm that the specific AI service, and not just the cloud provider, is covered by the attestations and contract terms your auditors and customers rely on.

What your team can operate

Someone has to run the workload after launch. Skills rarely transfer one to one: IAM policies differ from Azure role-based access control, AWS CloudFormation templates differ from Azure Bicep, and each cloud has its own monitoring tools. A cloud your team already operates will usually be cheaper to run safely than one that looks slightly better on paper.

What your agreements and commitments say

Enterprise agreements can tilt the decision. Under a Microsoft Azure Consumption Commitment (MACC), eligible Azure Marketplace purchases count toward the commitment, and Microsoft lists Claude usage in Foundry, billed in Claude Consumption Units, as MACC-eligible. If you hold an AWS commitment, ask your account team how Bedrock usage, including third-party models, is treated. Ask both about funding or credits for early projects, and read what they require.

How the AI connects to ERP and CRM

Most ERP and CRM systems expose APIs that either cloud can call, so integration rarely decides the matter alone. Managed connectors can shorten the work: Amazon AppFlow lists connectors for Salesforce, SAP OData, ServiceNow and Microsoft Dynamics 365, and Azure Logic Apps offers connectors for services such as Office 365, Dynamics and Salesforce. Where your data warehouse sits usually matters more than connector lists. See connecting AI to your ERP, CRM and data warehouse.

How do AWS and Azure compare for AI workloads?

The table reflects each provider's documentation as checked in September 2026. Details change often, so verify the rows that matter for your region and models.

When does using both clouds make sense?

Running AI across AWS and Azure is a legitimate choice in a few situations: a model or deployment option you need exists only on the other cloud in a compliant region, an acquired business runs on the other platform, or one business unit's data must stay where it already is. It is rarely worth it for a small price difference or a single benchmark result.

The cost is operational. Two clouds mean two identity setups, two sets of logs, two cost reports, two security reviews and two skill sets. If you go that way, keep the application and its data in a home cloud and call the other cloud's models through one gateway with consistent logging and access control. Azure API Management's AI gateway, for example, can manage models deployed in Microsoft Foundry or with providers such as Amazon Bedrock. Keeping model calls behind your own interface also keeps the decision reversible, as explained in model-agnostic AI architecture.

Illustrative example: Consider a 150-person accounting firm that runs on Microsoft 365, with Entra ID sign-in and client files in SharePoint. A former contractor built a small analytics workload on AWS. The firm wants an assistant that answers staff questions from engagement letters and internal policies. Its identity, documents and permissions all live in Microsoft, so Azure keeps the assistant inside the same sign-in, access rules and audit trail, and the AWS workload does not need to move for this project. The decision that deserves real attention is which deployment type keeps processing within the locations the firm has promised its clients.

What mistakes should you avoid when choosing?

1. Choosing on one model name or benchmark, when both catalogs now carry models from several major providers.
2. Assuming the region you select is where prompts are processed, without checking the deployment type.
3. Ignoring model lifecycle dates, which on both platforms end with requests failing.
4. Letting short-term credits decide a multi-year architecture.
5. Writing one provider's SDK directly into application code, which makes any later change expensive.
6. Forgetting to name who will operate, monitor and pay for the workload after launch.

How does Kastling approach the AWS or Azure decision?

Kastling's AI & Cloud Infrastructure service covers cloud architecture and deployment on both AWS and Azure. The recommendation starts from the work and the systems already in place: during discovery, and in a separately scoped paid audit where the project warrants one, the review covers identity, data location, compliance obligations, team skills and existing agreements. The usual outcome is to build where identity, data and people already sit, unless a specific requirement points elsewhere.

Deployment can use your AWS account or Azure subscription, or Kastling's accounts, with ownership, access and operating responsibilities written into the proposal. AWS and Azure specialists are brought in as the work requires, and model access is kept behind a thin layer so the choice can be revisited later.