AWS Emulator lleva la nube de AWS a tu laptop

La novedad importa porque los agentes de código trabajan en ciclo: escriben, ejecutan y leen el resultado antes de decidir el siguiente paso. Con la infraestructura dentro de ese ciclo, el agente prueba llamadas a AWS en segundos.

En este artículo verás:

• Qué es el AWS Emulator y cómo funciona
• Cómo instalar y apuntar el AWS CLI al endpoint local
• Cómo AWS mide la fidelidad y cuáles son los límites
• Qué cambia para quien programa con agentes

Qué es el AWS Emulator, el emulador local de AWS

El AWS Emulator es un emulador de código abierto de las APIs de Amazon Web Services. El AWS CLI, los SDKs y tus agentes de código se comunican con él a través de un endpoint HTTPS local, usando las mismas APIs que usarían en la nube.

Según AWS, el código de la aplicación permanece igual. Una prueba que crea una tabla en Amazon DynamoDB, guarda un elemento y lo lee de vuelta es la misma prueba, solo que se ejecuta en tu laptop y sin despliegue.

El emulador está escrito en Rust para consumir poca CPU y memoria. Soporta las APIs de los servicios que tienen modelo publicado en el repositorio de modelos de API de AWS, los mismos usados por los SDKs, y por eso las solicitudes y los errores tienen el mismo formato que en la nube.

AWS también afirma que el proyecto no tiene tarifa adicional: solo pagas por los recursos que crees en AWS al hacer despliegue. El código está en el repositorio aws/aws-emulator en GitHub.

Cómo instalar el AWS Emulator y apuntar el AWS CLI

En Linux, la instalación se hace por paquete RPM o Debian, que añade el comando aws-emulator al sistema. En macOS y Windows, AWS indica ejecutar el emulador en Docker. También se puede compilar a partir del código fuente.

Al iniciar, el emulador genera sus propias credenciales, un archivo de configuración y un certificado, guardados en ~/.aws/emulator/9297/. Luego, defines variables de entorno para que el SDK hable con tu laptop en lugar de AWS.

$ aws-emulator

Las claves cambian en cada inicio y los IDs de acceso comienzan con EMULATOR, lo que evita confusión con claves reales. El emulador rechaza solicitudes firmadas con cualquier otra clave y usa una única cuenta, la 000000000000.

Cuando se ejecuta como proceso local, exige firma SigV4 en todas las solicitudes, como hace AWS. También existe el endpoint /__admin/health, que permite a un script o contenedor esperar a que el emulador esté listo antes de ejecutar las pruebas.

Por defecto, el emulador envía datos anónimos de uso y de error, y AWS informa que es posible desactivarlo.

Cómo AWS mide la fidelidad del AWS Emulator

Un emulador solo vale si una prueba que pasa en él también pasa en AWS. Por eso la empresa usa las pruebas de fidelidad: programas cortos que usan un SDK para ejecutar un flujo, como guardar, leer y borrar un objeto, y verifican cómo se comporta AWS.

Cada prueba se verifica contra AWS real. Solo pasa si el emulador iguala a la nube en todas las llamadas, incluyendo código de estado, cuerpo de la respuesta, código y mensaje de error, además de los recursos creados.

En cada versión, AWS publica cuántas pruebas pasan por servicio, en formato k de n. Por ejemplo, 40 de 50 significa que 40 de las 50 pruebas de ese servicio pasan. El conjunto de pruebas es público, incluidos los que aún fallan.

La propia AWS pide cautela en la lectura: al añadir pruebas, la nota puede caer aunque el emulador mejore. Si una operación no existe, responde HTTP 501 y la prueba falla de inmediato.

Escrito por agentes: cómo se construyó el AWS Emulator

El emulador se construye y mantiene con agentes, a partir de los modelos de API de AWS, usando Amazon Bedrock AgentCore, AWS CodePipeline y AWS CodeCommit. Un grupo de agentes busca brechas comparando respuestas con AWS real y abre un issue por cada una.

Otro grupo toma el issue, escribe pruebas, implementa el comportamiento y revisa el cambio. Un agente de seguridad independiente revisa los cambios de forma adversarial, durante la corrección y de nuevo en el pipeline de lanzamiento.

En el texto publicado el 11 de noviembre en el blog All Things Distributed, el CTO de Amazon, Werner Vogels, publica un artículo invitado de Swami Sivasubramanian. El texto afirma que todo el código del emulador fue escrito y probado por agentes y que se construye a partir de más de 400 modelos de API, cubriendo más de 200 servicios de AWS.

El mismo texto dice que el código se libera bajo CC0, una dedicación al dominio público, y que el historial de commits y los issues abiertos por los agentes son públicos, incluida la carpeta con los comportamientos que aún no corresponden a AWS real.

Límites del AWS Emulator en el lanzamiento

AWS es directa sobre lo que el emulador no hace. No evalúa políticas de IAM como la nube y, por eso, una solicitud que AWS negaría puede funcionar en el emulador. La empresa recomienda no usarlo para probar si la aplicación es segura.

Cada emulador funciona como una única cuenta, sin comportamiento entre cuentas o entre regiones. La cobertura varía por servicio y recurso, así que vale la pena revisar las notas de fidelidad en la documentación de los servicios que usas.

Otra recomendación oficial: mantén las credenciales reales fuera del entorno de los jobs de prueba y valida las configuraciones de seguridad y la aplicación completa en AWS antes de pasar a producción.

Cómo probar el AWS Emulator hoy con tu agente de código

La documentación oficial describe un camino para agentes: instala la skill aws-emulator y deja que el agente de código instale, inicie y conecte el emulador. AWS cita agentes como Kiro y Claude Code como casos de uso.

Si quieres organizar este tipo de rutina, vale la pena leer cómo automatizar tareas de repositorio con GitHub Agentic Workflows, ya que las pruebas locales combinan bien con automatizaciones en CI.

Para la capa de interfaz, la guía sobre probar apps web con el Playwright CLI y agentes de IA muestra cómo darle al agente un navegador. La depuración en el front queda cubierta en el texto sobre Chrome DevTools MCP.