---
title: "Building an Azure AI Landing Zone Without Slowing Teams Down"
url: https://daily.dev/posts/building-an-azure-ai-landing-zone-without-slowing-teams-down-a4ovu2p5y
source_url: https://thomasthornton.cloud/building-an-azure-ai-landing-zone-without-slowing-teams-down
type: article
source: "Thomas Thornton"
published: 2026-08-12T14:27:22.916Z
updated: 2026-08-12T14:28:06.076Z
tags: ["cloud", "azure", "platform-engineering", "finops", "azure-openai"]
reading_time: 15
upvotes: 2
comments: 1
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Building an Azure AI Landing Zone Without Slowing Teams Down

**[Thomas Thornton](https://daily.dev/sources/thomasthornton)** · 15 min read · 2 upvotes · 1 comments

## Summary

An Azure AI Landing Zone should give teams a pre-approved, fast path for building AI workloads while keeping centralized controls where they genuinely matter. The architecture separates concerns across three layers: Azure Policy governs resources (regions, tagging, model deployment approval), Azure API Management governs runtime consumption (token limits, quotas, routing, telemetry via policies like llm-token-limit and llm-emit-token-metric), and workload teams own application logic, prompts, and evaluations. Guidance covers cost control through environment-specific defaults, model selection profiles, quota ownership, telemetry collection without wholesale prompt logging, and a phased rollout starting with one complete governed path before adding caching or failover.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://thomasthornton.cloud/building-an-azure-ai-landing-zone-without-slowing-teams-down>

## Questions this post answers

### What is the difference between Azure Policy and Azure API Management for governing AI workloads?

Azure Policy governs Azure resources themselves, such as approved regions, allowed model deployments, required tags, and public network access, and enforces this before or at deployment time. Azure API Management governs runtime consumption once traffic is flowing, controlling things like token allowances, rate limits, backend routing, and per-consumer quotas. Azure Policy cannot stop an application from flooding a model endpoint with requests; only APIM policies can.

_Architects weighing Azure Policy against APIM for AI governance can track this kind of platform guidance on daily.dev._

### How can I enforce token rate limits for an Azure OpenAI API exposed through Azure API Management?

Use the llm-token-limit policy in Azure API Management, which enforces token rate limits or quotas by a calculated key such as consumer identity. Pair it with llm-emit-token-metric to send token consumption metrics and custom dimensions to Application Insights, and llm-content-safety to check prompts and responses through Azure AI Content Safety. Policy availability varies by APIM tier, so check the support matrix before choosing a tier.

_Teams building an AI gateway on APIM can follow platform architecture patterns like this via daily.dev._

### Should every team share one Azure OpenAI or Microsoft Foundry resource, or should each team have its own?

There is no blanket rule; shared resources work well when teams have similar data boundaries, regional requirements, capacity needs, and operational expectations. Workload-owned resources become preferable once teams need independent scaling, separate deployment lifecycles, or stronger isolation. A landing zone should define governance for both patterns rather than forcing every team through one central AI resource.

_Platform teams deciding between shared versus dedicated AI resources can weigh trade-offs like these on daily.dev._

## Community discussion

Top comments from developers on daily.dev.

**@agustinbarrientos** · 0 upvotes

> I'd version each APIM policy profile with the infrastructure module and emit that version in every token metric. It'll expose drift without turning the platform team into another approval queue.

## Similar posts on daily.dev

- [AI Engineering Needs Platform Controls](https://daily.dev/posts/ai-engineering-needs-platform-controls-fbx2tn6vi) · Thomas Thornton · 3 upvotes · 0 comments
- [Enterprise AI Architecture From Pilot to Production](https://daily.dev/posts/enterprise-ai-architecture-from-pilot-to-production-bzcljsbkm) · portkey · 0 upvotes · 0 comments
- [Azure API Management Adds Dedicated AI Gateway Tier, Governing Models and MCP Tools](https://daily.dev/posts/azure-api-management-adds-dedicated-ai-gateway-tier-governing-models-and-mcp-tools-cx4kwhecw) · InfoQ · 1 upvotes · 0 comments
- [Azure Bicep at Scale: Architecture, Repos, and Landing Zones Done Right](https://daily.dev/posts/azure-bicep-at-scale-architecture-repos-and-landing-zones-done-right-1v8usm2i9) · Build5Nines · 0 upvotes · 0 comments

---

Tags: [#cloud](https://daily.dev/tags/cloud), [#azure](https://daily.dev/tags/azure), [#platform-engineering](https://daily.dev/tags/platform-engineering), [#finops](https://daily.dev/tags/finops), [#azure-openai](https://daily.dev/tags/azure-openai)

[View this post on daily.dev](https://daily.dev/posts/building-an-azure-ai-landing-zone-without-slowing-teams-down-a4ovu2p5y)
