Amazon Bedrock AgentCore Runtime V2 rend les démarrages à froid prévisibles, mais la facture doit encore faire ses preuves

Amazon a lancé Amazon Bedrock AgentCore Runtime V2 avec une affirmation frappante : les démarrages à froid restent proches de deux secondes pour des images de conteneur allant de 200 Mo à 2 Go.

Ce résultat remet en cause un compromis bien connu du serverless. Les équipes peuvent ramener un agent à zéro pour économiser de l’argent, mais l’utilisateur suivant attend souvent pendant le démarrage de son environnement. Garder des instances chaudes réduit ce délai, mais maintient aussi une capacité qui peut rester inactive.

Runtime V2 s’attaque aux deux aspects de cet arbitrage. AWS affirme qu’il restaure des snapshots préparés au lieu de reconstruire chaque environnement. Il récupère également la mémoire inutilisée tant qu’une session reste active, plutôt que de facturer la mémoire selon le pic atteint plus tôt dans la session.

L’annonce est importante, car les agents en production se comportent différemment des gestionnaires de requêtes conventionnels. Ils peuvent attendre des modèles, appeler des outils, traiter des fichiers et conserver un état de travail sur une longue série de requêtes. Un runtime conçu autour de brèves transactions web peut gaspiller des ressources lorsque ces pauses dominent la session.

AWS positionne V2 face à cette inadéquation d’infrastructure, et non simplement face à un autre framework d’agents. L’enjeu central oppose une exécution fondée sur des snapshots et sensible à l’utilisation à des environnements qui restent chauds ou conservent leurs allocations maximales pour garantir des performances prévisibles.

Microsoft et Google proposent déjà leurs propres réponses à la latence de démarrage des conteneurs. Microsoft utilise des pools de sessions préchauffées, tandis que Google recommande des instances minimales et l’accélération CPU au démarrage. Le nouvel argument d’Amazon est que les équipes ne devraient pas avoir besoin de capacité maintenue en permanence à chaud pour obtenir un comportement de démarrage cohérent.

Les chiffres sont prometteurs, mais ils proviennent du propre benchmark d’AWS. Les acheteurs ont encore besoin de preuves au niveau de leurs charges de travail, couvrant le code d’initialisation réel, les pics de trafic, la pression mémoire, la capacité régionale et la latence totale de l’application.

Ce que change réellement Amazon Bedrock AgentCore Runtime V2

Runtime V2 modifie le moment où les environnements d’agents effectuent leur initialisation et la durée pendant laquelle la mémoire allouée reste facturable.

Amazon Bedrock AgentCore Runtime est la couche de calcul managée d’AgentCore. Elle héberge un agent ou un outil dans une microVM isolée, c’est-à-dire une machine virtuelle légère disposant de ressources CPU, mémoire et système de fichiers distinctes.

AWS a annoncé V2 le 18 septembre 2026. Les développeurs peuvent le sélectionner en définissant platformVersion sur V2 lors de la création ou de la mise à jour d’un runtime. V1 reste la version par défaut selon l’architecture du runtime actuelle.

Le premier changement majeur concerne l’initialisation. Lorsqu’un développeur crée ou met à jour un runtime V2, AgentCore démarre le conteneur et attend la vérification de son état de santé. La plateforme capture ensuite un snapshot préparé de cet environnement en cours d’exécution.

Les futures instances restaurent ce snapshot au lieu de répéter toute la séquence de démarrage. Les tâches ponctuelles, telles que le chargement de bibliothèques, la récupération d’une configuration statique ou la préparation d’artefacts de modèles, peuvent donc être réalisées avant l’arrivée de la première requête en direct.

Le snapshotting n’est pas nouveau en soi. AWS Lambda SnapStart restaure également des environnements d’exécution initialisés afin de réduire les délais de démarrage. AgentCore applique cette approche à des sessions d’agents isolées et plus durables, avec des conteneurs personnalisés et des interactions avec état.

Le deuxième changement concerne la comptabilisation de la mémoire. V1 conservait la mémoire allouée jusqu’à la fin d’une session, même lorsque l’agent libérait des buffers ou cessait d’utiliser des données mises en cache. L’utilisation pouvait donc suivre l’allocation mémoire la plus élevée atteinte au cours de cette session.

V2 démarre avec une empreinte résidente plus faible et charge les pages mémoire à mesure que la charge de travail y accède. AWS indique que la plateforme récupère la mémoire après sa libération par l’application ou lorsque les données deviennent froides.

Les règles d’utilisation actuelles indiquent que la mémoire inactive dans V2 est automatiquement récupérée après 120 secondes. Un minimum de 128 Mo s’applique à la facturation de la mémoire, tandis que la surcharge système compte également dans l’utilisation mesurée.

Le CPU suivait déjà un modèle orienté consommation. Lorsqu’un agent attend un modèle, un outil, une base de données ou une API externe, les frais de CPU peuvent tomber à zéro si aucun processus d’arrière-plan ne reste actif. V2 étend plus concrètement cette élasticité à la mémoire.

Ces changements comptent surtout lorsqu’une session traverse des phases très différentes. Un agent documentaire peut allouer de la mémoire pendant l’analyse d’un gros fichier, libérer ces buffers, puis passer plusieurs minutes à attendre des appels de modèle.

Dans un modèle basé sur le pic maximal, la phase d’analyse peut déterminer l’utilisation de mémoire pour le reste de la session. Avec V2, AWS affirme que l’utilisation ultérieure peut diminuer après la disparition de cette allocation temporaire.

Les sessions AgentCore exigent toujours une gestion attentive de leur cycle de vie. Une microVM peut fonctionner jusqu’à huit heures, et le délai d’inactivité par défaut peut interrompre son calcul plus tôt. Les applications doivent également conserver les informations durables hors de la mémoire éphémère de la session.

Le lancement ne transforme donc pas un conteneur d’agent en infrastructure persistante illimitée. Il modifie l’efficacité et le comportement au démarrage de l’environnement managé tout en conservant les limites de session d’AgentCore.

Cette distinction crée la véritable tension. AWS promet la réactivité associée à une capacité préparée tout en préservant l’économie d’une exécution qui peut redescendre à zéro.

Pourquoi les charges de travail des agents ont mis à mal l’ancien modèle de mémoire

L’ancien modèle est devenu inefficace parce que les sessions d’agents restent actives entre des rafales alternées de calcul, de croissance mémoire et d’attente externe.

Une requête web conventionnelle suit généralement un cycle de vie court et compréhensible. Elle arrive, exécute le code applicatif, accède à une base de données, renvoie une réponse et libère son environnement d’exécution.

Un agent peut se comporter davantage comme un travailleur temporaire. Il reçoit un objectif, appelle un modèle, invoque plusieurs outils, télécharge du contenu, crée des fichiers intermédiaires, attend des approbations, puis reprend plus tard.

Ces étapes imposent des exigences différentes au runtime. Les appels d’outils peuvent laisser le CPU presque inactif. Le traitement de documents peut créer de brèves pointes de mémoire. Les conversations interactives pénalisent les délais de démarrage, tandis que les tâches sans supervision privilégient le coût plutôt que la réponse immédiate.

V1 offrait déjà l’isolation des sessions, le comportement de retour à zéro et une facturation CPU basée sur la consommation. Toutefois, sa gestion de la mémoire conservait les allocations après la fin de leur phase utile.

Prenons un agent de programmation qui examine un grand dépôt. Il peut charger un index, inspecter les résultats de build, conserver plusieurs réponses d’outils, puis libérer la majeure partie de ces données avant d’attendre le modèle.

Le pic de mémoire continuait d’affecter l’utilisation ultérieure avec le runtime initial. Les sessions plus longues amplifiaient cette conséquence, car une allocation précoce pouvait rester attachée à l’empreinte de la session.

AWS indique avoir étudié les schémas d’allocation de milliards de sessions lors du réglage de V2. Cette déclaration suggère une télémétrie interne étendue, mais l’entreprise n’a pas publié la distribution, la méthodologie ni le mélange représentatif de charges de travail à l’origine de l’analyse.

La récupération de mémoire froide rapproche le compteur de l’évolution de la charge de travail d’un agent. Elle crée aussi une nouvelle question opérationnelle : à quelle vitesse les données sorties de la mémoire peuvent-elles revenir lorsqu’un agent en a soudainement besoin ?

AWS décrit la mémoire comme chargée à la demande, récupérée lorsqu’elle est libérée et récupérée lorsqu’elle devient froide. L’annonce publique ne fournit pas de détails sur la latence des défauts de page ni sur les seuils applicables à chaque schéma de charge de travail.

Cette omission compte pour les agents dotés de grands caches réutilisables. Récupérer un cache peut réduire la mémoire mesurée, mais sa reconstruction ultérieure peut consommer du CPU, accroître la latence ou répéter des transferts réseau.

Les développeurs devront distinguer les allocations réellement jetables des données qui améliorent les tours suivants. Un graphique mémoire plus bas ne signifie pas automatiquement un workflow complet plus rapide ou moins coûteux.

L’architecture donne également davantage d’importance au comportement de l’application. Un logiciel qui libère les buffers temporaires donne à la plateforme la possibilité de récupérer de la mémoire. Un processus qui conserve indéfiniment des références ne peut pas attendre du runtime qu’il déduise que les données sont inutiles.

Les longues sessions d’agents rendent cette discipline précieuse. La documentation AWS indique que chaque session de microVM reçoit des ressources de calcul, de mémoire et de système de fichiers isolées. Une session arrêtée peut ultérieurement recevoir de nouvelles ressources de calcul, mais l’état éphémère disparaît à moins que l’application n’utilise un stockage de session persistant ou un autre service durable.

Cette conception protège la séparation entre les utilisateurs, mais elle empêche les développeurs de traiter la mémoire en processus comme un magasin de connaissances permanent. Les enregistrements de conversations, les préférences apprises et les faits réutilisables exigent un stockage durable hors de la microVM.

La distinction est particulièrement importante pour les agents riches en connaissances. Les équipes ont aussi besoin d’un registre opérationnel consultable couvrant les prompts, les documents source, les résultats de test et les changements de runtime. Une base de connaissances d’ingénierie maintenue peut préserver ce contexte au-delà d’une session d’exécution individuelle.

Runtime V2 ne supprime pas ces responsabilités architecturales. Il rend la couche de calcul temporaire plus élastique, ce qui accroît la valeur d’une séparation entre les données de travail transitoires et les connaissances organisationnelles durables.

La restauration de snapshots redéfinit l’arbitrage des démarrages à froid

L’amélioration phare provient de la restauration d’un snapshot initialisé et allégé, dont la taille reste relativement stable à mesure que l’image de conteneur augmente.

Un démarrage à froid désigne la période précédant la disponibilité d’un environnement nouvellement créé pour traiter le travail applicatif. Il peut inclure le téléchargement d’une image, le provisionnement du calcul, le démarrage du processus, le chargement des dépendances et l’exécution du code d’initialisation.

Les démarrages à froid deviennent particulièrement visibles lorsque le trafic arrive après qu’un service est redescendu à zéro. Ils apparaissent également lors de pics soudains, lorsque les environnements existants ne peuvent pas gérer chaque nouvelle session.

Les grands conteneurs d’agents peuvent aggraver le problème. Ils peuvent inclure des runtimes de langage, des dépendances de navigateur, des frameworks d’agents, des analyseurs de documents, des bibliothèques de machine learning et des outils internes.

Runtime V2 modifie ce chemin. AgentCore initialise l’environnement lorsqu’une version du runtime est préparée, capture son état et restaure cet état pour les futures instances.

AWS indique que la plateforme supprime également les caches et la mémoire transitoire dont une instance restaurée n’a pas besoin. Cet allègement vise à empêcher la taille du snapshot d’augmenter avec l’empreinte résidente complète d’un conteneur plus volumineux.

Le benchmark de lancement de l’entreprise a envoyé 5 000 invocations à froid par agent sur V1 et V2. Le test a couvert cinq tailles d’image selon les quotas de compte par défaut.

V2 a enregistré une latence de démarrage à froid P75 d’environ deux secondes, d’une image de 200 Mo jusqu’à une image de 2 Go. P75 signifie que 75 % des démarrages mesurés se sont achevés au temps indiqué ou en dessous.

V1 s’est comporté différemment dans le même test AWS. Son résultat P75 est passé d’environ 5,4 secondes pour la plus petite image à près de 30 secondes pour la plus grande.

Ces chiffres rendent le mécanisme plus intéressant qu’une simple amélioration en pourcentage. AWS affirme que la taille de l’image cesse d’être un facteur significatif de la latence de restauration dans la plage testée.

Le benchmark a également utilisé une application d’écho dont le code s’exécutait en environ 34 millisecondes au P75. Cette configuration isole le démarrage de l’infrastructure, mais elle ne reflète pas le chemin d’exécution complet d’un agent sophistiqué.

Les agents réels passent souvent plusieurs secondes sur chaque appel au modèle. Ils peuvent aussi contacter des outils distants, récupérer du contexte, authentifier les utilisateurs ou établir des connexions réseau une fois l’environnement prêt.

Un démarrage de plateforme de deux secondes ne signifie pas une réponse en deux secondes. Cela signifie que l’infrastructure ajoute un délai plus faible et plus prévisible avant que le code de l’agent ne reçoive sa première requête.

Cette prévisibilité peut compter davantage que la moyenne. Les équipes produit peuvent concevoir les états de chargement, les délais d’expiration et les attentes concernant le premier token avec davantage de confiance lorsque la latence de démarrage reste dans une plage étroite.

AWS suggère de démarrer une session lorsqu’un utilisateur ouvre une interface, avant que cette personne n’envoie sa première invite. Le texte d’accueil et le temps de saisie peuvent alors masquer une grande partie de l’intervalle de démarrage restant.

Cette tactique est pratique, mais elle modifie aussi la demande. L’ouverture d’une interface peut créer des sessions qui ne reçoivent jamais de message ; les équipes doivent donc mesurer les sessions abandonnées et les créations d’environnements inutiles.

Les snapshots introduisent également des considérations de déploiement. L’initialisation capturée avant le snapshot ne doit pas intégrer des identifiants expirés, de l’aléa non sûr ou un état propre à un utilisateur.

La configuration statique peut convenir. Les secrets sensibles au temps et l’identité par session doivent être obtenus via des mécanismes sûrs lors de la restauration. Les vérifications d’état doivent aussi représenter un environnement réellement préparé, et non simplement un port réseau à l’écoute.

Le modèle de snapshot déplace donc une partie du travail du moment de la requête vers celui du déploiement. Les équipes bénéficient d’une création d’instances plus rapide, mais elles doivent auditer ce qui devient partie intégrante de l’état capturé.

AWS Met la Pression sur le Modèle de Pool Préchauffé

L’argument concurrentiel d’Amazon ne porte pas simplement sur des conteneurs plus rapides ; il repose sur un démarrage cohérent sans exiger que chaque équipe finance en permanence une capacité maintenue à chaud.

Les fournisseurs de cloud proposent déjà plusieurs moyens de réduire la latence de démarrage à froid. La plupart des approches échangent des ressources inactives, des réglages opérationnels ou des contraintes applicatives contre des réponses plus rapides.

Azure Container Apps de Microsoft propose des sessions dynamiques. Elles utilisent des pools d’environnements préchauffés capables d’allouer des sessions isolées en quelques millisecondes.

Ce modèle convient aux interpréteurs de code et aux charges de travail nécessitant des sandboxes jetables. Sa rapidité vient de la disponibilité d’environnements prêts avant l’arrivée d’une requête.

Google Cloud Run adopte une approche plus générale des conteneurs. Les développeurs peuvent configurer des instances minimales afin de maintenir les conteneurs à chaud, et l’augmentation du CPU au démarrage peut accélérer l’initialisation.

Le maintien d’instances minimales réduit l’exposition aux démarrages à froid, mais les instances inactives peuvent augmenter les coûts. L’augmentation du CPU au démarrage améliore le chemin d’initialisation sans supprimer la nécessité de charger et de démarrer une application.

La conception V2 d’Amazon occupe une position différente. Elle prépare un snapshot du runtime une fois, supprime l’état inutile et restaure des instances isolées à mesure que les sessions arrivent.

La comparaison n’est pas absolue. Les pools préchauffés peuvent offrir une latence d’allocation inférieure au résultat P75 d’environ deux secondes rapporté par AWS. Ils peuvent également fournir un plancher de capacité plus clair lors d’une demande prévisible.

Les snapshots préservent une économie de mise à l’échelle jusqu’à zéro plus avantageuse lorsque le trafic est intermittent. Leur valeur augmente lorsqu’une équipe possède de nombreux agents qui restent inutilisés pendant de longues périodes mais doivent répondre de manière cohérente lorsqu’ils sont invoqués.

Cette compétition reflète une question de longue date dans le serverless. Les clients doivent-ils payer pour maintenir une capacité prête, ou la plateforme peut-elle rendre la création à la demande suffisamment prévisible pour que la capacité à chaud devienne facultative ?

Les charges de travail d’agents rendent la question plus pressante. Une entreprise peut exploiter des centaines d’agents spécialisés, alors qu’une petite partie seulement traite du travail à un instant donné. Garder chaque environnement à chaud gaspillerait de la capacité.

Le trafic en rafales crée la préoccupation inverse. Si de nombreuses sessions démarrent simultanément, la plateforme doit restaurer rapidement les snapshots sans introduire de pénalité de concurrence.

AWS affirme que V2 maintient une latence de démarrage à froid cohérente quelle que soit la concurrence. Toutefois, la description publiée du benchmark met l’accent sur la taille des images et les quotas par défaut. Elle ne révèle pas tous les niveaux de concurrence ni toutes les conditions régionales.

Les équipes qui évaluent AgentCore devraient comparer les objectifs complets de niveau de service, et non un seul chiffre de démarrage. Parmi les mesures utiles figurent la latence de queue, le délai avant le premier token du modèle, le comportement du cache restauré, les démarrages échoués et les performances lors de pics de trafic brusques.

Elles devraient également comparer la consommation totale de ressources. Un pool préchauffé présente une capacité inactive visible, tandis qu’un service basé sur des snapshots peut masquer des coûts dans la restauration, la pagination mémoire, le réseau ou une initialisation répétée après des changements de déploiement.

La portabilité reste un autre facteur. AgentCore accepte les applications conteneurisées et prend en charge des frameworks tels que LangGraph, CrewAI et Strands Agents. Pourtant, ses contrôles de runtime, ses API de session, sa couche d’identité et son modèle de facturation sont propres à AWS.

Microsoft et Google encouragent également l’intégration avec leurs services environnants d’identité, de supervision, de stockage et d’IA. La décision concurrentielle dépasse donc les seuls démarrages à froid.

Une entreprise déjà standardisée sur un cloud peut valoriser la cohérence opérationnelle davantage qu’un avantage de benchmark. Une équipe qui construit une plateforme d’agents sensible à la latence peut au contraire tester directement chaque runtime.

AWS obtient néanmoins un argument commercial important. V2 lui permet d’affirmer que le passage à l’échelle zéro n’exige plus que la latence de démarrage augmente avec l’image du conteneur.

Si des charges de travail indépendantes reproduisent ce résultat, les acheteurs de cloud s’attendront à ce que les plateformes rivales expliquent pourquoi les pools à chaud ou les instances minimales restent nécessaires pour des applications comparables.

Le Benchmark est Solide, mais Étroit

AWS a démontré une amélioration crédible de l’infrastructure, mais n’a pas encore établi un coût total inférieur ni une latence applicative prévisible pour chaque agent en production.

La première limite est l’indépendance de la source. AWS a conçu le runtime, sélectionné la configuration de test, exécuté le benchmark et publié les résultats.

Le code de test associé permet aux clients de reproduire l’expérience dans leurs comptes. C’est utile, mais la reproductibilité dépend toujours de la région, des quotas, de la conception des conteneurs, de la forme du trafic et du calendrier de chaque exécution.

La deuxième limite est le choix du percentile. Le P75 offre une meilleure vision qu’une moyenne, mais les services sensibles à la latence planifient souvent autour des résultats P95 ou P99.

Un P75 stable à deux secondes peut coexister avec des événements de queue plus lents. L’annonce ne fournit pas la distribution complète nécessaire pour évaluer des objectifs stricts orientés utilisateur.

La troisième limite est la simplicité de la charge de travail. Un test d’écho aide à isoler le démarrage de la plateforme, mais les conteneurs de production effectuent davantage d’initialisation et établissent plus de connexions externes.

La capture par snapshot peut intégrer une partie de l’initialisation. Elle ne peut pas garantir que chaque connexion de base de données, échange d’identifiants, route réseau ou dépendance externe soit immédiatement utilisable après restauration.

Le quatrième enjeu concerne l’interprétation des coûts. AWS indique que V2 applique un tarif de ressources plus élevé que V1, tandis que la plupart des agents devraient consommer suffisamment moins de mémoire pour réduire leur facture totale.

Il s’agit d’une projection de l’entreprise, et non d’un résultat universel. Un agent dont la mémoire reste stable et qui libère rarement des allocations peut réaliser des économies limitées tout en payant le tarif V2 plus élevé.

Un agent connaissant des pics temporaires de mémoire présente un cas plus favorable. Les économies devraient s’améliorer lorsque de gros buffers disparaissent tôt et que la session restante passe beaucoup de temps avec une faible empreinte mémoire.

Les équipes devraient tester les deux versions sur des traces identiques. Elles devraient enregistrer l’utilisation mémoire par seconde, la consommation CPU, la durée des sessions, la latence de restauration, les coûts des modèles, les coûts de stockage et les transferts réseau.

La télémétrie de facturation exige aussi de la prudence. AWS indique que les données de surveillance peuvent être retardées et différer des registres de facturation faisant autorité en raison de l’agrégation et du rapprochement.

La cinquième préoccupation est le renouvellement du cache. Si V2 récupère des données dont un agent a rapidement besoin de nouveau, la charge de travail peut consacrer du temps supplémentaire à reconstruire ces données.

La règle d’AWS de récupération après 120 secondes d’inactivité fournit un seuil visible, mais elle n’explique pas entièrement le comportement de chaque catégorie de mémoire. Les développeurs devraient tester des intervalles entre les tours qui franchissent ce seuil.

La sixième préoccupation concerne l’exactitude des snapshots. Les applications initialisent souvent des générateurs de nombres aléatoires, des identifiants, des clients réseau, des fichiers temporaires et des threads d’arrière-plan au démarrage.

Un processus restauré ne doit pas réutiliser un état non sûr entre des sessions isolées. Les équipes doivent vérifier le comportement de leurs bibliothèques après restauration et s’assurer que l’identité par session arrive après la frontière du snapshot.

AgentCore fournit des microVM isolées, mais l’application reste responsable du mapping utilisateur-session. Un backend client doit empêcher qu’un utilisateur fournisse ou réutilise l’identifiant de session d’un autre utilisateur.

Des défaillances opérationnelles restent également possibles. Les quotas, la capacité régionale, les conteneurs défaillants, les vérifications d’état incorrectes et les limites des services en aval peuvent tous dominer l’expérience utilisateur.

Aucune de ces questions n’invalide le benchmark de V2. Elles définissent l’écart entre un résultat de plateforme prometteur et une décision de production.

La bonne conclusion est conditionnelle. V2 semble particulièrement attrayante pour les agents à trafic en rafales dotés de grandes images, d’une initialisation coûteuse, de pics temporaires de mémoire et de longues périodes d’attente du modèle ou des outils.

Les agents avec une mémoire stable, une demande active en permanence, des processeurs spécialisés ou des exigences strictes de moins d’une seconde nécessitent une comparaison plus large. AWS prépare elle-même des options de calcul plus importantes et des engagements de base pour certaines de ces charges de travail.

Trois Signaux qui Détermineront si V2 l’Emporte

Le prochain test sera de savoir si les mesures des clients confirment une latence de démarrage stable, des factures totales plus faibles et un comportement sûr des snapshots en dehors du benchmark contrôlé d’AWS.

Le premier signal est la forme des résultats de latence indépendants. Les développeurs devraient publier les démarrages à froid P50, P75, P95 et P99 dans plusieurs régions et selon différents schémas de trafic.

La taille des images devrait rester une partie de ces tests, mais la concurrence compte tout autant. Une évaluation utile lancerait des vagues soudaines de sessions isolées après qu’un runtime est passé à l’échelle zéro.

Si la latence de queue reste stable à mesure que la taille des images et la concurrence augmentent, l’affirmation centrale d’AWS devient beaucoup plus solide. Les grands conteneurs ne forceraient plus les équipes à maintenir des environnements de réserve en fonctionnement.

Si les résultats P95 et P99 varient fortement, le titre annonçant un P75 de deux secondes aura moins de valeur opérationnelle. Les équipes disposant d’agents interactifs auraient encore besoin de capacité à chaud ou d’une précréation agressive des sessions.

Le deuxième signal est le coût mesuré sur des sessions complètes. Le tarif de ressources plus élevé de V2 signifie que le résultat économique dépend de la quantité de mémoire que le runtime récupère réellement.

Les équipes devraient rejouer des charges de travail aux phases connues. Un test représentatif pourrait analyser un grand document, libérer ses buffers, effectuer plusieurs appels au modèle, attendre au-delà de 120 secondes, puis reprendre.

Si la mémoire facturée diminue après la phase d’analyse et reste faible, V2 soutient l’argument de coût d’AWS. Si la consommation reste proche du pic antérieur, les économies attendues s’affaiblissent.

La comparaison devrait inclure plus que les frais Runtime. L’inférence du modèle, l’observabilité, le stockage, les transferts réseau, le stockage des conteneurs, les sessions de navigateur et les services d’outils peuvent dominer la facture finale.

Cette vision plus large évite qu’une petite économie de runtime soit présentée comme une réduction spectaculaire au niveau de l’application. Elle révèle aussi si un démarrage plus rapide incite les équipes à créer des sessions inutiles.

Le troisième signal est la mise à disposition par AWS des capacités annoncées comme à venir. La feuille de route inclut des remises pour engagement de base, davantage de calcul et de stockage, la prise en charge de microVM x86, un contrôle accru du cycle de vie et une identité limitée à la session.

Chaque élément traite d’une limite actuelle. Des environnements plus volumineux élargissent les charges de travail éligibles. La prise en charge x86 réduit les frictions de migration pour les dépendances qui ne peuvent pas facilement passer à une autre architecture.

Des contrôles de suspension et de reprise aideraient les agents à poursuivre au-delà d’un seul cycle de calcul. Une identité à portée limitée préciserait à quoi les agents non supervisés peuvent accéder lorsqu’aucune personne ne les supervise activement.

Si AWS fournit ces capacités avec une documentation claire et un comportement stable, Runtime V2 deviendra une plateforme plus large plutôt qu’une optimisation ciblée du démarrage à froid.

Des retards exposeraient les limites de la version actuelle. Certaines charges de travail persistantes, spécialisées ou non supervisées nécessiteraient encore d’autres options de calcul AgentCore ou une infrastructure externe.

Les développeurs peuvent commencer par un test contrôlé de V1 à V2. Ils doivent conserver constants le code de l’agent, les appels au modèle, la trace de trafic, la région et les paramètres d’observabilité.

La décision doit reposer sur cinq résultats : les percentiles de démarrage, le taux d’échec des sessions, l’utilisation de la mémoire au fil du temps, la latence complète du flux de travail et la facture cloud finale.

Les produits interactifs devraient également tester la tactique de session précoce d’AWS. Démarrer l’environnement lorsqu’un utilisateur ouvre un chat peut masquer le temps de démarrage, mais les sessions abandonnées doivent rester visibles dans l’analyse.

Les agents de production passent de plus en plus de temps à attendre, à conserver un état et à coordonner des outils plutôt qu’à exécuter un travail CPU continu. Cela rend l’économie conventionnelle des conteneurs peu adaptée à de nombreuses charges de travail.

Amazon Bedrock AgentCore Runtime V2 propose une réponse techniquement cohérente. Il prépare le travail une seule fois, restaure un instantané plus léger et libère de la mémoire à mesure que les besoins de la session diminuent.

La question qui reste est empirique : Amazon Bedrock AgentCore Runtime V2 préserve-t-il ces avantages avec vos conteneurs, vos pics de trafic, vos dépendances et vos contrôles de sécurité ?

Exécutez la même charge de travail sur les deux versions de la plateforme, conservez la distribution complète de la latence et examinez la facture après rapprochement. Ce sont ces éléments qui devraient déterminer la migration, et non le titre de lancement.