Should you use Azure OpenAI or OpenAI's own API? Choose Azure OpenAI when you need models inside your Azure estate: deployments under your subscription, a choice of where inference is processed, Microsoft Entra ID, private networking and billing through your Azure agreement. Choose OpenAI's API when you want new models and features first and one global endpoint, with regional processing in the US, Europe or the UAE if you need it. Since Azure's v1 API, the same OpenAI SDK talks to both. Many production teams run both, as two quotas and a failover pair for the same model family.
The differences that matter
| OpenAI API | Azure OpenAI | |
|---|---|---|
| Who runs it | OpenAI | Microsoft, in your Azure subscription |
| Endpoint | https://api.openai.com/v1 | https://YOUR-RESOURCE.openai.azure.com/openai/v1/ |
model field | Model id | Your deployment name |
| Authentication | API keys | API keys or Microsoft Entra ID tokens |
| Where inference runs | Global; regional processing in US, Europe, UAE | Global, a data zone (US, EU, APAC), or an Azure geography |
| New models | Usually first | Global deployments first, geography types last |
| Capacity model | Organization and project limits by tier | Quota per deployment type and region; provisioned throughput |
| Billing | OpenAI account | Your Azure agreement |
| Abuse monitoring | Up to 30 days by default; zero data retention by approval | Classifier-based, with automated and possible human review; modified monitoring by approval |
Calling Azure OpenAI with the OpenAI SDK
Microsoft's v1 API removes the old dated api-version parameter and the separate Azure client. You use the standard OpenAI() client, set base_url to your resource with /openai/v1/ appended, and pass the deployment name as the model1:
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["AZURE_OPENAI_API_KEY"],
base_url="https://YOUR-RESOURCE-NAME.openai.azure.com/openai/v1/",
)
response = client.responses.create(
model="my-gpt-deployment", # the deployment name you created, not the model id
input="Summarise this incident in two sentences.",
)For Entra ID, pass a bearer token provider for the https://ai.azure.com/.default scope as api_key, and the client refreshes tokens itself. The base URL also accepts the services.ai.azure.com host format, and the v1 API can call other providers' models deployed in Foundry, such as DeepSeek and Grok, with the same chat completions syntax1.
The deployment name is the most common migration bug: a request that names a model id where Azure expects a deployment name fails with "deployment not found". Keep a mapping from model id to deployment name in configuration, per environment.
Where your data is processed
This is usually the deciding row. Azure's deployment type sets the processing location, while data stored at rest stays in your resource's Azure geography2:
- Global types may process in any Azure region.
- Data Zone types process only within the Microsoft-defined US, EU or APAC data zone; the EU zone follows the Azure EU Data Boundary.
- Standard and Regional Provisioned types process prompts and responses within your chosen Azure geography.
There is a trade-off in timing. Microsoft recommends Global Standard as the default because it launches first when a new model releases, has the lowest price and the broadest regions; new deployment types arrive in the order Global, Data Zone, then geography-based, and geography-based types "have no guaranteed availability date"2. Strict residency can mean waiting for the newest models.
OpenAI's own API now has regional options too. Projects can set a region subject to eligibility: regional storage covers ten locations, while regional processing — inference within the region — is available in the United States, Europe and the United Arab Emirates3. Its pricing page applies a 10% uplift on regional processing endpoints4.
Capacity and cost
Azure gives three billing categories: Standard (pay per token), Provisioned (reserved throughput units with lower latency variance) and Batch (asynchronous, 50% less than Global Standard, with its own enqueued-token quota so it does not disturb online traffic)2. Quotas are per deployment type and region, which is why large Azure users spread deployments across regions or move to Global or Data Zone types with higher default quota.
OpenAI limits by organization and project and usage tier, with Batch and Flex at half the standard rate and Fast mode at double4. OpenAI API pricing has the rate card.
Prices on Azure depend on region, deployment type and your agreement, and can differ from OpenAI's list rate. If your company has committed Azure spend, model usage on Azure counts toward it; usage on a direct OpenAI contract does not. Price each request at the rate your contract carries, not the list rate on a website.
Data handling
OpenAI states that API data is not used to train its models unless you opt in, that abuse-monitoring logs are kept up to 30 days by default, and that zero data retention is available by approval for eligible endpoints3. Microsoft's abuse monitoring classifies prompts and completions; flagged content may be sampled for automated review, which does not store it or use it for training, and in some cases for human review by authorized Microsoft employees. Customers who meet Limited Access criteria can apply for modified abuse monitoring, which removes human review5. Read both against your own data classification; neither is a substitute for deciding which data may reach any model.
Why many teams run both
Running OpenAI and Azure OpenAI side by side gives you:
- Two independent quotas for the same model family, which raises the ceiling at launch.
- A failover pair. An incident on one platform rarely affects the other at the same moment, and prompts behave closest on the same model.
- Workload placement. Residency-sensitive traffic on an Azure data zone deployment, everything else on whichever endpoint has the newest model.
The cost is two sets of ids (model id versus deployment name), two error vocabularies and two quota systems to watch. Azure OpenAI and Bedrock behind one gateway covers the mapping work.
Connecting both to INFRO
INFRO connects OpenAI and Azure OpenAI as separate provider kinds on your own accounts; an Azure connection is configured with your resource, a deployment and its own key, so your application names the model id and the connection supplies the deployment. A route can put both behind one name, ordered or weighted, with failure rules per kind of error, so a 429 on Azure moves the request to OpenAI or the reverse. Negotiated rates can be set per model and per provider kind from the Team plan, because the same model bills differently on a direct account and on Azure. Codex and other Responses API clients reach both through INFRO's /v1/responses, sent to the provider as written.
Summary
Azure OpenAI is OpenAI's models inside your Azure estate: deployments, processing location by deployment type, Entra ID and your Azure agreement, with the newest models arriving on Global deployments first. OpenAI's API gets features first and now offers regional processing in three regions. Use the one your data and contracts require, and consider both when you need more capacity or a failover path.