1 Overview

Modules 1 and 2 made AI your assistant. Module 3 reverses the arrow: your applications become the caller, and OpenAI's models become a service your C# code consumes. The front door to that world for .NET teams is Azure OpenAI — OpenAI's model families operated as a first-class Azure service, inside your subscription, your identity system, your network, and your compliance boundary.

This tutorial is the map before the journey: what the service actually provides, how resources and deployments are structured, which model families exist and what they cost, the quota system that governs throughput, the Responsible AI machinery built into the platform, the Studio portal where you'll prototype, and — the decision every project makes early — how to choose the right model for a scenario.

Nothing here requires writing code yet; everything here is assumed by the code you'll write next. Teams that skip this layer end up confused about why their 'GPT-4o' code fails (they never deployed one), why bills surprise them (output tokens), or why load tests hit 429s (quota) — an hour of concepts now prevents all three.

2 Learning Objectives

After completing this tutorial, you will be able to:

• Explain what Azure OpenAI provides beyond raw model access — identity, networking, compliance, and data-handling guarantees.
• Describe the resource → deployment → call structure and why code targets deployment names.
• Distinguish standard, global, and provisioned throughput deployment options at a concept level.
• Survey the model families — GPT-4o and its mini variant, GPT-4 Turbo, embeddings models — and their roles.
• Reason about pricing: input vs output tokens, and quotas expressed as tokens per minute.
• State Microsoft's Responsible AI principles and how content filtering embodies them in the service.
• Navigate Azure OpenAI Studio (Azure AI Foundry) for deployments and playground experiments.
• Choose a model for a scenario using the capability–cost–latency triangle.

3 Prerequisites

• Tutorial 1's foundations: tokens, context windows, embeddings, and the three Microsoft AI products.
• Basic Azure familiarity: subscriptions, resources, resource groups, and the portal.
• An Azure subscription if you want to follow the step-by-step section hands-on (not required for the concepts).
• No new C# is needed this tutorial — code arrives in tutorial 11.

4 What Azure OpenAI Provides

Azure OpenAI is not 'a proxy to someone else's API'. It is the OpenAI model families — chat, reasoning, embeddings, image generation — operated by Microsoft as an Azure service, which changes four things that enterprises care about more than model quality:

• Identity and access: calls authenticate with API keys or, properly, Microsoft Entra ID with role-based access — the same identity fabric as the rest of your estate; no shared secrets in production.
• Network posture: resources support private endpoints and VNet integration, so AI traffic never crosses the public internet if you so choose.
• Data handling: your prompts and completions are not used to train the foundation models, and processing stays within your chosen Azure geography — the contractual answers to 'where does our data go?'.
• Operations: billing on your subscription, quotas you manage, Azure Monitor integration, SLAs, and regional deployment choices — a model as a managed Azure dependency, not an external experiment.

The mental model that organizes everything else: an Azure OpenAI resource is a container you create in a region; inside it you create one or more model deployments — named instances of specific models; and your code talks to the resource's endpoint, addressing a deployment name. The deployment indirection is the practical genius of the design: applications reference 'chat-prod', and which underlying model version that means is an operational decision you can change without touching code.

5 Deployment Models: From Resource to Running Requests

Deployments come in flavors that matter at different scales. Standard is pay-as-you-go against your regional quota — the default for development and most production workloads. Global variants route requests across Microsoft's global capacity for better availability of scarce models, trading strict regional processing. Provisioned throughput reserves dedicated capacity (purchased as PTUs) for workloads needing predictable latency at high volume — call-center scale, not side-project scale. Names and exact options evolve; the concept triangle — shared vs global vs dedicated capacity — is stable.

6 The Model Families: GPT-4o, GPT-4 Turbo, and Embeddings

The model catalog is a moving target — new versions ship, old ones retire on published schedules — but the family structure is durable and is what you should learn:

Two structural points beginners miss. First, chat models and embeddings models are different tools, not quality tiers — a complete AI feature typically deploys one of each (retrieval finds, chat writes; tutorial 1's division of labor). Second, model versions are explicit: a deployment pins a model version, versions have retirement dates, and upgrades are your scheduled operational act — with your regression set from tutorial 6 run before the switch, because prompts are model-sensitive.

7 Pricing: Tokens, Meters, and Quotas

Azure OpenAI's economics reduce to one sentence: you pay per token, in both directions, at rates that vary by model — and you are throttled per minute by quota. Everything you send — system message, conversation history, retrieved documents — meters as input tokens; everything generated meters as output tokens, at a higher rate (often 3–4×). This is why tutorial 3's history management and tutorial 4's context precision are cost engineering, not just craft: replayed history is re-billed every turn.

Quota is the operational half: each subscription receives per-region, per-model capacity expressed as tokens per minute (with a derived requests-per-minute), which you divide among deployments when creating them. Quota is not a bill — it's a ceiling; you can request increases. Provisioned throughput replaces the shared-pool model entirely with reserved capacity for workloads where p99 latency matters more than pay-as-you-go flexibility. The practical rules: watch usage metadata from day one, alert on 429 rates, and remember that the cheapest optimization is almost always a smaller model or a leaner prompt, not a bigger quota.

8 Responsible AI: Principles Into Platform

Microsoft operates Azure OpenAI under its Responsible AI standard — six principles that sound abstract until you meet their concrete platform embodiments: fairness (systems should treat people equitably), reliability and safety (systems should perform safely under expected and unexpected conditions), privacy and security (data protected and under user control), inclusiveness (systems should empower everyone), transparency (people should understand how decisions are made), and accountability (humans remain answerable for the systems they deploy).

In the service, the principles are machinery, not posters. Content filtering runs on every request by default: classifiers screen both prompts and completions across harm categories (hate, sexual, violence, self-harm, plus jailbreak detection), blocking above configurable severity thresholds — your application must handle 'the filter blocked this' as a normal response case. Access controls and abuse monitoring govern the service itself. Data-handling commitments (no training on your prompts; regional processing) implement privacy. And the accountability principle lands on you: the platform provides the guardrails, but what your application does with model output — tutorial 6's validation, gating, and human-in-the-loop design — remains your responsibility, explicitly.

9 Azure OpenAI Studio and the Tooling Around the Service

Azure OpenAI Studio — whose capabilities now live in the Azure AI Foundry portal — is the service's workbench: the place where concepts in this tutorial become clickable reality. What you do there:

• Deployments: browse the model catalog (families, versions, regional availability), create deployments, assign quota slices, and manage version upgrades.
• The chat playground: interactive prompt iteration against your deployments — system message editing, parameter sliders (temperature, max tokens), and conversation testing. Tutorial 2's iteration loop has a home here before any code exists.
• View code: the playground exports your current setup as starter code — a bridge to tutorial 11.
• Content filter configuration: view and (within policy) adjust category thresholds per deployment.
• Quota management: see per-region allocations and consumption, request increases.

Around the portal sits the standard Azure toolchain: everything the Studio does is scriptable via the Azure CLI and infrastructure-as-code (Bicep/Terraform) for real environments — resource, deployments, and network configuration in source control like any other infrastructure. And for code, the SDK families (Azure.AI.OpenAI for .NET among them) speak to the same endpoints — next tutorial's subject. The workflow that works: prototype prompts in the playground, export the shape, industrialize in C# with configuration and identity done properly.

10 Choosing the Right Model for a Scenario

Model selection is a triangle: capability (can it do the task well?), cost (per token, at your volume), and latency (time to first token and to completion). You cannot maximize all three; scenarios pick their corner:

The professional's default: start with the mini-class model and real test cases; escalate to the flagship only where measured quality falls short; and split pipelines — a cheap model for the bulk step, the expensive model for the hard 10%. Selection is also not permanent: the deployment indirection means the model behind 'chat-prod' is an operational dial, and your tutorial 6 regression set is the gate every time you turn it.

11 Code Examples in C#

Code proper begins next tutorial; here, the two C# artifacts worth having before any call is made. First, configuration that mirrors the service's structure — resource endpoint plus deployment names, never raw model names, never secrets in source:

// appsettings.json (non-secret parts):
// {
//   "AzureOpenAI": {
//     "Endpoint": "https://my-resource.openai.azure.com/",
//     "ChatDeployment": "chat-prod",       // -> GPT-4o mini today; swappable
//     "EmbeddingDeployment": "embed-prod"  // -> text-embedding-3-large
//   }
// }
// Key (dev only - prefer Entra ID in production):
//   dotnet user-secrets set "AzureOpenAI:ApiKey" "<key>"

public sealed class AzureOpenAIOptions
{
    public const string SectionName = "AzureOpenAI";

    public required Uri Endpoint { get; init; }
    public required string ChatDeployment { get; init; }
    public required string EmbeddingDeployment { get; init; }
    public string? ApiKey { get; init; } // null => use Entra ID credential
}

Second, a tiny cost model — the kind of helper that keeps token economics visible in design discussions before any invoice arrives:

public static class TokenCost
{
    // Illustrative per-1K-token rates - REAL rates vary by model and change;
    // read them from configuration, sourced from current published pricing.
    public static decimal EstimateRequestCost(
        int inputTokens, int outputTokens,
        decimal inputPer1K, decimal outputPer1K) =>
        inputTokens / 1000m * inputPer1K +
        outputTokens / 1000m * outputPer1K;

    // ~4 chars per token English heuristic (tutorial 1) for pre-call sizing:
    public static int RoughTokens(string text) =>
        (int)Math.Ceiling(text.Length / 4.0);
}

// Design-time sanity check for a summarization feature:
// 2,000 input tokens + 300 output, 50k requests/month
// -> run the numbers per candidate model BEFORE building.

12 Step-by-Step: Standing Up Your First Azure OpenAI Resource

The hands-on path from nothing to a tested deployment — portal edition (every step scriptable later via CLI/Bicep):

1. Check model availability first: consult the model-availability documentation and pick a region that has the models you want (a chat model and an embeddings model). Region is hard to change later.
2. Create the resource: Azure portal → Create resource → Azure OpenAI; choose subscription, resource group, the region from step 1, a resource name (it becomes your endpoint), and a pricing tier.
3. Open the Studio/Foundry portal from the resource and go to Deployments: deploy a chat model — pick the family (e.g. GPT-4o mini to start), a version, a deployment name your code will use ('chat-dev'), and a quota slice (TPM).
4. Deploy an embeddings model the same way ('embed-dev' → a text-embedding-3 model) — most real features need both, and deploying now saves a context switch later.
5. Test in the chat playground: select 'chat-dev', write a system message, converse; adjust temperature and max tokens and watch behavior change — tutorial 2's iteration loop, live.
6. Trip the content filter deliberately (ask for something the harm categories block) to see what a filtered response looks like — your code will need to handle this case gracefully.
7. Collect connection details: from the resource — endpoint URL and keys (Keys and Endpoint blade). Note them into user-secrets, not source; production will use Microsoft Entra ID instead.
8. Check Quotas: see your TPM allocation per model and region, how much your deployments consumed, and where to request increases — the page you'll revisit when load testing.
9. Optional but wise: use 'View code' in the playground to see your setup expressed as SDK calls — a preview of exactly what tutorial 11 builds properly.

13 Limitations and Caveats

• Everything specific ages fast: model names, versions, context sizes, prices, quota defaults, and portal layouts all change on months-scale. The families, the resource→deployment structure, and the selection axes are the durable knowledge; verify specifics against current documentation at build time.
• Naming is in transition: 'Azure OpenAI Studio' capabilities now live in the Azure AI Foundry portal — expect both names in docs and this course; they refer to the same workbench.
• Model availability is uneven across regions; the model you want may dictate your region, with data-residency consequences to check.
• Quota is a ceiling, not a guarantee of instant capacity — scarce models can be constrained; production plans include retry/backoff and sometimes multi-region strategies.
• Content filtering will occasionally block legitimate content (false positives) — handle filtered responses as a normal case, and know the adjustment process for your workload.
• Model retirements are real: deployments pin versions, versions have end-of-life dates, and upgrades are scheduled operational work gated by your regression set.
• Pricing in this tutorial is deliberately unstated in numbers: any figure printed here would be wrong within months. The cost model (input/output per-token, output premium) is the stable part.

14 Best Practices and Common Mistakes

The habits to establish before writing a line of calling code:

• Name deployments by role ('chat-prod', 'embed-dev'), never by model — preserve the indirection that makes upgrades codeless.
• Choose regions by model availability and residency needs, deliberately, first.
• Start with mini-class models; escalate on measured evidence, not vibes; split pipelines cheap-bulk/expensive-hard.
• Log usage metadata from the first prototype call; estimate costs at design time with the back-of-envelope model.
• Keep secrets in user-secrets/Key Vault from day one; plan production for Entra ID, not keys.
• Prototype prompts in the playground; export via View code; industrialize in C#.
• Handle content-filter blocks and 429s as normal response cases in every client you write.

The beginner mistakes this tutorial exists to prevent:

• Calling model names instead of deployment names, then being confused by 404s.
• Creating the resource in a region that lacks the model you actually wanted.
• Defaulting to the flagship model for everything and discovering the bill at month-end.
• Ignoring output-token premium — 'it's just a summary' at 4× input rates, times a million calls.
• Load-testing into 429s with no backoff and calling the service 'unreliable'.
• Treating content filtering as an error to eliminate rather than a case to handle.
• Hard-coding keys in source 'temporarily' — tutorial 6's rule did not expire.
• Assuming today's model catalog is tomorrow's — skipping the regression gate on upgrades.

20 Summary & Key Takeaways

• Azure OpenAI = frontier models + enterprise wrapper: Entra ID, private networking, no-training data commitments, regional processing, subscription operations.
• Structure everything on resource → deployment → call; name deployments by role and keep the indirection that makes upgrades codeless.
• Know the families — GPT-4o flagship, mini workhorse, o-series reasoning, text-embedding-3 vectors — and that chat vs embeddings is a division of labor.
• Economics: tokens both ways, output at a premium, history re-billed — prompt economy is cost engineering; log usage from call one.
• Quota throttles (429s), it doesn't bill — backoff, alerts, and capacity math are client responsibilities; PTUs exist for latency-critical scale.
• Responsible AI is machinery (content filtering, data handling) plus your retained accountability — filtered responses are a normal case to handle.
• The Studio/Foundry playground hosts prompt iteration before code; View code bridges to the SDK; real environments are scripted as IaC.
• Choose models by the capability–cost–latency triangle: mini-first, escalate on evidence, split pipelines, and re-verify with regression sets on every swap.

The platform layer is mapped. Next: the code — building a proper C# client for everything defined here, with configuration, identity, streaming, and error handling done the production way.

21 Next Steps

Continue with the next tutorial in the path: Calling Azure OpenAI from C# — the Azure.AI.OpenAI SDK, chat completions, streaming, embeddings calls, and the client patterns (retry, usage logging, filter handling) that this tutorial's concepts demand.

• Hands-on: run the section 12 walkthrough — resource, two deployments, playground session, deliberate filter trip, quota page visit.
• Practice: compute a design-time cost estimate for one feature you'd actually build — tokens per request × volume × current rates for two candidate models.
• Practice: write your team's deployment-naming convention and region-decision notes — one paragraph each, versioned with your infrastructure code.
• Reading: the Azure OpenAI models documentation (current families, versions, availability) and the quotas & limits page — the two pages this tutorial deliberately refuses to freeze in time.
• Looking ahead: keep the resource from the walkthrough alive — tutorial 11's code connects to it in the first ten minutes.