AWS a lancé Lambda MicroVMs, une nouvelle option de calcul sans serveur permettant d'exécuter du code généré par l'utilisateur et par l'IA dans des environnements virtuels isolés et avec état.
Les microVM Lambda utilisent la virtualisation AWS Firecracker pour fournir un environnement d'exécution distinct à chaque session utilisateur, tâche ou agent d'IA. Chaque microVM bénéficie d'un espace dédié. HTTPS point de terminaison et peut préserver son état de mémoire et de disque lorsqu'il est suspendu.
AWS positionne ce service pour les agents de codage IA, les outils de développement interactifs, les plateformes d'analyse de données, les scanners de sécurité, les systèmes CI/CD et autres applications qui exécutent du code que l'opérateur de la plateforme n'a pas écrit.
Dès HostScoreDe son point de vue, cette annonce est plus significative qu'un simple lancement de nouvelles fonctionnalités de calcul AWS. Elle suggère que l'hébergement d'IA s'étend au-delà du simple déploiement de modèles et GPU capacité. À mesure que les agents d'IA commencent à exécuter du code, à utiliser des outils et à gérer des fichiers, l'environnement dans lequel ces actions se produisent devient une partie distincte de la pile d'hébergement.
Qu'a réellement annoncé AWS ?
Les microVM AWS Lambda fournissent des environnements d'exécution isolés que les développeurs peuvent créer autour d'utilisateurs, de tâches ou de sessions d'agents individuels.
Les développeurs empaquetent leur application et leur Dockerfile avant de demander à Lambda de créer une image MicroVM. AWS initialise l'application et capture un instantané de l'environnement préparé. Les nouvelles MicroVM sont ensuite lancées à partir de cet instantané, évitant ainsi de répéter l'intégralité du processus d'installation.
Chaque MicroVM reçoit son propre HTTPS Point de terminaison. AWS prend en charge les connexions HTTP/2, gRPC et WebSocket, permettant à l'environnement d'héberger des outils de développement interactifs, des services d'exécution de code et d'autres applications nécessitant une communication continue.
Une MicroVM peut également être mise en veille lorsqu'elle est inactive. AWS préserve l'état de sa mémoire et de son disque et le restaure dès que le trafic reprend ou que l'application demande une reprise. La durée de vie maximale configurable d'une MicroVM, incluant les périodes d'exécution et de mise en veille, est de huit heures.
AWS a annoncé Lambda MicroVM le 22 juin 2026 et a publié un article technique plus détaillé sur le lancement le 10 juillet. La version initiale est disponible en Virginie du Nord, dans l'Ohio, en Oregon, à Tokyo et en Irlande.
Lire Annonce de lancement d'AWS et Article de lancement technique AWS.
Les microVM Lambda étendent ainsi les fonctionnalités de Lambda au-delà d'une exécution ponctuelle basée sur des événements. Elles offrent un environnement plus durable qui préserve l'état de fonctionnement tandis qu'AWS gère la virtualisation, la mise en réseau, la suspension et l'arrêt.
Pourquoi les agents d'IA ont-ils besoin d'environnements d'exécution avec état ?
Les agents d'IA ont besoin d'environnements d'exécution avec état car leurs tâches peuvent impliquer plusieurs actions liées entre elles, effectuées au cours d'une session prolongée.
Un agent peut générer un script, installer un paquet, traiter un fichier, exécuter un navigateur, appeler une API, examiner le résultat, puis modifier son action suivante. Les fichiers, les dépendances et l'état de l'application créés lors des premières étapes peuvent être nécessaires ultérieurement.
Reconstruire l'environnement après chaque action engendrerait des retards et obligerait le système à recréer sans cesse l'état de fonctionnement de l'agent.
Le code généré par l'IA a besoin d'une limite d'isolation.
Le code généré par l'IA nécessite une limite d'isolation car la plateforme ne peut pas supposer que chaque commande se comportera comme prévu.
Un code incorrect ou manipulé pourrait permettre d'accéder à des fichiers sensibles, de divulguer des informations d'identification, de se connecter à des systèmes non autorisés ou de perturber le travail d'un autre utilisateur. Les microVM Lambda utilisent la virtualisation matérielle pour offrir à chaque session un environnement invité distinct, au lieu d'exécuter toutes les tâches au sein du même processus applicatif.
Toutefois, l'isolation au niveau de la machine virtuelle ne détermine pas ce que l'agent est autorisé à faire.
Prépublication de la revue de juillet 2026 «Agents d'IA cyber-capacités : vulnérabilités, évaluation, confinement et réponse défensive« par Abu Bakar Siddik (sourceCette étude examine la frontière entre les agents d'IA performants et les environnements qui les hébergent. Elle identifie les risques liés à l'exposition des identifiants, à l'accès persistant, aux conflits avec les restrictions du bac à sable et à la vitesse d'exécution des actions automatisées.
AWS recommande également aux développeurs de mettre à jour les informations d'identification et de valider les connexions réseau lors de la reprise d'une MicroVM. Les hooks de cycle de vie permettent aux applications de fermer les connexions avant la suspension, de rétablir les connexions approuvées après la reprise et de libérer les ressources avant l'arrêt.
Les microVM Lambda isolent l'environnement d'exécution. Les propriétaires d'applications doivent néanmoins restreindre l'accès aux outils, aux identifiants, aux fichiers, aux réseaux et aux services externes au sein de cet environnement.
La rétention d'État soutient le travail des agents en plusieurs étapes
La conservation de l'état permet à un agent de se mettre en pause sans perdre ses fichiers, sa mémoire, ses dépendances installées et ses résultats intermédiaires.
AWS crée chaque microVM à partir d'un instantané préparé. L'environnement reste actif pendant l'exécution de l'agent, se suspend après une période d'inactivité configurable et reprend lorsqu'une nouvelle requête arrive.
Ce modèle réduit les initialisations répétées, mais la reprise n'est pas instantanée dans tous les cas. AWS indique que la première requête après une suspension est soumise à un délai d'attente pendant que la plateforme restaure l'état de la mémoire et du disque et exécute le mécanisme de reprise de l'application. Des états sauvegardés plus volumineux et des processus de reprise plus complexes peuvent allonger ce délai.
La conservation de l'état permet également de préserver des éléments susceptibles de nécessiter une actualisation ou une suppression. Un environnement suspendu peut contenir des jetons d'authentification, des sessions de navigation, des scripts générés, des fichiers temporaires ou des connexions réseau obsolètes.
Le serverless avec état améliore donc la continuité des actions des agents, mais il nécessite une gestion du cycle de vie et des accès plus poussée qu'une fonction sans état jetable.
Les microVM avec état remplacent-elles l'hébergement traditionnel ?
Les microVM avec état ne remplacent pas l'hébergement traditionnel. Elles exécutent des tâches d'agent temporaires, tandis que les serveurs cloud, l'hébergement VPS, les serveurs dédiés et les systèmes bare metal continuent d'exécuter les services persistants associés à ces tâches.
SpecBox Démontre l'importance de la vitesse en mode bac à sable
Des recherches récentes suggèrent que la préparation du bac à sable peut avoir un impact significatif sur les performances des agents d'IA.
Le journal de juillet 2026 «SpecBoxPlanification spéculative en environnement sandbox pour un service d'agents LLM efficace"(sourceCette étude a examiné le compromis entre le lancement d'environnements de test à la demande et leur maintien en permanence actifs. Lancer un environnement uniquement lorsqu'un agent le demande peut engendrer des délais de démarrage à froid. Maintenir tous les environnements de test actifs réduit ces délais, mais consomme davantage de mémoire.
SpecBox Le système prédit l'environnement de test dont un agent pourrait avoir besoin pendant que le modèle de langage génère encore sa sortie. Il commence ensuite à préparer cet environnement avant même la fin de l'appel à l'outil.
Dans les tests des auteurs, SpecBox La latence de bout en bout P99 a été réduite jusqu'à 2.9 fois par rapport à une configuration de référence en environnement de test à la demande. La consommation de mémoire maximale a également été réduite de 45.9 % par rapport aux déploiements en environnement de test réservé en permanence (voir la capture d'écran ci-dessous).
SpecBox Il s'agit d'un prototype de recherche qui n'a pas testé les microVM AWS Lambda. Ses résultats montrent néanmoins pourquoi la vitesse de lancement, de reprise et de basculement en environnement de test peut devenir un indicateur pertinent pour l'hébergement d'IA.
Un jeûne GPU ne garantit pas un agent rapide lorsque l'environnement d'exécution retarde chaque appel d'outil.
L'hébergement persistant exécute toujours la plateforme d'IA
L'hébergement traditionnel gère les systèmes qui doivent rester disponibles avant, pendant et après chaque session d'agent temporaire. Ces systèmes persistants peuvent inclure des applications. APIs, bases de données relationnelles, stockage vectoriel, orchestration d'agents, files d'attente de messages, services de surveillance, passerelles de modèles et processus de longue durée. Dédié GPU L'infrastructure peut également exécuter des charges de travail soutenues d'inférence de modèles ou d'entraînement.
Atlantic.NetPar exemple, cette entreprise fournit l'infrastructure nécessaire à la persistance de l'architecture. Ses services actuels incluent des serveurs virtuels cloud, des serveurs dédiés, des systèmes bare metal, une infrastructure gérée et des solutions cloud ou dédiées. GPU hébergement. Le fournisseur d'hébergement propose actuellement les services suivants : NVIDIA Options L40S et H100 NVL pour les charges de travail d'IA, d'apprentissage automatique, d'inférence et de calcul accéléré.
Une plateforme d'IA pourrait utiliser des microVM avec état pour isoler l'exécution de code temporaire pendant l'exécution de son application, de sa base de données, de son stockage et de ses données privées. APIs, GPU charges de travail sur une infrastructure persistante à partir de Atlantic.Net ou un autre fournisseur de serveurs.
Ces modèles d'hébergement couvrent différentes parties d'une même architecture. Les microVM gèrent l'exécution par session, tandis que les VPS, les serveurs dédiés, les serveurs physiques et les serveurs physiques GPU Les serveurs prennent en charge les services qui doivent rester en ligne.
HostScore Conclusion : L’hébergement IA devient bien plus qu’un simple hébergement. GPUs
L'hébergement d'IA s'étend au-delà GPU Les spécifications, la prise en charge des modèles et la vitesse d'inférence sont des attributs qui déterminent toujours la capacité d'un fournisseur à exécuter des modèles exigeants. Cependant, les microVM AWS Lambda mettent en lumière un autre aspect de l'infrastructure : l'environnement dans lequel un agent d'IA exécute ses actions.
Lors de nos recherches récentes Meilleur hébergement IA et Meilleurs guides d'hébergement pour les programmes LLMNous avons constaté que les fournisseurs d'hébergement se différencient principalement par la disponibilité des accélérateurs, les modèles pris en charge, la flexibilité de déploiement, les services gérés et le contrôle de la pile logicielle.
L'annonce d'AWS laisse entendre que les environnements d'exécution pourraient devenir un autre point de différenciation.
Les fournisseurs d'infrastructures d'IA pourraient de plus en plus se faire concurrence sur la rapidité avec laquelle ils lancent des environnements sandbox, sur l'efficacité avec laquelle ils conservent l'état de travail, sur la force avec laquelle ils isolent les sessions et sur la rigueur avec laquelle ils contrôlent l'accès au réseau et aux outils.
Cela pourrait également modifier l'unité autour de laquelle les ressources d'hébergement sont allouées.
L'hébergement mutualisé répartit les ressources entre les utilisateurs d'un compte. L'hébergement VPS alloue un serveur virtuel. Les plateformes de conteneurs allouent des instances d'application. Les fonctions sans serveur allouent la puissance de calcul en fonction des requêtes ou des événements.
Les plateformes d'agents IA peuvent allouer une infrastructure autour d'une session d'agent. Une session d'agent démarre un environnement isolé, exécute des outils, modifie des fichiers, se met en pause, reprend son exécution et se termine une fois sa tâche accomplie. Ce modèle se situe entre les fonctions sans état éphémères et les serveurs virtuels fonctionnant en permanence.
Nous ne prévoyons pas que l'infrastructure de sessions d'agents remplace les catégories d'hébergement existantes. Elle deviendra plus probablement une couche supplémentaire au sein d'une architecture d'IA mixte.
Cloud persistant, VPS, serveur dédié et serveurs bare metal continuera d'héberger des services d'applications et de données. GPU L'infrastructure exécutera les charges de travail du modèle. Les microVM à état et autres technologies de sandbox géreront les actions temporaires des agents.
AWS signale un changement plus large dans l'infrastructure de l'IA
Les microVM AWS Lambda montrent que les agents d'IA créent une demande pour des environnements d'exécution isolés avec conservation d'état temporaire et contrôles du cycle de vie gérés par le fournisseur.
Le service ne propose pas de serveurs cloud, d'hébergement VPS, de serveurs dédiés, d'infrastructure bare metal, ni de GPU L'hébergement est obsolète. Ces systèmes continueront d'exécuter les bases de données, les applications, les services d'orchestration et les charges de travail de modélisation associées à chaque session d'agent.
Le changement le plus important concerne la manière dont l'hébergement d'IA peut être évalué.
GPU La capacité et la vitesse du modèle resteront des facteurs clés. Les fournisseurs d'hébergement pourront également se concurrencer sur la rapidité et la sécurité avec lesquelles ils lancent, suspendent, restaurent et arrêtent des environnements d'exécution isolés.
C’est là le signal d’hébergement le plus important derrière les microVM AWS Lambda.
