Microsoft Foundry vs Amazon Bedrock in 2026: The Model Is No Longer the Decision

For two years, enterprise AI platform selection had a shortcut. If you needed GPT, you went to Azure. If you needed Claude, you went to AWS. The model catalog made the decision, and the architecture followed.

However, that shortcut is gone.

In June 2026, OpenAI revised its exclusive cloud arrangement with Microsoft, and GPT-5.5, GPT-5.4, and Codex reached general availability on Amazon Bedrock. Weeks later, Anthropic’s Claude models reached general availability in Microsoft Foundry, hosted on Azure. Both frontier families now run on both platforms. The era of choosing a cloud to reach a lab is effectively over.

As a result, this creates an uncomfortable situation for engineering leaders who built their platform strategy on model access. The decision did not disappear. It moved. It now sits in the agent runtime, the governance boundary, and the question of whose legal entity processes your data.

A naming note before we start

Azure AI Studio became Azure AI Foundry in late 2024. Foundry was then rebranded again to Microsoft Foundry. Most practitioners still say “Azure AI Foundry,” Microsoft’s own documentation is inconsistent, and search results for the platform span three names.

This is a small thing, but it is a real signal. Microsoft’s AI surface has changed names and shapes faster than teams can update their internal architecture documents, and that churn has a cost. We will return to it.

Model breadth: a metric that stopped mattering

The catalog comparison is still worth stating, if only to retire it.

Microsoft Foundry lists well over 1,900 models in its own documentation, spanning OpenAI, Anthropic, Meta, Mistral, DeepSeek, xAI, Cohere, NVIDIA, and a deep Hugging Face integration. Counts above 10,000 appear in some third-party write-ups, depending on how open-weight variants are tallied.

Amazon Bedrock is deliberately narrower: roughly 18 providers and somewhere north of 110 individually addressable model variants as of mid-2026, including Amazon’s own Nova family, Anthropic’s Claude line, Meta Llama, Mistral, Cohere, and now OpenAI.

Here is why that gap matters less than it looks. In practice, nobody evaluates 1,900 models. Teams evaluate three or four, pick one, and then spend eighteen months operating it. A catalog is a procurement convenience, not an engineering advantage. The 1,900 versus 110 comparison flatters Microsoft in a slide deck and tells you almost nothing about what you will actually run in production.

What does matter: both platforms now carry the frontier models most enterprises shortlist. Claude Fable 5, Anthropic’s most capable widely released model, has been generally available on Amazon Bedrock, Google Cloud, and Microsoft Foundry since June 9, 2026, alongside Claude Opus 4.8, Sonnet 5, and Haiku 4.5. Foundry carries that line next to the GPT-5.x family. Bedrock carries the same Claude line next to GPT-5.5 and GPT-5.4. Pricing on Bedrock for OpenAI models matches OpenAI’s direct rates and draws down existing AWS commitments. Claude usage in Foundry bills through Azure Marketplace and draws down Microsoft Azure Consumption Commitments.

In short, model access has become table stakes. Commercial plumbing is now the differentiator, and both vendors know it.

Agent Runtime: Where AWS and Microsoft Really Differ

The biggest difference between AWS and Microsoft is now their agent runtime, and many comparison articles are already outdated.

Amazon Bedrock has shifted from the original Bedrock Agents to AgentCore, which is now the recommended platform. AgentCore is modular and framework-agnostic, offering services like Runtime, Gateway, Memory, Identity, and Observability. It works with popular frameworks such as LangGraph, CrewAI, LlamaIndex, and the OpenAI Agents SDK, while also providing a managed runtime, built-in web search, and integrated guardrails.

Microsoft has also unified its ecosystem with Microsoft Agent Framework 1.0, replacing both AutoGen and Semantic Kernel as the primary development framework. Combined with Foundry Agent Service, it delivers managed hosting, durable execution, MCP support, and enterprise observability.

Ultimately, the main trade-off is simplicity. AWS offers a more streamlined path from framework to managed runtime, while Microsoft’s ecosystem is more feature-rich but spread across multiple products such as Agent Framework, Foundry, Copilot Studio, Microsoft 365 Agents SDK, and Agent 365, making the learning and adoption curve steeper.

Grounding and retrieval

Key Takeaway:

The biggest differentiator is where your enterprise data already resides, not the retrieval technology itself. If your knowledge is in AWS services, Bedrock is the natural choice. If it lives in Microsoft 365 and Azure, Foundry provides deeper native integration.

Governance & Compliance: Key Differences

• Both platforms are enterprise-ready with strong security, compliance, and governance capabilities.
• Amazon Bedrock
  • Supports ISO, SOC, GDPR, FedRAMP High, and is HIPAA eligible.
  • Bedrock Guardrails provide content filtering and policy enforcement independent of the underlying model.
  • Includes automated reasoning capabilities to improve response reliability.
• Microsoft Foundry
  • Inherits Azure’s enterprise security stack, including Entra ID, RBAC, Managed Identities, Private Endpoints, CMKs, and data residency controls.
  • Ideal for organizations already invested in the Microsoft ecosystem.

Important Consideration: Model Trust Boundary

• Azure OpenAI models run entirely within Microsoft’s Azure trust boundary.
• Claude on Microsoft Foundry is delivered through Anthropic, making Anthropic the data processor.
• Claude on Amazon Bedrock runs within your AWS environment, helping meet stricter data residency and compliance requirements.

Bottom Line

• Choose Bedrock if data residency and regulatory compliance (especially in Europe) are critical.
• Choose Foundry if you’re primarily using Azure OpenAI models and are already standardized on Azure.
• Always verify the latest documentation, as cloud AI offerings and compliance capabilities evolve rapidly.

Cost: where the money actually goes

Notably, both platforms are pay-as-you-go and both track their model providers’ direct API pricing within a narrow band. Per-token rate shopping between them is rarely worth the effort.

Three things move the number instead.

Data gravity and egress.

If your applications run on Lambda or ECS and you call Bedrock, transit costs stay at zero. Hosting data in S3 while routing inference through Foundry introduces network egress fees and latency on every call. This integration tax compounds silently and is usually discovered after the architecture is set.

Routing and optimization Building blocks.

Foundry’s Model Router deploys as a single endpoint and selects the underlying model per prompt, with modes optimized for balanced performance, cost, or quality. Bedrock counters with Intelligent Prompt Routing, prompt caching, and Model Distillation, where AWS reports distilled models running substantially faster and cheaper with limited accuracy loss. Both sets of building blocks are real and both are underused. Most teams leave meaningful savings on the table by calling one frontier model for every request, including the trivial ones.

The self-hosting tipping point.

There is a threshold at which migrating high-volume, low-complexity work, such as classification, extraction, and routine summarization, onto a fine-tuned open-weight model on dedicated compute beats managed per-token pricing. Where that threshold sits depends on your token mix, latency tolerance, and the fully loaded cost of the engineers who will operate the inference stack. Be suspicious of any article that names a specific request-per-day number. Model your own workload. The managed-versus-self-hosted crossover has moved every year, and the operational cost of self-hosting is chronically understated.

Worth noting: agent runtimes now bill separately from inference. Foundry Agent Service charges consumption on compute and memory, with model inference and persistent memory billed on top. Budget for the runtime as its own line item.

So how should you actually decide?

First, retire the model-availability question. It no longer separates these platforms.

At a glance, here is how the two platforms line up across the dimensions that actually decide it:

Ask these instead, in order.

1. Where does your data live, and what will it cost to move? This is the highest-signal question and it usually answers the others. Cross-cloud inference carries a permanent tax.
2. Which trust boundary does your legal team need? Not which platform, which boundary. First-party inference and third-party marketplace inference are different things wearing the same badge. If you are in a regulated European industry and Claude is central to your architecture, this question likely eliminates Foundry today.
3. How much orchestration control do you want, and how much churn can you absorb? Bedrock and AgentCore give you a composable, framework-agnostic runtime and a cleaner path from prototype to production. Microsoft gives you a richer integrated ecosystem, deeper Microsoft 365 reach, and a wider set of surfaces to keep track of. Both vendors just forced a migration on their existing agent customers. Assume they will do it again.
4. What is your team’s existing operational muscle? Foundry rewards Microsoft shops with Entra ID, Fabric, and SharePoint already in production. Bedrock rewards teams fluent in IAM, CloudTrail, VPC endpoints, and the AWS building-block style.

Therefore, if you are Microsoft-centric, run Microsoft 365 and Entra ID, want evaluation, observability, and agent monitoring in one console, and your compliance posture is already Azure-approved, Foundry is the path of least resistance.

A concrete example of where that plays out:

A national insurer building an internal underwriting assistant. Its policy documents, underwriting guidelines, and claims correspondence already live in SharePoint and Teams, identity runs through Entra ID, and its compliance team approved Azure years ago. It wants an agent that answers underwriter questions from that corpus and logs every interaction for audit. Foundry IQ reaches SharePoint and Microsoft Graph natively, Agent 365 gives governance the audit surface it needs, and legal has no new trust boundary to review. The knowledge never leaves the environment it already lives in, which is exactly why the project ships in a quarter instead of a year.

If you are AWS-native, value composability over integration, want a framework-agnostic agent runtime, or need Claude inference running inside your own tenant with documented residency guarantees, Bedrock is the stronger fit.

A concrete example of where that is the clear call:

A European digital bank building customer operations on Claude. It needs documented data residency and inference that runs inside its own cloud tenant, and its regulators will not accept a third-party marketplace processor subject to the CLOUD Act. That single constraint decides it. Claude through Bedrock keeps inference in-tenant with residency guarantees the bank’s legal team can point to, and Foundry, today, cannot offer the Claude equivalent. Here the governance section outranks everything else, exactly as warned.

And if your honest answer is “we are already both,” you are not unusual. The multi-cloud reality is why model gateways and MCP-based abstraction layers went from a nice-to-have to a design pattern in the space of about a year. Build the abstraction before you need it, not after your provider announces the next rename. Not sure which platform fits your architecture? Get a free AI Opportunity Audit.

That abstraction is smaller than it sounds. A thin provider interface lets your application target either cloud, so switching Claude between Bedrock and Foundry, or moving a workload entirely, becomes a configuration change rather than a rewrite: 

# A thin provider interface: swap clouds without touching application code
from dataclasses import dataclass


@dataclass
class ModelRequest:
    prompt: str
    system: str
    max_tokens: int = 1024


class ModelProvider:
    def invoke(self, request: ModelRequest) -> str:
        raise NotImplementedError


class BedrockProvider(ModelProvider):
    # Claude inference stays inside your own AWS tenant
    def invoke(self, request: ModelRequest) -> str:
        return bedrock_runtime.converse("anthropic.claude-fable-5", request)


class FoundryProvider(ModelProvider):
    # Billed through Azure Marketplace against your MACC
    def invoke(self, request: ModelRequest) -> str:
        return foundry_client.responses("gpt-5-5", request)


def answer(question: str, provider: ModelProvider) -> str:
    request = ModelRequest(
        prompt=question,
        system="You are an internal knowledge assistant. Cite your sources.",
    )
    return provider.invoke(request)


# Switching providers is a one-line change, not a re-architecture
gateway = BedrockProvider()
print(answer("Summarize this quarter's underwriting exceptions.", gateway))

This same discipline of writing precise, portable specs instead of one-off prompts is why spec engineering is becoming a core skill for AI teams.

Platform capabilities, model availability, and residency terms in this space change on a monthly cadence. Every claim here reflects publicly available documentation and reporting as of July 2026 and should be verified against vendor documentation before an architectural commitment is made.