AWS publie un émulateur local de ses API, sans compte ni facture

Tester du code qui parle à AWS a longtemps supposé un compte, des identifiants et une petite angoisse au moment de la facture. Le dépôt GitHub d’AWS Emulator, relayé sur Hacker News le 11 novembre 2026, propose autre chose : un émulateur local des API d’AWS, publié sous la bannière d’AWS, à lancer sur votre poste, sur un serveur de développement ou en intégration continue.

Un point d’accès AWS qui ne quitte pas votre machine

Le principe tient en une phrase : vos requêtes partent vers l’émulateur, pas vers AWS, et vous manipulez des ressources émulées. Le README précise qu’aucun compte AWS n’est nécessaire et que l’outil n’entraîne pas de frais de service supplémentaires. Vous ne payez que les ressources réellement déployées chez AWS.

N’attendez pas de console : il n’y a aucune interface graphique. L’émulateur sert un point d’accès et, une fois lancé, quelques variables d’environnement suffisent à y diriger l’AWS CLI ou un SDK. Votre code tourne ensuite comme d’habitude. Par défaut, il écoute en HTTPS sur 127.0.0.1:9297, avec un certificat auto-signé.

Trois façons de le lancer, dont une par agent

Le mode serveur est le plus classique. Sous Linux, il s’installe par paquet RPM ou Debian. Sous Windows et macOS, il passe par un conteneur construit à partir d’un court Dockerfile.

Le mode embarqué vise les tests écrits en Rust : l’émulateur s’ajoute en dépendance de développement et tourne dans le processus, avec une instance isolée par test. Il n’y a alors ni URL, ni certificat, ni variable à régler, puisque le client HTTP de l’émulateur se branche directement dans le SDK.

La troisième voie est dans l’air du temps : le README propose d’installer une compétence aws-emulator pour un agent de code, puis de lui demander de tout configurer. Il faut pour cela l’AWS CLI en version 2.35.0 ou ultérieure.

Cent gigaoctets pour un cloud de poche

Le dépôt est un espace de travail Cargo qui compte un crate par service AWS, chacun piloté par son modèle Smithy, avec un fichier par opération et un état gardé en mémoire. Cette architecture soignée a un prix. Compiler depuis les sources, ce qui n’est pris en charge que sous Linux (x86_64 et aarch64), demande au moins 100 Go d’espace disque libre pour le répertoire target/, un chiffre appelé à grossir avec le nombre de services.

Le mode embarqué hérite de la note, car il compile l’émulateur dans votre binaire de test. Le premier cargo test construit donc les crates de service en plus de votre code. AWS recommande de partager un même CARGO_TARGET_DIR entre projets, de mettre target/ en cache en intégration continue et de figer l’émulateur sur un commit de version.

Ce que l’émulateur ne prétend pas faire

Le README pose ses limites sans détour. L’outil sert à construire et à tester : il ne doit être utilisé ni pour de la production, ni pour tester la sécurité. Il ne détaille pas non plus la liste des services couverts. Il renvoie à des scores de fidélité publiés avec chaque version, service par service, et à un répertoire issues/ où les comportements absents sont rangés dans things-that-do-not-work/, avant de migrer vers things-that-now-work/ une fois corrigés.

Dernier détail à connaître avant de lancer le binaire : la télémétrie est activée par défaut et remonte des données d’usage à AWS.

Vous pouvez donc désormais faire tourner un cloud entier sans carte bancaire. Il faudra simplement lui offrir un disque dur.