OpenAI quietly ended its Azure exclusivity this week. The models aren't moving, the APIs aren't changing, but the paperwork landscape just shifted — and that matters more than most coverage is letting on.
What actually changed
Since 2019, Microsoft Azure was the only cloud that could host OpenAI's models for enterprise customers. If a client wanted GPT-4 in a HIPAA-compliant environment with a Business Associate Agreement in place, Azure was the answer — full stop.
That's no longer true. OpenAI can now sign direct enterprise agreements with AWS, Google Cloud, or any other provider. They can also sell direct without a hyperscaler intermediary at all.
What didn't change: Azure's existing OpenAI customers keep their contracts, their pricing, and their compliance posture. Microsoft didn't lose anything it already had. The change is about what comes next — new builds, new clients, new contracts.
The three things that actually shift
Most clients don't care which data center their LLM calls route through. What they care about is procurement, data residency, and compliance paperwork. Here's where the new landscape changes each.
Procurement. Before this week, a client on AWS who wanted OpenAI models had two choices: add Azure to their cloud footprint (another vendor relationship, another billing account, another security review) or route API calls through OpenAI's direct API with no enterprise contract. Now they can negotiate an OpenAI agreement that runs natively inside AWS. One fewer vendor. One fewer invoice.
Data residency. Azure's OpenAI service has strong data residency commitments — models can be deployed to specific Azure regions, and data processed there stays there. AWS and GCP have equivalent region controls. OpenAI's direct API is US-based by default. The specifics of each new cloud agreement aren't public yet, but if your client has EU data residency requirements, you'll need to read the actual contract, not assume parity with the Azure offering.
BAA and HIPAA. Azure has a signed BAA covering Azure OpenAI Service. If a client wants a BAA for OpenAI on AWS, that agreement doesn't exist yet — it will need to be negotiated as part of any enterprise deal. For healthcare clients, this is the piece to watch. Don't assume a BAA is available just because the technical integration is.
How to think about provider choice on a new build
When we're scoping an AI feature for a client, the model provider choice comes down to four questions — in this order:
1. Is there an existing cloud commitment? If a client already has committed spend on AWS or GCP (reserved instances, enterprise discount program, credits), routing OpenAI calls through that cloud can offset cost against existing budget. That's worth real money. If they're on Azure, nothing changes — stay there.
2. Are there compliance constraints? HIPAA, FedRAMP, SOC 2 Type II requirements narrow the field fast. Azure OpenAI Service has the most established compliance documentation right now. New cloud agreements for OpenAI on AWS or GCP will take time to accumulate the same audit history. For regulated clients, Azure is still the low-risk choice in 2026.
3. What does the rest of the stack look like? We build most new projects on Vercel + Supabase. Vercel deploys closest to the edge; Supabase runs on AWS. Adding Azure just for OpenAI when everything else is AWS introduces latency and operational complexity that usually isn't worth it. For a Vercel + Supabase project, OpenAI direct or an AWS-native agreement is the cleaner fit.
4. Does model choice even require OpenAI? For a lot of what we build — content generation, classification, light reasoning tasks — Claude Haiku or Gemini Flash are cheaper and perform comparably. We only reach for GPT-4 class models when a client has a specific reason. The provider question is moot if you pick the right model first.
Clients already on Azure OpenAI: nothing to do right now
If a client is running production workloads on Azure OpenAI Service today, there's no reason to move. The service isn't being deprecated. Microsoft still has a deep investment in keeping it competitive — they have a 49% stake in OpenAI's profits and aren't walking away from that.
The scenario where you'd consider migrating is if a client runs everything else on AWS, has significant committed AWS spend, and is planning to scale AI usage heavily over the next 12 months. In that case, consolidating vendors and applying committed spend against OpenAI calls on AWS could save meaningful money. Run the numbers before committing to that migration, though — data transfer costs and re-engineering time add up.
What this means for agencies advising clients
The practical impact for most agency clients this year is limited. The change matters more for enterprise procurement teams at larger organizations than for the $50K–$200K web projects we run.
Where it does affect agency work: when a client is in the early scoping phase and asks which cloud to use for a new AI-powered product. That decision is no longer "Azure if you want OpenAI with an enterprise contract, anything else if you don't." Now it's a genuine choice.
The decision tree we're using: existing cloud commitment first, compliance constraints second, stack fit third, model selection last. The provider exclusivity question doesn't appear anywhere in that list — because it shouldn't. Pick the provider that makes the build clean, compliant, and cost-efficient. The OpenAI–Azure relationship is Microsoft's business, not yours.
