AWS Emulator: emula las APIs de AWS sin cuenta ni nube

AWS ya tiene su propio emulador de AWS. El repositorio AWS Emulator permite correr tests contra las APIs de AWS en tu máquina, en un servidor de desarrollo o en tu pipeline de CI, sin cuenta de AWS, sin credenciales y sin pagar por recursos que no existen. La compañía aclara que no cobra ninguna tarifa adicional por el emulador: solo pagas por los recursos reales cuando despliegas en la nube.

Para un equipo que hoy mantiene un entorno de staging encendido solo para validar código, el dato no es menor. El propio repositorio lo dice sin rodeos: tus requests van al emulador, no a AWS. Y agrega una advertencia que conviene leer dos veces: no es para workloads de producción ni para testear seguridad.

¿Qué es AWS Emulator y cómo se usa?

AWS Emulator es un programa local que expone un endpoint compatible con las APIs de AWS. No tiene interfaz gráfica: una vez arrancado, apuntas la AWS CLI o cualquier SDK a ese endpoint con variables de entorno y ejecutas tu código como siempre. El emulador sirve HTTPS en 127.0.0.1:9297 con un certificado autofirmado.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

La arquitectura interna es deliberadamente granular: hay un crate de Rust por cada servicio de AWS, y el protocolo de cada servicio se genera a partir de un modelo Smithy, el mismo formato que AWS usa para describir sus APIs. Eso hace que la fidelidad no sea un detalle de implementación, sino el eje del proyecto: cada release publica fidelity scores por servicio, y los huecos conocidos se rastrean en el directorio issues/things-that-do-not-work/ del repositorio, separados de los que ya se resolvieron.

AWS también lo empaquetó como skill para agentes de código. Con la AWS CLI 2.35.0 o posterior, se instala con aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1 y después se le pide al agente que configure el emulador. Es una señal clara del público que busca: equipos que ya escriben y testean código con agentes de IA.

A diferencia de Floci, que comunica cuántos servicios emula, la documentación inicial de AWS Emulator no incluye esa cifra. La única referencia pública son los fidelity scores que acompañan cada release.

¿Cómo se instala y cuánto cuesta correrlo en CI?

Hay tres caminos de instalación y uno de compilación, y el costo real está en el cuarto:

Linux: instalar el paquete RPM o Debian y ejecutar aws-emulator.
Windows y macOS: correr el emulador en un contenedor construido desde un Dockerfile corto.
Modo embebido: agregarlo como dev-dependency y correrlo in-process, con una instancia aislada por test. No hay URL de endpoint, ni certificado, ni variables de entorno: el test conecta el cliente HTTP del emulador directamente al cliente del SDK.
Compilar desde fuente: requiere toolchain de Rust con Cargo, compilador de C, al menos 100 GB libres para el directorio target/ y una máquina multi-core. Un build completo en frío compila todos los crates de servicio y tarda; después los rebuilds incrementales son rápidos. Solo está soportado en Linux x86_64 y aarch64.

El detalle que importa para el presupuesto: el modo embebido compila el emulador dentro de tu binario de test, así que ese primer build pesa lo mismo que compilar desde fuente. La recomendación del propio repositorio es reutilizar un CARGO_TARGET_DIR entre proyectos, cachear target/ o usar sccache en CI, y fijar el emulador a un commit de release para que no se recompile en cada cambio.

¿Telemetría encendida por defecto? Lo que tu equipo debe decidir

AWS Emulator recopila y reporta datos de uso a AWS, y la telemetría está activada por defecto. La documentación asegura minimización estricta: los registros nunca incluyen el contenido de tus requests o responses, ni tu código, ni credenciales, ni datos personales, y no se comparten con terceros.

Apagarla tiene cuatro vías, según el alcance que necesites:

Por proceso: aws-emulator --telemetry off.
Por shell: export EMULATOR_TELEMETRY=off.
Por máquina: enabled = false en la sección [telemetry] del archivo ~/.aws/emulator/config.toml.
En modo embebido: pasar Telemetry::Off en las opciones al crear el emulador.

Hay un punto que muchos equipos pasan por alto: si construyes una herramienta que incluye el emulador, por ejemplo un framework de tests que otros corren, el repositorio pide explícitamente que avises a tus usuarios y les des una forma de apagarla, o que la envíes ya desactivada.

Para un equipo que trabaja con datos regulados, la comparación es directa. Floci, el emulador open source que creció al calor de la migración desde LocalStack, no recolecta telemetría, no hace llamadas externas en runtime y opera completamente offline, algo que TechTimes describe como una garantía relevante para equipos bajo HIPAA o SOC 2 o en entornos aislados. AWS ofrece control granular y minimización; Floci ofrece ausencia total de canal. Tu equipo de seguridad probablemente tenga una preferencia.

¿Por qué AWS entra a un mercado que dominaban terceros?

Emular AWS en local dejó de ser un hobby de nicho. LocalStack, el jugador de referencia, anunció en diciembre de 2025 que su edición community, distribuida bajo Apache 2.0, se consolidaría en una única imagen de pago que exige cuenta y token. El cambio entró en vigor el 23 de marzo de 2026 y el período de gracia para saltarlo venció el 6 de abril de ese año, según TechTimes. Los planes pagos arrancan en US$39 por licencia al mes facturado anualmente.

La escala de lo que se movió detrás de esa decisión: LocalStack reportó 350 millones de descargas de Docker, más de 60.000 estrellas en GitHub y más de 1.500 clientes con suscripción paga, según el anuncio que la compañía hizo en AWS re:Invent en diciembre de 2025.

El hueco lo llenó Floci: según TechTimes, superó las 10.000 estrellas en GitHub en mayo de 2026, cubría 45 servicios de AWS sobre el puerto 4566 —el mismo que usaba LocalStack— y se presentaba como reemplazo directo con licencia MIT, sin cuenta ni token. En agosto de 2026, i-programmer reportaba que ya emulaba 69 servicios sobre el mismo puerto.

En paralelo, la presión sobre los pipelines subió por otro lado. En abril de 2026 LocalStack presentó App Inspector, y en ese anuncio el analista Paul Nashawaty situó entre el 30% y el 50% el código que hoy se genera con ayuda de asistentes de IA, con hasta el 70% de los incidentes mayores de producción originados en malas configuraciones. Más código generado más rápido significa más necesidad de validarlo barato, y eso es exactamente un emulador local.

AWS Emulator, Floci o LocalStack: ¿cuál le conviene a tu equipo?

AWS Emulator: fidelidad declarada por quien define el protocolo. Publica fidelity scores por release y mantiene un registro público de lo que no funciona. Considera que el repositorio no acepta pull requests: los huecos se reportan como issues, no se parchean desde fuera.
Floci: licencia MIT, sin telemetría, y un arranque de aproximadamente 24 milisegundos con 13 MiB en reposo frente a los cerca de 3.300 milisegundos y 143 MiB de LocalStack, según los benchmarks que el propio proyecto publica y que recoge TechTimes. Son cifras autoinformadas: trátalas como tales.
LocalStack: el más maduro en herramientas de debugging —App Inspector visualiza flujos entre servicios— y el único con clientes de pago declarados a esa escala. A cambio, la edición community quedó sin parches de seguridad.
Moto: librería de Python que simula llamadas al SDK in-process. No habla el wire protocol de AWS y no sirve para codebases que no sean Python ni para despliegues con Terraform o CDK, según TechTimes.

La pregunta correcta no es cuál es mejor en abstracto, sino cuál falla menos en tu suite. Un emulador que devuelve respuestas sintéticas en un servicio donde tu test depende de que algo se ejecute de verdad te va a dar un falso positivo.

Qué significa esto para tu startup

1. Corre tu suite real antes de decidir. No migres por entusiasmo ni por el logo de AWS. Revisa los fidelity scores del release que vas a usar y el directorio de issues abiertos, y apunta los tests que tocan flujos entre servicios: S3 disparando Lambda, EventBridge enrutando a Step Functions, SQS alimentando workers. Verifica si el emulador resuelve esas interacciones del lado del servidor o solo acepta llamadas aisladas.

2. Define una política de telemetría explícita. Si trabajas con datos sensibles o en un entorno regulado, la decisión no puede quedar en el default. Deja el ajuste en el archivo de configuración versionado o exporta EMULATOR_TELEMETRY=off en el pipeline, y documenta por qué.

3. Presupuesta el costo de CI, no solo el de licencia. El modo embebido es cómodo, pero mete el emulador en tu binario de test: el primer build es pesado. Cachear el directorio de compilación y fijar una versión puntual del emulador no es optimización opcional, es higiene de pipeline. Un equipo que corre cientos de jobs al día siente la diferencia en minutos facturados.

4. No lo lleves a producción ni lo uses como test de seguridad. El repositorio es explícito en ambos puntos. Emula APIs, no reproduce el modelo de aislamiento ni las garantías de seguridad de AWS real.

5. Aprovecha el momento para auditar tu emulador actual. Si tu equipo quedó anclado a una imagen antigua de un emulador community sin actualizaciones de seguridad, ese es un riesgo de supply chain, no una molestia. Pasa la misma lupa que le pasas a una dependencia crítica: gobernanza, licencia y ritmo de parches.

Conclusión

Durante años, emular AWS en local fue un mercado de terceros: LocalStack, Moto, Floci y una lista creciente de alternativas. Además del software, hay tres decisiones de infraestructura que no dependen de tu código: si el emulador recibe parches, qué telemetría envía y quién puede contribuir a él. AWS acaba de meter su propia pieza en ese tablero, con la ventaja de definir el protocolo que los demás intentan imitar y la limitación de no aceptar contribuciones externas. Para un equipo en LATAM o España, donde cada minuto de CI y cada entorno de staging se pagan de la caja del runway, la jugada sensata no es elegir el emulador de moda: es medir cuál reproduce mejor los flujos que tu producto realmente usa.