Deployment Types: Where Your Data Is Processed and How You Pay

What this slice covers

Once a model is going to be served through a serverless API deployment, one more decision remains: the deployment type. This is the setting that decides where inference data is processed, what billing model applies, and what performance characteristics you can expect. It applies only to the serverless API option — open-source and custom models on managed compute do not use these types at all.

Learners often meet the full list of nine names and try to memorise it flat. That is the wrong shape. The list is really two independent axes crossed with each other, plus one special case.

Axis one: where data is processed

Three choices, in decreasing breadth:

• Global. Traffic is dynamically routed to available datacentres, so inference data may be processed in any Azure region. Broadest model availability, highest initial throughput limits, and new models and features arrive here first.
• Data zone. Processing stays inside a Microsoft-defined boundary — the United States, the European Union, or Asia Pacific. The EU zone follows the Azure EU Data Boundary, which can include EFTA countries such as Norway and Switzerland alongside member states.
• Single region. Processing happens in the deployment's own region.

The vital qualifier: this axis governs inferencing data. Data stored at rest remains in the designated Azure geography regardless of which type you pick. Conflating the two is the classic data-residency error.

Axis two: how you pay

• Standard — pay-per-token. Best-effort service, suited to variable and bursty traffic. Customers with high consistent volume may see greater latency variability.
• Provisioned — reserved capacity, purchased as provisioned throughput units. Each model-version pair needs a different number of PTUs and yields different throughput per PTU. Provisioned types give guaranteed throughput and lower latency variance.
• Batch — asynchronous processing at 50 percent less cost than Global Standard, with a 24-hour target turnaround and its own separate enqueued-token quota so it does not disturb your online workloads. You submit many requests in one file rather than one at a time.

Cross the two axes and the names become predictable rather than memorised: Global Standard, Global Provisioned, Global Batch, Data Zone Standard, Data Zone Provisioned, Data Zone Batch, Standard, Regional Provisioned.

The special case

Developer is the ninth type, and it does not belong to either axis. It exists solely for evaluating fine-tuned models. It is cheap, it has a fixed 24-hour lifetime after which the deployment is deleted automatically, and it offers neither an SLA nor data-residency guarantees. Nothing that matters should run on it.

The default, and the launch order

For most workloads the recommendation is unambiguous: start with Global Standard. It launches first when a new model releases, carries the lowest price, gives the broadest region coverage, and provides the highest default quota. Move away from it only for a specific reason — data residency, reserved throughput, or asynchronous batch work.

There is a structural reason the default is so strong. New deployment types become available in a set order: global first, then data zone, then single region. Single-region deployment types arrive last, have no guaranteed availability date, and depend on capacity freed up as older models retire. So a strict single-region requirement narrows not just which regions you can use but which models are available to you and when.

Not every model supports every type, and specialised modalities such as audio, image, and video generation are often offered only as data zone or global deployments.

Governance

Deployment types are enforceable. Azure Policy can block a specific type by its SKU name, which is how an organisation stops teams from creating, say, global deployments when residency rules forbid them. Learning the SKU code alongside the display name — for instance, that Regional Provisioned appears in code as ProvisionedManaged — is worth the few minutes it takes.

Mistakes to avoid

• Believing global processing moves your stored data outside its geography. It does not; the distinction is inferencing versus rest.
• Choosing single-region by default out of caution. It is the most constrained option on availability, quota, and model coverage.
• Buying provisioned capacity for bursty low-volume traffic. Reserved throughput suits consistent high volume; pay-per-token suits burstiness.
• Expecting batch to behave like a discount on real-time calls. It trades responsiveness for price and has no real-time SLA.
• Running anything durable on Developer, which deletes itself after a day.

What to carry forward

Two axes and one exception. Decide residency first, then billing shape, and let Global Standard be the answer unless a stated requirement overrides it.