AWS lance AWS Emulator pour tester ses applications en local

AWS Emulator apporte l'API d'AWS sur votre ordinateur portable

AWS a présenté AWS Emulator sur son blog d'actualités, dans un article de Daniel Abib daté du 11 novembre 2026. Il s'agit d'un émulateur local des services Amazon Web Services, qui s'exécute sur la machine du développeur. L'interface en ligne de commande AWS CLI, les kits SDK d'AWS et les agents de programmation lui parlent par un point d'accès HTTPS local, avec les mêmes API que dans le nuage. Selon AWS, l'outil n'entraîne aucun frais de service supplémentaire : on ne paie que les ressources AWS réellement déployées. Le code source est publié sur GitHub. Sous Linux, l'installation se fait avec un paquet RPM ou Debian. Sous macOS et sous Windows, l'émulateur tourne dans Docker. AWS ne propose pas d'image toute prête : il faut la construire à partir d'un court Dockerfile fourni dans la documentation.

Le déroulement d'une exécution locale

La marche à suivre est simple. On installe le paquet, on lance la commande aws-emulator, puis on dirige les outils vers le point d'accès local. Au démarrage, l'émulateur génère ses propres identifiants, un fichier de configuration et un certificat, qu'il écrit dans ~/.aws/emulator/9297/. Il sert le HTTPS sur 127.0.0.1:9297, de sorte que seul votre ordinateur peut l'atteindre. On définit ensuite quelques variables d'environnement, comme AWS_ENDPOINT_URL, et l'on supprime toute variable qui pourrait fournir de vrais identifiants AWS. Le code de l'application ne change pas.

Les clés sont nouvelles à chaque démarrage. Les identifiants de clé d'accès commencent par EMULATOR, ce qui évite toute confusion avec de vraies clés, et l'émulateur refuse les requêtes signées avec d'autres clés. Il n'utilise qu'un seul compte, numéroté 000000000000. Dans la démonstration, l'auteur crée un compartiment S3 et y copie un objet. Il demande ensuite à l'agent Kiro de créer une table Amazon DynamoDB, d'écrire un élément puis de le relire, le tout contre le point d'accès local et non contre un vrai compte. Une suite de tests existante peut suivre le même chemin : lancer l'émulateur, définir les mêmes variables dans le script de test, puis exécuter les tests comme d'habitude.

Un mode intégré pour des tests rapides et isolés

Pour les tests, une seconde option existe. Le mode intégré permet de créer l'émulateur directement dans le processus de test et de le brancher sur le kit SDK par son client HTTP. Chaque instance intégrée garde son propre état : les tests ne partagent donc ni compartiments, ni tables, ni files d'attente, et peuvent s'exécuter en grand nombre en parallèle. Au lancement, ce mode n'est disponible que pour le kit AWS SDK for Rust, grâce à la bibliothèque aws-emulator-embedded. Quand l'émulateur tourne comme processus séparé, certains kits SDK demandent un réglage de plus pour faire confiance à son certificat. L'article cite le magasin de confiance du kit SDK pour Java. En tant que processus, il exige une signature SigV4 sur chaque requête et expose un point /__admin/health, afin qu'un script ou un conteneur attende qu'il soit prêt avant de lancer les tests.

Comment AWS mesure la fidélité

Un émulateur n'est utile que si un test réussi en local réussirait aussi sur AWS. C'est pourquoi AWS emploie des tests de fidélité. Chacun est un court programme qui exécute un scénario avec un kit SDK et vérifie le comportement d'AWS. Chaque test est d'abord validé contre le vrai AWS. Il n'est réussi que si l'émulateur correspond à AWS pour chaque réponse, y compris le code d'état, le corps, le code d'erreur exact et son message, ainsi que les ressources créées par le scénario. À chaque version, AWS publie un score par service sous la forme k sur n. L'ensemble des tests est public dans le dépôt aws-emulator-evaluation-suite, y compris ceux qui échouent encore. AWS prévient aussi qu'un score peut baisser quand de nouveaux tests s'ajoutent, même si l'émulateur progresse. Si une opération n'est pas encore implémentée, l'émulateur renvoie le code HTTP 501 : le test échoue aussitôt au lieu de réussir par hasard.

Une construction et une revue confiées à des agents

AWS affirme que des agents construisent et entretiennent l'émulateur à partir des modèles d'API d'AWS, avec Amazon Bedrock AgentCore Runtime Instances, AWS CodePipeline et AWS CodeCommit. Un premier groupe d'agents repère les écarts et ouvre un ticket pour chacun. Un second groupe écrit les tests, implémente le comportement et relit la modification. Un envoi déclenche ensuite le pipeline, qui exécute les tests de fidélité avant toute publication dans le dépôt public. Un agent de sécurité indépendant examine les changements de façon contradictoire, pendant la correction puis dans le pipeline de livraison. Ce sont les propres déclarations d'AWS sur son processus. L'article ne fournit aucun audit indépendant.

Les limites à prévoir

L'article est franc sur les limites. L'émulateur n'évalue pas les politiques IAM ni les politiques de ressources comme le fait AWS : une requête qu'AWS refuserait peut donc réussir en local. AWS demande de ne pas s'en servir pour vérifier la sécurité d'une application. Chaque émulateur agit comme un compte unique, sans comportement entre comptes ni entre régions. La proximité avec AWS varie selon le service et la fonctionnalité, il faut donc consulter les scores de fidélité des services utilisés. Par défaut, il envoie des données anonymes d'usage et d'erreur, que l'on peut désactiver. Un lecteur, dans un seul commentaire sous l'article, signale un certificat régénéré à chaque démarrage et un défaut dans le stockage des envois S3 signés par blocs depuis le kit .NET, entre autres problèmes. Ce sont des retours d'utilisateur non vérifiés de façon indépendante, et non des déclarations d'AWS. À traiter comme non confirmés tant qu'AWS n'a pas répondu.

Ce que cela change pour les développeurs

Pour les équipes qui testent aujourd'hui contre de vrais comptes AWS, un point d'accès local assez fidèle peut réduire le coût et l'attente, et offre aux agents de programmation un endroit sûr pour essayer et recommencer. Le prix à payer : un test vert en local ne prouve pas le comportement en production, surtout pour les règles de sécurité. Gardez les vrais identifiants hors des tâches de test et faites les vérifications finales sur AWS avant la mise en production.