AWS a montré comment Amazon Bedrock AgentCore Gateway se connecte à des API et services privés

AWS a montré comment configurer Amazon Bedrock AgentCore Gateway pour un accès sécurisé des agents IA aux ressources privées au sein d'un VPC. À la base de l'architecture se trouve Resource Gateway, qui crée des Elastic Network Interfaces dans les sous-réseaux et fournit un chemin contrôlé vers les API privées, les services et les endpoints internes.

Comment cela fonctionne

L'idée principale est que les agents n'ont pas besoin de sortir sur Internet public pour accéder à un service interne. Resource Gateway déploie une ENI dans chaque sous-réseau Amazon VPC sélectionné et les utilise comme point d'entrée vers l'infrastructure privée. De ce fait, les demandes d'AgentCore Gateway transitent par le réseau interne d'AWS, et les équipes obtiennent des mécanismes de contrôle familiers : groupes de sécurité, gestion des tables de routage et segmentation des sous-réseaux.

Pour les entreprises qui ne souhaitent pas exposer publiquement les API internes, c'est le scénario le plus pratique. Cette approche est particulièrement importante pour les agents IA qui doivent fonctionner non seulement avec des modèles publics, mais aussi avec des outils commerciaux propriétaires. Cela peut signifier des CRM internes, des services de gestion de documents, des endpoints d'inférence privés ou des API accessibles uniquement depuis le VPC. Au lieu de construire des schémas alternatifs avec des proxies et des passerelles publiques, AWS offre un canal d'accès natif au sein de son propre réseau. Cela simplifie l'architecture et aide à garder les exigences de sécurité, d'audit et d'isolation réseau au même endroit.

Deux modes de déploiement

AWS propose deux options de mise en œuvre : gérée et auto-gérée. En mode géré, la majorité de l'infrastructure réseau est créée et maintenue par le service, de sorte que les équipes atteignent une connexion fonctionnelle plus rapidement et consacrent moins de temps à l'infrastructure routinière. Le mode auto-géré est destiné à ceux qui ont besoin d'un contrôle total sur le schéma de déploiement, les paramètres réseau et l'intégration avec les politiques existantes de l'entreprise.

Le choix entre eux ne dépend pas de la fonctionnalité de l'agent, mais de la mesure dans laquelle l'entreprise souhaite gérer la couche réseau de manière indépendante.

• La gestion est appropriée pour les démarrages rapides et les scénarios typiques.
• L'auto-gestion offre plus de contrôle sur le réseau et le modèle opérationnel.
• Les ENI sont créées dans les sous-réseaux du VPC, ce qui aide à maintenir le routage du trafic privé.
• Les politiques d'accès peuvent être combinées avec les groupes de sécurité et les routes existants.

Le sens pratique de cette distinction est simple : Bedrock AgentCore Gateway n'impose pas une seule méthode de connexion rigide. Si l'équipe valorise la rapidité de la preuve de concept, elle peut s'appuyer sur le modèle géré. Si la priorité est une topologie personnalisée, des exigences d'entreprise ou des règles d'accès spéciales entre les segments de réseau, vous pouvez construire le schéma vous-même. Pour les équipes d'entreprise, c'est un signal important : le service est conçu non seulement pour les démonstrations, mais pour les environnements de production réels avec des contraintes internes.

Trois scénarios pratiques

AWS présente trois scénarios qui montrent clairement pourquoi Resource Gateway est nécessaire.

Le premier consiste à se connecter à un endpoint privé dans Amazon API Gateway, lorsqu'un agent doit appeler une API non disponible en externe. Le second consiste à travailler avec un serveur MCP dans Amazon EKS, c'est-à-dire avec un serveur d'outils déployé dans un cluster Kubernetes au sein du réseau en nuage. Le troisième est l'accès à une API REST privée qui peut servir des applications internes, des bases de connaissances ou une logique commerciale.

• Appeler un Amazon API Gateway privé sans publier l'endpoint publiquement.
• Intégration avec un serveur MCP dans Amazon EKS pour les outils d'agents.
• Connexion à une API REST interne qui n'existe que dans le VPC.

Ces exemples couvrent un spectre assez large de tâches. Dans un cas, l'agent accède à des passerelles d'API déjà existantes, dans un autre à l'infrastructure Kubernetes avec ses propres outils, et dans le troisième à n'importe quel service web interne avec une interface REST. Essentiellement, AWS montre un modèle : si vous avez un service à l'intérieur d'un réseau privé, vous pouvez le rendre disponible de manière claire pour AgentCore Gateway sans l'exposer à Internet. Cela réduit le compromis entre la sécurité et l'utilité des agents.

Ce que cela signifie

AWS transforme progressivement AgentCore Gateway en un pont entre les agents LLM et l'infrastructure d'entreprise fermée. Pour les entreprises, cela supprime l'une des principales barrières à l'adoption : les agents peuvent être connectés aux API internes, aux services Kubernetes et aux outils propriétaires sans exposition externe inutile, ce qui signifie des transitions plus rapides de preuve de concept à la production.