Azure OpenAI vs OpenAI directly: what actually changes in your code

Code written against OpenAI's API and code written against Azure OpenAI look almost identical at the call-site level — the SDK shapes are close, the request and response bodies are close. The differences that actually cause friction are almost all in configuration and operations, not in how you call the model.

Deployments, not model names

OpenAI's API takes a model name directly — gpt-4o, and so on. Azure OpenAI instead routes requests to a deployment you created in the Azure portal, which has its own name you chose, separately from the underlying model it points to. Code ported from OpenAI that hardcodes a model name will fail against Azure, not because the model doesn't exist, but because Azure is expecting a deployment name in that field, which may or may not match the model name depending on what you called it when you created the deployment.

# OpenAI
client.chat.completions.create(model="gpt-4o", ...)

# Azure OpenAI
client.chat.completions.create(model="my-gpt4o-deployment", ...)  # deployment name, not model name

Auth is a bigger shift than it looks

OpenAI uses a single API key. Azure OpenAI supports API keys too, but the production-recommended path is Azure AD (Entra ID) authentication with managed identities, which means no long-lived secret sitting in an environment variable at all — the application authenticates as an Azure identity and gets short-lived tokens. This is a genuinely better security posture, and it's also more setup: role assignments, identity configuration, and a different code path for acquiring credentials than "read an API key from an env var."

Rate limits are per deployment

On OpenAI, rate limits apply per account/organization. On Azure, they're provisioned per deployment, set when you create it (measured in tokens-per-minute), and don't auto-scale — hitting the ceiling means a 429 until you request a quota increase, not a limit that adjusts to demand. This matters operationally: a deployment sized for a proof of concept will rate-limit a real production load, and the fix is a quota request through Azure support, which has its own lead time separate from anything in your codebase.

Feature lag

New OpenAI model releases and API features don't land on Azure OpenAI simultaneously — there's typically a gap, sometimes weeks, sometimes longer, before a given capability is available as an Azure deployment. If a project's roadmap depends on a specific new feature landing on a specific date, that's worth checking against Azure's actual availability, not just OpenAI's announcement date, because those are two different dates.

None of this makes Azure OpenAI worse — for an org already standardized on Azure for compliance, networking, or identity reasons, the tighter integration is the entire point. It just means the actual porting work between the two is in configuration and infrastructure, not in prompt or completion code, and budgeting for that upfront avoids a surprise mid-migration.