3.1.1. Deployment Types: Standard, Provisioned, Batch, and Routing Scope
💡 First Principle: Deployment type answers two independent questions at once — how is capacity allocated (standard/pay-per-token vs. provisioned/reserved) and where does processing happen (global, data zone, or regional routing). Reading a scenario means spotting which of those two questions the constraint is about.
The capacity axis: Standard (pay-as-you-go) bills per token with best-effort capacity — ideal for variable, bursty, low-to-medium volume, and dev/test, but high consistent volume can see latency variability. Provisioned (PTU) reserves a fixed block of processing capacity billed at an hourly rate per PTU regardless of use — ideal for predictable production traffic and latency-sensitive workloads, giving lower and more consistent latency. Global Batch processes asynchronous request groups with separate quota and a ~24-hour turnaround at roughly half the cost of Global Standard — ideal for large offline jobs where latency doesn't matter.
The routing axis (applies to both capacity types): Global may process in any Azure region (highest availability, lowest minimum PTU, lowest rates). Data Zone keeps processing within a Microsoft-specified zone (US or EU) for residency with a rate premium. Regional confines processing to the single deployment region (strictest residency, typically highest minimum PTU).
⚠️ Exam Trap: "High volume" alone does not mean "use provisioned." Provisioned wins for predictable high volume; bursty high volume often stays cheaper on standard because you don't pay for reserved capacity during the troughs. The qualifier — predictable vs. spiky — decides the answer, not the raw volume.
Reflection Question: A regulated EU healthcare app has steady, predictable production traffic and must keep processing within the EU. Which capacity type and which routing scope, and which single requirement word forces each choice?
