Microsoft announced the general availability of Azure OpenAI Service on January 17, 2023. The service brought selected OpenAI models into Azure with Microsoft-operated cloud infrastructure and enterprise-oriented controls. That launch is historically important, but its model catalog, APIs, access model, branding, and platform context have changed substantially since then.
Use this page for the 2023 milestone. For a present-day deployment, follow current Microsoft Foundry documentation rather than treating the original announcement as a current product specification.
By Kodi A. Cochran · Published and reviewed September 28, 2026. Historical event: January 17, 2023.
Microsoft's January 2023 announcement said Azure OpenAI Service was generally available and described it as a way for organizations to apply for access to advanced OpenAI models through Azure. The launch built on Microsoft's partnership with OpenAI and positioned the service for enterprise application development rather than only experimental model access.
The date matters because search results often surface old announcement pages next to current implementation documentation. A reader searching for “Azure OpenAI general availability January 2023” is usually trying to establish a historical fact: when the service reached GA and what Microsoft said at that point. The answer is January 17, 2023.
General availability did not mean every model, region, feature, deployment type, API, or later product capability was already present. It meant the Azure service itself had moved into a generally available state under Microsoft's service model. Model availability and platform capabilities continued to evolve after the announcement.
This distinction matters for architecture and procurement evidence. A dated launch article can establish that a service existed and describe its initial positioning. It should not be used by itself to prove what models, controls, regions, quotas, interfaces, or commercial terms are available years later.
The January 2023 Azure blog stated that businesses could apply for access to models including GPT-3.5, Codex, and DALL-E 2. That list is useful historical context because it shows the types of workloads Microsoft was emphasizing: language generation, code-oriented assistance, and image generation.
Was ChatGPT already included at GA? The announcement described ChatGPT access through Azure OpenAI as a future addition. It did not say ChatGPT was already available through the service that day. Keep the service launch, individual model availability, and ChatGPT's separate product history distinct when recording this milestone.
Do not convert that sentence into a current model catalog. Azure OpenAI has changed repeatedly since 2023, and current Microsoft Foundry documentation now describes a much broader and newer set of Azure OpenAI models. Model availability also varies by region, deployment category, cloud, and lifecycle stage.
For a present-day design, record the exact model identifier, deployment type, region, API surface, lifecycle policy, context limits, supported modalities, quota, and pricing basis that apply to your workload. Those are implementation facts that should be sourced from current documentation and your actual subscription rather than inherited from a historical launch post.
The same rule applies to “GA” labels at the model level. The service being generally available does not imply that every model or feature exposed through that service is itself generally available. Some capabilities can be preview while the underlying platform is mature.
For enterprise technology teams, the strategic appeal of Azure OpenAI was the ability to consume OpenAI model capabilities through a cloud platform they may already have used for identity, networking, billing, monitoring, policy, procurement, and operational support. The model was only one component of the production system.
That framing is still useful. A generative AI workload needs more than an inference endpoint. It needs an identity model, authorization, application secrets, network design, data-handling rules, observability, abuse controls, cost management, model-version governance, incident response, continuity planning, and a process for evaluating model changes.
Cloud integration can make some of those controls easier to connect, but it does not automatically create a safe AI application. Teams still need to define what data may be sent to the model, how prompts and outputs are logged, what downstream actions are allowed, how sensitive information is filtered or protected, and what happens when the model is unavailable or produces an unsafe result.
Procurement teams should therefore separate platform assurance from application assurance. A cloud provider can document its service controls while the customer remains responsible for the way its application uses the service, the identities granted access, the data submitted, and the decisions made from generated output.
Define which applications, workloads, users, and administrators can invoke model deployments or change configuration. Prefer workload identities and narrowly scoped roles over shared long-lived secrets where the platform and application architecture support them.
Map the prompts, retrieved context, uploaded files, conversation state, outputs, logs, and evaluation data that pass through the system. Apply data-handling rules based on actual sensitivity rather than assuming every AI request has the same risk.
Record the exact deployment and version assumptions. A model upgrade can change quality, latency, token behavior, tool use, safety behavior, or cost. Treat model changes as production changes that require evaluation and rollback planning where appropriate.
Plan for rate limits, regional availability, provider incidents, unsafe outputs, prompt injection, excessive cost, data leakage, dependency failure, and compromised application identities. The AI endpoint should fit into ordinary resilience and security engineering rather than sit outside it.
By 2026, Microsoft documentation describes Azure OpenAI models as part of Microsoft Foundry's model ecosystem. The current platform includes model catalogs, multiple deployment categories, modern API surfaces, region-specific availability, lifecycle controls, and a broader set of AI development capabilities than the January 2023 launch article described.
That evolution is exactly why historical technology pages need explicit dates. The original GA announcement remains useful for the timeline and the launch-era value proposition. It is not the right document for deciding which model to deploy today or which API version an application should call.
Microsoft also provides an upgrade path from older Azure OpenAI resource experiences into the broader Foundry experience. Existing workloads may keep established Azure OpenAI endpoints while gaining additional Foundry capabilities depending on how the environment is upgraded. A migration decision should therefore inventory the current resource type, endpoints, identities, network restrictions, policy assignments, model deployments, quotas, and application dependencies before making changes.
For current implementation work, start from Microsoft Learn and the Foundry portal associated with your tenant. Verify model availability in the intended region and cloud, then capture the exact documentation and configuration used in the architecture record.
A useful evaluation begins with the application outcome rather than the model catalog. Define the tasks the system must perform, the quality threshold, unacceptable failure modes, latency target, expected volume, data classes, integration requirements, geographic constraints, and human-review needs.
Then build a representative evaluation set. Measure task quality, factuality where relevant, structured-output reliability, tool-call behavior, refusal behavior, prompt-injection resistance, latency, throughput, token use, and cost. Re-run the evaluation when the model, system prompt, retrieval layer, tool permissions, or application logic changes materially.
Review the platform controls separately. Test authentication, network access, secret handling, role assignment, logging, model deployment changes, quota behavior, incident escalation, and recovery. If a model endpoint is unavailable, know whether the application fails closed, falls back, queues work, or switches to another approved deployment.
Finally, document which claims come from Microsoft and which come from your own testing. Vendor documentation can establish supported capabilities and platform behavior; it cannot prove that your prompt design, retrieval data, agent tools, business process, or safety controls work for your organization.
The January 2023 GA milestone remains useful because it marks an important transition in enterprise generative AI. Its best use today is as a historical anchor, not a substitute for current architecture evidence.
Follow the next implementation topic without returning to search.
Evaluate model quality, risk, and evidence before deployment
Continue readingEstablish accountable AI governance and evidence practices
Continue readingEvaluate AI vendors with governance and evidence controls
Continue readingUse the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.