Azure AI Foundry vs. Azure OpenAI

Part of a series on running AI workflows across model providers — this one untangles three names that sound like one product.

If you've searched for guidance on Azure's AI offerings recently, you've probably run into at least three names for what feels like it should be one thing: Azure OpenAI Service, Azure AI Foundry, and — as of a rename announced at Microsoft Ignite 2025 — Microsoft Foundry. None of these names is wrong, exactly, but they refer to genuinely different things, and picking the right one matters for what you're actually building.

The short version

Azure OpenAI Service is the original, narrower resource type — specifically for OpenAI's models, running on Azure infrastructure with Azure's compliance and networking wrapped around it. It's still fully supported: the underlying resource type (Microsoft.CognitiveServices/accounts with kind: OpenAI) is still creatable today, still works, and still receives new GPT models as they're released.

Microsoft Foundry (the current name for what was called Azure AI Foundry) is the newer, broader platform — a unified resource (kind: AIServices) that consolidates what used to be three separate things: Azure OpenAI, Azure AI Services, and the AI Hub. One Foundry resource can host multiple isolated "Projects" for different teams, with role-based access control managed centrally, and it gives you access to models beyond OpenAI's — Anthropic, Meta's Llama, Mistral, DeepSeek, and others — on a single Azure bill.

Same underlying infrastructure family, genuinely different scope — one resource type is OpenAI-specific, the other spans multiple model providers.

This is a consolidation, not a replacement

It's worth being precise here because a lot of secondary commentary blurs this: Azure OpenAI Service was not deprecated or folded into Foundry by force. Existing Azure OpenAI resources, including their original endpoint format (*.openai.azure.com), remain functional and fully compatible with applications built against them. If you have a stable, single-model GPT workload with well-understood compliance requirements already running on Azure OpenAI Service, there's no requirement to migrate.

Where Foundry becomes the clear right choice is for anything newer or broader in scope: building AI agents (where the older Assistants API has already been retired, covered in the next article), needing non-OpenAI models alongside GPT models on one bill, or wanting the project-based team isolation Foundry provides that a single Azure OpenAI resource doesn't.

What this means for a DNotifier setup

DNotifier's Azure AI provider connects to your Azure resource's endpoint regardless of which resource type it is — Azure OpenAI Service or a Foundry resource. What matters for your DNotifier configuration is that the endpoint and deployment names you enter match whatever resource type you actually created, not which brand name is on the marketing page you read to get there.

A use case that shows why the distinction matters practically, not just terminologically

A team building a new customer-support agent evaluated Azure options and initially assumed "Azure OpenAI" was the only option, since that's the name they'd heard most. Partway into building, they needed a Claude model alongside GPT-4o for a specific reasoning-heavy step — a need Azure OpenAI Service alone couldn't meet, since it's scoped to OpenAI's models only. Provisioning a Foundry resource instead, with both models deployed as separate deployments inside it, solved the need without switching away from Azure infrastructure entirely — the fix was picking the broader resource type, not switching providers.

The moment you need more than one model family on Azure, that's the signal to look at Foundry rather than a plain Azure OpenAI resource.

The naming history, briefly

For context on why the naming is confusing: what launched as "Azure AI Foundry" was positioned early on as something closer to a model playground — a place to browse and test models. The Ignite 2025 rename to "Microsoft Foundry" came with a genuine repositioning, not just a name change: Microsoft now describes it as "an agent platform with models, tools, workflows, and observability, all treated as first-class, composable pieces," placed alongside Microsoft 365 and Fabric as a company-wide strategic pillar rather than an Azure-specific product. The practical mechanics — creating projects, deploying models from multiple providers, using the SDK in Python, C#, TypeScript, or Java — carried over unchanged through the rename.

Frequently asked questions

Do I need to migrate an existing Azure OpenAI Service resource to Foundry?

Not automatically, and not urgently if your workload is stable and single-model. Migrate when you actually need something Foundry offers that your current resource doesn't.

Does DNotifier's Azure AI provider work differently depending on which resource type I use?

No — the setup process (endpoint, credentials, deployment list) is the same regardless of resource type. What differs is what's available inside that resource to deploy in the first place.

Is "Microsoft Foundry" the same thing people meant by "Azure AI Foundry" a year ago?

Functionally, largely yes, with a genuine broadening of scope and positioning that came with the rename — not just a cosmetic name change.

Which one should a brand-new project default to?

For most new projects, Microsoft Foundry — it's the more capable superset, and the older Azure OpenAI Service resource type mainly makes sense if you specifically want the narrower, OpenAI-only scope.

The Bottom Line

Next in this series: a change that already happened — Azure's Assistants API retired on a specific date this year, and here's what to check if you haven't dealt with it yet.

Read part three: Azure Retired Its Assistants API. Explore dnotifier.com.