Si vous développez pour AWS, il y a de bonnes chances que LocalStack tourne déjà quelque part dans votre docker-compose ou votre CI. C'est un peu l'outil incontournable pour tester ses buckets S3 et ses fonctions Lambda sans avoir à toucher au vrai cloud. Sauf que depuis mars dernier, ses nouvelles versions exigent un compte LocalStack et un jeton d'authentification, CI comprise, et surtout l'édition Community n'est plus prise en charge.

Ouin !

Et comme si ça ne suffisait pas, l'offre gratuite qui reste interdit totalement l'usage commercial. Donc si vous l'utilisez dans le cadre de votre travail, faudra passer à la caisse. Alors, oui, ne pas respecter la licence ou se figer sur une ancienne image reste possible, mais déjà, ça ne se fait pas, et ensuite, niveau faille de sécu, ce n'est pas top.

Mais c'est là qu'arrive en sauveur Floci, un émulateur AWS local sous licence MIT qui se présente comme un remplaçant direct de LocalStack, sans avoir besoin de se créer un compte ou un jeton et surtout sans offre payante planquée dedans.

Maintenant, le principe reste le même puisque vous pointez dessus l'AWS CLI (Floci écoute sur le port 4566), vos SDK, Terraform, OpenTofu ou le CDK, avec la région de votre choix et des identifiants bidon, et vos commandes habituelles tomberont sur votre machine au lieu de partir chez Amazon.

Le plus simple pour démarrer, c'est sa CLI qu'on peut déployer avec Homebrew (il y a aussi un script pour Linux et un pour Windows) :

brew install floci-io/floci/floci
floci start
eval $(floci env)
aws s3 mb s3://my-bucket

Ensuite, faites un floci start pour lancer l'émulateur dans un conteneur et lui monter le socket Docker de votre machine. Floci s'appuie sur de vrais conteneurs dès que la fidélité l'exige ce qui fait que Lambda tourne dans l'image d'exécution officielle d'AWS, RDS lance un vrai PostgreSQL, MySQL ou MariaDB, ElastiCache un Valkey, et c'est pareil pour ECS, EC2 ou EKS.

J'ai fait l'essai sur mon Mac avec un bucket S3, une table DynamoDB et une petite fonction Lambda en Python, et tout a répondu du premier coup à la CLI AWS. La Lambda a juste mis six secondes à répondre au premier appel, puis moins d'une seconde au suivant.

Pour voir ce qui se passe ensuite, une console web est dispo localhost:4566/_floci/ui, avec vos ressources rangées par service.

La console web de Floci sur localhost, après un essai sur S3, DynamoDB et Lambda

Notez aussi que si vous venez de LocalStack, la bascule se résume simplement dans le nom de l'image puisque Floci traduit tout seul les variables d'environnement de LocalStack, exécute sans modification les scripts d'init rangés dans /etc/localstack/init/ et répond même sur /_localstack/health. Cela veut dire qu'une CI qui attend ce signal ne voit pas la différence et ça c'est super cool pour migrer vite fait bien fait.

Et si vos scripts appellent aws ou boto3, prenez l'image floci/floci:latest-compat, qui embarque les deux.

Par contre, méfiez-vous du volume de données, car LocalStack range tout par défaut dans /var/lib/localstack et Floci dans /app/data. Donc dans le docker compose, pointez bien votre volume sur /app/data sinon, vous perdrez vos fichiers au premier restart du docker.

Après n'oubliez pas non plus que Floci imite le comportement d'AWS, et pas sa sécurité. En effet, par défaut, il n'applique aucune politique IAM, donc si vous voulez vérifier qu'un rôle trop resserré bloque bien une action, il faudra activer la variable FLOCI_SERVICES_IAM_ENFORCEMENT_ENABLED. Et certains services ne sont également que des façades. Par exemple Bedrock Runtime renvoie des réponses factices et Transcribe termine ses tâches aussitôt, sans jamais traiter l'audio, donc oui, votre code peut les appeler, mais le résultat ne sera pas au rendez-vous, ce qui est tout à fait normal.

Pour le reste, les données sont stockées en mémoire par défaut et s'effaceront à l'arrêt, ce qui est pile poil ce qu'on veut en CI. Vous pouvez quand même le paramétrer pour que ça s'écrive sur le disque si vous voulez...

Voilà, à essayer sur une branche de votre CI si vous voulez vous débarrasser de débrancher LocalStack pour de bon !

Source : Floci sur GitHub

AWS a-t-il ouvert le back-end d’AgentCore Runtime ?

Le lancement des microVM Lambda a poussé certains à faire le rapprochement. Il faut dire que les workloads agentiques apparaissent comme la principale cible de cette offre.

On y retrouve la technologie de virtualisation Firecracker, associée à SnapStart (utilisation d’instantanés pour éviter le démarrage à froid). En revanche, là où les fonctions Lambda « traditionnelles » se destinent aux applications pilotées par les événements et ont une durée d’exécution maximale de 15 minutes*, les microVM peuvent tourner jusqu’à 8 heures et ne nécessitent pas de gestionnaire de fonction (méthode qui traite les événements). Elles procurent par ailleurs des capacités spécifiques (accès shell, montage de systèmes de fichiers, installation de paquets…), par défaut sur le fondement d’une image de base Amazon Linux.

On package le code de l’application avec un Dockerfile que Lambda exécute. Une fois l’environnement initialisé, il capture un snapshot qui sert ensuite à lancer les microVM. Chacune a son point de terminaison public avec authentification JWE, gérant HTTP/1.1, HTTP/2, WebSockets, gRPC et SSE.

AWS propose 5 configurations de base allant de 0,5 Go de mémoire et 0,25 vCPU à 8 Go et 4 vCPU. Chacune peut scaler jusqu’à 4x, moyennant une facturation supplémentaire à la seconde. On peut les suspendre en cas d’inactivité – avec conservation de l’état de la mémoire et du disque – et reprendre automatiquement en cas de trafic entrant. Pendant cette période, on ne paye que pour le stockage du snapshot.

Un déploiement de référence pour Claude Managed Agents

Les microVM Lambda ciblent les applications multilocataires où chaque utilisateur a besoin d’un environnement dédié pour exécuter du code tiers. Parmi elles, les scanners de vulnérabilités, les plates-formes d’analyse de données, les outils CI/CD et les serveurs de jeux qui exécutent des scripts fournis par le joueur. Mais aussi les sandbox IA.

AWS propose un déploiement de référence pour Claude Managed Agents. L’orchestration (modèle et harnais agentique) reste chez Anthropic, tandis que les outils s’exécutent dans des microVM (une par session Claude). Le seul trafic entrant est l’appel webhook. Le reste du workflow est en pull.

ClickHouse associe les microVM Lambda à son moteur chDB

En plus des variables d’environnement définies à la création des images, on peut transmettre des paramètres de configuration à une VM donnée, lors de l’exécution.

Les microVM Lambda sont pour le moment disponibles dans une poignée de régions AWS, dont une en Europe (Irlande), sur ARM64. ClickHouse fait partie des entreprises à les avoir déjà mises en œuvre, pour porter divers cas d’usage de son moteur analytique « in-process » chDB. Entre autres :

• Requêtes fédérées joignant données locales, S3, CDN et Postgres
• Exécuteurs CI/CD isolés
• Sandbox à la demande pour reproduire des bugs
• Mémoire locale pour chaque session agentique

* Hors « fonctions durables », dont l’exécution peut s’étaler sur 1 an, à renfort de checkpoints et de replays. Une option introduite en 2025.

Illustration principale © Aryan – Adobe Stock

The post Dopé aux microVM, Lambda se rapproche d’AgentCore appeared first on Silicon.fr.