Le runtime AWS AgentCore ajoute des sessions plus grandes et le montage de systèmes de fichiers

Le 12 novembre 2026, Amazon Web Services a enrichi son service de nouvelle génération Amazon Bedrock AgentCore Runtime en proposant des sessions d’agent plus grandes, une facturation selon un socle minimal engagé et le montage dynamique de systèmes de fichiers. AWS indique que ces mises à jour permettent de démarrer les sessions jusqu’à 15 fois plus rapidement, tout en préservant l’isolation matérielle.

Le runtime mis à jour est disponible dans les régions AWS d’Amérique du Nord, d’Amérique du Sud, d’Europe et d’Asie-Pacifique. AgentCore Runtime est la couche de calcul gérée d’AgentCore, la plateforme d’AWS permettant de créer des agents avec différents frameworks et modèles ; la plateforme dans son ensemble couvre également l’authentification, le contrôle des accès et l’observabilité.

Cette version fait suite à la présentation d’AgentCore Runtime V2 le 18 septembre 2026, qui avait introduit le démarrage à partir d’instantanés et la libération de mémoire. AWS avait alors annoncé que des capacités de calcul et de stockage supérieures, ainsi qu’une tarification fondée sur un socle minimal engagé, seraient bientôt disponibles. Ces fonctionnalités constituent désormais une grande partie de la mise à jour, à laquelle s’ajoute le montage de systèmes de fichiers.

Des sessions plus grandes, sans pools préchauffés

Chaque session peut désormais utiliser jusqu’à 8 vCPU et 32 Go de mémoire, et prendre en charge des images de conteneur pouvant atteindre 10 Go. AWS indique que cela représente quatre fois la capacité de calcul de la version précédente et que les sessions démarrent en moins de deux secondes, quelle que soit la taille de l’image ou la concurrence. Il n’est donc plus nécessaire que les clients gèrent eux-mêmes des pools préchauffés ou des clusters préprovisionnés pour éviter les démarrages à froid.

Le mécanisme de démarrage repose sur la restauration d’instantanés plutôt que sur une initialisation répétée. AgentCore prépare une fois un environnement de conteneur opérationnel, en capture l’état initialisé, puis restaure cet instantané pour chaque nouvelle instance. Ainsi, le chargement des artefacts de modèle et la récupération de la configuration statique, par exemple, n’ont pas à être répétés à chaque démarrage à froid.

Siwei Shen, vice-président de l’ingénierie chez Coinbase, a décrit les résultats en production : « Le passage à la nouvelle génération d’AgentCore Runtime a réduit le temps de démarrage à froid de nos sessions d’agent, qui était proche d’une minute, à moins de cinq secondes, même lors des pics de trafic. Cela a également éliminé les délais de démarrage supérieurs à 30 secondes, alors même que le volume hebdomadaire de nos agents a plus que doublé. »

Mission Cloud a indiqué qu’une première comparaison, portant sur la même charge de requêtes en langage naturel exécutée sur les deux versions du runtime, avait révélé des démarrages à froid 35 % plus rapides pour les requêtes d’inférence, des démarrages de vérification de l’état 77 % plus rapides et un coût d’exécution mesuré par appel inférieur de 17 %. Son agent récupère des informations sur les biens immobiliers et les ventes sans obliger les utilisateurs à naviguer dans des systèmes de données complexes.

Libération de mémoire et facturation selon un socle minimal

AWS modifie également la facturation de la mémoire pendant les périodes d’inactivité. Le runtime récupère la mémoire quelques minutes après qu’un agent l’a libérée et réduit à zéro les ressources d’un agent inactif ; selon AWS, les agents qui traitent plusieurs échanges et connaissent des pauses naturelles peuvent utiliser jusqu’à 68 % de mémoire en moins par session. Cette évolution corrige une limite de l’ancien modèle, qui facturait la capacité maximale allouée à une session même lorsque la mémoire n’était plus utilisée.

Pour les agents actifs en permanence, la tarification fondée sur un socle minimal engagé fixe une quantité de mémoire de référence par session, facturée au minimum, et permet de monter à la demande jusqu’à quatre fois ce niveau. AWS indique que le tarif prévisible ainsi obtenu pour les charges de travail régulières est équivalent à celui des microVM AWS Lambda ; la tarification à la consommation reste proposée pour les charges variables et celles dont les ressources peuvent être ramenées à zéro.

Zuora a indiqué que, dans de nombreux cas d’usage, le nouveau runtime avait réduit d’environ 60 % son empreinte mémoire par invocation, tout en lui permettant de traiter davantage de trafic avec une latence stable.

Stockage, isolation et limites de déploiement

Chaque session continue de s’exécuter dans sa propre microVM Firecracker isolée au niveau matériel, avec une identité, une politique d’accès et une piste d’audit qui lui sont propres. Les agents peuvent désormais monter dynamiquement un système de fichiers et y enregistrer leur travail, par exemple dans un compartiment Amazon S3 avec prise en charge de FUSE. AWS indique que, pendant toute la durée de la tâche, les données restent à l’intérieur du périmètre de confiance de la session et sont soumises à un même ensemble de contrôles, ce qui étend l’isolation au-delà de l’environnement de calcul.

La délimitation des dossiers de stockage par session ne fait pas partie des fonctionnalités annoncées comme disponibles. AWS indique que, d’ici re:Invent, des identifiants associés à chaque session rattacheront celle-ci à son propre dossier de stockage, ajoutant ainsi un contrôle plus précis à la fonctionnalité de montage.

La documentation actuelle de V2 présente également certaines différences de déploiement. V2 reste activé sur demande, car V1 est la version par défaut, sauf si platformVersion est défini sur V2; la création ou la mise à jour d’un runtime V2 prend plusieurs minutes, le temps qu’AWS prépare l’instantané, et le conteneur doit signaler qu’il est opérationnel via son /ping point de terminaison dans un délai de 120 secondes. Ces durées de configuration sont distinctes de la latence de démarrage à froid des sessions.

Les sessions peuvent persister jusqu’à huit heures, mais prennent fin après 15 minutes d’inactivité, lorsqu’elles atteignent cette limite de durée ou si elles deviennent non opérationnelles. L’état des sessions est éphémère ; à la fin d’une session, la microVM est détruite et la mémoire est nettoyée.

Cette version réunit le calcul des sessions, la facturation de la mémoire et les données des tâches au sein d’un même modèle de runtime géré. Le point qui reste à compléter concerne l’isolation précise du stockage : la délimitation du stockage par session est la dernière étape pour étendre la garantie d’isolation du runtime de l’exécution aux travaux des agents enregistrés.