Microsoft Foundry and Azure OpenAI: Projects, Models, Deployments, Quotas, and Safety

Microsoft Foundry—formerly called Azure AI Foundry—is Azure's platform for building, evaluating, observing, governing, and operating AI applications and agents across a model catalog. Azure OpenAI provides managed access to supported OpenAI models within Azure's identity, networking, quota, safety, and billing environment. Names and portal screens continue to evolve.

Lab: 45–60 minutes · Cost: model input/output, hosted capacity, evaluations, search, storage, networking, and logs can charge · Prerequisite: subscription/model access, regional availability, quota, and role assignments.

What changed from Azure AI Foundry to Microsoft Foundry?

The current public product is Microsoft Foundry. Older tutorials, resource providers, URLs, SDK packages, APIs, and resource names may still contain azure, ai, or the former Azure AI Foundry name. Follow the current Microsoft Learn page for the chosen API and do not rename working resource types based only on marketing text.

What are the core objects?

• A Foundry resource is an Azure management and billing/security boundary for supported capabilities.
• A project organizes development assets, connections, agents, evaluations, and collaboration.
• A model deployment gives a selected model a deployment name and capacity/quota context.
• A connection links approved Azure or external resources.
• A playground is an interactive experiment surface, not a production runtime architecture.

How do you create a project in the Foundry portal?

1. Open ai.azure.com and sign in.
2. Select Start building.
3. Create or choose a Foundry project/resource.
4. Select subscription, resource group, region, and project name.
5. Review advanced network and dependency options.
6. Create the project.
7. Open Models or the model catalog and inspect license, region, modality, context, safety, price, and deployment type.
8. Deploy only a model approved for the workload.

Portal names differ between new and classic experiences. Microsoft Learn provides tabs for Foundry portal, SDK, and CLI where supported.

How do you choose and deploy a model?

Evaluate models against a versioned dataset and business metric. Consider quality, latency, input/output price, context length, tool use, structured output, language, modality, data policy, region, quota, rate limits, and lifecycle. A larger model is not automatically better for routing, classification, extraction, or simple grounded answers.

Use a deployment name such as chat-primary rather than the model version in application code. That abstraction lets operators change the underlying approved model after evaluation.

How should applications authenticate?

Prefer Entra ID with managed identity. Give the workload the narrow Foundry/Azure AI data role it needs. Use API keys only where identity is unsupported; store them in Key Vault, rotate them, and never put them in frontend code.

How do you test the same approved model deployment?

Use the deployment name—not a raw model version—in every method. Keep the prompt non-sensitive, cap output, and record tokens, latency, filter result, and cost.

Ways to build

Choose the Azure tool you want to use. The underlying resource stays the same.

Microsoft Foundry portalSDKREST API

Microsoft Foundry portal

Open the project → Models + endpoints, select the approved deployment, and open its playground. Set the same system instruction and a harmless test input, lower the maximum output for the test, run it, then inspect the deployment details, content-safety result, and monitoring view. Do not paste production data into a development playground.

SDK

Use a current OpenAI-compatible Azure endpoint and an Entra token provider:

python

WrapCopy

import os from azure.identity import DefaultAzureCredential, get_bearer_token_provider from openai import OpenAI credential = DefaultAzureCredential() token_provider = get_bearer_token_provider( credential, "https://cognitiveservices.azure.com/.default", ) client = OpenAI( base_url=os.environ["FOUNDRY_OPENAI_BASE_URL"], api_key=token_provider, ) response = client.responses.create( model=os.environ["MODEL_DEPLOYMENT_NAME"], input="Return only JSON with a greeting field.", ) print(response.output_text)

SDK signatures and base URLs differ by API generation. Use the current quickstart for your resource and pin tested package versions.

REST API

Set FOUNDRY_OPENAI_BASE_URL to the current documented OpenAI-compatible base URL (including /openai/v1 where required), obtain a short-lived Entra token, and call the Responses endpoint without storing an API key:

bash

WrapCopy

ACCESS_TOKEN="$(az account get-access-token \ --resource https://cognitiveservices.azure.com \ --query accessToken --output tsv)" curl --fail-with-body \ --request POST \ --url "${FOUNDRY_OPENAI_BASE_URL}/responses" \ --header "Authorization: Bearer ${ACCESS_TOKEN}" \ --header "Content-Type: application/json" \ --data '{ "model": "REPLACE_DEPLOYMENT_NAME", "input": "Return only JSON with a greeting field.", "max_output_tokens": 100 }'

Use the endpoint format from the deployment's current Get endpoint view. Never print the token or put it in a URL, repository, or long-lived environment file.

What do quota and rate limits mean?

Quota limits allocated capacity; per-deployment limits and dynamic throttling can still apply. Models and deployment types vary by region. Request only justified quota, distribute deployments intentionally, and implement bounded retries that respect Retry-After. Limit concurrency so a retry storm does not worsen throttling.

Capacity planning uses measured tokens per request × requests per second, output variability, tool calls, and peak concurrency. Control maximum output tokens and route simple tasks to smaller models.

What safety layers are required?

• Product input validation and authorization.
• Platform content filters/safety configuration.
• Grounding and citation rules.
• Tool allowlists, parameter validation, and least-privilege identities.
• Human approval for consequential actions.
• Prompt injection and data-exfiltration defenses.
• Output validation before code, SQL, messages, or actions are used.
• Abuse monitoring, incident response, and evaluation.

A content filter is not a complete application safety system. It cannot know your authorization rules or business consequences.

How do CLI, Bicep, and Terraform fit?

Use current Microsoft Foundry CLI/SDK guidance for projects and deployments. Resource APIs are evolving. Bicep/AzAPI can create supported resource types, deployments, identities, private endpoints, DNS, role assignments, and diagnostics. Terraform provider support may lag new features; use azapi only with an owned testing strategy.

Never emit API keys as deployment outputs. Treat model deployment changes like application releases: evaluate, canary, observe, and roll back.

Verify and clean up

Run a small prompt, record deployment name/model/version, latency, input/output tokens, safety result, and cost estimate. Delete the model deployment and project resources after the lab. Check for retained search, storage, hub/resource, private endpoints, and logs.

Official references

• What is Microsoft Foundry?
• Create a Foundry project
• Model catalog and deployment
• Azure OpenAI documentation
• Foundry quotas and limits