Microsoft Foundry : quatre accès inter‑régions

Les équipes Foundry peuvent cibler des modèles situés dans d’autres régions Azure. Quatre méthodes sont prises en charge, avec des effets différents sur l’identité, le routage et le chemin des données. Certaines fonctions de première partie ne survivent pas à tous les montages, tandis qu’une option via API Management s’opère en réseau entièrement privé.

Passerelle : ce qui reste opérationnel et ce qui coince

Lorsque les appels transitent par une passerelle, les agents porteurs d’état continuent de fonctionner et la plupart des mécanismes de routage restent valides. En revanche, la mise en relation de première partie associée à des appels routés par une passerelle ne fonctionne pas ou doit être déplacée. Une des configurations peut également provoquer l’échec d’outils de première partie comme SharePoint avec une erreur bad_request. Des recommandations sont fournies pour construire un réseau privé de bout en bout, et un flux de décision ainsi qu’un ordre de construction sont proposés pour guider le choix de la solution.

API Management : gouvernance centrale et exécution en privé

L’utilisation d’Azure API Management comme passerelle de modèle, avec un itinéraire adapté au type de déploiement, permet à une équipe de plateforme d’imposer centralement l’identité gérée, le routage et l’étiquetage des réponses. Ce dispositif donne accès à des budgets de jetons, des métriques, un cache et des contrôles de résilience. Il peut fonctionner de manière entièrement privée grâce à des points de terminaison privés et un DNS privé, et son usage en environnement isolé est documenté.

Quatre options, des arbitrages sur identité, routage et données

Les quatre alternatives d’accès se distinguent par la façon dont elles traitent l’identité, le type de routage utilisé et le trajet emprunté par le réseau. La liaison directe entre Foundry et Foundry permet une gouvernance figée des modèles, mais ne donne pas la possibilité d’appliquer des règles spécifiques à chaque appel, comme les plafonds de jetons, le suivi des métriques, la gestion du cache ou la résilience aux pannes. L’ajout d’API Management en amont de l’agent permet d’assurer la gouvernance et l’observabilité, mais ne rend pas possible la substitution de l’identité de l’appelant au niveau de l’agent ; dans cette configuration, les fonctions de première partie au nom de reposent sur la vérification du jeton par Foundry. Adapter le routage pour l’API Responses, où le nom du modèle figure dans le corps de la requête, s’appuie sur les connexions dynamiques de modèles de Foundry plutôt que sur un itinéraire unique de passerelle, ce qui réduit la visibilité centralisée du routage au profit d’un dispatch plus direct.

Pourquoi ces montages : une disponibilité strictement régionale

La disponibilité des modèles et fonctionnalités dans Microsoft Foundry est limitée à chaque région Azure, ce qui peut conduire à devoir accéder à une ressource située hors de la région approuvée pour un projet. Quatre méthodes sont donc prévues pour permettre l’accès à des déploiements dans une autre région. Ces options ont été comparées et leurs effets sur les fonctionnalités recensés afin d’orienter le choix de connexion inter-régions.