A team starts on Azure, opens the portal to create their first resource, and the create dialog hands them a choice they were not ready for: a Microsoft Foundry resource, an Azure OpenAI resource, or an Azure Machine Learning workspace. Three products, overlapping names, and no arrow pointing at the one their project belongs in. I get this question more than any other on new engagements. So here is the map I draw on the whiteboard, and the rule I use to place a project in the right one on day one.

Three products, one family tree

Start with what each thing actually is, because the names blur together and the marketing does not help. Azure OpenAI Service is a managed resource whose whole job is to serve OpenAI models, the GPT family, embeddings, and image and audio models, on Azure infrastructure with Azure identity, networking, and billing around them. That resource still exists in 2026, still gets new GPT models, and is not going away. If someone tells you Azure OpenAI is deprecated, they are wrong.

Microsoft Foundry is the platform Microsoft built by consolidating three things that used to be separate: the Azure OpenAI resource, the old Azure AI Studio, and Azure AI Services. Under the hood a Foundry resource is a Cognitive Services resource of kind AIServices with project management switched on, and it exposes the OpenAI models plus non-OpenAI models from providers like DeepSeek, Meta, Mistral, and xAI, along with agents and tracing, through one resource and one set of credentials. It went generally available as Azure AI Foundry in late 2024 and was later renamed Microsoft Foundry. Same platform, newer label.

Azure Machine Learning is the odd one out, and on purpose. It is a workspace for the full machine learning lifecycle: prepare data, train a model with your own code, track experiments, register and version models, and deploy them to managed endpoints. It predates the generative AI wave and it is where you go when you are building or deeply customizing a model rather than calling a hosted one. A workspace here is a different resource type with its own compute, datastores, and MLflow tracking. Foundry borrowed a lot of its plumbing, but it did not replace it.

How the resource types differ

The confusion is not really about the products. It is about the resource types you create in Azure, because that is the decision the portal forces on you first and the one you cannot easily undo later. A resource type, or kind, is the Azure object you provision; it sets which APIs light up, how billing meters, and which portal you manage it in. Three products means three kinds, and they behave differently.

A Foundry resource carries the kind AIServices with project management enabled. It gives you Foundry projects in the new portal, the unified inference endpoint, and access to both OpenAI and partner models. An Azure OpenAI resource is a narrower Cognitive Services kind that serves only OpenAI models; it is what you get if you specifically want the OpenAI surface and nothing else. An Azure Machine Learning workspace is a wholly separate kind with compute clusters, datastores, and a job scheduler attached. You manage Foundry in the Foundry portal, Azure OpenAI in either the Foundry portal or the older Azure OpenAI views, and Azure ML in the Azure Machine Learning studio.

Source: Microsoft Foundry "What is Foundry" and Foundry Models overview.

Which one does your project belong in?

Here is the decision I actually run, in order, and it takes about thirty seconds. Ask first whether you are training or fine-tuning a model with your own code and data, or wiring a classical machine learning pipeline. If yes, that is Azure Machine Learning, full stop. None of the hosted-catalog products do gradient descent on your behalf.

If you are calling hosted models, ask the second question: will you ever want a non-OpenAI model, an agent, evaluation, or tracing in this project? If yes, or if you are not sure, pick Foundry. If your scope is genuinely locked to OpenAI models and nothing else, an Azure OpenAI resource is legitimate and slightly simpler. When in doubt, Foundry, because it is the superset and the reversible upgrade path runs toward it, not away from it.

One endpoint for OpenAI and non-OpenAI models

The concrete reason I default to Foundry is the endpoint. A Foundry resource exposes a v1 OpenAI-compatible endpoint, and the api-version query parameter that plagued older Azure OpenAI code is gone with the v1 GA surface. You point the standard OpenAI Python client at your resource with /openai/v1/ on the base URL, and you change only the model name to move between an OpenAI deployment and a partner deployment that speaks the same chat completions syntax, such as DeepSeek or Grok. One client, one key, one base URL, many models.

# pip install 'openai>=1.0'
from openai import OpenAI

client = OpenAI(
    api_key='<your-key>',
    base_url='https://<your-resource>.openai.azure.com/openai/v1/',
)

# a GPT deployment on this Foundry resource
gpt = client.chat.completions.create(
    model='gpt-4.1',          # the deployment name you chose
    messages=[{'role': 'user', 'content': 'reply with one word: ok'}],
)
print('gpt:', gpt.choices[0].message.content)

# same client, swap only the model name to a partner deployment
alt = client.chat.completions.create(
    model='grok-3',          # a non-OpenAI deployment on the same resource
    messages=[{'role': 'user', 'content': 'reply with one word: ok'}],
)
print('alt:', alt.choices[0].message.content)

Expected: two lines, gpt: ok and alt: ok, from two different model families through the same endpoint and key, with no api-version anywhere.

Failure mode: a 404 DeploymentNotFound means the model string is not the name of a deployment on that resource; deployment names are what you set at deploy time, not the catalog model id. A partner model that does not implement the v1 chat completions syntax will error instead of answering, in which case call it through its own route rather than this shared one.

That single-endpoint habit is also why the resource sprawl on the separate-services path adds up. A team that runs an Azure OpenAI resource for GPT, a second setup for a partner model, and an Azure ML workspace for a side model is managing three resources, three sets of keys, and three places to look when something breaks. Consolidate the hosted-model work onto one Foundry resource and that surface collapses.

Upgrade the resource, keep the endpoint

If you already run an Azure OpenAI resource and now want the wider Foundry surface, you do not rebuild. Microsoft provides an in-place upgrade from an Azure OpenAI resource to a Foundry resource. It is opt-in, it is reversible, and it preserves the resource name, the endpoint URL, the API keys, your fine-tuned models, and your provisioned throughput reservations. Your running clients keep calling the same endpoint with the same key while the resource gains project management and access to partner models. That reversibility is the part that lets you say yes without a change-review fight.

Where Azure Machine Learning still wins

Foundry took over so much of the generative AI story that people assume Azure ML is legacy. It is not. It is where you go the moment you stop calling a hosted model and start producing one. Training a model from scratch, continued pre-training on your own corpus at scale, classical machine learning like gradient-boosted trees or forecasting, feature engineering pipelines, distributed training across a GPU cluster you control, experiment tracking with MLflow, and a model registry with lineage all live in Azure ML. Foundry does not do any of those; it consumes their output.

The two also meet in the middle, which is worth knowing. Managed compute deployments for open models, which Part 4 covered, are backed by Azure ML compute even when you drive them from the Foundry catalog. And a hub-based Foundry project is literally sitting on an Azure ML hub. So the honest picture is not three walled gardens. It is Foundry as the front door for hosted models and apps, Azure ML as the workbench for models you build, and a shared compute layer underneath that both of them lean on.

Foundry and Azure ML overlap on the hosted catalog and managed compute; they diverge hard on who trains the model.

If you want the same decision from the AWS side of the fence, the split between Bedrock and SageMaker AI is the near-exact mirror: a hosted-model service next to a build-your-own workbench, with the same question about who owns the training. The names change, the decision does not.

Foundry by default, Azure ML when you own the training

Here is the recommendation, plainly. For new generative AI work, create a Foundry resource. It is the superset, it gives you OpenAI and partner models on one endpoint, and it costs you nothing to hold the wider surface until you need it. Keep an Azure OpenAI-only resource only when the scope is deliberately locked to OpenAI models, and remember you can upgrade it in place later without touching the endpoint. Reach for Azure Machine Learning the moment the work is training or customizing a model you own, or classical ML, because neither hosted product does that job. Do not create three resource types out of caution; you will manage three of everything for no benefit.

Next, we get into deployment types in depth: Standard against provisioned throughput units against Batch, and how to size a PTU reservation without overbuying the capacity you just learned carries across an upgrade. Before you read it, open the create-resource dialog in your own subscription and note which kind you land on by default. That single choice is the one this part exists to get right. [AUTHOR: add anecdote about a team that stood up an Azure OpenAI-only resource and hit the wall when they wanted a non-OpenAI model.]

References

• What is Microsoft Foundry
• Azure OpenAI in Microsoft Foundry Models v1 API
• Microsoft Foundry Models overview
• What is Azure Machine Learning

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts