Déployer des agents IA sur AWS sans créer de gâchis de sécurité

La plupart des agents utiles ont besoin d’accéder à des données privées.

Ils doivent interroger des bases de données internes, appeler des systèmes internes ou lire des données qui n'ont jamais été destinées à être publiques. Ces exigences soulèvent immédiatement des questions sur l’exposition du réseau, la gestion des informations d’identification et la conformité.

Comment l'agent se connecte-t-il à une base de données privée ? Où va-t-il ? Comment gérer plusieurs utilisateurs sans partager l’état d’exécution ? Comment accorder l’accès à des systèmes privés sans informations d’identification codées en dur ni élargir l’accès au réseau ?

Cet article présente un exemple de la façon dont j'ai répondu à ces questions pour un agent que j'ai déployé sur AWS.

Vous pouvez trouver la vidéo complète dans laquelle je construis cette solution de bout en bout ici.

L'exemple courant

J'ai construit un agent d'assistance logistique simple à l'aide du SDK Strands Agents et d'un modèle OpenAI. Il répond aux questions sur les expéditions en interrogeant une base de données PostgreSQL en direct exécutée sur Amazon Relational Database Service (RDS) dans un Amazon Virtual Private Cloud (VPC) sur AWS.

La partie la plus facile consistait à construire la logique de l'agent. Je l'ai fait fonctionner localement en utilisant des outils simulés pour les premiers tests.

La partie la plus difficile a été de déployer l'agent de manière à :

• n'expose pas la base de données publiquement
• n'intègre pas les informations d'identification dans le code
• ne perce pas de trous inutiles dans le réseau
• isole correctement les sessions utilisateur

AWS fournit les éléments de base pour résoudre ces problèmes, mais vous devez toujours faire des choix délibérés sur la manière dont ils s'articulent.

Cet article utilise l'agent logistique comme exemple concret. Chaque extrait provient soit du code de l'agent, soit des fichiers d'infrastructure qui le déploient.

Introduction à Amazon Bedrock AgentCore

Dans cet exemple, AgentCore Runtime est l'environnement d'hébergement de l'agent logistique.

AgentCore Runtime est un environnement d'exécution géré, sans serveur et hébergé qui exécute des agents dans des sessions isolées, gère l'authentification, la mise à l'échelle et la gestion du cycle de vie sans que vous ayez à réécrire complètement votre agent pour l'intégration. Il est indépendant du framework et du modèle et prend en charge plusieurs protocoles, notamment : HTTP, MCP et A2A.

Vous pouvez en savoir plus sur Amazon Bedrock AgentCore Runtime ici.

L'architecture en un coup d'œil

Le diagramme ci-dessus montre l'architecture du backend de l'agent logistique, y compris la manière dont il se connecte à la base de données privée et au fournisseur de modèles externe, OpenAI.

• L'agent s'exécute sur Amazon Bedrock AgentCore Runtime.
• AgentCore Runtime déploie des interfaces réseau élastiques (ENI) dans des sous-réseaux privés à l'intérieur d'un VPC pour permettre la connectivité avec des ressources privées.
• La base de données s'exécute sur une instance RDS privée dans le même VPC.
• L'agent lit les informations de connexion à la base de données à partir d'AWS Systems Manager Parameter Store.
• L'agent lit les secrets d'AWS Secrets Manager (informations d'identification de la base de données et clé OpenAI du fournisseur de modèles).
• Les points de terminaison d'un VPC conservent les appels vers les services AWS sur le réseau AWS, y compris les appels vers AgentCore, AWS Systems Manager et AWS Secrets Manager.
• Une passerelle NAT fournit un accès Internet sortant afin que l'agent puisse appeler OpenAI à des fins d'inférence.
• Contrôles IAM :
  • qui peut invoquer l'agent
  • quelles API AWS l'agent peut appeler une fois invoqué

Si vous souhaitez voir le code complet ou la pile AWS Cloud Development Kit (CDK), le guide étape par étape est disponible sur GitHub ici.

Une carte rapide des problèmes de sécurité et des fonctionnalités AWS prises en charge