Microsoft Foundry: 4 Access to Out-of-Region Models

Key Takeaways

1Four methods allow access to Foundry models located in other Azure regions

2Options vary based on identity management, routing, and networking

3Some configurations via API Management block first-party tools in on-behalf-of mode

4A decision flow guides the choice based on ownership and connectivity

Why it matters : Foundry projects can thus choose the architecture that fits their governance and networking constraints.

Foundry models are regional. To access a deployment located elsewhere, four approaches are supported, with explicit trade-offs regarding identity, routing, and networking. Some configurations block first-party tools in on-behalf-of mode, while a gateway via Azure API Management can remain entirely private. A decision flow guides the choice based on ownership and connectivity.

APIM Gateway: compatibilities, blocks, and private network

One of the inter-region access methods causes first-party tools like SharePoint to fail, resulting in a bad_request error. More broadly, while some features can traverse a gateway hop via Azure API Management, first-party tools in on-behalf-of mode do not function in this context. Conversely, setting up API Management as a gateway can operate over a fully private network. This configuration relies on subnets, private endpoints, and private DNS to remain confined within the internal network perimeter.

Choice guided by control, identity, and data path

Accessing models in another region primarily hinges on a decision of ownership at the intersection of control, identity, and data path. In these architectures, content filtering and monitoring can be consistently maintained. When API Management is placed in front of the agent surface, entry governance is strengthened, but Foundry must validate the caller's token for on-behalf-of scenarios and tools, introducing strict constraints.

Le brief IA que lisent les pros

Le brief IA que les pros lisent chaque soir

Les 7 actus IA du jour, décryptées en 5 min. Gratuit.

Inclus dès l'inscription : notre sélection des meilleurs guides & comparatifs IA.

Choisissez votre rythme

Gratuit · Pas de spam · Désabonnement en 1 clic

Four supported inter-region access models

Four models connect a Foundry project from one Azure region to model deployments in another region. The direct linking of two Foundry instances constitutes the most basic approach, but it does not allow for access control on each request. Another possibility is that Azure API Management can act as a gateway via a single configurable route, integrating quotas and token statistics, caching functions, load balancing, and fault tolerance. When API Management is positioned before the agent layer, it enhances governance of incoming access while still being subject to on-behalf-of token checks performed by Foundry. Finally, dynamic connections for the response API place the model name in the JSON body and delegate routing decisions to the project.

A decision framework for regional models

A decision flow and construction order are proposed, with the idea that once the strategy for ownership and networking is established, the appropriate model largely presents itself. Thus, four inter-region access methods are available. They address the initial constraint of model availability being limited by region while covering the case where an approved project for one region needs a model or functionality from the Foundry Agent Service hosted in another.