Create and deploy an Azure OpenAI Service resource
| Product family | Azure OpenAI |
|---|---|
| Document source | Azure Developer Java Ai |
| Guide type | Reference Guide |
| Skill level | Intermediate to advanced |
| Time | 15 - 60 minutes depending on environment |
This page documents Create and deploy an Azure OpenAI Service resource for engineers working with Azure OpenAI. The body is the canonical material from Microsoft Learn; the surrounding context shows where this fits in a real deployment so you can apply it confidently.
Creating and deploying an Azure OpenAI service resource from Java is the first call you make on any AI-flavoured project. The Java SDK does the heavy lifting; the gotchas are in regional availability, quota, and pricing.
Provision the account first
Java doesn't create the cognitive services account itself - you do that via az CLI or ARM, then deploy a model into it. The two-step is intentional; it lets you separate identity setup from app deployment.
Pick the region carefully. As of mid-2026, GPT-4o is in South India but GPT-4o-mini is not - you'd have to hit Sweden Central. Mismatched regions add 80ms of latency for an Indian end-user, which adds up at the 95th percentile.
az cognitiveservices account create \
--name openai-prod-cin \
--resource-group rg-openai \
--kind OpenAI \
--sku S0 \
--location centralindiaDeploy a model
Once the account exists, deploy a model. The capacity field is your TPM cap in thousands. 50 means 50K TPM. Start low, monitor, grow. Over-provisioning quota you don't use costs you nothing, but the deploy fails if regional capacity is exhausted - and it sometimes is in South India.
az cognitiveservices account deployment create \
--name openai-prod-cin \
--resource-group rg-openai \
--deployment-name gpt-4o-mini-prod \
--model-name gpt-4o-mini \
--model-version 2024-07-18 \
--model-format OpenAI \
--sku-capacity 50 \
--sku-name StandardWire it into Java
Use com.azure.ai.openai.OpenAIClientBuilder with DefaultAzureCredentialBuilder. The Java SDK supports streaming responses, function calling, and Azure-specific extensions like 'on your data'.
OpenAIClient client = new OpenAIClientBuilder()
.endpoint("https://openai-prod-cin.openai.azure.com")
.credential(new DefaultAzureCredentialBuilder().build())
.buildClient();Cost reality
GPT-4o-mini at INR 12.5 / USD 0.15 per 1M input tokens is the workhorse for an Indian SaaS. A typical support-chatbot workload (1M conversations a month, 4K tokens average) costs around INR 50,000 (USD 602). GPT-4o is 25x the input cost - reserve it for the requests where the quality delta actually matters.
How this fits in a real Indian deployment
Most Indian SaaS teams I help run a three-environment ladder: dev in B-series VMs (around INR 2,400 / USD 29 a month per node), staging in D2s_v5 (INR 7,800 / USD 94), production in D4s_v5 with autoscale (INR 14,200 / USD 171 per node at baseline). The operation we just covered behaves the same across all three, but the blast radius is wildly different. Practise it in dev. Rehearse it in staging. Only then run it in prod.
The other piece that catches Indian teams off-guard is timezone handling. Azure diagnostic logs default to UTC. Your team's working hours are IST. When you correlate a 'something happened at 14:30' user report with the logs, you're really looking at 09:00 UTC. I configure Log Analytics workspace queries with explicit IST conversion - costs nothing, saves hours.
The on-call playbook
I keep a 6-line on-call playbook for every operation like this. Symptom (what the user sees). Detection (which metric fires). First triage command (read-only). First mitigation (reversible). Escalation criteria (when to wake someone up). Postmortem trigger (what counts as worth a writeup). Pin it in the team's runbook repo and reference it from the alert text.
A Bengaluru fintech I work with reduced their mean time to mitigate from 47 minutes to 11 minutes after we standardised on this format across all 30+ runbooks. Same engineers, same Azure, just better paper. Sometimes the cheapest reliability investment is the runbook, not the infrastructure.
What I'd test before touching production
Test the operation against a copy of the production state. For most Azure resources, that means deploying an identical resource in a dev subscription, populating it with synthetic data, and running the operation there. The Indian dev subscriptions I help set up usually cost between INR 8,000-15,000 (USD 96-180) a month for a realistic test environment - cheap compared to a botched production change.
I also run the operation in dry-run mode where the API supports it. Azure CLI's --no-wait or --what-if flags are underused. They show you what would happen without committing. Make the team's deploy pipeline run --what-if as a check on every PR that touches infrastructure. The friction is low; the catch rate is high.
Monitoring after the change
Every operation needs a 'did it actually work' metric. Pick one before you start the change. For deployment changes, that's request success rate. For configuration changes, that's the relevant config-read endpoint returning the new value. For role assignments, that's an actual API call from a member of the granted scope.
Set a 30-minute observation window in Application Insights or Azure Monitor right after the change. If the chosen metric drifts, roll back. Don't wait for the user complaints. The cost of false-positive rollbacks is minimal; the cost of confirmed-broken changes that linger is enormous - reputation, churn, the team's confidence in the deploy pipeline.
Application Insights costs INR 200 (USD 2.40) per GB ingested. A small Indian SaaS pushes 5-15 GB a month - call it INR 2,000 (USD 24). That budget pays for the monitoring and the change-validation queries combined. Skip this and you save INR 2,000 a month while paying for incidents that the monitoring would have caught.
Compliance posture for regulated workloads
For RBI-regulated fintech, IRDA-regulated insurance, or NPCI-adjacent payment workloads, treat every Azure operation as auditable. Activity logs to a separate Log Analytics workspace owned by the security team. Resource locks on production. Approval gates for high-blast-radius operations via Azure DevOps or GitHub Actions environments. None of this slows the team down once it's set up; not having it slows the team down catastrophically when the auditor visits.
I worked with a Pune insurance startup last quarter that hit IRDA's threshold for additional audit requirements at INR 50 crore in annual GWP. Their Azure governance was already mostly there because we'd built it in from year one. The audit took two weeks instead of two months. Build the boring infrastructure early.
Teaching this to a new hire
The fastest way to onboard a junior to an operation like this is the 'narrate-and-do' loop. Senior runs it once narrating every step. Junior runs it once with senior watching silently. Junior writes the runbook update. Senior reviews. Twenty minutes of senior time, junior is now operationally fluent. I've taught this pattern to lead engineers at three Indian companies this year and they all reported the same improvement in onboarding speed.
Pair this with a one-page architecture diagram that shows where this operation sits in the larger system. Indian engineering interviews often emphasise depth in narrow areas; what's underweighted is breadth across the system. The diagram fixes that. Keep it in the team wiki, update it quarterly, and refer to it during every incident retro.
What I won't do
I will not run an unfamiliar Azure operation in production without first running it in dev and reading the API reference for unexpected side effects. I will not skip the rollback rehearsal because the deploy 'looks safe'. I will not let a junior run a destructive command without me on the call - not because I don't trust the junior, but because two pairs of eyes catch more.
I will not approve any change that doesn't have a rollback path. Sometimes that means delaying the change by a day while we build the rollback. The pressure to ship is real; the cost of an unrecoverable production state is realler. Indian engineering teams I work with respond well to this discipline once they've experienced one ugly unrecoverable change.
What I actually do in production
I've seen this fail when a Mumbai broker app used the wrong subscription scope and got blasted with quota errors at market open. The fix was always the same boring thing: read the actual error, check the scope of the token or the SKU of the resource, and re-run with verbose logging. On the South India region with reserved instances for a year, the same footprint drops to around INR 12,800 (USD 154) per month.
The deeper lesson is that the boring stuff matters more than the clever stuff. A team that gets the boring 90% of the operation right will out-deliver a team that gets the clever 10% right and skips everything else. Indian engineering culture sometimes over-indexes on the clever; rebalance toward boring discipline and the velocity climbs.
Cost reality for Indian teams
On the South India region with reserved instances for a year, the same footprint drops to around INR 12,800 (USD 154) per month. Reserved capacity helps if you can predict 12 months out. If you cannot, stay on-demand and use autoscale - the savings from right-sizing usually beat the savings from prepaying.
Cost of egress is the one Indian teams under-budget most. Cross-region traffic between Central India and any non-India region runs INR 7-9 (USD 0.084-0.108) per GB after the free tier. A chatty service that does 200 GB a month of cross-region calls is INR 1,600 (USD 19) - small alone, but it compounds across a dozen services. Audit egress quarterly; co-locate where you can.
Support tier is the other one. Standard support is USD 100 (INR 8,300) a month. Most Indian startups skip it until they hit their first P1, then panic-upgrade. Develop the muscle of using Stack Overflow, Microsoft Learn, and the GitHub Azure issues before reaching for support - it builds team capability and saves money. Upgrade to Standard or Professional Direct when you actually have a P1 worth escalating.
Frequently asked
Will this break in air-gapped environments? Usually yes unless you mirror the dependency cache locally. I keep a Nexus proxy on a B2ms VM (INR 4,200 / USD 50 a month) for exactly this. The mirror serves Maven, npm, PyPI, and Docker registries; one VM solves the proxy problem for every language in the team.
What about compliance for RBI-regulated workloads? Keep the resource group in Central India or South India, enable diagnostic logs to a separate subscription, and document the data residency claim. Auditors ask for that paper trail. Tag every resource with the regulation it falls under (rbi=true, irda=true) so resource-graph queries can produce compliance inventories in seconds.
How do I rehearse the rollback? Quarterly drill on staging. Pick a recent deploy, write the rollback steps, run them, time the result. Goal is under 5 minutes from decision to traffic restored. Track the trend; if quarterly times are climbing, something rotted in the runbook and needs attention.
What if the operation fails mid-way? Most Azure operations are idempotent on the resource ID - re-running them is safe. The dangerous ones (delete operations, certain identity changes) are not idempotent and need careful retry logic. Read the API reference for the specific operation before you assume safety; the docs note idempotency explicitly.
Can I automate this with an MCP-enabled agent? Yes, with guardrails. The agent should refuse to run any destructive operation without a human confirmation step. Read-only operations (gets, lists, shows) are safe to let an agent run unattended. The Azure MCP server's annotations layer (destructive, requiresApproval) is exactly designed for this distinction - wire it into your agent policy.
Does this work the same in Azure Government or Azure China? Mostly yes, but check the endpoint URLs - they're different per cloud. Indian teams rarely touch those clouds; the answer matters for teams selling into US federal customers or mainland China. Use the AZURE_ENVIRONMENT env var or the equivalent SDK option to switch clouds without code changes.
How do I keep this skill fresh on the team? Schedule a 30-minute quarterly review where the team walks through the runbook end-to-end against the current Azure portal and CLI. Microsoft renames things; the runbook drifts. Catch the drift in a calm quarterly slot, not during an incident at 2am IST.
That's the version I wish I had when I started. If you found this useful, the next deeper layer is the cost-and-quota dashboard built on the same primitives - I'll publish that in a future article on this site.
Related fixes
Related guides worth a look while you sort this one out: