Por Daniel Abib, em 11 NOV 2026, nas categorias Amazon Bedrock AgentCore, Announcements, Developer Tools, Launch, Technical How-to
Hoje anunciamos o AWS Emulator, um emulador local para Amazon Web Services (AWS) que você executa na sua máquina. A AWS Command Line Interface (AWS CLI), os AWS SDKs e seus agentes de codificação se comunicam com ele por meio de um endpoint HTTPS local usando as mesmas APIs da AWS que usariam na nuvem, a partir do seu laptop. O AWS Emulator não tem taxa de serviço adicional. Você paga apenas pelos recursos da AWS quando faz deploy na AWS. Seu código-fonte está no GitHub. Você o instala a partir de um pacote RPM ou Debian no Linux e, no macOS e Windows, você o executa no Docker.
Como funciona
Você instala o emulador, inicia-o e aponta suas ferramentas para o endpoint local. Quando o AWS Emulator é iniciado, ele gera suas próprias credenciais, um arquivo de configuração e um certificado, e os grava em ~/.aws/emulator/9297/. Você define variáveis de ambiente para que o AWS SDK converse com o seu laptop em vez da AWS, e o código da sua aplicação permanece inalterado.
A partir daí, seus testes existentes, scripts de CLI e agentes de codificação continuam funcionando como já fazem. Um teste de unidade que cria uma tabela do Amazon DynamoDB, grava um item e o lê de volta é o mesmo teste, e ele roda na sua máquina sem necessidade de deploy. Um agente de codificação pode criar recursos, verificar o resultado e iterar novamente sem esperar por um deploy em uma região.
O emulador é implementado em Rust para que permaneça leve em CPU e memória em um laptop. Ele suporta as APIs de serviços da AWS que possuem um modelo de API no repositório de modelos de API da AWS no GitHub e, por ser construído a partir desses modelos — os mesmos usados pelos AWS SDKs —, suas requisições e os erros que você recebe têm o mesmo formato que na AWS.
Se você é desenvolvedor, especialmente se trabalha com agentes de codificação como Kiro ou Claude Code, pode usar esse ciclo para testar interações com a AWS de complexidade real localmente.
Vamos experimentar
Para começar, instalei o pacote no Amazon Linux 2023. O pacote adiciona o comando aws-emulator em /usr/bin/, então ele fica no PATH.
PKG=https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest
sudo dnf install -y $PKG/aws-emulator-x86_64.rpm
aws-emulator -vNo macOS e Windows, você constrói uma imagem Docker a partir do Dockerfile curto disponível na documentação e executa o emulador em um contêiner. Não publicamos uma imagem pronta.
Iniciei o emulador com aws-emulator. Ele serve HTTPS em 127.0.0.1:9297, de modo que apenas o meu próprio computador pode acessá-lo, e grava seu log como linhas JSON que mostram o endereço, o arquivo de configuração e o arquivo de certificado.
aws-emulatorEm outro terminal, defini as variáveis de ambiente que apontam a AWS CLI para o emulador e desconfigurei quaisquer variáveis que pudessem fornecer credenciais reais da 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_PROFILEO emulador gera novas chaves toda vez que é iniciado. Seus IDs de chave de acesso começam com EMULATOR, então você não pode confundi-los com chaves reais da AWS, e ele rejeita requisições assinadas com quaisquer outras chaves. Para confirmar que meu shell estava falando com o emulador, verifiquei o endpoint de health e a identidade do chamador. O emulador usa uma única conta, 000000000000.
curl --cacert ~/.aws/emulator/9297/ca.pem https://127.0.0.1:9297/__admin/health
aws sts get-caller-identityEm seguida, criei um bucket, copiei um pequeno objeto e o listei.
$ 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/Com a AWS CLI apontada para o meu laptop, eu tinha os mesmos comandos que já uso e um endpoint local que os respondia.
Depois, quis ver como realmente trabalho agora, então, com o emulador ainda rodando, abri o Kiro e pedi que criasse uma tabela do Amazon DynamoDB, gravasse um item e o lesse de volta, tudo contra o AWS Emulator em vez da minha conta 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 a mesma configuração com uma suíte de testes existente, eu iniciaria o emulador, definiria as mesmas variáveis de ambiente no script que roda os testes e os executaria normalmente.
Usando o emulador em processo
Executar o emulador como um processo local oferece um endpoint HTTPS que funciona com a AWS CLI e os AWS SDKs por meio de variáveis de ambiente. Alguns SDKs precisam de uma configuração extra para confiar no certificado do emulador, por exemplo, um trust store para o AWS SDK para Java. Para testes, há uma segunda opção. O AWS Emulator inclui um modo embutido que você instancia diretamente dentro do seu processo de teste e conecta ao SDK por meio do seu cliente HTTP, em vez de falar com um servidor separado pela rede. Cada instância embutida mantém seu próprio estado, de modo que os testes não compartilham buckets, tabelas ou filas, e você pode executar muitos deles em paralelo. O modo embutido está disponível para o AWS SDK para Rust. Você adiciona o crate aws-emulator-embedded do GitHub à seção [dev-dependencies] do seu arquivo Cargo.toml. O exemplo a seguir cria uma tabela do Amazon DynamoDB, grava um item e o lê de volta, totalmente em processo.
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");
}Quando roda como um processo local, o emulador exige que todas as requisições sejam assinadas com Signature Version 4 (SigV4), da mesma forma que a AWS, e expõe um endpoint /__admin/health na mesma porta para que um script ou contêiner possa aguardar até que esteja pronto antes de executar os testes. Por padrão, ele também envia dados anônimos de uso e erro, e você pode desativar isso.
Como medimos a fidelidade
Um emulador só é útil se um teste que passa nele também passaria na AWS, então medimos isso diretamente com testes de fidelidade. Um teste de fidelidade é um programa curto que usa um AWS SDK para executar um fluxo de trabalho, como armazenar um objeto e depois lê-lo e excluí-lo, e verifica como a AWS se comporta. Verificamos cada teste de fidelidade contra a AWS real. Um teste de fidelidade só passa se o emulador corresponder à AWS na resposta de cada chamada, incluindo o código de status, o corpo e o código e mensagem de erro exatos, e nos recursos e dados que o fluxo de trabalho cria.
A cada release, publicamos quantos testes de fidelidade passam para cada serviço, no formato k de n. Por exemplo, 40 de 50 significa que 40 dos 50 testes de fidelidade do serviço passam. O conjunto de testes de fidelidade é público no repositório aws-emulator-evaluation-suite no GitHub, incluindo os que ainda não passam, para que você possa ver o que verificamos e executar os testes de fidelidade você mesmo. Leia uma pontuação como um retrato de um produto que está melhorando. Quando adicionamos testes de fidelidade, uma pontuação pode cair mesmo enquanto o emulador melhora.
Se o emulador ainda não implementa uma operação, ele retorna HTTP 501 (Not Implemented), então seus testes falham imediatamente. Se o emulador se comportar de maneira diferente da AWS, você pode nos informar abrindo uma issue no repositório AWS Emulator no GitHub.
Como o emulador é construído
O AWS Emulator é construído e mantido por agentes a partir dos modelos de API da AWS usando Amazon Bedrock AgentCore Runtime Instances, AWS CodePipeline e AWS CodeCommit, de modo que permanece atualizado com a AWS conforme esses modelos mudam.
Um grupo de agentes procura lacunas, tanto comparando as respostas do emulador com a AWS real quanto comparando estaticamente o código do emulador com os modelos Smithy publicados, e arquiva uma issue para cada lacuna encontrada. Outro grupo pega uma issue, escreve testes, implementa o comportamento e revisa a mudança quanto a correção, desempenho e segurança. Quando a mudança está pronta, ela é enviada para um repositório de origem, e esse push aciona uma execução do AWS CodePipeline que roda os testes de fidelidade antes de a mudança ser publicada no repositório público do GitHub.
Como o mantemos seguro
Como o código é escrito por agentes, um agente de segurança independente revisa as mudanças de forma adversarial, tanto enquanto a correção está sendo feita quanto novamente no pipeline de lançamento, como uma verificação final antes de qualquer coisa ser publicada.
A segurança do seu próprio uso continua sendo uma responsabilidade compartilhada. Construímos o emulador para rodar com segurança na sua máquina: por padrão, ele escuta apenas no seu próprio computador e rejeita requisições que não estejam assinadas com suas próprias chaves. Você decide onde ele roda, quais dados coloca nele e como testa antes da produção. Não use o emulador para testar se sua aplicação é segura. Ele não avalia políticas do AWS Identity and Access Management (IAM) e políticas baseadas em recursos da mesma forma que a AWS, então uma requisição que a AWS negaria pode ter sucesso no emulador. Mantenha credenciais reais fora do ambiente dos seus jobs de teste e teste suas configurações de segurança e toda a sua aplicação na AWS antes de ir para produção.
Já disponível
O AWS Emulator está disponível de forma geral a partir de hoje. Ele não tem taxa de serviço adicional. Você paga apenas pelos recursos da AWS quando faz deploy na AWS. Você pode instalá-lo a partir de pacotes RPM ou Debian no Linux, executá-lo no Docker no macOS e Windows, ou compilar a partir do código-fonte, e ele funciona com os AWS SDKs e a AWS CLI uma vez que você define as variáveis de ambiente. No lançamento, ele tem alguns limites. Ele não avalia políticas do IAM da mesma forma que a AWS, e cada emulador age como uma única conta, sem comportamento entre contas ou entre regiões. O quão próximo ele corresponde à AWS varia por serviço e recurso. Para ver o quão bem o emulador cobre os serviços que você usa, verifique as pontuações de fidelidade na documentação do AWS Emulator.
Se você quiser verificar a disponibilidade regional, visite a página AWS Capabilities by Region no AWS Builder Center. Se quiser chamar APIs, pesquisar documentação, encontrar disponibilidade regional e verificar solução de problemas sobre este novo recurso, tente usar o AWS MCP Server e plugins com sua ferramenta de IA preferida.
Para começar, consulte a documentação do AWS Emulator.
Sobre o autor
Daniel Abib é arquiteto sênior especialista em soluções na AWS, focado em IA generativa e Amazon Bedrock — e apaixonado por serverless. Ele ajuda startups e empresas a criar aplicações com IA e a modernizar com arquiteturas nativas da nuvem. Três vezes finalista do Ironman e quatro vezes palestrante no re:Invent, ele traz a mesma mentalidade de resistência para construir soluções em nuvem.