AWS Emulator: AWS en local, sin cuenta y con tu agente de IA

Le pides a tu agente que monte una cola en SQS, un bucket en S3 y una tabla en DynamoDB para probar una idea.

Y lo primero que te pregunta es por tus credenciales de AWS.

Ahí se para todo. Porque no quieres darle a un agente las llaves de una cuenta con tarjeta de crédito detrás. Y porque, para probar una idea de tarde, crear una cuenta, configurar IAM y vigilar la factura es demasiado peaje.

AWS Emulator quita ese peaje. Es un emulador oficial de las APIs de AWS que se ejecuta en tu máquina: la CLI y los SDK le hablan como si fuera AWS, pero ninguna llamada sale de tu portátil. Y viene con una skill para agentes, aws-emulator, que lo instala, lo arranca, configura tu proyecto y te dice qué partes de tu código puedes fiar al emulador.

En este artículo vas a encontrar:

• Qué es AWS Emulator y qué lo diferencia de otras formas de “AWS en local”
• Cómo instalarlo en Linux y con Docker (macOS y Windows), y cómo apuntar la CLI y el SDK
• Qué hace la skill aws-emulator y cómo instalarla para Claude Code, Kiro o Cursor
• Los límites que importan: memoria, IAM, fidelidad por operación
• Cinco prompts sencillos para que tu agente construya mini-proyectos que lo aprovechen

¿Qué es AWS Emulator? ¶

AWS Emulator es un emulador local de las APIs de AWS, publicado por la propia AWS, para probar software sin llamar a AWS. Así lo resume el README del repositorio: sirve un endpoint de API en local, sin interfaz gráfica, no necesita cuenta y no tiene coste de servicio.

La guía oficial le asigna tres usos:

1. Pruebas locales de código que usa servicios de AWS.
2. CI/CD, para que los tests de integración no dependan de una cuenta real.
3. Prototipos con agentes de IA, que pueden crear y romper recursos sin riesgo económico.

Ese tercer punto es el que más me interesa. Hasta ahora, dejar a un agente “jugar” con infraestructura de AWS significaba darle credenciales reales o montarle un sandbox con presupuestos y alarmas. Con el emulador, lo peor que puede pasar es que tengas que reiniciar un proceso.

Algunos datos para situarte:

• El repositorio acumula más de 3.400 estrellas y casi 30.000 commits en GitHub, y la guía dice que se actualiza “muchas veces al día”. La última versión cuando escribo esto es la v1.0.322.
• La licencia es CC0-1.0 (dominio público), salvo la carpeta vendor/, que va con Apache-2.0.
• No acepta pull requests. Los fallos se reportan como issues, y el repo mantiene dos carpetas curiosas: issues/things-that-do-not-work/ e issues/things-that-now-work/.
• El ámbito declarado es ambicioso: soporta las APIs de los servicios que tienen modelo publicado en el repositorio de modelos de API de AWS en GitHub. La documentación y las notas de versión mencionan S3, DynamoDB, Lambda, CloudFormation, EC2, Step Functions, Cloud Map o CloudWatch Logs, entre muchos otros.

🔑 Soportar una API no significa reproducirla al cien por cien. AWS mide cuánto se parece cada operación a la real con pruebas de fidelidad, y esa es la parte que de verdad tienes que mirar antes de fiarte. Lo vemos más abajo.

Curso gratis por email

Si aws-emulator te convence, aprende a instalar skills y a crear la tuya

Un minicurso por email, a tu ritmo, para dejar de repetirle lo mismo a tu agente: instalas skills y acabas con una propia.

Apúntate al minicurso →

¿Cómo se instala AWS Emulator? ¶

Depende de tu sistema. En Linux se instala como paquete RPM o Debian; en macOS y Windows se ejecuta en Docker, construyendo tú la imagen con un Dockerfile corto. Compilarlo desde el código en Rust es posible, pero el README avisa de que necesitas al menos 100 GB libres para la carpeta target/. Para el día a día, olvídate de esa vía.

En Linux (RPM o Debian) ¶

Para distribuciones basadas en RPM (Fedora, RHEL, Amazon Linux 2023) en x86_64:

sudo dnf install -y https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest/aws-emulator-x86_64.rpm

Para Debian o Ubuntu en amd64:

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

Si tu máquina es ARM, cambia el sufijo por aarch64.rpm o arm64.deb. En Amazon Linux 2, usa yum en lugar de dnf.

Comprueba la versión y arráncalo:

aws-emulator -v
aws-emulator

Se queda escuchando en https://127.0.0.1:9297 con un certificado autofirmado. Lo paras con Ctrl+C. Si ese puerto está ocupado, aws-emulator -p 0 deja que el sistema elija uno y lo verás en el log de arranque.

En reposo consume unos 160 MiB de memoria, y crece según los recursos que crees.

En macOS y Windows (Docker) ¶

No busques la imagen en Docker Hub: AWS no publica una imagen ya construida. La documentación te da el Dockerfile y la construyes tú:

FROM public.ecr.aws/amazonlinux/amazonlinux:2023-minimalADD https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest/aws-emulator-x86_64.rpm /tmp/aws-emulator.rpmRUN rpm -i /tmp/aws-emulator.rpm && rm /tmp/aws-emulator.rpm \    && mkdir -p /home/emulator && chown 1000 /home/emulatorUSER 1000ENV HOME=/home/emulatorEXPOSE 9297ENTRYPOINT ["aws-emulator", "-b", "0.0.0.0"]

En un Mac con Apple Silicon, cambia aws-emulator-x86_64.rpm por aws-emulator-aarch64.rpm en la línea ADD.

Construye la imagen, crea la carpeta compartida y arranca el contenedor:

docker build -t aws-emulator .

mkdir -p ~/.aws/emulator

PORT=9297
docker run --rm --memory=2g --memory-swap=2g -p 127.0.0.1:$PORT:$PORT \
  -e HOME="$HOME" -v "$HOME/.aws/emulator:$HOME/.aws/emulator" \
  aws-emulator -p $PORT

El volumen no es decorativo. El emulador escribe en ~/.aws/emulator/<puerto>/ las credenciales, la configuración y el certificado que necesitan la CLI y el SDK, y así quedan en tu máquina.

⚠️ Fíjate en el -p 127.0.0.1:9297:9297. La documentación insiste en no usar la forma corta -p 9297:9297, porque expone el emulador a toda tu red. Un AWS de mentira con la puerta abierta sigue siendo una puerta abierta.

¿Cómo apunto la AWS CLI y el SDK al emulador? ¶

Con variables de entorno. Cada vez que arranca, el emulador genera claves de acceso nuevas y deja en ~/.aws/emulator/9297/ tres ficheros: emulator_credentials, config y ca.pem. Solo tienes que decirle a la CLI dónde están y a qué endpoint hablar:

export AWS_ENDPOINT_URL=https://127.0.0.1:9297export AWS_SHARED_CREDENTIALS_FILE=~/.aws/emulator/9297/emulator_credentialsexport AWS_CONFIG_FILE=~/.aws/emulator/9297/configexport AWS_CA_BUNDLE=~/.aws/emulator/9297/ca.pemexport AWS_EC2_METADATA_DISABLED=trueexport AWS_DISABLE_HOST_PREFIX_INJECTION=trueexport AWS_REGION=us-east-1export AWS_DEFAULT_REGION=us-east-1# muy importante: que no se cuele tu cuenta realunset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE

Ese unset final es el que te salva de un susto. Si tienes un perfil real configurado, mejor que no esté a mano mientras pruebas.

Para comprobar que hablas con el emulador y no con AWS:

aws sts get-caller-identity

Te devolverá la cuenta 000000000000 y el ARN arn:aws:iam::000000000000:user/emulator. Si ves ese montón de ceros, estás en casa. También hay un endpoint de salud:

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

Y en tu código, ¿qué cambia? ¶

Casi nada, que es lo bonito. Los SDK leen AWS_ENDPOINT_URL y las demás variables, así que tu código no necesita saber que habla con un emulador. Lo que sí cambia es cómo confía cada SDK en el certificado autofirmado, según la guía para apuntar el SDK:

Si usas Node.js, que es lo habitual por aquí, el arranque queda así:

export NODE_EXTRA_CA_CERTS=~/.aws/emulator/9297/ca.pem
node src/worker.js

Y el cliente se crea como siempre:

import { S3Client } from "@aws-sdk/client-s3";import { SQSClient } from "@aws-sdk/client-sqs";import { DynamoDBClient } from "@aws-sdk/client-dynamodb";// El endpoint, la región y las credenciales salen de las variables de entorno.// El mismo código funciona contra el emulador y contra AWS real.export const s3 = new S3Client({});export const sqs = new SQSClient({});export const dynamo = new DynamoDBClient({});

Dos detalles más de la documentación. Para algunas operaciones que añaden un prefijo al host (Step Functions StartSyncExecution, Cloud Map DiscoverInstances, CloudWatch Logs StartLiveTail), en JavaScript crea el cliente con disableHostPrefix: true. Y usa 127.0.0.1, no localhost: con una IP, el SDK pone el nombre del bucket en la ruta; con localhost, los SDK de JavaScript, Java y Go intentan meterlo en el nombre de host.

¿Qué hace la skill aws-emulator? ¶

Hasta aquí, todo lo puedes hacer a mano. La gracia está en que no tienes que hacerlo tú. La skill aws-emulator forma parte del Agent Toolkit for AWS y le enseña a tu agente a:

1. Instalar el emulador con el paquete de Linux o con Docker, según tu sistema.
2. Arrancarlo y apuntar la CLI o el SDK de tu proyecto.
3. Arreglar los errores típicos de conexión, certificado y firma de peticiones.
4. Comprobar si tu proyecto va a funcionar: busca las operaciones de AWS que usa tu código y las contrasta con las pruebas de fidelidad y sus puntuaciones.

Si nunca has trabajado con skills, aquí tienes en qué se diferencian de los prompts, los MCP y los subagentes. La versión corta es que son instrucciones empaquetadas que el agente carga solo cuando la tarea las necesita.

Según su propio SKILL.md, esta solo trae documentos (references/*.md), ningún script. Y antes de escribir fuera de su carpeta de trabajo, por ejemplo usar sudo o tocar tu perfil de shell, te pide permiso. Eso es lo que esperas de una herramienta que instala software en tu máquina.

El cuarto punto es el que más valor tiene. Según la página Check your project, la skill te dice en qué partes puedes confiar en el emulador y cuáles “podrían comportarse distinto que AWS”. Y si encuentra una diferencia, puede redactar un issue para el repositorio, enseñándote el borrador antes de publicar nada.

¿Cómo se instala la skill? ¶

La vía oficial pide AWS CLI 2.35.0 o posterior. Comprueba tu versión:

aws --version

E instala la skill:

aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1

Ese comando la instala para todos los agentes que la CLI encuentra en tu máquina: la documentación cita Kiro, Cursor y Claude Code.

Si prefieres el instalador universal de skills, skills.sh ofrece esta alternativa:

npx skills add https://github.com/aws/agent-toolkit-for-aws --skill aws-emulator

Después, ya en tu agente, basta con una frase:

Install AWS Emulator and point my project at it.

O, en castellano, “instala AWS Emulator y apunta mi proyecto a él”. Si quieres la otra mitad del valor, la pregunta es esta: “¿Funcionará la app de este repo en AWS Emulator?”.

Si te mueves con Claude Code y quieres ver qué otras skills merecen un hueco, tengo una selección de las 10 mejores skills para Claude Code aplicadas a metodologías de agentes.

¿Qué son las pruebas de fidelidad y por qué importan? ¶

Las pruebas de fidelidad son tests de comportamiento que comparan lo que hace el emulador con lo que hace AWS de verdad. Viven en un repositorio aparte, aws-emulator-evaluation-suite, y cada una es un script de Python con boto3 que crea recursos, llama a una operación y comprueba el estado resultante, el código de error y el mensaje.

Según el README, cada prueba se verificó contra al menos dos cuentas de AWS reales en sandbox. Alguien vio a AWS responder así antes de escribir la aserción.

Con esas pruebas, AWS calcula una puntuación de fidelidad por servicio: cuántas pruebas pasa el emulador del total, del tipo “40 de 50”. Las publica con cada versión en la página de releases. Ojo: en varias versiones recientes la nota dice “Scores are not available for this release”, así que revisa la versión que de verdad vas a usar.

Y una frase de la guía de fidelidad que conviene tatuarse:

💡 “Hoy, el emulador se parece más a AWS en las APIs de plano de control.” Es decir, crear, listar, configurar y borrar recursos va mejor que las operaciones de datos, y el soporte del plano de datos y de la infraestructura como código varía según el servicio.

Traducido a tu día a día: crear una cola SQS es terreno seguro; el comportamiento fino de la visibilidad de mensajes o de un reintento hay que comprobarlo. Cuando una operación no está implementada, el emulador responde HTTP 501 con el código NotImplemented, así que al menos falla con claridad.

Puedes ejecutar tú mismo una prueba concreta. Necesitas uv y el emulador instalado:

uv sync --locked --extra checks
home=$(mktemp -d); HOME=$home aws-emulator -p 4566 & pid=$!
until curl -sk -o /dev/null https://127.0.0.1:4566; do sleep 1; done
uv run fidelity-tests-runner run behavioral/dynamodb/check_update_item_set_list_preserves_element_order.py \
  --endpoint https://127.0.0.1:4566 --emulator-home "$home" --report report.json
kill $pid; wait $pid

Ese bloque es del propio README de la suite. Arranca un emulador limpio en un HOME temporal, ejecuta una prueba de DynamoDB y guarda el informe. El ejecutor devuelve 0 si pasa, 11 si falla la aserción y 12 si hay error.

🛡️ Si una operación que necesitas no tiene prueba de fidelidad, la documentación es honesta: puede que el emulador la haga bien, pero nadie lo ha confirmado. En ese caso, escribe tu propio test y ejecútalo contra el emulador y contra una cuenta de prueba.

¿Qué límites tiene AWS Emulator? ¶

Los límites son pocos, pero cambian cómo planteas un proyecto. Todos salen de la documentación oficial:

El de IAM es el que más gente va a pisar. Si tu test comprueba que un rol no puede leer un bucket, el emulador te dirá que sí puede, y te dará un verde que no vale nada. La seguridad, en otro sitio.

Y un detalle de privacidad: la telemetría viene activada por defecto. Se desactiva con aws-emulator --telemetry off, con la variable EMULATOR_TELEMETRY=off o con enabled = false en la sección [telemetry] de ~/.aws/emulator/config.toml.

¿Cómo se monta un proyecto real con el emulador y un agente? ¶

Con el emulador y la skill juntas tres cosas que hasta ahora iban por separado:

1. AWS sin AWS: desarrollas contra servicios emulados, sin credenciales reales ni factura.
2. Infraestructura gestionada por el agente: Claude Code, Codex, OpenCode o Kiro preparan los recursos y comprueban que responden.
3. Una aplicación de verdad: un producto pequeño que obliga a coordinar varios servicios, no un “hola mundo” con un bucket.

La pieza que lo hace posible es la combinación de la skill con un script de inicialización. Como todo vive en memoria, cada vez que arrancas el emulador tienes un AWS vacío. Así que el primer encargo para el agente siempre es el mismo: un scripts/seed.sh (o seed.ts) que cree buckets, colas y tablas, y un test que compruebe que existen.

Eso tiene un efecto secundario muy sano. Tu infraestructura queda descrita en código desde el minuto uno, porque no hay otra forma de que sobreviva al reinicio.

Una recomendación de arquitectura que vas a ver repetida en los prompts: si el flujo pasa por Lambda, plantéate usar workers de Node.js normales que consumen mensajes de SQS. Funcionan igual en local y no dependen de lo completa que esté la emulación de Lambda en tu versión. Cuando lo lleves a AWS, convertirlos en Lambdas es un cambio acotado.

Guía premium

Antes de soltar al agente, elige la frase que te suena y llévate su prompt

Probarlo →

Cinco prompts para mini-proyectos que aprovechan el emulador ¶

Todos parten de lo mismo: tienes la skill instalada y un repositorio vacío o casi vacío. Están pensados para que el agente haga el trabajo y tú revises. Cópialos, cambia el stack si quieres y lánzalos.

Hay un párrafo que repito en todos a propósito. Es la red de seguridad:

Reglas: usa la skill aws-emulator. No uses credenciales reales ni despliegues nada en AWS.
Antes de implementar, comprueba qué operaciones de AWS necesita el proyecto y contrástalas
con las pruebas de fidelidad. No asumas que una API está implementada sin probarla.
Documenta en LIMITACIONES.md lo que no funcione y la alternativa local que hayas usado.

1. La fábrica de archivos (S3 + SQS + DynamoDB) ¶

El más completo y mi favorito. Subes archivos, se encolan trabajos, unos workers los procesan y puedes consultar el estado de cada uno.

Construye una app de procesamiento asíncrono de documentos con Node.js, TypeScript y React,
usando AWS Emulator para toda la infraestructura.

- S3: bucket "entrada" para originales y bucket "salida" para resultados.
- SQS: cola "trabajos" con una cola de mensajes fallidos (DLQ).
- DynamoDB: tabla "estados" con el estado de cada trabajo (pendiente, procesando, hecho, error).
- Un worker Node.js que consuma la cola, genere un resumen de metadatos de cada archivo
  (tamaño, tipo, número de líneas) y lo guarde en "salida".
- Un frontend mínimo para subir varios archivos y ver su estado.

Crea scripts/seed.sh para recrear los recursos al arrancar el emulador y tests de integración
que suban 20 archivos y comprueben que todos acaban en "hecho".

[Reglas]

Gancho para enseñarlo: “100 archivos, procesamiento distribuido y cero euros en AWS”.

2. La tienda que sobrevive a los fallos (SQS + DynamoDB) ¶

Un e-commerce de juguete donde provocas fallos a propósito y compruebas que los pedidos no se pierden.

Crea un backend de pedidos en Node.js con AWS Emulator.

- Una API HTTP recibe pedidos y los mete en una cola SQS.
- Un worker reserva inventario en DynamoDB con una escritura condicional
  (que nunca quede stock negativo).
- Si el worker falla, el mensaje vuelve a la cola; tras 3 intentos, va a una DLQ.

Escribe un test de caos: lanza 50 pedidos simultáneos del mismo producto con stock 10,
mata el worker a mitad y vuelve a arrancarlo. Al final debe haber 10 pedidos confirmados,
40 rechazados y ninguno perdido. Si algún comportamiento de SQS no se parece a AWS según
las pruebas de fidelidad, dímelo antes de dar el test por bueno.

[Reglas]

Este prompt toca justo la zona gris: la visibilidad de mensajes y los reintentos son plano de datos. Ver al agente contrastarlo es parte del aprendizaje.

3. El DevOps autónomo (lo que el agente decida) ¶

Aquí no le dices qué servicios usar. Le das una descripción y que proponga.

Te describo una app: "Un acortador de URLs que guarda las estadísticas de clics por día
y genera un informe semanal en CSV".

1. Propón qué servicios de AWS usarías y por qué. Espera mi visto bueno.
2. Comprueba con la skill aws-emulator qué operaciones de esos servicios tienen buena
   fidelidad en la versión instalada.
3. Ajusta la propuesta si algo no encaja y explícame el cambio.
4. Implementa la infraestructura en scripts/seed.sh y un test que verifique cada recurso.

[Reglas]

El paso 1 con “espera mi visto bueno” no es de adorno. Quieres ver el razonamiento antes de que se ponga a crear cosas, aunque sean de mentira.

4. Analíticas caseras (SQS + DynamoDB + S3) ¶

Una web de prueba emite eventos, los agrupas por lotes y sacas un panel con métricas.

Monta un sistema de analíticas mínimo con AWS Emulator:

- Un script que simule 1.000 eventos de navegación (page_view, click, signup) y los envíe a SQS.
- Un worker que los lea por lotes de 10, agregue contadores por hora en DynamoDB y guarde
  los eventos crudos en S3 como ficheros JSON por hora.
- Una página HTML estática que lea los contadores y pinte un gráfico simple.

Añade un test que compruebe que la suma de contadores coincide con los eventos enviados.

[Reglas]

5. El laboratorio de “¿funcionará en el emulador?” (tu propio repo) ¶

El más sencillo y quizá el más útil. Sobre un proyecto que ya tienes:

Este repositorio usa el SDK de AWS. Con la skill aws-emulator:

1. Haz una lista de todas las operaciones de AWS que llama el código.
2. Dime cuáles tienen pruebas de fidelidad que pasan en la versión instalada,
   cuáles fallan y cuáles no tienen prueba.
3. Prepara un .env.emulator y un script para ejecutar los tests de integración
   contra el emulador.
4. Ejecuta los tests y resume qué pasa y qué falla.

No cambies código de la aplicación sin preguntarme.

Es la pregunta que la propia documentación sugiere, convertida en un encargo con pasos. Y te da un informe que puedes llevar a tu equipo para decidir si los tests de integración del CI pueden dejar de depender de una cuenta compartida.

💡 Si un prompt funciona bien, no lo dejes en el historial del chat. Conviértelo en un fichero de objetivos o en una skill propia. Así la próxima vez el agente arranca sabiendo cómo trabajas.

¿Merece la pena frente a una cuenta de AWS de pruebas? ¶

Para lo que promete, sí, y como complemento de la cuenta, no como sustituto. La cuenta sandbox sigue siendo el sitio para IAM, rendimiento y la prueba final antes de producción. El emulador se queda con todo lo demás: el bucle rápido de desarrollo, los tests del CI y, sobre todo, el terreno de juego para agentes.

Y te sirve para algo más que AWS. Con una skill oficial y un entorno que se puede romper sin coste, puedes medir hasta dónde llega tu agente con infraestructura: si propone bien, si comprueba antes de asumir, si documenta lo que no sabe. Con dinero real de por medio, eso no lo pruebas con la misma tranquilidad.

Si vienes de buscar trabajo en este mundo, tener un sitio donde practicar sin tarjeta es justo lo que faltaba. Te dejo también cómo conseguir trabajo en AWS, por si el experimento se te va de las manos.

Preguntas frecuentes sobre AWS Emulator ¶

¿Qué es AWS Emulator?
Es un emulador local y oficial de las APIs de AWS, publicado por Amazon Web Services en GitHub. Sirve un endpoint HTTPS en tu máquina (127.0.0.1:9297) al que hablan la AWS CLI y los SDK, sin cuenta de AWS y sin coste de servicio.

¿Necesito una cuenta de AWS para usarlo?
No. El emulador genera sus propias credenciales en cada arranque y usa la cuenta ficticia 000000000000. Ninguna petición sale a AWS.

¿Cómo instalo AWS Emulator en macOS?
Con Docker. AWS no publica una imagen, así que construyes la tuya con el Dockerfile de la documentación (base Amazon Linux 2023 más el RPM del emulador) y la ejecutas publicando el puerto solo en 127.0.0.1.

¿Qué servicios de AWS soporta?
Aspira a soportar las APIs de los servicios con modelo publicado en el repositorio de modelos de API de AWS. La documentación menciona S3, DynamoDB, Lambda, CloudFormation, EC2 o Step Functions, entre otros, pero la fidelidad varía por servicio y por operación.

¿Qué hace la skill aws-emulator?
Enseña a tu agente de IA a instalar y arrancar el emulador, apuntar la CLI o el SDK, resolver errores de certificado o firma y comprobar qué operaciones de tu proyecto tienen pruebas de fidelidad que pasan.

¿Cómo instalo la skill aws-emulator?
Con AWS CLI 2.35.0 o posterior: aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1. La instala para los agentes que detecta, como Kiro, Cursor o Claude Code. También puedes usar npx skills add https://github.com/aws/agent-toolkit-for-aws --skill aws-emulator.

¿Los datos se guardan al parar el emulador?
No. Todo vive en memoria y se borra al detener el proceso. Por eso conviene un script de inicialización que recree recursos y datos en cada arranque.

¿Puedo probar políticas IAM con AWS Emulator?
No. El emulador no evalúa las políticas IAM ni las basadas en recursos como lo hace AWS. La documentación desaconseja usarlo para probar seguridad.

¿Qué son las pruebas de fidelidad del emulador?
Tests de comportamiento en Python, en el repositorio aws-emulator-evaluation-suite, verificados contra al menos dos cuentas reales de AWS. Con ellos se calcula una puntuación por servicio que AWS publica con cada versión.

¿Sirve AWS Emulator para producción o pruebas de carga?
No. Es una herramienta de desarrollo, pruebas y prototipado. AWS indica que no lo ha probado para uso prolongado ni para carga, y que no es apto para producción.

TL;DR ¶

• 🧪 AWS Emulator es el emulador oficial de las APIs de AWS: un endpoint en 127.0.0.1:9297, sin cuenta, sin factura y con la cuenta ficticia 000000000000.
• 📦 Se instala con un paquete RPM o Debian en Linux, o construyendo tu propia imagen de Docker en macOS y Windows. Compilarlo pide 100 GB libres: no lo hagas.
• 🤖 La skill aws-emulator (AWS CLI 2.35.0+) instala, configura y, sobre todo, contrasta las operaciones de tu proyecto con las pruebas de fidelidad.
• ⚠️ Sus límites: todo en memoria, sin evaluación real de IAM y con más fidelidad en plano de control que en plano de datos.
• 🏭 El mejor uso: dejar que tu agente monte proyectos con S3, SQS y DynamoDB sin riesgo. Empieza por la fábrica de archivos.

Fuentes ¶

• aws/aws-emulator en GitHub: README, instalación y licencia.
• Guía de usuario de AWS Emulator: qué es, instalación en Linux y Docker, configuración de SDK y fidelidad.
• Check your project: cómo se contrasta un proyecto con las pruebas de fidelidad.
• aws/aws-emulator-evaluation-suite: pruebas de fidelidad y su ejecutor.
• aws/agent-toolkit-for-aws y la ficha de la skill en skills.sh.
• Releases de AWS Emulator: versiones y puntuaciones de fidelidad.

🧨 Última oportunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter