por Daniel Abib el 11 NOV 2026 en Amazon Bedrock AgentCore, Anuncios, Herramientas para desarrolladores, Lanzamiento, Guía técnica · Enlace permanente · Comentarios · Compartir
Hoy anunciamos AWS Emulator, un emulador local de Amazon Web Services (AWS) que se ejecuta en tu equipo. La interfaz de línea de comandos de AWS (AWS CLI), los SDK de AWS y tus agentes de codificación se comunican con él a través de un endpoint HTTPS local, utilizando las mismas API de AWS que usarían en la nube, desde tu portátil. AWS Emulator no tiene ningún cargo adicional por servicio. Solo pagas por los recursos de AWS cuando despliegas en AWS. Su código fuente está en GitHub. Lo instalas desde un paquete RPM o Debian en Linux, y en macOS y Windows lo ejecutas en Docker.
Cómo funciona
Instalas el emulador, lo inicias y apuntas tus herramientas al endpoint local. Cuando AWS Emulator arranca, genera sus propias credenciales, un archivo de configuración y un certificado, y los escribe en ~/.aws/emulator/9297/. Configuras variables de entorno para que el SDK de AWS hable con tu portátil en lugar de con AWS, y el código de tu aplicación permanece sin cambios.
A partir de ahí, tus pruebas existentes, scripts de CLI y agentes de codificación siguen funcionando como ya lo hacen. Una prueba unitaria que crea una tabla de Amazon DynamoDB, escribe un elemento y lo lee de vuelta es la misma prueba, y se ejecuta en tu máquina sin necesidad de un despliegue. Un agente de codificación puede crear recursos, comprobar el resultado e iterar de nuevo sin esperar un despliegue en una Región.
El emulador está implementado en Rust para que se mantenga ligero en consumo de CPU y memoria en un portátil. Es compatible con las API de los servicios de AWS que tienen un modelo de API en el repositorio de modelos de API de AWS en GitHub, y como está construido a partir de esos modelos, los mismos que usan los SDK de AWS, tus solicitudes y los errores que recibes tienen la misma forma que en AWS.
Si eres desarrollador, especialmente si trabajas con agentes de codificación como Kiro o Claude Code, puedes usar ese ciclo para probar localmente interacciones con AWS de verdadera complejidad.
Vamos a probarlo
Para empezar, instalé el paquete en Amazon Linux 2023. El paquete añade el comando aws-emulator a /usr/bin/, por lo que está en la ruta.
PKG=https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest
sudo dnf install -y $PKG/aws-emulator-x86_64.rpm
aws-emulator -vEn macOS y Windows, construyes una imagen Docker a partir del Dockerfile corto que aparece en la documentación y ejecutas el emulador en un contenedor. No publicamos una imagen lista para usar.
Inicié el emulador con aws-emulator. Sirve HTTPS en 127.0.0.1:9297, por lo que solo mi propio ordenador puede acceder a él, y escribe su registro como líneas JSON que muestran la dirección, el archivo de configuración y el archivo de certificado.
aws-emulatorEn otra terminal, configuré las variables de entorno que apuntan la AWS CLI al emulador y desactivé cualquier variable que pudiera suministrar credenciales reales de AWS.
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
export AWS_DEFAULT_REGION=us-east-1
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILEEl emulador genera nuevas claves cada vez que se inicia. Sus ID de clave de acceso comienzan con EMULATOR, para que no los confundas con claves reales de AWS, y rechaza las solicitudes firmadas con cualquier otra clave. Para confirmar que mi shell estaba hablando con el emulador, comprobé el endpoint de salud y la identidad del llamante. El emulador utiliza una única cuenta, 000000000000.
curl --cacert ~/.aws/emulator/9297/ca.pem https://127.0.0.1:9297/__admin/health
aws sts get-caller-identityLuego creé un bucket, copié un objeto pequeño y lo listé.
$ aws s3 mb s3://local-getting-started
make_bucket: local-getting-started
$ echo "hello from the emulator" > hello.txt
$ aws s3 cp hello.txt s3://local-getting-started/
upload: ./hello.txt to s3://local-getting-started/hello.txt
$ aws s3 ls s3://local-getting-started/Con la AWS CLI apuntando a mi portátil, tenía los mismos comandos que ya uso y un endpoint local que los respondía.
A continuación quise verlo de la forma en que realmente trabajo ahora, así que con el emulador todavía en ejecución abrí Kiro y le pedí que creara una tabla de Amazon DynamoDB, escribiera un elemento y lo leyera de vuelta, todo contra AWS Emulator en lugar de contra mi cuenta de AWS.
kiro> Using the local AWS Emulator (the environment variables
are already set in this shell), create a DynamoDB table
"kiro-demo" with a string key "id", put an item
{id: "item-1", msg: "hello from kiro"}, then read it
back with get-item.
$ aws dynamodb create-table --table-name kiro-demo \
--attribute-definitions AttributeName=id,AttributeType=S \
--key-schema AttributeName=id,KeyType=HASH \
--billing-mode PAY_PER_REQUEST
$ aws dynamodb put-item --table-name kiro-demo \
--item '{"id": {"S": "item-1"}, "msg": {"S": "hello from kiro"}}'
$ aws dynamodb get-item --table-name kiro-demo --key '{"id": {"S": "item-1"}}'Para usar la misma configuración con un conjunto de pruebas existente, iniciaría el emulador, establecería las mismas variables de entorno en el script que ejecuta las pruebas y las ejecutaría como de costumbre.
Uso del emulador en proceso
Ejecutar el emulador como un proceso local te proporciona un endpoint HTTPS que funciona con la AWS CLI y los SDK de AWS a través de variables de entorno. Algunos SDK necesitan una configuración adicional para confiar en el certificado del emulador, por ejemplo un almacén de confianza para el SDK de AWS para Java. Para las pruebas, existe una segunda opción. AWS Emulator incluye un modo embebido que instancias directamente dentro de tu proceso de prueba y conectas al SDK a través de su cliente HTTP, en lugar de hablar con un servidor separado a través de la red. Cada instancia embebida mantiene su propio estado, por lo que las pruebas no comparten buckets, tablas ni colas, y puedes ejecutar muchas en paralelo. El modo embebido está disponible para el SDK de AWS para Rust. Añades la crate aws-emulator-embedded desde GitHub a la sección [dev-dependencies] de tu archivo Cargo.toml. El siguiente ejemplo crea una tabla de Amazon DynamoDB, escribe un elemento y lo lee de vuelta, todo en proceso.
use aws_emulator_embedded::{AwsEmulatorEmbedded, EmbeddedOptions};
use aws_sdk_dynamodb::types::{
AttributeDefinition, AttributeValue, BillingMode, KeySchemaElement, KeyType,
ScalarAttributeType,
};
#[tokio::test]
async fn put_then_get_returns_the_item() {
let emulator = AwsEmulatorEmbedded::new(EmbeddedOptions::default());
let config = aws_config::defaults(aws_config::BehaviorVersion::latest())
.http_client(emulator.http_client())
.region(aws_config::Region::new("us-east-1"))
.credentials_provider(emulator.aws_credentials_provider())
.load()
.await;
let ddb = aws_sdk_dynamodb::Client::new(&config);
ddb.create_table()
.table_name("emulator-demo-table")
.attribute_definitions(
AttributeDefinition::builder()
.attribute_name("id").attribute_type(ScalarAttributeType::S)
.build().unwrap())
.key_schema(
KeySchemaElement::builder()
.attribute_name("id").key_type(KeyType::Hash)
.build().unwrap())
.billing_mode(BillingMode::PayPerRequest)
.send().await.unwrap();
ddb.put_item()
.table_name("emulator-demo-table")
.item("id", AttributeValue::S("item-1".into()))
.item("msg", AttributeValue::S("hi".into()))
.send().await.unwrap();
let got = ddb.get_item()
.table_name("emulator-demo-table")
.key("id", AttributeValue::S("item-1".into()))
.send().await.unwrap();
assert_eq!(got.item().unwrap().get("msg").unwrap().as_s().unwrap(), "hi");
}Cuando se ejecuta como un proceso local, el emulador exige que cada solicitud esté firmada con Signature Version 4 (SigV4), de la misma manera que lo hace AWS, y expone un endpoint /__admin/health en el mismo puerto para que un script o un contenedor pueda esperar hasta que esté listo antes de ejecutar las pruebas. Por defecto también envía datos anónimos de uso y errores, y puedes desactivarlo.
Cómo medimos la fidelidad
Un emulador solo es útil si una prueba que pasa contra él también pasaría contra AWS, así que lo medimos directamente con pruebas de fidelidad. Una prueba de fidelidad es un programa corto que utiliza un SDK de AWS para ejecutar un flujo de trabajo, como almacenar un objeto y luego leerlo y eliminarlo, y comprueba cómo se comporta AWS. Verificamos cada prueba de fidelidad contra AWS real. Una prueba de fidelidad solo pasa si el emulador coincide con AWS en la respuesta a cada llamada, incluido el código de estado, el cuerpo y el código y mensaje de error exactos, y en los recursos y datos que crea el flujo de trabajo.
Con cada versión, publicamos cuántas pruebas de fidelidad pasan para cada servicio, como k de n. Por ejemplo, 40 de 50 significa que 40 de las 50 pruebas de fidelidad del servicio pasan. El conjunto de pruebas de fidelidad es público en el repositorio aws-emulator-evaluation-suite de GitHub, incluidas las que aún no pasan, para que puedas ver lo que hemos verificado y ejecutar las pruebas de fidelidad tú mismo. Lee una puntuación como una instantánea de un producto que está mejorando. Cuando añadimos pruebas de fidelidad, una puntuación puede bajar aunque el emulador mejore.
Si el emulador aún no implementa una operación, devuelve HTTP 501 (Not Implemented), por lo que tus pruebas fallan de inmediato. Si el emulador se comporta de forma diferente a AWS, puedes comunicárnoslo abriendo un issue en el repositorio de AWS Emulator en GitHub.
Cómo se construye el emulador
AWS Emulator lo construyen y mantienen agentes a partir de los modelos de API de AWS, utilizando Amazon Bedrock AgentCore Runtime Instances, AWS CodePipeline y AWS CodeCommit, por lo que se mantiene actualizado con AWS a medida que esos modelos cambian.
Un grupo de agentes busca lagunas, tanto comparando las respuestas del emulador con AWS real como comparando estáticamente el código del emulador con los modelos Smithy publicados, y registra un issue por cada laguna que encuentra. Otro grupo toma un issue, escribe pruebas, implementa el comportamiento y revisa el cambio en cuanto a corrección, rendimiento y seguridad. Cuando el cambio está listo, se sube a un repositorio de origen, y esa subida desencadena una ejecución de AWS CodePipeline que ejecuta las pruebas de fidelidad antes de que el cambio se publique en el repositorio público de GitHub.
Cómo lo mantenemos seguro
Como el código lo escriben agentes, un agente de seguridad independiente revisa los cambios de forma adversarial, tanto mientras se realiza la corrección como de nuevo en el pipeline de lanzamiento como comprobación final antes de que se publique algo.
La seguridad de tu propio uso sigue siendo una responsabilidad compartida. Construimos el emulador para que se ejecute de forma segura en tu equipo: por defecto solo escucha en tu propio ordenador y rechaza las solicitudes que no estén firmadas con sus propias claves. Tú decides dónde se ejecuta, qué datos pones en él y cómo pruebas antes de producción. No uses el emulador para probar si tu aplicación es segura. No evalúa las políticas de AWS Identity and Access Management (IAM) ni las políticas basadas en recursos de la misma manera que AWS, por lo que una solicitud que AWS denegaría podría tener éxito en el emulador. Mantén las credenciales reales fuera del entorno de tus trabajos de prueba y prueba tu configuración de seguridad y toda tu aplicación en AWS antes de pasar a producción.
Ya disponible
AWS Emulator está disponible con carácter general hoy. No tiene ningún cargo adicional por servicio. Solo pagas por los recursos de AWS cuando despliegas en AWS. Puedes instalarlo desde paquetes RPM o Debian en Linux, ejecutarlo en Docker en macOS y Windows, o compilarlo desde el código fuente, y funciona con los SDK de AWS y la AWS CLI una vez que configuras las variables de entorno. En el lanzamiento tiene algunas limitaciones. No evalúa las políticas de IAM de la misma manera que AWS, y cada emulador actúa como una única cuenta, sin comportamiento entre cuentas ni entre regiones. El grado de coincidencia con AWS varía según el servicio y la funcionalidad. Para ver qué tan bien cubre el emulador los servicios que utilizas, consulta las puntuaciones de fidelidad en la documentación de AWS Emulator.
Si quieres comprobar la disponibilidad regional, visita la página de capacidades de AWS por región en AWS Builder Center. Si quieres llamar a API, buscar documentación, encontrar disponibilidad regional y consultar la solución de problemas sobre esta nueva función, prueba a utilizar AWS MCP Server y los complementos con tu herramienta de IA preferida.
Para empezar, consulta la documentación de AWS Emulator.
Daniel Abib es arquitecto sénior especialista en soluciones en AWS, centrado en inteligencia artificial generativa y Amazon Bedrock, y apasionado por la tecnología sin servidor. Ayuda a startups y empresas a crear aplicaciones impulsadas por IA y a modernizarse con arquitecturas nativas de la nube. Tres veces finalista de Ironman y cuatro veces ponente en re:Invent, aporta la misma mentalidad de resistencia a la construcción de soluciones en la nube.
Cargando comentarios…