# AWS Emulator: probá AWS en tu computadora sin gastar en la nube **¿Y si pudieras crear un bucket S3, probar tu aplicación y ejecutar comandos de AWS sin desplegar un solo recurso en la nube?** AWS acaba de lanzar una herramienta que me llamó muchísimo la atención: **AWS Emulator**. Y no solamente por lo que permite hacer, sino también por cómo fue construido. Porque sí, estamos hablando de un emulador oficial de AWS, open source, desarrollado y mantenido con agentes de inteligencia artificial. Así que decidí llevarlo a mi Mac, ejecutarlo con Docker y explorar cómo podemos combinarlo con Kiro para desarrollar y validar aplicaciones localmente. Vamos a verlo. --- ## ¿Qué es AWS Emulator? AWS Emulator es una herramienta que permite simular el comportamiento de APIs de servicios de AWS directamente en tu computadora. En lugar de enviar las solicitudes a la nube, herramientas como AWS CLI, los SDKs y los agentes de programación pueden comunicarse con un endpoint HTTPS local. Por ejemplo, podemos trabajar con servicios como: - Amazon S3. - Amazon DynamoDB. - Amazon SQS. - Otras APIs de AWS, con distintos niveles de implementación y fidelidad. La idea es sencilla: **desarrollar, probar y experimentar sin depender de un despliegue real para cada iteración**. Y eso abre posibilidades interesantes para quienes trabajamos con automatización, desarrollo de aplicaciones, DevOps y CI/CD. ### ¿Es gratis? AWS Emulator no tiene un cargo adicional por el servicio. Podés ejecutar pruebas localmente sin crear recursos facturables en AWS. Si posteriormente desplegás infraestructura real, esos recursos sí tendrán sus costos habituales. Eso sí, el emulador no garantiza una reproducción completa de todos los servicios de AWS. ## ¿Cómo funciona? Imaginemos que estamos desarrollando una aplicación que necesita almacenar archivos en Amazon S3. Normalmente, para probar una integración real podríamos crear un bucket en AWS, configurar credenciales, permisos y comenzar a realizar operaciones. Con AWS Emulator podemos cambiar ese flujo. Nuestra aplicación sigue utilizando Boto3, AWS CLI o el SDK correspondiente, pero las solicitudes se dirigen a un servidor local. ```text Aplicación Python / Kiro | v AWS SDK | v AWS Emulator localhost:9297 | v S3 emulado ``` El emulador está desarrollado en Rust y utiliza los modelos de APIs de AWS para reproducir las estructuras de solicitudes y respuestas. Un detalle importante: que una API tenga un modelo disponible no significa que todas sus operaciones estén completamente implementadas. --- ## Instalando AWS Emulator en macOS En Linux podemos instalarlo utilizando paquetes RPM o DEB. En macOS y Windows, AWS documenta su ejecución mediante Docker. Y algo interesante: AWS no distribuye una imagen Docker oficial lista para descargar. Tenemos que construirla utilizando el paquete correspondiente. ### 1\. Verificar requisitos ```bash docker --version docker info aws --version uname -m ``` Si utilizás Apple Silicon, `uname -m` debería devolver `arm64`. ### 2\. Preparar el proyecto ```bash mkdir -p ~/aws-emulator-demo cd ~/aws-emulator-demo ``` ### 3\. Crear el Dockerfile Primero identificamos la arquitectura: ```bash ARCH=$(uname -m) if [ "$ARCH" = "arm64" ]; then RPM_ARCH="aarch64" else RPM_ARCH="x86_64" fi URL="https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest/aws-emulator-${RPM_ARCH}.rpm" ``` Ahora generamos el Dockerfile: ```bash cat > Dockerfile < demo.txt ``` ### Subirlo ```bash aws s3 cp demo.txt s3://roxs-emulator-demo/ ``` ### Listar los objetos ```bash aws s3 ls s3://roxs-emulator-demo/ ``` ### Leer el contenido ```bash aws s3 cp s3://roxs-emulator-demo/demo.txt - ``` Y ahí tenemos nuestra primera prueba. Los mismos comandos que utilizamos habitualmente con AWS CLI, pero dirigidos a un servicio emulado localmente. Sin desplegar un bucket real. Sin esperar a que se aprovisione infraestructura. Y sin generar cargos por recursos de S3 en AWS. --- ## Ahora viene lo interesante: AWS Emulator + Kiro Una de las posibilidades que más me llamó la atención es la integración con agentes de programación. AWS dispone de una skill llamada `aws-emulator`, que podemos agregar mediante AWS Agent Toolkit. Con AWS CLI 2.35.0 o superior: ```bash aws agent-toolkit add-skill \ --skill-name aws-emulator \ --region us-east-1 ``` La skill proporciona instrucciones para que agentes compatibles puedan trabajar con AWS Emulator. En mi caso, la idea es combinarlo con Kiro. ### El prompt que utilizamos > Usando la skill `aws-emulator`, creá una demo en Python con Boto3 que cree un bucket S3, suba un archivo, liste los objetos y lea su contenido. > > Utilizá AWS Emulator en `https://127.0.0.1:9297`, sin conectarte a AWS ni utilizar credenciales reales. Verificá la conexión y ejecutá la demo para mostrar los resultados. El objetivo es que Kiro pueda generar el código, ejecutar las operaciones contra el emulador y ayudarnos a comprobar su funcionamiento. Y acá aparece algo que me parece especialmente interesante. **El agente puede escribir código, pero también puede utilizar un entorno local para obtener resultados y corregir su implementación.** Pasamos de pedirle que genere una función a darle un entorno donde pueda probarla. Eso no elimina la necesidad de revisar el código ni de validar posteriormente el comportamiento en AWS real. Pero sí puede hacer mucho más rápido el ciclo de desarrollo. --- ## ¿Y qué pasa con CI/CD? Acá es donde veo uno de los casos de uso más interesantes. Imaginemos un pipeline que necesita probar una aplicación que interactúa con DynamoDB o S3. Podríamos levantar AWS Emulator durante la ejecución de las pruebas, configurar los SDKs para utilizar su endpoint y validar las operaciones necesarias. El flujo sería: ```text Commit / Pull Request | v Pipeline CI | v AWS Emulator | v Pruebas de integración | v Resultados ``` Esto puede ayudarnos a reducir la dependencia de infraestructura remota durante ciertas pruebas, mejorar los ciclos de feedback y facilitar la experimentación. Pero hay que elegir bien qué validar localmente. Un test que funciona en el emulador no garantiza que vaya a funcionar de la misma manera en AWS. --- ## Lo más sorprendente: el emulador está construido con agentes de IA AWS explica que AWS Emulator es construido y mantenido mediante agentes que utilizan los modelos de APIs de AWS. Su proceso involucra servicios como Amazon Bedrock AgentCore Runtime Instances, AWS CodePipeline y AWS CodeCommit. Hay agentes encargados de detectar diferencias entre el comportamiento del emulador y los servicios reales. Otros trabajan en implementar funcionalidades, escribir pruebas y revisar cambios. También existen revisiones de seguridad independientes y pruebas de fidelidad antes de publicar las modificaciones. Esto me parece importante porque demuestra otro caso de uso de la IA. No estamos hablando solamente de un asistente que completa código. Estamos hablando de agentes participando en el mantenimiento y evolución de una herramienta de desarrollo. Y eso también nos obliga a pensar en cómo verificamos lo que producen. --- ## ¿Reemplaza a AWS real o a LocalStack? No tan rápido. AWS Emulator es una nueva alternativa para determinadas pruebas locales, pero todavía presenta limitaciones. Por ejemplo: - No evalúa las políticas IAM de la misma forma que AWS. - No reproduce escenarios entre múltiples cuentas o regiones. - Algunas operaciones todavía no están implementadas y devuelven HTTP 501. - La fidelidad varía dependiendo del servicio y la funcionalidad. - El estado de los recursos es temporal y se pierde al detener el emulador. AWS publica pruebas de fidelidad para comparar el comportamiento del emulador con el de los servicios reales. Por eso, antes de adoptar la herramienta en un proyecto, conviene revisar qué operaciones necesitamos y cuál es su nivel de compatibilidad. Y sobre LocalStack, creo que lo interesante no es declarar un ganador inmediatamente. La comparación debería considerar cobertura de servicios, compatibilidad, experiencia de desarrollo, automatización, mantenimiento y necesidades reales del equipo. --- ## Mi reflexión: desarrollar más rápido también implica validar mejor Cada vez tenemos más herramientas para generar código, automatizar tareas y reducir el tiempo entre una idea y una implementación. Pero hay algo que no cambia. **Que una prueba pase no significa automáticamente que el sistema esté listo para producción.** AWS Emulator puede ayudarnos a experimentar más rápido. Kiro puede ayudarnos a generar código y ejecutar pruebas. Y nuestros pipelines pueden automatizar parte de ese proceso. Pero la responsabilidad de validar el comportamiento, la seguridad y las decisiones de arquitectura sigue siendo nuestra. Para mí, ahí está el verdadero valor de estas herramientas: no solamente escribir más código, sino crear mejores ciclos de aprendizaje y validación. **La IA opina. Vos aprobás. 🔥** ## Recursos para comenzar - [AWS Emulator — repositorio oficial](https://github.com/aws/aws-emulator) - [Anuncio oficial de AWS Emulator](https://aws.amazon.com/about-aws/whats-new/2026/11/aws-emulator-now-available/) - [AWS Emulator — documentación](https://docs.aws.amazon.com/emulator/latest/userguide/) - [Instalación con Docker](https://docs.aws.amazon.com/emulator/latest/userguide/getting-started-docker.html) --- ¿Ya probaste AWS Emulator? ¿Lo incorporarías a tus pruebas locales o preferís seguir utilizando LocalStack? Te leo en los comentarios. **Soy Roxs. Build with Fire. Deploy with Power. 🔥**