Microsoft Foundry: Four Inter-Regional Access Points

Key Takeaways

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

2The API Management option provides centralized governance, token budgets, metrics, caching, and resilience, and operates privately

3Some first-party capabilities are not compatible with all setups, and a configuration may generate a bad_request error with SharePoint

Why it matters : Teams need to choose the appropriate method to ensure cross-region access without losing essential features.

Foundry teams can target models located in other Azure regions. Four methods are supported, each with different effects on identity, routing, and data paths. Some first-party functions do not survive all configurations, while an option via API Management operates over a fully private network.

Gateway: What Remains Operational and What Gets Stuck

When calls pass through a gateway, stateful agents continue to function, and most routing mechanisms remain valid. However, first-party binding associated with calls routed through a gateway does not work or must be moved. One of the configurations may also cause first-party tools like SharePoint to fail with a bad_request error. Recommendations are provided for building an end-to-end private network, along with a decision flow and a construction order to guide the choice of solution.

API Management: Central Governance and Private Execution

Using Azure API Management as a model gateway, with a route tailored to the type of deployment, allows a platform team to centrally enforce managed identity, routing, and response labeling. This setup provides access to token budgets, metrics, caching, and resilience controls. It can operate entirely privately through private endpoints and private DNS, and its use in isolated environments is documented.

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 Options, Trade-offs on Identity, Routing, and Data

The four access alternatives differ in how they handle identity, the type of routing used, and the path taken by the network. Direct binding between Foundry and Foundry allows for fixed governance of models but does not provide the ability to apply specific rules for each call, such as token limits, metric tracking, cache management, or failure resilience. Adding API Management upstream of the agent ensures governance and observability but does not allow for the substitution of the caller's identity at the agent level; in this configuration, first-party functions on behalf of rely on token verification by Foundry. Adapting routing for API Responses, where the model name appears in the request body, relies on dynamic connections of Foundry models rather than a single gateway route, which reduces centralized visibility of routing in favor of more direct dispatch.

Why These Configurations: Strictly Regional Availability

The availability of models and features in Microsoft Foundry is limited to each Azure region, which may lead to the need to access a resource located outside the approved region for a project. Therefore, four methods are planned to allow access to deployments in another region. These options have been compared, and their effects on the identified functionalities have been documented to guide the choice of inter-region connection.