AWS Emulator pone las API de Amazon Web Services en la laptop, y los agentes de código lo prueban sin tocar una cuenta real. Amazon Web Services (AWS) lo anunció el 11 de noviembre en su blog oficial de noticias y ya está disponible para todo el público: un programa que se instala en la máquina del desarrollador, responde en la dirección local https://127.0.0.1:9297 y recibe las mismas llamadas que la interfaz de línea de comandos de AWS (AWS CLI), los kits de desarrollo (SDK) y los agentes de programación hacen contra la nube. Sin despliegues. Sin esperar a que una región aprovisione recursos.

El cambio práctico se entiende con una prueba sencilla. Una prueba unitaria que crea una tabla de Amazon DynamoDB, escribe un registro y lo lee de vuelta tarda lo que tarde el despliegue cuando corre contra AWS de verdad; contra el emulador, esa misma prueba corre en la laptop y devuelve la respuesta en milisegundos, contó la compañía en su página del producto. El código de la aplicación no cambia: al arrancar, el emulador genera sus propias credenciales, su configuración y su certificado, los guarda en la carpeta ~/.aws/emulator/9297/ y el desarrollador ajusta las variables de entorno para apuntar sus herramientas a la dirección local.

Las claves que genera empiezan con la palabra EMULATOR, para que nadie las confunda con claves reales, y el programa rechaza cualquier petición firmada con otras credenciales. Trabaja con una sola cuenta ficticia, la 000000000000, exige la firma digital Signature Version 4 (SigV4) en cada llamada y guarda el estado en memoria: al apagarlo, todo desaparece. En Linux se instala con paquetes RPM o Debian; en macOS y Windows corre dentro de Docker.

Un programa escrito por agentes, medido contra la nube real



El dato que separa a este lanzamiento de otros emuladores está en su origen. AWS afirma que todo el código del emulador lo escribieron y lo probaron agentes autónomos de inteligencia artificial, sin código humano de por medio. Swami Sivasubramanian, vicepresidente de la compañía, lo detalló en un texto invitado en el blog de Werner Vogels: el programa nace de más de 400 modelos de API que cubren más de 200 servicios de AWS, y los agentes trabajan en equipos con tareas separadas. Un grupo busca diferencias con la nube real, otro escribe las pruebas y un tercero corrige cada fallo, relató Cloud Computing News.

Esas pruebas tienen nombre propio: pruebas de fidelidad. Cada una ejecuta un flujo completo con un SDK, por ejemplo guardar un objeto en Amazon S3 y borrarlo, y primero se ajusta hasta pasar contra AWS de verdad; después el emulador debe pasar la misma prueba con el mismo código de estado y el mismo mensaje de error. El conjunto completo es público en GitHub, incluidas las que todavía fallan, y con cada versión AWS publica cuántas pasa cada servicio, en un formato del tipo 40 de 50. Cuando el emulador aún no implementa una operación, responde HTTP 501 y la prueba se cae al momento.

El programa está escrito en Rust para consumir poca memoria y poco procesador. Para las pruebas hechas con el SDK de Rust trae un modo integrado que levanta un emulador dentro del propio proceso de prueba, con estado separado para cada caso, y la compañía ofrece una habilidad instalable para que agentes como Kiro o Claude Code monten el entorno solos. En el ejemplo del anuncio oficial, Kiro creó una tabla de DynamoDB, guardó un registro y lo leyó de vuelta hablando solo con el emulador. Quien programa contra la nube de Amazon, el negocio que creció 39 % en el trimestre reportado en octubre, gana un banco de pruebas que no factura por cada intento.

Los límites que AWS pone por escrito



El emulador no cobra tarifa de servicio: se paga solo por los recursos reales al desplegar en AWS, y su código está en GitHub con licencia CC0, de dominio público. Arranca en segundos, cada copia usa su propio puerto y sus propias claves, y un equipo puede levantar una por agente o por rama sin que se pisen los recursos.

Las fronteras vienen escritas por la propia AWS y conviene leerlas antes de confiarle una prueba seria. El emulador no evalúa las políticas de AWS Identity and Access Management (IAM) ni las políticas basadas en recursos con el mismo rigor que la nube: una petición que AWS rechazaría puede pasar en local, y la compañía pide de forma expresa que nadie lo use para comprobar si una aplicación es segura. Cada copia actúa como una sola cuenta, sin comportamiento entre cuentas ni entre regiones, y la cercanía con el servicio real varía por servicio y por función, dato que se consulta en el informe de fidelidad de la documentación. Tampoco sirve para producción ni para pruebas de carga largas.

Para el desarrollador hispano que trabaja con agentes de código a diario, el valor está en el ciclo corto: el agente escribe el código, crea el cubo de S3 o la cola de SQS en el emulador, lee el error con la misma forma que devolvería AWS y corrige sin salir de la laptop ni exponer credenciales reales. La verificación de seguridad y los permisos finos quedan para el despliegue real. Esa división, local para iterar y nube para validar, es la apuesta que AWS presentó el 11 de noviembre.

Fuente: AWS News Blog