AWS Emulator simula serviços da AWS no laptop sem custo de nuvem

O que mudou

A AWS anunciou o AWS Emulator, um emulador local dos serviços da AWS que roda inteiramente na sua máquina. Ele expõe um endpoint HTTPS em 127.0.0.1 que fala as mesmas APIs que o AWS CLI, os AWS SDKs e agentes de código como Kiro ou Claude Code já usam contra a nuvem real. A diferença é que nenhuma chamada sai do seu laptop: o código-fonte está aberto no GitHub.

O emulador trabalha com uma única conta fixa, 000000000000, e gera credenciais que começam com EMULATOR de propósito, para ninguém confundir com uma chave real. Qualquer requisição assinada com credencial diferente é rejeitada. É assim que você sabe, sem ambiguidade, que está testando local e não em produção.

Onde está disponível

Em Linux, a instalação é via pacote RPM ou Debian, testada em Amazon Linux 2023 com dnf. Em macOS e Windows a AWS não publica imagem pronta: é preciso construir uma imagem Docker a partir de um Dockerfile disponível na documentação oficial.

A fonte não menciona restrição por Region do emulador em si, já que ele roda localmente e não depende de infraestrutura da AWS. Nos exemplos oficiais a variável AWS_REGION é configurada como us-east-1, mas nada no anúncio impede apontar sa-east-1 (São Paulo) se o seu código de aplicação já espera essa Region em produção. O comportamento cross-Region, porém, não é simulado: cada instância do emulador atua como uma conta única, sem replicar nada entre regiões.

Quanto custa

Não existe taxa adicional de serviço para rodar o AWS Emulator. Você só paga por recursos da AWS quando efetivamente faz deploy na nuvem real; rodar comandos de teste contra o emulador, por mais intenso que seja o loop, não gera cobrança.

Como começar

Em Amazon Linux 2023, o caminho mais direto é baixar o pacote e instalar com dnf:

PKG=https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest
sudo dnf install -y $PKG/aws-emulator-x86_64.rpm
aws-emulator -v
aws-emulator

O processo sobe um servidor HTTPS em 127.0.0.1:9297, gera credenciais, config e certificado em ~/.aws/emulator/9297/. Scripts de CI podem esperar o serviço ficar pronto consultando /__admin/health antes de rodar os testes.

Para apontar o AWS CLI para o emulador, exporte as variáveis abaixo e remova qualquer credencial real do shell:

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_REGION=us-east-1
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE

curl --cacert ~/.aws/emulator/9297/ca.pem https://127.0.0.1:9297/__admin/health
aws sts get-caller-identity

Com isso, comandos que você já usa continuam funcionando sem alteração de código:

aws s3 mb s3://local-getting-started
echo "hello from the emulator" > hello.txt
aws s3 cp hello.txt s3://local-getting-started/
aws s3 ls s3://local-getting-started/

O mesmo vale para fluxos com DynamoDB executados por um agente de código. No próprio anúncio, a AWS mostra o Kiro criando uma tabela, gravando um item e lendo de volta, tudo contra o emulador:

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"}}'

Para quem já escreve testes automatizados em Rust, há modo embutido: o crate aws-emulator-embedded, em [dev-dependencies] no Cargo.toml, instancia o emulador dentro do próprio processo de teste, com estado isolado por instância, sem servidor externo e sem rede. Hoje é a única linguagem com esse modo.

O que muda para quem já usa

O ganho prático é no ciclo de feedback. Um pipeline de CI que hoje espera um deploy real numa Region para checar se uma tabela DynamoDB foi criada corretamente passa a rodar esse mesmo teste em milissegundos, sem fila de deploy e sem recurso provisionado só para o teste.

Isso tem limites que a própria AWS documenta e que valem anotar antes de confiar demais na ferramenta:

• O emulador não avalia políticas de IAM nem políticas baseadas em recurso da forma como a AWS faz: uma chamada que a AWS negaria pode funcionar no emulador.
• Cada instância atua como uma única conta, sem comportamento cross-account ou cross-Region.
• Operação ainda não implementada devolve HTTP 501, em vez de simular algo parecido, o que evita falso positivo mas exige ajuste manual.
• Com SDKs como o AWS SDK for Java, é preciso configurar o trust store apontando para o certificado do emulador antes de qualquer chamada funcionar.

Para medir se o emulador merece confiança, a equipe publica, a cada release, uma pontuação de fidelidade por serviço no formato k de n (por exemplo, 40 de 50 testes passando), comparando a resposta do emulador com a resposta real da AWS, status, corpo e mensagem de erro inclusos. O conjunto de testes está público no repositório aws-emulator-evaluation-suite, incluindo os que ainda falham.

Em resumo: o emulador reduz ciclo de desenvolvimento e custo de experimento, mas não substitui validação de IAM nem teste de segurança contra a conta real. A régua prática é usar o emulador para lógica de aplicação e integração rápida, e manter um estágio contra a AWS real, ou ao menos uma conta de staging, antes de qualquer coisa ir para produção.

Fonte: iMasters