AWS Emulator fait tourner les services AWS en local, mais ne valide pas vos politiques IAM
Le 11 novembre 2026, AWS met à disposition générale un émulateur local qui répond aux mêmes API que le cloud, écrit en Rust et maintenu par des agents d’IA. Adoptez-le pour votre boucle de développement, mais n’en déduisez rien sur la sécurité de vos politiques IAM.
11 novembre 2026. AWS met en disponibilité générale AWS Emulator, un émulateur local de ses services. 127.0.0.1:9297. C’est l’endpoint HTTPS sur lequel la CLI AWS, les SDK et vos agents de codage dialoguent avec lui, avec les mêmes API qu’en production. Écrit en Rust. Le binaire tient sur un portable sans peser sur le CPU. Pourquoi c’est important : pour la première fois, un développeur peut exécuter une vraie boucle de développement contre AWS — créer une table DynamoDB, écrire un objet S3, lire une file — sans déployer et sans attendre un aller-retour vers une région, tout en gardant son code applicatif inchangé.
Un émulateur qui parle le langage du cloud
Le principe est simple : vous installez l’émulateur, vous le démarrez, puis vous pointez vos outils vers l’endpoint local. Au démarrage, AWS Emulator génère ses propres identifiants, un fichier de configuration et un certificat, qu’il écrit dans ~/.aws/emulator/9297/. Il suffit ensuite de définir des variables d’environnement pour que le SDK parle à votre portable plutôt qu’à AWS.
export AWS_ENDPOINT_URL=https://127.0.0.1:9297
export AWS_SHARED_CREDENTIALS_FILE=~/.aws/emulator/9297/emulator_credentials
export AWS_CONFIG_FILE=~/.aws/emulator/9297/config
export AWS_REGION=us-east-1
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKENUne fois les variables en place, votre code applicatif ne change pas. Un test unitaire qui crée une table DynamoDB, y écrit un élément et le relit reste le même test — mais il s’exécute sur la machine, sans déploiement. Un agent de codage peut créer une ressource, vérifier le résultat et itérer à nouveau, sans attendre qu’un déploiement se propage dans une région.
Deux détails de conception rendent l’outil crédible pour un usage quotidien. D’abord, les identifiants générés portent le préfixe EMULATOR, impossible à confondre avec de vraies clés, et l’émulateur rejette toute requête signée avec une autre clé. Ensuite, il exige la signature SigV4, exactement comme AWS, et expose un endpoint __admin/health pour qu’un script ou un conteneur attende qu’il soit prêt avant de lancer les tests.
Un mode embarqué pour les tests parallèles
À côté du mode « processus local », l’émulateur propose un mode embarqué destiné aux suites de tests. Au lieu de dialoguer avec un serveur séparé, vous instanciez l’émulateur directement dans le processus de test et vous le câblez dans le SDK via son client HTTP. Chaque instance conserve son propre état — les tests ne partagent ni buckets, ni tables, ni files — et vous pouvez en exécuter beaucoup en parallèle. Le mode embarqué est disponible pour le SDK AWS pour Rust, via la crate aws-emulator-embedded à ajouter dans les dépendances de développement.
// Création d’une table, écriture puis relecture, entièrement en processus
let emulator = AwsEmulatorEmbedded::new(EmbeddedOptions::default());
let config = aws_config::defaults(aws_config::BehaviorVersion::latest())
.http_client(emulator.http_client())
.region(aws_config::Region::new("us-east-1"))
.credentials_provider(emulator.aws_credentials_provider())
.load()
.await;Pour un ingénieur qui maintient des tests d’intégration, c’est le vrai gain : des tests qui frappaient le cloud réel deviennent déterministes, rapides et gratuits, sans réécrire le code métier.
La question de la fidélité, traitée de front
Un émulateur ne vaut que si un test qui passe chez lui passerait aussi chez AWS. AWS aborde le sujet avec des tests de fidélité : des programmes courts qui exécutent un workflow via un SDK — stocker un objet, le relire, le supprimer — et qui vérifient le comportement attendu. Chaque test est validé contre le vrai AWS, et ne passe que si l’émulateur correspond au cloud sur chaque réponse : code de statut, corps, code et message d’erreur exacts, ainsi que les ressources créées.
À chaque version, AWS publie un score par service sous la forme k sur n — par exemple « 40 sur 50 » signifie que 40 des 50 tests de fidélité du service passent. La suite de tests est publique sur GitHub, y compris les tests qui échouent encore. Un score se lit comme un instantané d’un produit qui s’améliore. Quand l’émulateur n’implémente pas encore une opération, il renvoie un HTTP 501 — le test échoue tout de suite, sans faux positif.
Un outil maintenu par des agents d’IA
Le point le plus singulier est la chaîne de production. AWS Emulator est construit et maintenu par des agents à partir des modèles d’API AWS, en s’appuyant sur Amazon Bedrock AgentCore Runtime Instances, AWS CodePipeline et AWS CodeCommit. Un groupe d’agents cherche les écarts — en comparant les réponses de l’émulateur au vrai AWS et en confrontant son code aux modèles Smithy publiés — et ouvre une issue pour chaque écart. Un autre groupe récupère l’issue, écrit les tests, implémente le comportement et relit le changement. Le push déclenche un pipeline qui exécute les tests de fidélité avant publication sur le dépôt public.
La sécurité suit le même principe : parce que le code est écrit par des agents, un agent de sécurité indépendant relit chaque changement de façon contradictoire, pendant l’écriture puis une dernière fois dans le pipeline de release.
La limite qui change tout pour un SRE
Le passage le plus important de l’annonce est un avertissement, pas une fonctionnalité. L’émulateur n’évalue pas les politiques IAM ni les politiques basées sur les ressources comme le fait AWS. Concrètement, une requête qu’AWS refuserait peut réussir dans l’émulateur. Chaque instance agit comme un compte unique (000000000000), sans comportement inter-comptes ni inter-régions.
La conséquence est directe et vaut d’être écrite en gras : n’utilisez pas l’émulateur pour tester la sécurité de votre application. La fidélité mesurée porte sur la forme des API, pas sur le plan de contrôle des autorisations. Un pipeline qui « passe au vert » sur l’émulateur peut déployer une configuration qu’AWS rejettera — ou pire, une configuration qui passerait sur l’émulateur mais qu’AWS accepterait différemment. Gardez les vraies identifiants hors des environnements de test, et validez vos réglages de sécurité sur AWS avant la production.
Verdict
Si vous développez contre AWS ou si vous pilotez des agents de codage, adoptez AWS Emulator pour la boucle locale — création de ressources, tests d’intégration, itérations d’agents — c’est un gain réel de vitesse et de coût, et le mécanisme de fidélité public est honnête. Mais si votre objectif est de valider des politiques IAM, des service control policies ou des frontières de sécurité, restez sur AWS : l’émulateur ne remplace pas le plan de contrôle des autorisations, et l’utiliser comme oracle de sécurité produirait une fausse confiance. Pour les équipes qui testent le comportement applicatif, la règle est simple : émulateur pour la logique, cloud réel pour les autorisations.