Same Claude, different boundary: on Azure and AWS, the delivery path is the governance decision

A common enterprise question sounds simple: “Can we use Claude?” In 2026 the honest answer is another question: “Through which door?”

On September 30, Anthropic ran two sessions with its cloud partners. One, with Microsoft, walked through tool integrations for Claude in Microsoft Foundry. The other, with AWS, laid out four separate paths to production on AWS. Together with Microsoft’s August update for Foundry, they make one point clear: the same model now arrives through several delivery paths, and each path draws the data, identity and billing boundary in a different place.

The Azure side: capabilities follow the deployment type

In August, Microsoft extended five Claude capabilities to Foundry deployments hosted on Azure. Until then they were available only on deployments hosted by Anthropic:

• Structured outputs (generally available): generation is constrained by a grammar compiled from your JSON Schema, so output cannot be malformed.
• Web search and web fetch (generally available), with citations.
• Tool search (generally available): Claude searches a tool catalog and loads only the tools it needs.
• MCP connector (beta): Claude can call remote MCP servers directly, with allowlists and denylists.

The details matter more than the list. Microsoft states that for deployments hosted on Azure, prompts and completions stay within Azure, and only usage metadata and content flagged by Anthropic’s safety systems leave for Anthropic. It also notes that the MCP connector’s exchange with servers is not covered by zero data retention, and that structured output schemas are cached for 24 hours, so they should not contain protected health information. The supported deployment types are Global Standard and US Data Zone Standard, the latter keeping inference in the United States.

The AWS side: four paths, four boundaries

Anthropic and AWS describe four ways to run Claude on AWS:

Path	What it gives you	Boundary, as described
Claude Platform on AWS	The full Anthropic API	AWS handles billing and sign-in
Claude on Amazon Bedrock	Claude as an AWS service	AWS stays the sole data processor
Claude Enterprise via AWS Marketplace	The full product, with SSO and admin controls	Seats and usage billed through AWS
Claude Desktop on Bedrock	The desktop app pointed at your own Bedrock	Prompts and outputs stay inside your AWS boundary

The trade-off is visible even in the vendors’ own framing: one path optimizes for the newest developer features, another for keeping the cloud provider as the only data processor, another for a finished end-user product.

1. Claude Platform on AWS
2. Foundry, hosted on Anthropic
3. Amazon Bedrock
4. Foundry, hosted on Azure

• Anthropic runs inference: Claude Platform on AWS · Foundry, hosted on Anthropic
• Your cloud provider runs inference: Amazon Bedrock · Foundry, hosted on Azure

Prompts and outputs stay in your cloud provider's boundary, per AWS and Microsoft

What the path actually decides

Who processes your data. The difference between “Anthropic runs inference” and “your cloud provider runs inference” is the first thing privacy and procurement teams will ask about. It determines which contract, which data processing terms and which audit rights apply.

Which features you get, and when. Capabilities do not always arrive on every path at the same time. Microsoft’s update is itself an example: five features reached Azure-hosted deployments after they were already available on Anthropic-hosted ones. If a use case depends on a beta feature, check which path has it today.

Where tools leak. The boundary of the model is not the boundary of the agent. Web search reaches the public internet. An MCP connector exchanges data with whatever server you point it at, outside zero data retention. Tool design needs its own data review.

How identity works. A Marketplace subscription to Claude Enterprise brings SSO and admin controls for people. An application calling Bedrock or Foundry uses cloud identities and roles. Those are different governance models, and many organizations will need both.

For Microsoft-heavy US enterprises

For organizations already standardized on Azure and Entra, Foundry hosted on Azure is now a serious path for agent work: the procurement relationship, the identity model and the data boundary they already know, with the tool capabilities that previously required Anthropic-hosted deployments. That is what “Microsoft-native, not Microsoft-only” looks like in practice: the governance stays in the Microsoft stack, while the model choice stays open. We looked at the reverse move, Google’s agents acting inside Microsoft 365, in our analysis of Gemini Enterprise and Microsoft 365.

A practical checklist:

1. Pick the path per use case, not per company. An internal assistant for employees and a customer-facing agent may belong on different paths.
2. Choose the deployment type deliberately. For regulated data in the US, compare Global Standard with US Data Zone Standard.
3. Review every tool separately. List which tools send data outside the boundary, and decide which are allowed for which data classes.
4. Keep schemas and prompts clean. Do not put sensitive data in cached artifacts such as output schemas.
5. Write down why. Record the path, the deployment type and the data review for each use case, so the decision survives the next audit.

The bottom line

Model access is no longer one decision. The same Claude model can sit inside your cloud provider’s boundary or the model provider’s, be billed by either, and reach tools that cross both. The teams that move fastest will treat the delivery path as an architecture decision with an owner. It is the same lesson we drew from AWS’s managed agent runtime: the platform supplies mechanisms, and the boundary is still yours to draw.