InfrastructureAWS ML Blog1h

Configurer Amazon Bedrock AgentCore Gateway pour un accès sécurisé aux ressources privées

Résumé IASource uniqueImpact UE

Amazon a dévoilé une nouvelle fonctionnalité pour son service Bedrock AgentCore Gateway : la connectivité VPC gérée, qui permet aux agents d'intelligence artificielle d'accéder à des ressources privées hébergées derrière des réseaux Amazon Virtual Private Cloud (VPC) sans exposer le trafic sur l'internet public. Concrètement, ce mécanisme repose sur un composant appelé Resource Gateway, qui provisionne automatiquement des interfaces réseau élastiques (ENI) directement à l'intérieur du VPC cible, à raison d'une interface par sous-réseau. Deux modes de fonctionnement sont proposés : le mode managé, où AgentCore prend en charge l'intégralité de l'infrastructure réseau à partir des identifiants VPC, de sous-réseau et des groupes de sécurité fournis par l'utilisateur ; et le mode auto-géré, qui laisse davantage de contrôle à l'équipe technique. Trois scénarios pratiques illustrent ces cas d'usage : la connexion à un endpoint privé Amazon API Gateway, l'intégration avec un serveur MCP (Model Context Protocol) hébergé sur Amazon Elastic Kubernetes Service (EKS), et l'accès à une API REST privée dans un réseau isolé.

Pour les équipes qui déploient des agents IA en production, cette capacité représente un gain opérationnel significatif. Jusqu'ici, chaque chemin de connexion entre un agent et un outil interne (base de données, API métier, microservice) nécessitait une configuration réseau manuelle, ralentissant les déploiements et multipliant les risques de mauvais paramétrage. Avec AgentCore Gateway VPC egress, une Resource Configuration délimite précisément l'endpoint accessible, un nom de domaine ou une adresse IP, plutôt que d'ouvrir l'accès à l'ensemble du VPC. La Service Network Resource Association, créée et gérée automatiquement par AgentCore, connecte ensuite cette configuration au réseau de service, ce qui permet à l'agent d'invoquer l'endpoint privé de façon sécurisée et traçable. Pour les organisations avec des architectures multi-VPC ou hybrides, le service s'intègre nativement avec AWS Transit Gateway et le VPC peering inter-régions.

Cette annonce s'inscrit dans la stratégie plus large d'Amazon pour rendre ses agents IA exploitables dans des environnements d'entreprise contraints, où la sécurité réseau et la conformité interdisent tout transit par l'internet public. Bedrock AgentCore est la couche d'infrastructure d'Amazon dédiée à l'orchestration et au déploiement d'agents autonomes en production, concurrençant directement les offres de Microsoft Azure AI Foundry et Google Vertex AI Agent Builder. La prise en charge du protocole MCP, standard ouvert porté par Anthropic pour connecter les agents à des outils externes, signale une convergence de l'écosystème autour d'interfaces interopérables. À mesure que les agents IA migrent du prototype vers le système critique, la capacité à les brancher sur des ressources internes sans compromettre le périmètre de sécurité devient un prérequis incontournable pour les DSI, ce qu'Amazon positionne désormais comme une fonctionnalité de première classe.

Impact France/UE

Les organisations européennes soumises au RGPD déployant des agents IA peuvent exploiter cette connectivité VPC privée pour maintenir leurs données internes hors de l'internet public, facilitant ainsi la conformité réglementaire.

Dans nos dossiers

Anthropic Agents IA

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

1AWS ML Blog

Exécuter des proxies MCP personnalisés en serverless sur Amazon Bedrock AgentCore Runtime

Amazon Web Services vient de détailler une architecture permettant de déployer des proxys MCP (Model Context Protocol) personnalisés en mode serverless sur Amazon Bedrock AgentCore Runtime. Cette solution s'adresse aux équipes qui souhaitent insérer une couche de contrôle programmable entre leurs agents IA et les outils auxquels ils accèdent, bases de données, API tierces, systèmes de fichiers, sans modifier ni le client ni le serveur MCP en amont. Le proxy s'exécute comme une charge de travail sans état sur AgentCore Runtime, découvre automatiquement les outils disponibles au démarrage, les réexpose avec la logique personnalisée appliquée, puis transfère les requêtes de manière transparente. L'infrastructure est entièrement gérée par AWS, avec mise à l'échelle automatique, observabilité intégrée via Amazon CloudWatch et OpenTelemetry, et gestion des identités via AgentCore Identity. L'intérêt concret est d'ordre gouvernance et conformité. En production, les interactions entre agents IA et outils doivent respecter des politiques de sécurité internes, des réglementations sectorielles et des exigences d'auditabilité spécifiques : nettoyage des entrées avant qu'elles atteignent les systèmes backend, génération de journaux d'audit dans des formats particuliers, ou encore rédaction de données sensibles au niveau du protocole. AgentCore Gateway propose déjà des intercepteurs Lambda pour intégrer ce type de logique, mais certaines organisations disposent de bibliothèques de filtrage MCP internes ou de systèmes de conformité on-premises qu'elles ne souhaitent pas refactoriser en fonctions Lambda. Le proxy serverless sur Runtime offre alors une alternative portable, réutilisable dans des environnements hybrides ou multi-systèmes, sans dépendance à un intercepteur spécifique à une plateforme. Ce développement s'inscrit dans l'adoption rapide du Model Context Protocol comme standard de facto pour connecter les agents IA à leurs outils. MCP, initialement proposé par Anthropic fin 2024, est désormais supporté par la plupart des grandes plateformes d'agents, et AWS positionne AgentCore comme son infrastructure de référence pour les déploiements en production. La solution présentée s'appuie sur une implémentation open source disponible sur GitHub, ce qui facilite l'adoption et la personnalisation. Elle peut également se connecter à AgentCore Gateway pour bénéficier de la découverte gérée des outils, de la gestion des credentials et de l'application de politiques à l'échelle, y compris sur des fonctions Lambda et des intégrations SaaS. Pour les équipes qui industrialisent leurs agents IA, ce pattern représente une brique d'infrastructure critique pour passer du prototype au déploiement régi par des exigences d'entreprise réelles.

UELes entreprises européennes déployant des agents IA sur AWS peuvent s'appuyer sur cette architecture pour implémenter des couches de conformité RGPD et AI Act sans refactoriser leurs bibliothèques de filtrage MCP existantes.

InfrastructureActu

1 source

2AWS ML Blog

Amazon Bedrock propose désormais une attribution détaillée des coûts

Amazon Web Services vient d'annoncer une nouvelle fonctionnalité d'attribution granulaire des coûts pour Amazon Bedrock, son service d'inférence d'IA en cloud. Désormais, Bedrock attribue automatiquement chaque dépense d'inférence à l'identité IAM (Identity and Access Management) qui a effectué l'appel, qu'il s'agisse d'un utilisateur IAM classique, d'un rôle assumé par une application Lambda, ou d'une identité fédérée via un fournisseur comme Okta ou Microsoft Entra ID. Ces données apparaissent directement dans AWS Cost and Usage Reports (CUR 2.0) sans aucune ressource supplémentaire à gérer ni modification des workflows existants. Concrètement, un rapport peut montrer qu'Alice a dépensé 0,069 dollar en tokens d'entrée et 0,214 dollar en tokens de sortie avec Claude Sonnet 4.6, pendant que Bob a consommé 1,188 dollar au total avec Claude Opus 4.6, avec une précision à l'identité près. Il est également possible d'ajouter des tags de coût sur les identités IAM pour regrouper les dépenses par équipe, projet ou centre de coût dans AWS Cost Explorer. Cette visibilité fine répond à un besoin croissant des entreprises qui voient l'inférence IA représenter une part de plus en plus significative de leur facture cloud. Sans attribution précise, il est impossible de refacturer correctement les équipes internes, d'identifier les usages inefficaces ou de planifier les budgets. Grâce à cette fonctionnalité, un DSI peut désormais savoir exactement quelle équipe produit, quel service applicatif ou quel développeur génère quels coûts LLM, sans déployer d'infrastructure de monitoring supplémentaire. Pour les organisations qui font transiter leurs appels via une passerelle LLM centralisée, AWS recommande d'utiliser AssumeRole avec des tags de session dynamiques afin de préserver la granularité par utilisateur final, même derrière un proxy unique. Cette annonce s'inscrit dans une tendance de fond : les grands fournisseurs de cloud cherchent à rendre l'IA générative compatible avec les pratiques de gouvernance financière des entreprises. Amazon Bedrock, qui donne accès à des modèles de plusieurs éditeurs dont Anthropic, Mistral et Meta, doit convaincre les directions financières que la dépense IA est traçable et contrôlable. La concurrence avec Azure AI et Google Vertex AI pousse AWS à muscler ses outils de FinOps autour de l'IA. À mesure que les modèles comme Claude Opus deviennent plus coûteux à l'usage, la capacité à attribuer précisément chaque dollar dépensé devient un argument de vente central pour les déploiements en entreprise, où la responsabilisation budgétaire par équipe est souvent non négociable.

UELes entreprises européennes utilisant Amazon Bedrock peuvent désormais attribuer précisément leurs dépenses d'inférence IA par équipe ou projet, facilitant la gouvernance financière et la refacturation interne sans infrastructure supplémentaire.

InfrastructureActu

1 source

3VentureBeat AI

Oracle unifie sa pile de données IA pour offrir aux agents d'entreprise une source unique de vérité

Oracle a annoncé cette semaine un ensemble de nouvelles capacités pour sa plateforme Oracle AI Database, articulées autour d'un composant central baptisé Unified Memory Core. Ce moteur transactionnel unique traite simultanément des données vectorielles, JSON, graphes, relationnelles, spatiales et en colonnes — sans couche de synchronisation intermédiaire. L'annonce comprend également Vectors on Ice, un service d'indexation vectorielle native sur les tables Apache Iceberg, un service managé Autonomous AI Vector Database gratuit au démarrage, et un serveur MCP permettant aux agents externes d'accéder directement à la base de données sans code d'intégration personnalisé. Oracle, dont l'infrastructure de base de données équipe les systèmes transactionnels de 97 % des entreprises du Fortune Global 100 selon ses propres chiffres, positionne ces fonctionnalités comme une réponse architecturale directe aux problèmes rencontrés en production par les équipes déployant des agents IA. Le problème que cherche à résoudre Oracle est précis : les agents IA construits sur une combinaison de bases vectorielles, relationnelles, de graphes et de lakehouses nécessitent des pipelines de synchronisation pour maintenir leur contexte à jour — et sous charge de production, ce contexte devient obsolète. En centralisant tous les types de données dans un seul moteur ACID, Oracle élimine ce besoin de synchronisation et garantit une cohérence transactionnelle sur l'ensemble des formats. La fonctionnalité Vectors on Ice s'adresse spécifiquement aux équipes utilisant Apache Iceberg avec Databricks ou Snowflake : l'index vectoriel se met à jour automatiquement à mesure que les données sous-jacentes évoluent, permettant des requêtes combinant recherche vectorielle et données relationnelles ou graphes dans une seule opération. Le serveur MCP applique automatiquement les contrôles d'accès par ligne et par colonne d'Oracle, quelle que soit la requête émise par l'agent. Cette annonce s'inscrit dans un marché en pleine recomposition. Les bases vectorielles spécialisées comme Pinecone, Qdrant ou Weaviate ont émergé comme points d'entrée naturels pour les développeurs IA, mais Oracle fait le pari que ces outils ne constituent qu'une étape transitoire avant que les entreprises ne cherchent une infrastructure unifiée et cohérente pour aller en production. Maria Colgan, vice-présidente en charge des moteurs de données mission-critical chez Oracle, a reconnu ouvertement que toutes les données d'entreprise ne résident pas dans Oracle — une concession inhabituelle pour l'éditeur — mais argue que le Unified Memory Core offre un avantage structurel là où la fragmentation du stack devient un frein opérationnel. L'enjeu est de taille : convaincre les architectes data que le bon endroit pour faire tourner des agents IA en production n'est pas un assemblage de services spécialisés, mais le moteur de base de données lui-même.

UELes entreprises européennes déployant des agents IA avec des stacks fragmentés (Oracle + Databricks/Snowflake) peuvent réduire leur complexité opérationnelle en production, sans impact réglementaire direct sur la France ou l'UE.

InfrastructureOpinion

1 source

4AWS ML Blog

Amazon SageMaker AI propose désormais des recommandations optimisées pour l'inférence d'IA générative

Amazon a annoncé que SageMaker AI prend désormais en charge les recommandations optimisées pour le déploiement de modèles d'IA générative en production. Cette nouvelle fonctionnalité s'appuie sur NVIDIA AIPerf, un composant modulaire du framework open source NVIDIA Dynamo, pour fournir automatiquement des configurations de déploiement validées accompagnées de métriques de performance précises. Concrètement, SageMaker AI évalue les combinaisons d'instances GPU, de conteneurs de service, de stratégies de parallélisme et de techniques d'optimisation, puis restitue aux équipes les configurations les plus adaptées à leurs exigences de latence, de débit ou de coût. Eliuth Triana, Developer Relations Manager chez NVIDIA, a salué l'intégration, soulignant qu'elle permet aux entreprises de déployer des modèles d'IA générative avec confiance, en remplaçant des semaines de tests manuels par des configurations prêtes à l'emploi. L'enjeu est considérable pour les équipes d'ingénierie. Aujourd'hui, passer d'un modèle entraîné à un endpoint de production opérationnel prend entre deux et trois semaines par modèle, une durée imposée par la nécessité de tester manuellement des dizaines de configurations possibles : plus d'une douzaine de types d'instances GPU, plusieurs conteneurs de service, différents degrés de parallélisme, et des techniques comme le décodage spéculatif. Sans guidance validée, les équipes provisionnent des instances, déploient le modèle, exécutent des tests de charge, analysent les résultats, puis recommencent. Ce cycle mobilise une expertise en infrastructure GPU et en frameworks de service que la plupart des équipes ne possèdent pas en interne, conduisant systématiquement à du sur-provisionnement coûteux. AWS élimine ce goulot d'étranglement en automatisant l'ensemble du processus d'exploration et de validation des configurations. Cette évolution s'inscrit dans une course à la mise en production de l'IA générative que se livrent les entreprises pour alimenter leurs assistants intelligents, outils de génération de code et moteurs de contenu. Le coût du sur-provisionnement GPU, qui s'accumule à chaque modèle déployé et à chaque mois d'exploitation, représente un problème structurel pour l'industrie. AWS s'appuie sur sa collaboration technique approfondie avec NVIDIA, formalisée ici par l'intégration directe des composants de Dynamo dans SageMaker, pour s'imposer comme la plateforme cloud de référence pour les déploiements d'IA en production. En standardisant le benchmarking via AIPerf, dont les contrôles de concurrence et les options de jeux de données permettent d'itérer rapidement sur des scénarios variés, Amazon réduit la barrière technique pour les organisations qui cherchent à industrialiser leurs modèles sans constituer une équipe d'experts en infrastructure dédiée.

UELes entreprises européennes utilisant AWS SageMaker peuvent réduire leurs délais de mise en production de modèles IA de plusieurs semaines, sans impact réglementaire ou institutionnel direct sur la France ou l'UE.

InfrastructureActu

1 source