1. Ce qu'est AWS Emulator — et pourquoi il fait soudainement parler de lui

AWS Emulator est un émulateur local des API AWS, publié sous licence CC0-1.0 (dédicace au domaine public) — le répertoire vendor/ est sous Apache-2.0. Vous le lancez sur votre machine, vous pointez l'AWS CLI ou un SDK AWS vers son point de terminaison local, puis vous exécutez votre code comme d'habitude — vos requêtes vont vers l'émulateur, pas vers AWS. Il n'y a ni interface graphique ni frais de service : vous ne payez que les ressources AWS réelles quand vous déployez sur AWS. Il est écrit en Rust, sert du HTTPS sur 127.0.0.1:9297 avec un certificat auto-signé, et couvre les API des services AWS qui ont un modèle dans le dépôt des modèles d'API AWS — plus de 200 services, selon AWS.

Les chiffres derrière l'engouement : le dépôt GitHub aws/aws-emulator affichait 4 450 étoiles quand nous l'avons consulté le 12 novembre 2026, et sa publication Hacker News a atteint 922 points et 254 commentaires. AWS ajoute un détail étonnant sur sa fabrication : des agents IA autonomes auraient écrit chaque ligne du code, sans relecture par ses ingénieurs — un agent de sécurité indépendant passe les modifications en revue à la place. Une affirmation pareille mérite un test réel plutôt qu'un résumé des articles des autres ; nous l'avons donc fait — sur notre propre machine, avec nos propres données de test.

2. Comment l'installer — les étapes exactes que nous avons suivies

Prérequis (d'après la documentation officielle) : Linux x86_64 ou aarch64 pour le paquet natif (macOS et Windows le lancent dans Docker), plus l'AWS CLI version 2.35.0 ou ultérieure pour dialoguer avec lui. Notre test a tourné sur Ubuntu 24.04 (x86_64) le 12 novembre 2026.

Étape 1 — Télécharger le paquet Debian depuis AWS. La page officielle « Getting started on Linux » donne exactement cette commande. Attention au nom de fichier : le paquet Debian s'appelle aws-emulator_amd64.deb — le nom aws-emulator-x86_64.deb n'existe pas (nous l'avons essayé : erreur 403). C'est le paquet RPM qui s'appelle aws-emulator-x86_64.rpm.

curl -fsSLo aws-emulator.deb https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest/aws-emulator_amd64.deb
sudo apt-get install -y ./aws-emulator.deb

Étape 2 — Vérifier la signature avant l'installation (facultatif, mais nous l'avons fait). AWS signe chaque paquet ; le fichier de signature se trouve à côté du paquet, avec .sig en plus. Nous l'avons téléchargé avec la clé de publication d'AWS, et l'empreinte correspondait exactement à celle de la documentation — 98BC F336 A3BE 53B7 34E9 67C5 2E5B F49B D940 F624 — et gpg --verify a répondu Good signature from "SSM Publishing <ssm-publishing@amazon.com>".

curl -fsSLO https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest/aws-emulator_amd64.deb.sig
curl -fsSLo aws-publishing.asc https://downloads.aws.com/keys/gpg/current.asc
gpg --import aws-publishing.asc
gpg --verify aws-emulator_amd64.deb.sig aws-emulator.deb

Étape 3 — Confirmer la version. Le paquet installe l'émulateur dans /opt/aws-emulator/ et ajoute la commande aws-emulator dans /usr/bin/. Le nôtre a affiché :

aws-emulator -v
# Version: 1.0.322
# Release date: 2026.11.10
# Commit: 7753983c6e495ec3612695b1336bf4936fc7b7fd

Notez la version : le canal de paquets LTS a servi la 1.0.322 alors que la page des versions GitHub listait déjà la v1.0.336 le même jour. Si vous avez besoin d'une version précise, la documentation a une page « Finding and installing a specific version » — ne supposez pas que « latest » signifie la plus récente.

Étape 4 — Installer l'AWS CLI v2 (nous n'en avions pas sur cette machine) avec l'installateur officiel :

curl -fsSLo awscliv2.zip https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip
unzip awscliv2.zip
sudo ./aws/install
aws --version
# aws-cli/2.40.1

Étape 5 — Démarrer l'émulateur et pointer le terminal vers lui. Nous l'avons démarré avec la télémétrie désactivée (voir la section sécurité — la télémétrie est activée par défaut). Il répondait aux vérifications de santé environ 2 secondes plus tard. Les variables d'environnement ci-dessous sont celles du billet officiel du blog AWS ; elles font utiliser à la CLI les identifiants générés par l'émulateur au lieu de vos vrais identifiants AWS — supprimez donc les vôtres d'abord.

aws-emulator --telemetry off
curl --cacert ~/.aws/emulator/9297/ca.pem https://127.0.0.1:9297/__admin/health
# ok

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_EC2_METADATA_DISABLED=true
export AWS_DISABLE_HOST_PREFIX_INJECTION=true
export AWS_REGION=us-east-1
export AWS_DEFAULT_REGION=us-east-1
export AWS_CA_BUNDLE=~/.aws/emulator/9297/ca.pem
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE

3. Notre test réel : S3, DynamoDB et SQS, pour de vrai

Objectif : la même boucle rapide que le billet officiel du blog — prouver que la CLI parle bien à l'ordinateur portable, stocker un fichier dans S3 et le relire octet pour octet, écrire puis relire un élément DynamoDB, et envoyer puis recevoir un message SQS. Chaque valeur ci-dessous est ce que l'émulateur lui-même a renvoyé, pas ce que nous avons tapé en supposant le résultat. Toutes les données de test sont les nôtres.

Vérification d'identité — parle-t-on vraiment à l'ordinateur portable ?

aws sts get-caller-identity
# {
#     "UserId": "AIDAH5I7GEMO7ADXNFAZU",
#     "Account": "000000000000",
#     "Arn": "arn:aws:iam::000000000000:user/emulator"
# }

L'émulateur utilise un seul compte, 000000000000, et génère de nouvelles clés à chaque démarrage — les identifiants commencent par EMULATOR, donc impossible de les confondre avec de vraies clés AWS, et il rejette les requêtes signées avec d'autres clés.

S3 — créer le compartiment, envoyer, lister, télécharger, comparer

echo "hello from the emulator" > hello.txt
aws s3 mb s3://local-getting-started
# make_bucket: local-getting-started
aws s3 cp hello.txt s3://local-getting-started/
# upload: ./hello.txt to s3://local-getting-started/hello.txt
aws s3 ls s3://local-getting-started/
# 2026-11-12 16:26:05         24 hello.txt
aws s3 cp s3://local-getting-started/hello.txt hello-back.txt
diff hello.txt hello-back.txt   # aucune différence — aller-retour S3 OK

DynamoDB — celle qui nous a piégés

aws dynamodb create-table --table-name kiro-demo \
  --attribute-definitions AttributeName=id,AttributeType=S \
  --key-schema AttributeName=id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST
# table: kiro-demo, status: CREATING
aws dynamodb put-item --table-name kiro-demo \
  --item '{"id": {"S": "item-1"}, "msg": {"S": "hello from kiro"}}'
# ERROR: ResourceNotFoundException — Requested resource not found

La table était encore CREATING quand nous avons écrit dedans, et l'écriture a échoué. Après environ 10 secondes, describe-table a indiqué ACTIVE — et alors le même put-item et le même get-item ont fonctionné, en relisant exactement ce que nous avions écrit :

aws dynamodb get-item --table-name kiro-demo --key '{"id": {"S": "item-1"}}'
# { "Item": { "id": {"S": "item-1"}, "msg": {"S": "hello from kiro"}} }

Leçon pour vos propres tests : attendez que la table devienne ACTIVE avant d'écrire. Interrogez describe-table en boucle dans votre script de test ; ne supposez pas que « créé » veut dire « prêt ».

SQS — envoyer, puis recevoir le même message

aws sqs create-queue --queue-name demo-queue
# queue: https://sqs.us-east-1.amazonaws.com/000000000000/demo-queue
aws sqs send-message --queue-url https://127.0.0.1:9297/000000000000/demo-queue \
  --message-body "test-message-42"
# msg id: cc18857c-a158-4c75-87a0-0df852c1df83
aws sqs receive-message --queue-url https://127.0.0.1:9297/000000000000/demo-queue
# received: test-message-42

Un échec délibéré — ce qui se passe sur un service non implémenté

La documentation dit qu'une opération que l'émulateur n'a pas encore implémentée renvoie HTTP 501 (Not Implemented), pour que vos tests échouent bruyamment au lieu de réussir en silence. Nous avons essayé Import/Export, qui n'a aucun modèle dans l'émulateur, et nous avons obtenu une erreur JSON au lieu d'un 501 net : {"__type":"UnknownService","message":"no emulated service is registered for 'ingestionservice'"}, que la CLI a signalée comme une réponse mal formée. L'échec reste bruyant — rien n'a réussi en silence — mais la forme de l'erreur ne correspond pas au 501 documenté. À savoir avant de le brancher dans votre CI : vérifiez l'échec lui-même, pas le texte exact de l'erreur.

Ce que nous avons vérifié	Résultat
Installation depuis le paquet Debian officiel, signature vérifiée	Réussi. L'empreinte GPG correspondait exactement à la documentation ; aws-emulator -v a affiché 1.0.322.
Démarrage et point de terminaison de santé	Réussi. Prêt en ~2 secondes ; /__admin/health a renvoyé ok.
L'identité STS est le compte local	Réussi. Compte 000000000000, utilisateur emulator.
S3 : créer le compartiment, envoyer, lister, télécharger, comparer octet pour octet	Réussi. Le fichier de 24 octets est revenu identique.
DynamoDB : créer la table, écrire un élément, le relire	Réussi, avec un piège. La table met ~10 secondes à devenir ACTIVE ; écrire pendant qu'elle est CREATING échoue avec ResourceNotFoundException.
SQS : créer la file, envoyer, recevoir	Réussi. test-message-42 reçu mot pour mot.
Un service non implémenté échoue bruyamment	Partiellement conforme à la documentation. L'échec a bien eu lieu, mais avec une erreur JSON UnknownService plutôt que le HTTP 501 documenté.

Notre verdict : la boucle principale est réelle — installer, démarrer, pointer la CLI vers votre ordinateur portable, et S3, DynamoDB et SQS se comportent comme la documentation le promet, avec une vraie particularité de timing sur la création de table DynamoDB. Pour un outil vieux d'un jour, c'est l'essentiel. Les aspérités sont honnêtes — voir la section suivante — pas cachées.

4. Ce qu'AWS Emulator ne fait pas (encore) — les limites, dites franchement

• Ne l'utilisez pas pour tester la sécurité. AWS le dit explicitement, et c'est important : l'émulateur n'évalue pas les politiques IAM ni les politiques basées sur les ressources comme AWS le fait, donc une requête qu'AWS refuserait peut réussir en local. Un test vert ici ne prouve pas que votre configuration de production est sûre.
• Ne l'utilisez pas pour des charges de production. Il sert uniquement à construire et à tester. Tout vit en mémoire — quand vous arrêtez l'émulateur, il supprime ses fichiers et toutes les ressources émulées disparaissent. (Nous l'avons confirmé : après l'arrêt, ~/.aws/emulator/9297/ était vide.)
• Les tables DynamoDB ne sont pas inscriptibles dès leur création. La création renvoie CREATING ; écrire trop tôt échoue avec ResourceNotFoundException. Attendez ACTIVE — environ 10 secondes dans notre test.
• La fidélité varie selon le service. AWS publie un score de fidélité par service à chaque version (k tests réussis sur n), et suit 6 545 écarts connus dans le répertoire issues/things-that-do-not-work/ du dépôt. Avant de vous appuyer sur un service, vérifiez son score — un test réussi sur un service ne dit rien d'un autre.
• Un seul compte, une seule région à la fois. Chaque émulateur est un compte unique (000000000000), sans comportement inter-comptes ni inter-régions.
• La télémétrie est activée par défaut. L'émulateur envoie des données d'usage anonymes à AWS sauf si vous la désactivez avec --telemetry off ou EMULATOR_TELEMETRY=off. Notre journal de démarrage a confirmé qu'elle était désactivée avec l'option.
• Les opérations non implémentées n'échouent pas toujours comme la documentation le dit. Nous avons vu une erreur JSON là où la documentation promet un HTTP 501. L'échec reste bruyant, mais ne vérifiez pas le texte exact de l'erreur.
• Ce que nous n'avons pas testé : Lambda, EC2, le mode embarqué (Rust), le chemin Docker, macOS/Windows, la compilation depuis les sources (le README dit qu'une compilation complète demande au moins 100 Go de disque pour target/), ni la compétence pour agent de codage IA. La documentation les couvre ; nous ne les revendiquons pas.

5. Sécurité — lisez ceci avant d'installer quoi que ce soit

• Utilisez uniquement les sources officielles : le dépôt GitHub aws/aws-emulator, l'hôte de paquets downloads.aws.com, et l'installateur de l'AWS CLI sur awscli.amazonaws.com. Nous avons vérifié la signature du paquet avec l'empreinte publiée dans la documentation AWS avant de l'installer.
• Vérifiez le paquet si vous l'installez. L'empreinte GPG doit être 98BC F336 A3BE 53B7 34E9 67C5 2E5B F49B D940 F624. Si elle diffère, n'installez pas le paquet.
• Gardez vos vrais identifiants hors de l'environnement de l'émulateur. Supprimez AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN et AWS_PROFILE avant de lancer les tests, et pointez la CLI vers le fichier d'identifiants généré par l'émulateur. L'émulateur rejette les requêtes signées avec d'autres clés, mais c'est l'habitude qui vous protège.
• Désactivez la télémétrie si vous n'en voulez pas. Elle est activée par défaut ; aws-emulator --telemetry off la désactive pour cette exécution.
• Par défaut, il n'écoute que sur votre propre machine (127.0.0.1:9297) et n'accepte que les requêtes signées avec ses propres clés fraîchement générées. N'exposez pas le port et ne partagez pas les identifiants générés.
• Ne testez que votre propre code et vos propres données. L'émulateur est un outil de test pour vos logiciels. Ne l'utilisez pas pour sonder les systèmes de quelqu'un d'autre, et ne testez pas vos réglages de sécurité ici — testez-les sur AWS avant la production.
• Gratuit veut dire gratuit ici. Pas de compte, pas de clé de licence, pas de frais de service ; AWS gagne son argent quand vous déployez. Le code est en CC0-1.0 (dédicace au domaine public), donc vous pouvez l'utiliser et l'expliquer librement.

6. FAQ

AWS Emulator est-il vraiment gratuit ?

Oui — pas de frais de service, pas de compte AWS, pas de clé de licence. AWS dit que vous ne payez que les ressources AWS quand vous déployez sur AWS. Le code source est en CC0-1.0, une dédicace au domaine public, donc il n'y a rien à acheter et aucun niveau payant à débloquer.

Faut-il un compte AWS ?

Non. L'émulateur génère ses propres identifiants et les écrit dans ~/.aws/emulator/9297/ au démarrage. Vos requêtes ne quittent jamais votre machine. Vous n'avez besoin d'un compte que quand vous déployez pour de vrai.

Est-ce un remplaçant de LocalStack ?

Il résout le même problème — tester du code AWS sans toucher à AWS — mais c'est l'émulateur officiel d'AWS elle-même, construit à partir des mêmes modèles d'API que les SDK, avec des scores de fidélité publiés par service et une liste publique des écarts connus. Qu'il remplace LocalStack pour vous dépend des services que vous utilisez : vérifiez le score de fidélité de vos services avant de changer. Nous n'avons testé que S3, DynamoDB et SQS.

Pourquoi mon put-item DynamoDB a-t-il échoué juste après create-table ?

Parce que la table était encore CREATING. Dans notre test, écrire juste après create-table a échoué avec ResourceNotFoundException, et la table est devenue ACTIVE environ 10 secondes plus tard — ensuite le même put-item a fonctionné. Attendez ACTIVE (interrogez describe-table en boucle) avant d'écrire.

Puis-je l'utiliser pour vérifier si mon application est sûre ?

Non — AWS est explicite à ce sujet. L'émulateur n'évalue pas les politiques IAM ni les politiques basées sur les ressources comme AWS le fait, donc une requête qu'AWS refuserait peut réussir en local. Testez vos réglages de sécurité sur AWS avant la production.

Que deviennent mes données de test quand je l'arrête ?

Elles disparaissent. L'émulateur garde tout en mémoire, et l'arrêter supprime ses fichiers et toutes les ressources émulées. Considérez chaque exécution comme un compte AWS frais et vide — c'est exactement ce qui le rend bon pour des tests répétables.

Envie d'un site construit avec des outils comme celui-ci ?

AWS Emulator est le genre d'outil gratuit et officiel que nous utilisons quand nous construisons des sites web pour les petites entreprises — pratique, sans abonnement, et il fait le travail promis. Découvrez notre service de création de sites web, ou parcourez nos outils gratuits — codes QR, factures, outils de couleur et plus, qui tournent tous localement dans votre navigateur.