Microsoft Foundry (Azure AI Foundry)

Microsoft Foundry — still widely referenced by its earlier name, Azure AI Foundry — is Microsoft's unified platform on Azure for discovering, evaluating, fine-tuning, and deploying AI models, spanning a model catalog (OpenAI's GPT family, Claude, Llama, Mistral, and Microsoft's own Phi and MAI models) alongside the agent-building, evaluation, and MLOps tooling needed to take a model from prototype to production inside Azure's infrastructure.

The Rebrand: From Azure ML Studio and Azure AI Studio to Microsoft Foundry

The product's naming history matters for anyone following older documentation or tutorials. Azure Machine Learning Studio was the original workspace for training and deploying custom ML models on Azure — the classic MLOps surface with pipelines, compute clusters, and model registries. Azure AI Studio launched later as a separate, generative-AI-focused workspace specifically for building with foundation models: prompt flow, model catalog browsing, and evaluation tooling lived there instead. Microsoft has since consolidated both into a single product, rebranded Microsoft Foundry, folding the foundation-model catalog and agent tooling from Azure AI Studio together with the training and deployment infrastructure that used to live in Azure ML Studio. A tutorial or blog post referencing "Azure AI Studio" or "Azure ML Studio" today is describing functionality that now lives inside Foundry under a single workspace rather than two overlapping ones.

Pricing Structure

Pricing follows the same usage-based shape as other major cloud model platforms and doesn't reduce to a single number. Model inference is billed per token, with the rate depending on which model is called — OpenAI's flagship models routed through Foundry cost meaningfully more per token than smaller or open models in the catalog. Fine-tuning and training jobs are billed separately by compute time, and features like Azure AI Search integration, content safety filtering, and evaluation runs carry their own meters on top of base inference. Anyone budgeting for Foundry needs to price an actual workload — which models, how much fine-tuning, and what evaluation volume — rather than expect a flat subscription number.

Choosing Microsoft Foundry Over Other Cloud Platforms

The criterion that matters most is the same one that applies when weighing AWS Bedrock against Google Vertex AI: which cloud a team is already standardized on. Foundry's strength is being the Azure-native option — Entra ID (formerly Azure AD) instead of a separate auth system, VNet integration instead of new network exposure, and billing that lands on an existing Azure invoice. A team already running its identity and data infrastructure on Azure, or already invested in Microsoft 365/Copilot tooling, gets the least friction here, since Foundry's model catalog and agent framework are built to plug into that ecosystem directly. As with the other major cloud platforms, none is meaningfully "better" at raw inference quality since they largely serve overlapping model providers (OpenAI's models, in particular, are available through more than one of these platforms) — the differentiator is which cloud's identity system, data residency, and existing tooling a team already lives in. Teams that want more portability before committing to a specific cloud's deployment path often start at a hub like Hugging Face, comparing and fine-tuning open models before deciding where — Foundry, Bedrock, or Vertex AI — to run them in production.

The practical decision starts with existing identity and data infrastructure, not a feature checklist: which cloud already holds the access policies and compliance certifications a workload needs, and whether the model catalog on offer actually includes the specific model a team wants to standardize on. Pricing should be modeled against a specific model and workload rather than compared as a flat number across providers.