The part nobody reads until they get the bill
So Microsoft Foundry gives you like nine deployment types now. Nine. And the docs make it sound like a nice clean decision — pick your data residency, pick your billing, done. But honestly? It is not that simple when you are actually running production workloads and someone from finance pings you asking why the API bill tripled.
Let me break this down the way I wish someone had explained it to me before we went live with a client project last year.
The two big categories are Standard (pay-per-token) and Provisioned (reserved capacity with PTUs — provisioned throughput units). Within each, you pick where your data gets processed: Global means any Azure region anywhere, DataZone means US or EU only, and Regional means one specific region. Then there is Batch which is its own thing — 50% cheaper but your results come back within 24 hours, maybe longer. No real-time SLA on batch at all.
Global Standard is where most people start. Highest default quota, no need to load balance across resources yourself, Azure handles the routing. Pay per token, simple. The problem — and I am speaking from experience — is that when you hit consistent high volume, latency starts jumping around. Not a little. Enough that your users notice. We had a chatbot deployment at OZ where response times were fine during testing but once we crossed a certain threshold in production, the variance made the UX feel broken. Users thought the system was crashing.
Provisioned fixes that. You buy PTUs upfront, you get guaranteed capacity, latency stays consistent. But here is the thing — you are paying whether you use it or not. It is like renting a dedicated server versus using serverless functions. If your traffic is bursty, you will waste money. If your traffic is consistent and high, provisioned saves you headaches and probably money too.
Where this actually breaks down
The decision tree Microsoft gives you is based on three things: data residency, workload pattern, and latency needs. Fine. But there is a fourth thing nobody talks about — model availability. Not all models support all deployment types. I have seen teams plan entire architectures around Global Provisioned only to find out the specific model version they need is not available in that SKU yet. Always check model availability first. I mean it. Before you design anything.
DataZone is interesting if you have EU compliance requirements. Your data stays within EU member nations for processing, which matters for GDPR stuff. But the quota is lower than Global. So if you are processing large volumes for European customers, you might hit limits faster than you expected. Same applies to the US data zone but honestly most US-based teams just use Global and don't think about it.
The batch option — Global Batch or DataZone Batch — is genuinely good for what it does. 50% cost savings is real. We used it for a document summarization pipeline, thousands of contracts, and it worked great. You submit a file with all your requests, come back later, get your results. The 24-hour turnaround is a target not a guarantee though. I have seen jobs take longer. If your workflow can handle async processing, batch should be your default for any bulk operation. The savings add up fast.
The cost nobody warns you about
Standard pricing looks clean on paper. Pay per token, done. But then you start factoring in retries from latency spikes, the fact that Global routing means your costs vary slightly by region, and the quota limits that force you to spread across multiple deployments — suddenly your architecture is more complex than it needed to be. With Provisioned, at least the cost is predictable. You know exactly what you are paying.
One thing I learned — if you are doing fine-tuning evaluation, there is a Developer tier that auto-deletes after 24 hours. No SLA, no data residency guarantees, but it is cheap for testing. Don't deploy production on it. I say this because I know someone will try.
My actual recommendation? Start with Global Standard. Monitor your latency variance and token consumption for two weeks. If you see consistent high usage with latency problems, move to Provisioned. If you have compliance requirements, DataZone. If you have bulk processing, Batch. Don't over-architect this from day one. The migration between deployment types is not that painful and you will make a much better decision with real data than with estimates.
