On 16 January 2023, Microsoft moved Azure OpenAI Service from limited preview to general availability. That is a small phrase with a fairly large practical impact. It means the GPT-3.5 family, Codex, and DALL-E 2 models became available to any business that applies and gets approved, running on Azure infrastructure instead of directly through OpenAI’s own API. For architects who had been waiting on the sidelines because a preview service is hard to justify to a security or procurement team, this was the moment the conversation actually became possible.
I want to walk through what changed with GA, what the application process really looks like in practice, and where I think this fits (and does not fit) compared to calling the OpenAI API directly. This is less a tutorial and more a field guide for the decisions you will actually face when someone in your organisation asks ‘can we use ChatGPT-style models in our product.’
GA versus preview: what actually changed
Preview services are fine for a proof of concept on your own laptop. They are a much harder sell once legal, compliance, or a customer’s security questionnaire gets involved, because preview terms usually carry weaker SLAs and no formal support commitment. General availability changes that conversation. With GA, Azure OpenAI Service sits under the same production support and enterprise agreement terms as any other Azure service, which is the detail that actually unblocks internal approval in most regulated organisations I have worked with.
The models on offer at GA were GPT-3.5 (the family behind ChatGPT), Codex (code generation, since retired in favour of newer GPT models), and DALL-E 2 for image generation. Microsoft also confirmed that a fine-tuned ChatGPT model trained and served on Azure infrastructure was coming through the same service shortly after. None of this was new technology at the model level. What was new was the packaging: the same models, wrapped in Azure’s compliance certifications, private networking options, and regional data residency controls.
The Limited Access Framework: what applying for access is actually like
Here is the part the announcement glosses over and the part that catches most teams off guard. Getting access to Azure OpenAI Service at GA was not a matter of clicking ‘create resource’ in the Azure portal. Microsoft ran it through what they call the Limited Access Framework, which requires you to submit an application describing your intended use case before you get approved to deploy the service in a subscription.
In practice this means writing a short but specific description of what you plan to build, who your end users are, and what kind of content the model will generate or process. Vague applications (‘we want to explore AI capabilities’) tend to sit in a queue longer than applications that name a concrete scenario, such as summarising support tickets or drafting first-pass marketing copy for internal review. If you are planning a proof of concept, apply early and apply with a real use case in mind, because approval was taking anywhere from a few days to a couple of weeks depending on the scenario and region at the time of GA.
This gating is also why Azure OpenAI Service is not a drop-in replacement for the public OpenAI API in every scenario. If your product needs same-day self-serve signup for end users, this approval step is friction you cannot design around. If your organisation already has an enterprise agreement with Microsoft and needs the model behind your existing compliance boundary, the same friction is the point, not a bug.
Content filtering: a guardrail you should design around, not fight
Azure OpenAI Service ships with content filters that sit in front of and behind the model, screening both the prompts going in and the completions coming out for categories like hate, violence, self-harm, and sexual content. These filters are not optional add-ons you toggle on for a stricter deployment. They run by default, and Microsoft has been clear that repeated or serious policy violations can result in a developer being asked to change their usage or losing access entirely.
The practical takeaway for architects: build your error handling around the possibility that a completion gets blocked by the content filter, not just around rate limits or timeouts. I have seen teams treat a content-filter rejection as an application bug during testing, when it was actually the filter doing exactly what it is meant to do on ambiguous or borderline input. Log filter rejections separately from other failures so you can tell the difference between ‘the model is down’ and ‘the model refused this specific input.’
Why Microsoft is pushing the infrastructure story so hard
A good chunk of the original announcement is really about Azure’s hardware, not the OpenAI models themselves, and that is worth paying attention to. Azure was, at the time, the only public cloud offering purpose-built AI supercomputers at the scale needed to train and serve models like GPT-3.5, built on Nvidia A100 GPUs with a custom networking design. Azure ranked in the top 15 of the TOP500 global supercomputer list, the highest ranking of any public cloud provider.
This matters practically because it explains why large customers like GitHub (for Copilot), Power BI, and later Microsoft Designer were all running production workloads on this same infrastructure before the public GA date. If you are evaluating Azure OpenAI Service for a workload with real production traffic, the fact that Microsoft was already dogfooding it internally at scale is a more useful signal than the announcement’s own promotional language about advanced AI models.
Where this fits against calling OpenAI directly
The question I get asked most often is why a team would choose Azure OpenAI Service over signing up directly with OpenAI. The honest answer is that it depends on what constraint you are solving for. If your organisation already has data residency requirements, needs the workload inside a private virtual network, or needs the model provider to be covered under an existing Microsoft enterprise agreement and audit trail, Azure OpenAI Service solves a real problem. If you are a small team or an individual building a side project and none of that applies, the direct OpenAI API will almost always get you moving faster, since it skips the Limited Access application step entirely.
One trade-off worth flagging: at GA, Azure OpenAI Service was only available in a handful of Azure regions, and model availability varied by region. Do not assume every model is available in every region you already use for other Azure services. Check regional availability before you commit an architecture diagram to a specific region, because moving a workload later to chase model availability is a bigger job than most teams budget for upfront.
What to actually do next
If you are starting from zero, the practical path is to apply for access to Azure OpenAI Service first, since that approval step is the long pole. Once approved, you create the Azure OpenAI resource from the Azure portal like any other Azure resource, then deploy a model from the ones available in your chosen region before you can call it. From there you have a choice between the Azure OpenAI Studio web interface for quick experimentation, or the SDK and REST API directly if you are wiring it into an existing application.
A natural follow-up piece from here, and one I would recommend to anyone reading this as a starting point rather than a full guide, is a hands-on walkthrough of provisioning the resource, applying for access, and deploying a first chat completion model with the quota and region caveats spelled out step by step. This announcement is the starting gun, not the instructions.
Leave a Reply