Une petite boîte en carton sur un bureau en bois clair projette une longue ombre en forme de nuage.

AWS Emulator, l’émulateur local d’AWS écrit par des agents d’IA

Par Rédaction IP73 dans DevOps & Cloud le

AWS a publié le 11 novembre « AWS Emulator », un émulateur local gratuit et open source, écrit en Rust, qui reproduit sur la machine du développeur la plupart des API de ses services. Selon Simon Willison, le dépôt compte 29 684 commits en trois semaines, et ITmedia affirme que tout le code a été rédigé par des agents autonomes, sans relecture humaine.

Un faux AWS qui tourne chez soi

Le principe est simple. On démarre un programme local qui expose un point d’accès compatible avec les API d’AWS, on pointe la CLI ou un SDK dessus via des variables d’environnement, puis on exécute son code comme d’habitude. Les requêtes ne partent pas chez Amazon : elles s’adressent à des ressources simulées. Aucun compte AWS n’est requis, et l’outil ne s’accompagne d’aucun frais de service, précise le dépôt GitHub. On ne paie que les ressources réelles, au moment du déploiement. Tom « Spot » Callaway, stratège open source principal chez AWS, présente le projet à DevOps.com comme un moyen de construire et tester ses applications en local avant de les déployer dans le cloud.

Le dépôt décrit trois usages : la machine du développeur, un serveur de développement et l’intégration continue. Un mode « embarqué » est aussi proposé pour les projets Rust : l’émulateur s’ajoute comme dépendance de développement et tourne dans le processus de test, une instance isolée par test, sans URL de point d’accès ni certificat. Le test branche le client HTTP de l’émulateur directement dans le client du SDK.

L’installation dépend du système. Sous Linux, des paquets RPM et Debian sont fournis. Sous Windows et macOS, il faut passer par un conteneur Docker construit à partir d’un court Dockerfile. Simon Willison espère que cette contrainte disparaîtra : il aimerait pouvoir disposer d’un binaire unique à télécharger et à glisser dans une suite de tests, quel que soit le langage ou la plateforme. AWS propose par ailleurs une compétence à installer dans un assistant de code (via la commande aws agent-toolkit add-skill, qui exige la CLI AWS 2.35.0 ou plus récente) pour que l’agent configure l’émulateur à votre place.

Un développeur vu de dos travaille sur un ordinateur portable dans un bureau lumineux, un terminal flou à l'écran.

Du code écrit par des agents, et la fidélité mesurée

L’annonce d’AWS met en avant la quasi-totalité des services du catalogue, avec une fidélité mesurée par rapport au comportement réel d’AWS. Concrètement, chaque version publiée s’accompagne de scores de fidélité par service sur la page des releases. Les lacunes connues sont suivies dans un dossier du dépôt : ce qui ne fonctionne pas encore d’un côté, ce qui a été corrigé de l’autre.

C’est là que l’origine du code compte. Simon Willison parle d’« une énorme nuée d’agents », et renvoie à un billet invité de Swaminathan (Swami) Sivasubramanian sur le blog de Werner Vogels, qui raconte la genèse du projet. ITmedia va plus loin : aucun humain n’aurait relu le code. Ni le dépôt GitHub ni l’annonce d’AWS ne détaillent le processus de revue : ce dernier point reste, à ce stade, l’affirmation d’un média japonais.

Si elle se confirme, la démarche est audacieuse pour un émulateur dont la valeur tient à un seul critère : se comporter exactement comme le vrai service. Or la fidélité chiffrée publiée à chaque version joue ici le rôle de garde-fou. Faute de relecteur humain pour chaque ligne, c’est la comparaison avec AWS lui-même qui fait foi. Le dépôt est d’ailleurs structuré pour cela : une caisse (crate) Rust par service, un modèle Smithy qui pilote le protocole de communication, une opération par fichier, et des tests propres à chaque service. Une organisation qui se prête, on l’imagine, au travail en parallèle de nombreux agents.

Ce que cela coûte, et ce qu’on ne doit pas lui demander

Le gratuit a ses limites. Compiler depuis les sources, ou utiliser le mode embarqué, réclame une chaîne Rust, un compilateur C, une machine multicœur et au moins 100 Go d’espace disque pour le répertoire de build, puisque chaque service est une caisse à part et que le total grossit à chaque ajout. AWS recommande de partager un même dossier de build entre projets, de mettre en cache celui-ci en intégration continue (ou d’utiliser sccache) et de figer une version précise pour éviter les recompilations. La compilation depuis les sources est prise en charge sous Linux x86_64 et aarch64 seulement.

Mode Plateformes Ce qu’il faut
Paquet RPM ou Debian Linux Installer, lancer aws-emulator
Conteneur Docker Windows, macOS Un Dockerfile court
Mode embarqué Linux (build) Rust, C, environ 100 Go de disque

Le message d’AWS est sans ambiguïté sur le périmètre : l’outil sert à construire et tester, pas à faire tourner de la production ni à éprouver la sécurité. Lancé depuis les sources, l’émulateur sert en HTTPS sur 127.0.0.1, port 9297, avec un certificat auto-signé. Et puisque AWS exclut explicitement les tests de sécurité, valider ses règles d’accès sur l’émulateur pour les croire valables en production serait une erreur.

Télémétrie activée par défaut

Autre point à lire avant d’installer : l’émulateur envoie des données d’usage à AWS par défaut. AWS assure que la collecte est minimale, qu’elle ne permet d’identifier ni utilisateur, ni compte, ni organisation, qu’elle n’inclut jamais le contenu des requêtes, le code, les identifiants ou des données personnelles, et qu’elle n’est pas partagée avec des tiers. On la coupe avec l’option --telemetry off, la variable EMULATOR_TELEMETRY=off ou le fichier de configuration config.toml. Pour des équipes françaises soumises à des règles internes strictes sur les flux sortants, notamment en CI, mieux vaut désactiver cette option dès le premier lancement et le documenter.

Ce qui reste flou

L’annonce ne chiffre pas le nombre de services couverts, et il faut aller lire les scores publiés avec chaque version pour savoir lesquels se comportent vraiment comme sur AWS. Rien n’indique non plus si un binaire natif pour macOS et Windows est prévu. Quant à la question de fond, celle d’un outil de test dont le code serait né sans relecture humaine, elle ne trouvera de réponse que dans l’usage : les scores de chaque version et la liste des écarts connus seront à suivre de près ces prochaines semaines.

Sources

Partager :FacebookXLinkedInBlueskyE-mail

Articles récents

Prochains événements

Tous les événements →