AWS Lambda MicroVMs : le serverless gagne un sandbox isolé et stateful

Les AWS Lambda MicroVMs sont une nouvelle primitive de calcul serverless qui vous offre une isolation au niveau machine virtuelle, un démarrage quasi instantané à partir d'un snapshot et une exécution stateful que vous pouvez suspendre et reprendre. Elle s'appuie sur Firecracker, la même virtualisation légère qui sous-tend déjà plus de 15 000 milliards d'invocations Lambda par mois. En résumé : Lambda vient d'acquérir la capacité de confier à chaque session son propre sandbox dédié, isolé et durable, sans que vous ayez à gérer la moindre virtualisation vous-même.

Si vous avez déjà essayé d'exécuter en toute sécurité du code que votre propre application n'a pas écrit, de l'exécution de code multi-tenant, des notebooks interactifs, des scanners de vulnérabilités, vous savez déjà pourquoi cela compte. La réponse honnête jusqu'à présent était « lancez des conteneurs ou des VMs et construisez vous-même la tuyauterie d'orchestration, d'isolation et de cycle de vie ». Les MicroVMs ramènent tout cela à un appel d'API.

Ce qui est réellement nouveau

Les fonctions Lambda classiques sont stateless, à courte durée de vie et pilotées par événements. Elles sont excellentes pour cela. Elles sont aussi le mauvais outil dès que vous avez besoin d'une session qui vit pendant des minutes ou des heures, conserve un état en mémoire et isole du code non fiable au niveau du noyau. Les MicroVMs sont une primitive différente au sein du même service, visant précisément ce manque. AWS la présente comme trois capacités qu'aucun service de calcul AWS n'offrait ensemble avant aujourd'hui.

1. Isolation au niveau VM

Chaque session s'exécute dans sa propre MicroVM dédiée, sans noyau partagé ni ressources partagées entre les utilisateurs. C'est la garantie Firecracker : le code non fiable d'un tenant reste confiné à son propre environnement, sans aucun chemin vers d'autres environnements ni vers l'hôte. Les conteneurs partagent un noyau ; une MicroVM non. Pour exécuter du code que vous n'avez pas écrit, cette frontière est tout l'enjeu.

2. Démarrage et reprise rapides par snapshot

Le modèle est image-puis-lancement. Vous construisez une MicroVM Image à partir d'un Dockerfile et d'un artefact de code dans Amazon S3. Lambda exécute le Dockerfile, initialise votre application et prend un snapshot Firecracker de l'état mémoire et disque en cours d'exécution. Chaque MicroVM lancée à partir de cette image reprend depuis le snapshot pré-initialisé au lieu de démarrer à froid. Même une session interactive de plusieurs gigaoctets revient assez vite pour donner une impression de continuité. C'est l'idée de SnapStart poussée à sa conclusion logique : vous ne démarrez pas un processus, vous restaurez un processus en cours d'exécution.

3. Exécution stateful et suspendable

Une MicroVM en cours d'exécution conserve sa mémoire, son disque et ses processus tout au long de la session. Lorsqu'elle devient inactive, elle peut être suspendue avec son état intact, puis reprise quand le trafic revient. Les paquets installés, les données chargées et les fichiers de travail sont toujours là. Les MicroVMs supportent jusqu'à 8 heures d'exécution totale et se suspendent automatiquement après une fenêtre d'inactivité configurable. C'est la partie qui rompt l'ancienne hypothèse du serverless stateless, et c'est une bonne chose.

À quoi ressemble l'exploitation

Deux appels CLI portent l'essentiel du workflow. D'abord, construire l'image :

aws lambda-microvms create-microvm-image \
  --code-artifact uri=<path/to/s3/artifact.zip> \
  --name my-sandbox \
  --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
  --build-role-arn <build role ARN>

Les logs de build sont transmis à CloudWatch sous /aws/lambda/microvms/<image-name>, et l'image terminée apparaît avec son propre ARN et sa version. Ensuite, lancez une MicroVM à partir de celle-ci :

aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-sandbox \
  --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \
  --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'

Lambda retourne un identifiant unique de MicroVM et une URL d'endpoint dédiée, avec l'application déjà en cours d'exécution puisqu'elle a repris depuis le snapshot. Aucun réseau à configurer. La idle-policy est l'endroit où réside le contrôle du cycle de vie : combien de temps rester inactive avant de suspendre, combien de temps rester suspendue avant de terminer, et faut-il reprendre automatiquement à la requête suivante.

Où cela s'inscrit, et où non

Les MicroVMs ne remplacent pas les fonctions, et ce n'est pas un moyen bon marché de faire tourner un serveur 24/7. Le plafond de 8 heures et le modèle suspend-resume sont conçus pour des sessions : un sandbox de code qu'un utilisateur ouvre puis laisse, un scan qui tourne pendant dix minutes, une tâche analytique qui mouline pendant deux heures puis se tait. Si votre charge de travail est un service de longue durée constamment occupé, c'est toujours le terrain d'ECS ou d'EC2.

La mise en garde sur les snapshots à connaître

Parce que chaque MicroVM reprend depuis un snapshot pré-initialisé, tout ce que votre application fait pendant l'initialisation en supposant un état neuf peut vous surprendre. Les identifiants uniques générés au démarrage, les connexions réseau ouvertes au boot, les graines aléatoires ou les données éphémères chargées une seule fois peuvent tous être figés dans le snapshot et réutilisés d'un lancement à l'autre. C'est la même catégorie de piège que les utilisateurs de SnapStart connaissent déjà : si quelque chose doit être unique ou neuf par session, générez-le après la reprise, pas pendant l'init. AWS expose des hooks pour cela, et vous en aurez besoin pour tout ce qui est orienté connexion ou sensible à la sécurité.

Ce qu'il faut retenir

Les Lambda MicroVMs sont le signal le plus clair à ce jour que le serverless n'est plus condamné à être uniquement stateless et à courte durée de vie. Vous disposez désormais d'un sandbox Firecracker managé avec une vraie isolation, des démarrages à vitesse snapshot et un état suspend-resume, exposé sous la forme de deux appels d'API et d'une politique d'inactivité. Pour quiconque construit de l'exécution de code multi-tenant, cela supprime la partie la plus difficile et la moins différenciante du travail : la tuyauterie d'isolation et de cycle de vie. Construisez le produit, laissez Lambda gérer le parc de microVMs.

À lire ensuite

• AWS Monthly (Nov '25): The Stateful Serverless Revolution, pour la tendance de fond dans laquelle s'inscrivent les MicroVMs.
• Securing Docker Containers, sur la raison pour laquelle un noyau partagé est la frontière que les MicroVMs sont conçues pour supprimer.

Pour l'angle IA et agents sur ce même lancement, pourquoi les MicroVMs sont conçues pour exécuter du code généré par IA, consultez les notes de terrain sur ercan.ai. Pour du conseil sur AWS, le serverless et le travail de plateforme, ou simplement pour dire bonjour, commencez par ercanermis.com.