Microsoft Foundry vs Azure AI Studio vs Azure OpenAI: What Actually Changed

If you learned Azure AI on Azure OpenAI Studio, then relearned it on Azure AI Studio, and now read documentation that says Microsoft Foundry, you are not behind. The product was renamed and restructured twice in under two years, and the older names still appear in Microsoft Learn modules, blog posts, SDK package names and exam-adjacent material.

This article is a re-orientation guide. It is not a definition of Foundry (we cover that in Azure AI Foundry explained) and it is not a use-case list (that is what teams actually build with Foundry). It answers one question: if you already know the old surfaces, what has actually changed under you, and what does that mean for your code, your portal habits and the AI-103 exam.

The short version

The names describe three different things, which is why the confusion persists.

• Azure OpenAI Service is a resource type. It is the Azure-hosted deployment of OpenAI models, with Azure identity, networking and quota. It still exists. It did not get renamed away.
• Azure AI Studio was a portal. It was the web experience that sat over multiple AI resources. It was renamed to Azure AI Foundry portal.
• Microsoft Foundry, or Azure AI Foundry, is the platform: the portal, the project structure, the model catalogue, the agent service, the evaluation tooling and the SDK, as one product surface.

So Azure OpenAI is a thing you provision. Foundry is where you work. Azure AI Studio is a name that no longer appears in the product.

What actually changed, not just what got renamed

Renames are cosmetic. Three structural changes are not.

1. The project became the unit of work

In the Azure OpenAI Studio era, your mental model was resource first. You created an Azure OpenAI resource, deployed a model into it, and pointed a key and an endpoint at your app. Everything else, search indexes, storage, content safety, was wired up by hand.

In Foundry the project is the container. A project holds model deployments, connections to other services, agents, evaluation runs, files and traces. When you sign in to the Foundry portal now, Microsoft creates a project for you automatically rather than dropping you on an empty resource screen. That behaviour catches out people following older tutorials, which still begin with "create a new project".

Practical consequence: permissions, quota and cost now aggregate at a level you did not previously think about. If you scope role assignments to the resource only, teammates can hit a project they cannot fully use.

2. Models stopped meaning OpenAI models

Azure OpenAI gives you OpenAI models. The Foundry model catalogue gives you OpenAI models plus Microsoft Phi, Meta Llama, Mistral, Cohere, and a long list of partner and open-weight models, with two different hosting shapes behind them: serverless endpoints billed per token, and managed compute you provision and pay for by the hour.

This is the single biggest source of surprise bills. A model that looks similar to another in the catalogue can have a completely different cost shape. Serverless costs nothing when idle. Managed compute bills while the endpoint exists, whether you call it or not.

3. Agents became a first-party service

Under Azure OpenAI you built the orchestration yourself, or you used the Assistants API. Foundry ships an Agent Service: an agent definition with instructions, attached tools, threads and runs, plus tracing of every tool call. It is a real service rather than a pattern you assemble.

That does not make it always correct. Agents add latency and non-determinism. If your task is a single grounded answer over your own documents, a retrieval call and one completion is still the better design, for the reasons we set out in when RAG is not the right answer.

Name-by-name translation table

You knew it as	It is now	What to do
Azure OpenAI Studio	Foundry portal, Azure OpenAI section	Same models, new surrounding navigation
Azure AI Studio	Azure AI Foundry portal	Pure rename, bookmarks redirect
Hub and project	Still hub and project, project is now the default entry point	Expect a project to exist already
Assistants API	Foundry Agent Service	Migrate for tracing and tool management
Older preview generative SDKs	azure-ai-projects plus azure-ai-inference	Repin packages, do not mix generations
Prompt flow	Still prompt flow, inside Foundry projects	Unchanged concepts
Content Safety standalone portal	Content safety inside Foundry, plus the standalone resource	Prefer the in-project route

Does your existing code break?

Mostly no, and that is the useful part of the answer.

Existing Azure OpenAI calls against your openai.azure.com endpoint with an API version continue to work. Nothing about the rename invalidated those endpoints. Teams running on the Azure OpenAI SDK are not on a deadline.

What does change is what you should write next:

• New work should use Entra ID rather than keys. Key based auth still functions, and it is still the fastest thing to demo, but managed identity is now the default path in Microsoft own samples and the one assessed on the exam.
• New work should use the project client. AIProjectClient resolves connections, deployments and agents from the project rather than from hard coded endpoints. It is the difference between an app that survives moving between dev and production projects and one that does not.
• Avoid mixing SDK generations in one service. The preview packages from the Azure AI Studio period and the current project and inference packages coexist happily on PyPI, which means a stale requirements file will install something that looks right and behaves differently.

Where each one still wins

Foundry is not automatically the right choice for everything.

Stay on a plain Azure OpenAI resource when you have one service calling one model, no retrieval, no agents, no evaluation loop, and a platform team that already manages the resource, networking and quota. Adding project scaffolding around a single completion call buys you nothing.

Move to Foundry when you need more than one model, want the evaluation tooling instead of eyeballing outputs, need agents with traced tool calls, or want connections to search and storage managed rather than copied into environment variables.

Use managed compute when you need a model that is not offered serverless, need predictable latency under sustained load, or have data residency requirements that rule out shared endpoints. Otherwise start serverless.

What this means for AI-103

AI-103 is written against Foundry, not against the older surfaces, and the exam assumes the current vocabulary. Three consequences worth planning around:

1. Study material predates the exam. A large share of the free AI-102 era material online describes portals and flows that no longer look like that. If a walkthrough tells you to open Azure AI Studio, treat the concepts as valid and the click path as stale.
2. Objectives are framed around projects and connections, so questions describe scenarios in those terms. Knowing that a connection is a project level object, not a per-deployment setting, resolves a surprising number of them.
3. Evaluation and responsible AI carry real weight. These were thin in AI-102 and are not thin now. Running one evaluation for real is worth more than reading the evaluator list twice.

We break the objective level detail down in AI-102 to AI-103: what carries over, and the full path map is in the AI-103 study guide.

A 20 minute exercise to reset your mental model

If you learned the old surfaces, this is the fastest way to update:

1. Sign in to the Foundry portal and note that a project already exists. Look at where it sits in the resource group.
2. Open the model catalogue and filter to serverless. Deploy one small model.
3. Open the deployment and copy the target URI. Notice it is a project scoped inference endpoint, not the resource shape you used before.
4. Add a connection to a storage account or a search service from inside the project, then look at how it appears in code through the project client rather than as an environment variable.
5. Run one built in evaluator over five sample outputs. That single run teaches the shape of the tooling faster than any diagram.

That is the whole re-orientation. Same models, same Azure controls, a different container around them.

FAQ

Is Microsoft Foundry the same as Azure AI Foundry? Yes. Microsoft has been shifting the branding toward Microsoft Foundry, and documentation uses both. There is no separate product behind the two names.

Was Azure AI Studio discontinued? It was renamed, not discontinued. The portal is the Azure AI Foundry portal, and old links redirect.

Do I still need an Azure OpenAI resource? Only if you want the Azure OpenAI specific surface, for example existing deployments, quota arrangements or endpoint shapes your code depends on. New projects can deploy OpenAI models through Foundry without thinking in resource first terms.

Will my Azure OpenAI keys stop working? No. Key based authentication against existing endpoints continues to work. Prefer Entra ID for anything new.

Which name will the AI-103 exam use? Expect Foundry terminology throughout, with Azure OpenAI referenced where the resource itself is the subject.

Try it rather than read about it

Reading the differences gets you the vocabulary. Deploying a model, wiring a connection and running an evaluator gets you the muscle memory the exam actually tests. Our AI-103 labs give you a live Azure environment with the project, the models and the evaluation tooling already reachable, so you spend the hour on the platform rather than on subscription setup.

Related reading

• What Azure AI Foundry is used for
• Foundry Agent Service: when it is the wrong tool
• AI-103 study guide: all four learning paths