Microsoft Foundry : 4 accès aux modèles hors région

Les modèles Foundry sont régionaux. Pour accéder à un déploiement situé ailleurs, quatre approches sont prises en charge, avec des compromis explicites sur l'identité, le routage et le réseau. Certaines configurations bloquent les outils de première partie en mode on-behalf-of, tandis qu'une passerelle via Azure API Management peut rester entièrement privée. Un flux de décision oriente le choix selon la propriété et la connectivité.

Passerelle APIM : compatibilités, blocages et réseau privé

Une des méthodes d'accès inter-régions provoque l'échec d'outils de première partie comme SharePoint, avec une erreur bad_request. Plus largement, si certaines fonctionnalités traversent un saut de passerelle via Azure API Management, les outils de première partie en mode on-behalf-of ne fonctionnent pas dans ce contexte. À l'inverse, la mise en place d'API Management comme passerelle peut opérer sur un réseau entièrement privé. Cette configuration s'appuie sur des sous-réseaux, des points de terminaison privés et des DNS privés pour rester confinée au périmètre réseau interne.

Choix guidé par contrôle, identité et chemin des données

L'accès à des modèles dans une autre région repose d'abord sur une décision de propriété au croisement du contrôle, de l'identité et du chemin des données. Dans ces architectures, le filtrage de contenu et la surveillance peuvent être maintenus de manière cohérente. Lorsque l'API Management est placée devant la surface de l'agent, la gouvernance d'entrée est renforcée, mais Foundry doit valider le jeton de l'appelant pour les scénarios et outils on-behalf-of, ce qui introduit des contraintes strictes.

Quatre modèles d'accès inter-régions pris en charge

Quatre modèles relient un projet Foundry d'une région Azure à des déploiements de modèles dans une autre région. La liaison directe entre deux instances Foundry constitue l'approche la plus élémentaire, mais elle ne permet pas de contrôle d'accès à chaque requête. Autre possibilité, Azure API Management peut agir comme une passerelle via un itinéraire unique paramétrable, intégrant des quotas et des statistiques de jetons, des fonctions de cache, de répartition de charge et de tolérance aux défaillances. Lorsque API Management est positionné avant la couche de l'agent, il renforce la gouvernance des accès entrants, tout en restant assujetti aux vérifications de jetons on-behalf-of réalisées par Foundry. Enfin, des connexions dynamiques pour l'API des réponses mettent le nom du modèle dans le corps JSON et confient les décisions de routage au projet.

Un cadre de décision pour des modèles régionaux

Un flux de décision et un ordre de construction sont proposés, avec l'idée qu'une fois la stratégie de propriété et de mise en réseau arrêtée, le modèle adapté s'impose largement. Quatre méthodes d'accès inter-régions sont ainsi disponibles. Elles répondent à la contrainte initiale d'une disponibilité des modèles limitée par région, tout en couvrant le cas où un projet approuvé pour une région a besoin d'un modèle ou d'une fonctionnalité du Foundry Agent Service hébergé dans une autre.