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

Microsoft Foundry supports four distinct patterns for connecting a Foundry project in one Azure region to model deployments in another, according to a guide by Microsoft Azure & AI MVP Dave R published on Towards AI. The patterns differ in who owns identity, routing, and the network path: a direct Foundry-to-Foundry connection, Azure API Management (APIM) as a model gateway with one parameterized route per deployment type, APIM on the agent ingress, and a Responses API routing pattern that relies on Foundry's dynamic model connections because the model name sits in the request body. The guide notes that routing calls through a gateway breaks first-party grounding such as SharePoint grounding with a bad_request error, while state-bearing agents and most routing continue to work.

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