Four Ways to Reach a Model in Another Azure Region From Microsoft Foundry

Author(s): Dave R | Microsoft Azure & AI MVP ☁️ Originally published on Towards AI. How each pattern handles identity, routing, and private networking, and which Foundry features stop working when a gateway sits in the path. Microsoft Foundry model availability is regional, so the model or Foundry Agent Service feature you need can live outside the region your project was approved for. Foundry supports four ways to reach it, and they differ in who owns identity, routing, and the network path. One of them also makes first-party tools such as SharePoint grounding fail with bad_request. This guide compares all four patterns, shows the API Management option running on a fully private network, lists which features survive the hop, and ends with a decision flow you can apply to your own landing zone. Four patterns connecting a Foundry project in one Azure region to model deployments in another region.The article explains why cross-region model access is an ownership decision across three boundaries—control plane, identity, and the data path—and then details four supported patterns. Pattern 1 is a direct Foundry-to-Foundry connection that provides static model governance but cannot enforce per-call policies like token limits, metrics, caching, or failover. Pattern 2 uses Azure API Management (APIM) as a model gateway, with one parameterized route per deployment type so a platform team can centrally apply managed identity, routing, and response labeling while gaining token budgets, metrics, caching, and resilience controls; it also shows how to run this fully privately using private endpoints and private DNS. Pattern 3 places APIM on the agent ingress for governance and observability, but it cannot replace the caller’s identity on the agent surface, so key first-party on-behalf-of capabilities depend on Foundry validating the caller token. Pattern 4 adapts routing for the Responses API, where the model name is in the request body; it relies on Foundry’s dynamic model connections rather than a single APIM route, trading centralized routing visibility for cleaner dispatch. Finally, it summarizes what still works when traffic goes through a gateway (e.g., state-bearing agents and most routing) and what breaks or must be moved (notably first-party grounding with gateway-routed calls), provides guidance for private networking end-to-end, and closes with a decision flow and recommended build order. Read the full blog for free on Medium. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI