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

AWS a montré comment configurer Amazon Bedrock AgentCore Gateway pour que des agents IA accèdent en toute sécurité à des ressources privées au sein d'un VPC. Le schéma repose sur Resource Gateway, qui crée des Elastic Network Interfaces dans les sous-réseaux et ouvre un chemin contrôlé vers des API fermées, des services et des endpoints internes.

Comment ça fonctionne

L'idée centrale : l'agent n'a pas besoin de passer par l'internet public pour appeler un service interne. Resource Gateway déploie une ENI dans chaque sous-réseau Amazon VPC sélectionné et s'en sert comme point d'entrée vers l'infrastructure privée. Les requêtes d'AgentCore Gateway transitent ainsi par le réseau interne d'AWS, et l'équipe conserve les mécanismes de contrôle habituels : security groups, routage par tables de routage et segmentation par sous-réseaux. Pour les entreprises qui ne veulent pas exposer leurs API internes, c'est le scénario le plus pratique.

Cette approche compte surtout pour les agents IA qui doivent travailler non seulement avec des modèles publics, mais aussi avec les outils fermés de l'entreprise : CRM internes, services de gestion documentaire, endpoints d'inférence privés ou API accessibles uniquement depuis le VPC. Plutôt que de bricoler des contournements avec des proxys et des passerelles publiques, AWS propose un canal d'accès natif au sein de son réseau. Cela simplifie l'architecture et regroupe au même endroit les exigences de sécurité, d'audit et d'isolation réseau.

Deux modes de fonctionnement

AWS propose deux options de déploiement : managed et self-managed. En mode managed, le service crée et maintient l'essentiel de la plomberie réseau ; l'équipe obtient donc plus vite une connexion opérationnelle et passe moins de temps sur l'infrastructure de routine. Le mode self-managed s'adresse à ceux qui veulent un contrôle total sur le schéma de déploiement, les paramètres réseau et l'intégration avec les règles existantes de l'entreprise. Le choix ne dépend pas des fonctionnalités de l'agent, mais du degré de maîtrise que l'entreprise veut avoir sur la couche réseau.

• Managed convient à un démarrage rapide et aux scénarios courants.
• Self-managed 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 à conserver une route privée pour le trafic.
• Les politiques d'accès peuvent être combinées avec les security groups et routes existants.

Le sens pratique de cette séparation est simple : Bedrock AgentCore Gateway n'impose pas une seule méthode de connexion rigide. Si la rapidité du pilote compte, l'équipe peut s'appuyer sur le modèle managé. Si la priorité est une topologie sur mesure, des exigences d'entreprise ou des règles d'accès particulières entre segments réseau, elle peut monter le schéma elle-même. Pour les équipes enterprise, c'est un signal important : le service n'est pas conçu que pour des démos, mais aussi pour de vrais environnements de production soumis à des contraintes internes.

Trois scénarios pratiques

AWS présente trois scénarios qui montrent bien à quoi sert Resource Gateway. Le premier : la connexion à un endpoint privé d'Amazon API Gateway, lorsque l'agent doit appeler une API inaccessible depuis l'extérieur. Le deuxième : le travail avec un serveur MCP sur Amazon EKS, c'est-à-dire un serveur d'outils déployé dans un cluster Kubernetes au sein du réseau cloud. Le troisième : l'accès à une API REST privée, qui peut servir des applications internes, des bases de connaissances ou de la logique métier.

• Appel d'un Amazon API Gateway privé sans publier l'endpoint à l'extérieur.
• Intégration avec un serveur MCP sur Amazon EKS pour des outils d'agents.
• Connexion à une API REST interne qui n'existe qu'à l'intérieur du VPC.

Ces exemples couvrent un éventail assez large de besoins. Dans un cas, l'agent accède à des passerelles d'API existantes ; dans un autre, à une infrastructure Kubernetes avec ses propres outils ; dans le troisième, à n'importe quel service web interne doté d'une interface REST. En somme, AWS fournit un modèle : si vous avez un service dans un réseau privé, vous pouvez le rendre accessible à AgentCore Gateway avec soin, sans l'exposer sur internet. Cela réduit le compromis entre sécurité et utilité des agents.

Ce que cela signifie

AWS transforme peu à peu AgentCore Gateway en pont entre les agents LLM et l'infrastructure d'entreprise fermée. Pour les sociétés, cela lève l'un des principaux freins à l'adoption : les agents peuvent être connectés à des API internes, des services Kubernetes et des outils maison sans exposition superflue vers l'extérieur, ce qui permet de faire passer plus vite les pilotes en production.