AWS repense le runtime AgentCore de Bedrock pour une mémoire élastique et des démarrages à froid rapides

Amazon Web Services annoncé le nouveau runtime AgentCore le 18 septembre 2026, une version repensée de la couche de calcul gérée dans Amazon Bedrock AgentCore que l’entreprise affirme que la mémoire est récupérée lorsque les sessions d’agent la libèrent et qu’elle offre des temps de démarrage à froid constants, quel que soit la taille de l’image du conteneur ou le niveau de concurrence.

Le runtime AgentCore est la couche de calcul gérée qui offre aux développeurs un environnement entièrement géré pour déployer et exécuter des agents sans construire ni maintenir d’infrastructure. AWS a indiqué que des milliers d’équipes l’ont utilisé pour faire fonctionner des agents en production depuis son lancement, et que la première version a établi une fondation sans serveur avec isolation des sessions, comportement d’échelle à zéro et tarification à l’usage. Ce modèle de consommation se poursuit : la facturation suit l’utilisation des ressources sans frais pour le CPU inactif en attente d’E/S, et la plateforme se réduit entièrement à zéro lorsqu’un agent n’a aucune tâche.

Les problèmes que le lancement vise à résoudre

Dans le runtime original, une session conservait la mémoire qui lui était allouée du moment de l’allocation jusqu’à la fin de la session, car rien ne la récupérait en cours de route. AWS a indiqué que cela laissait les agents à longue durée ou à trafic éclaté payer pour leur pic de consommation en permanence, bien après que la mémoire n’était plus utilisée, ce qui constituait une lacune particulière pour les agents qui connaissent des pointes occasionnelles mais restent inactifs la majeure partie de la journée.

Le comportement au démarrage était le deuxième défi. AWS a indiqué qu’une session qui atterrit sur un environnement déjà initialisé démarre en moins de 100 millisecondes, mais maintenir les environnements suffisamment chauds pour garantir cela implique de garder des ressources de calcul en réserve, de sorte que la plupart des sessions commencent par un démarrage à froid qui initialise un nouvel environnement, récupère l’image et initialise l’agent avant que la première requête ne soit exécutée. Cette latence augmente avec la taille de l’image et le niveau de concurrence et est la plus élevée lors d’un trafic éclaté, lorsque le plus grand nombre de sessions arrive et que le nombre d’environnements prêts est le plus faible. Selon AWS, les clients ont contourné ces deux problèmes en maintenant des environnements de secours prêts, en optimisant l’allocation de mémoire et en réduisant la capacité afin de maîtriser les coûts.

Ce que AWS a mesuré

Pour isoler ce que la plateforme elle‑même ajoute à un démarrage à froid, AWS a testé un agent d’écho vide qui renvoie son entrée et n’appelle aucun modèle ni aucun outil. Un client Python sur une instance Amazon EC2 dans us-west-2 a invoqué des agents dans us-east-1 via Internet public sans peering VPC, en utilisant le SDK boto3, de sorte que chaque mesure côté client comprend le aller‑retour entre les deux régions AWS en plus du temps de démarrage propre à la plateforme. L’entreprise a envoyé 5 000 invocations à froid par agent, couvrant les deux versions du runtime et cinq tailles d’image, dans les quotas de compte par défaut.

Mesurés ainsi, AWS a indiqué que le nouveau runtime offrait une latence de démarrage à froid P75 d’environ 2 secondes pour une image de 200 Mo jusqu’à 2 Go, la taille de l’image n’ayant aucune influence, tandis que la latence du runtime original augmentait avec la taille de l’image, passant d’environ 5,4 secondes à près de 30 secondes. Dans le test d’écho, le code propre de l’agent s’est exécuté en environ 34 millisecondes au P75, de sorte que presque tout le temps mesuré était le temps de démarrage de la plateforme. AWS suggère de masquer le temps de démarrage pour les agents interactifs en lançant la session dès que l’utilisateur interagit, par exemple lorsqu’il ouvre une conversation, afin que l’environnement se réchauffe pendant qu’il tape la première requête.

Comment fonctionne le nouveau runtime

Le nouveau runtime démarre chaque session à partir d’un petit profil mémoire plutôt que d’une empreinte entièrement provisionnée, puis alloue et charge en mémoire supplémentaire à la demande lorsque la charge de travail y accède. Lorsqu’un agent libère des tampons par requête ou laisse expirer les données en cache entre les requêtes, la plateforme récupère la mémoire au lieu de la laisser occupée jusqu’à la fin de la session. AWS a indiqué qu’elle a ajusté le comportement de récupération en s’appuyant sur une analyse des schémas d’allocation à travers des milliards de sessions.

Les démarrages à froid changent parce que chaque agent se charge une fois puis s’exécute à partir d’un instantané. Lorsqu’un runtime est créé ou mis à jour, AgentCore lance le conteneur, attend qu’il signale un état sain, puis capture un instantané de l’environnement en cours d’exécution, de sorte que l’initialisation unique, comme le chargement des artefacts du modèle et la récupération de la configuration statique, est déjà effectuée. Chaque nouvelle instance restaure cet instantané au lieu d’initialiser à partir de zéro. AWS a indiqué que le runtime supprime les caches et la mémoire transitoire de l’instantané, de sorte que sa taille reste à peu près constante à mesure que l’image du conteneur augmente, ce qui maintient la latence de restauration stable sur un large éventail de tailles d’image.

La facturation évolue avec le modèle de mémoire. Le nouveau runtime facture la mémoire réellement utilisée par un agent, chargée à la demande et récupérée lorsqu’elle est inactive, plutôt que de facturer la totalité de l’image du conteneur en mémoire pendant toute la durée d’une session. AWS a décrit ce changement comme un taux plus élevé appliqué à beaucoup moins de gigaoctet‑heures, et a indiqué que pour la plupart des agents, l’empreinte diminue davantage que le taux n’augmente, ce qui fait baisser la facture.

Versions de la plateforme, régions et limites

Les développeurs activent le nouveau runtime en définissant le champ platformVersion sur V2 lors de la création ou de la mise à jour d’un runtime, selon le Guide du développeur AgentCore. V1 est la valeur par défaut : omettre le champ lors de la création produit un runtime V1, et l’omettre lors d’une mise à jour conserve la version de plateforme actuelle du runtime. V2 est disponible dans us-east-1, us-east-2, us-west-2, eu-west-1 et ap-northeast-1.

Parce qu’une création ou mise à jour V2 prépare et prend un instantané de l’environnement, ces opérations durent plusieurs minutes avant que le runtime n’atteigne l’état READY, alors qu’un runtime V1 devient prêt en quelques secondes. AgentCore prend l’instantané dès la première réponse saine de l’endpoint /ping du conteneur, et si le conteneur ne signale pas d’état sain dans les 120 secondes suivant le démarrage, la création échoue avec une erreur de vérification de santé. Le guide indique également que V2 limite actuellement la taille totale des variables d’environnement à 1,5 KB pour les déploiements de code directs et à 2,5 KB pour les agents de conteneur, contre 4 KB sur V1, et que AWS CloudFormation et le AWS CDK ne prennent pas encore en charge la définition de platformVersion.

Les instantanés suivent les versions et les points de terminaison du runtime plutôt que d’être gérés directement. AgentCore crée un instantané lorsqu’un point de terminaison pointe vers une version et en supprime un lorsqu’aucun point de terminaison ne le référence, la suppression pouvant prendre jusqu’à 8 heures, durée maximale d’une session, car les sessions déjà en cours sur l’instantané continuent jusqu’à leur terminaison. Les sessions s’exécutent dans des microVM dédiées avec des ressources CPU, mémoire et système de fichiers isolées, persistent jusqu’à 8 heures et se terminent après 15 minutes d’inactivité, moment où la microVM est arrêtée et la mémoire est assainie.

Feuille de route et démarrage

Au‑delà du lancement, AWS a annoncé plusieurs fonctionnalités à venir : des remises de base engagées qui réservent un seuil de mémoire par session avec un dépassement à la demande, destinées aux sessions constamment actives ; plus de RAM, de vCPU et de stockage de session ; prise en charge des microVM x86 ; suspension‑et‑reprise avec instantané de mémoire ainsi que des hooks d’exécution pour sérialiser l’état avant la terminaison d’une session active ; et des clés de contexte de session qui attribuent à chaque session une identité délimitée pour les agents non surveillés.

AWS a dirigé les développeurs vers le Guide du développeur AgentCore, le référentiel d’exemples AgentCore sur GitHub, ainsi qu’un exemple de test de charge accompagnant qui montre la latence de démarrage à froid du nouveau runtime dans le compte AWS personnel de l’utilisateur.