Jorge Turbica / blog · Blog ← Todos los artículos EN · Read in English
Cloud

AWS saca un emulador local gratis y sin cuenta, el hueco que dejó LocalStack Community

AWS Emulator corre S3, DynamoDB y más en tu portátil, sin coste ni cuenta. Lo que cubre frente a LocalStack y por qué no sirve para probar IAM.

Un emulador oficial de AWS que corre en tu portátil, habla las mismas APIs que la nube y no cobra nada. AWS presentó AWS Emulator el 11 de noviembre de 2026, ya disponible de forma general, casi ocho meses después de que LocalStack dejara de mantener su edición Community gratuita y empezara a exigir cuenta y token para arrancar su imagen.

Para quien tiene tests de integración contra S3, DynamoDB o SQS, la pregunta ya no es solo "LocalStack o mocks", sino si el emulador del propio proveedor basta.

Qué es y cómo funciona por dentro

AWS Emulator es un binario en Rust que sirve un endpoint HTTPS en 127.0.0.1:9297. La AWS CLI, los SDK y los agentes de código le hablan como si fuera AWS: basta con apuntar AWS_ENDPOINT_URL a él y el código de la aplicación no cambia.

Lo interesante es cómo se construye. No está escrito a mano servicio por servicio: se genera a partir de los modelos Smithy que publica AWS, los mismos de los que salen los SDK. Por eso las peticiones y los errores tienen la misma forma que en la nube. El repositorio tiene un crate por servicio y lo mantienen agentes: unos buscan diferencias comparando respuestas con AWS real y abren una incidencia por cada una; otros escriben los tests, implementan el cambio y lo revisan, y un agente de seguridad revisa los cambios antes de publicarlos.

Algunos detalles que importan al montarlo en CI:

  • Al arrancar genera credenciales propias, un config y un certificado en ~/.aws/emulator/9297/. Las claves empiezan por EMULATOR y rechaza cualquier petición que no venga firmada con ellas (SigV4), así que es difícil apuntar por error a una cuenta real.
  • Todo vive en memoria: unos 160 MiB en reposo, y al pararlo borra los recursos y sus ficheros.
  • Simula una única cuenta (000000000000), sin comportamiento entre cuentas ni entre regiones.
  • Expone /__admin/health en el mismo puerto para que el pipeline espere a que esté listo.
  • Si una operación no está implementada responde 501, de modo que el test falla en vez de pasar en falso.

Cómo probarlo

En Linux se instala como paquete (RPM o Debian, x86_64 y ARM); en macOS y Windows se construye una imagen Docker a partir del Dockerfile de la documentación, porque AWS no publica una imagen lista.

bash
# Debian/Ubuntu (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

# Fedora, RHEL o Amazon Linux 2023 (x86_64)
sudo dnf install -y https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest/aws-emulator-x86_64.rpm

aws-emulator --telemetry off

En otra terminal, se apunta la CLI al emulador y se quitan las credenciales reales del entorno:

bash
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
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE

aws sts get-caller-identity
aws s3 mb s3://pruebas-locales

La telemetría viene activada por defecto; --telemetry off o EMULATOR_TELEMETRY=off la desactivan. Para varios emuladores en paralelo, -p 0 elige un puerto libre y cada instancia guarda sus ficheros en su propio directorio.

Hay un segundo modo, el embebido, que mete el emulador dentro del proceso de test: cada test tiene su propia instancia, sin puerto ni certificado, y se pueden lanzar en paralelo sin compartir tablas ni buckets. De momento solo existe para el SDK de Rust (crate aws-emulator-embedded) y tiene un coste serio: compila un crate por servicio, y el README pide al menos 100 GB libres para target/. En CI habrá que cachear target/ o usar sccache.

AWS Emulator frente a LocalStack

LocalStack era la respuesta por defecto para emular AWS en local. Desde el 23 de marzo de 2026 su imagen única en Docker Hub exige una cuenta y un token, y su plan gratuito no permite uso comercial.

AWS EmulatorLocalStack for AWS
PrecioSin costePlan gratuito solo para uso no comercial; planes de pago para empresas
Cuenta para arrancarNoSí, cuenta y token
CódigoPublicado en GitHub, licencia CC0-1.0Edición Community sin mantenimiento desde marzo de 2026
DistribuciónRPM y Debian en Linux; Docker construido por ti en macOS y WindowsImagen en Docker Hub
Tests en procesoSí, solo para el SDK de Rust—
Cómo mide la fidelidadTests de fidelidad públicos, con un "k de n" por servicio en cada release—

Dónde gana AWS Emulator. El precio y la licencia, para empezar: un equipo que usaba LocalStack Community en una empresa tenía que pagar o quedarse en una versión congelada, y ahora tiene una alternativa del propio proveedor. Generarse desde los modelos Smithy le da una ventaja estructural: un servicio nuevo o un cambio de API puede llegar al emulador sin que nadie lo programe a mano. Y publicar los tests de fidelidad, incluidos los que fallan, permite saber antes de migrar si los servicios que usas están cubiertos.

Dónde pierde. La madurez. AWS Emulator acaba de salir y su propia documentación reconoce que la fidelidad varía por servicio y por funcionalidad. Tampoco hay una imagen oficial de Docker, lo que en macOS y Windows supone construirla y mantenerla.

La cautela que importa: IAM no se evalúa

AWS lo dice claro: el emulador no evalúa las políticas de IAM ni las políticas de recursos como lo hace AWS, así que una petición que AWS denegaría puede funcionar en local. Un test verde contra el emulador no dice nada de permisos. Los errores de AccessDenied por una política mal escrita, que son de los fallos más habituales al desplegar, seguirán apareciendo en el primer entorno real. Los tests de permisos y de seguridad tienen que seguir ejecutándose contra una cuenta de AWS.

Veredicto

Para quién sí: equipos con tests de integración contra servicios comunes (S3, DynamoDB, SQS) que pagaban LocalStack solo por eso o que se quedaron en la última Community; quien trabaja con agentes de código y quiere que creen y borren recursos sin tocar una cuenta; proyectos en Rust, que con el modo embebido tienen tests aislados y paralelos.

Para quién todavía no: quien depende de servicios poco comunes o de comportamiento entre cuentas o regiones, y quien necesita validar IAM en local. Lo razonable es mirar los tests de fidelidad de cada servicio que uses y, si cuadran, migrar primero un pipeline no crítico.

Fuentes

Jorge Turbica

Software Engineer y SRE. Escribo sobre los retos reales que me encuentro en producción.

Ver portfolio ↗