Model Deployment and Data Residency
The Azure model deployment type determines where inference may be processed and also affects capacity, latency, availability, and cost. The location of the Azure resource alone does not answer the inference-processing question.
Processing Boundaries
| Deployment family | Inference processing | Typical consideration |
|---|---|---|
| Global | May use Azure's global infrastructure | Broad model availability and quota; not suitable when processing must stay in one zone or region |
| Data Zone | Stays within the Microsoft-defined data zone, such as the EU | Zone boundary with broader routing than a single region |
| Regional or geography-based | Uses the selected regional/geographic boundary where supported | Stricter location requirement; availability and quota may be narrower |
| Provisioned variants | Reserved capacity within the selected processing scope | Predictable throughput and lower latency variance |
Not every model supports every deployment type or region. Verify availability during design and again before production rollout.
Review Checklist
- Record the exact deployment type, not only the resource region.
- Separate data stored at rest from prompts and responses processed for inference.
- Review stateful features, batch processing, fine-tuning, stored completions, and preview features separately.
- Confirm the model router's complete allowed model subset.
- Document provider abuse-monitoring and content-safety behavior that applies to the subscription.
- Recheck the design when changing model, deployment type, region, or provider feature.
For EU requirements, use an EU Data Zone or regional deployment only where the required model supports it, and validate the current Microsoft documentation and customer policy. Global deployments may process prompts and responses outside the EU even when the Azure resource itself is located in Europe.
Official references: