Imagina abrir o GitHub e encontrar um repositório da AWS com 29.684 commits, 322 releases e nenhuma linha de código escrita ou revisada por um ser humano. Parece fanfic de dev no LinkedIn, mas aconteceu: no dia 11 de novembro de 2026, a Amazon lançou o AWS Emulator, um emulador local e gratuito de praticamente toda a nuvem AWS, construído do zero por agentes autônomos de IA.

O projeto matou dois coelhos com uma cajadada só. Primeiro, entregou o que a comunidade pedia há anos: uma forma oficial de testar código contra APIs da AWS sem gastar um centavo e sem precisar de conta. Segundo, provou que agentes de IA conseguem construir software de produção em escala, sozinhos, de ponta a ponta.

Eu acompanho cloud desde os tempos em que “serverless” ainda causava calafrios. E posso dizer: esse lançamento muda o jogo pra quem desenvolve na AWS.

O que é o AWS Emulator (e por que você deveria ligar)

O AWS Emulator é um binário único de 163 MB, escrito em Rust, que roda no seu computador e responde chamadas da AWS CLI e dos SDKs exatamente como a nuvem real faria. Sem conta AWS, sem cartão de crédito, sem surpresas na fatura.

Você aponta seu SDK pro endpoint local (127.0.0.1:9297), e pronto. O emulador intercepta as chamadas e devolve respostas no mesmo formato que a AWS retornaria. Funciona com qualquer linguagem: Python (boto3), JavaScript, Go, Java, .NET, Rust. Se o SDK da AWS suporta, o emulador também suporta.

A proposta é simples: você desenvolve e testa local, de graça. Quando está tudo funcionando, deploya na AWS real e aí sim paga pelo uso. A Amazon ganha dinheiro quando você vai pra produção, não quando está debugando um Lambda às 2h da manhã.

# Instalar no Linux (Debian/Ubuntu)
curl -LO https://github.com/aws/aws-emulator/releases/latest/download/aws-emulator_amd64.deb
sudo dpkg -i aws-emulator_amd64.deb

# Iniciar o emulador
aws-emulator

# Em outro terminal, apontar a CLI pro emulador
export AWS_ENDPOINT_URL=https://127.0.0.1:9297
export AWS_CA_BUNDLE=~/.aws/emulator/ca.pem

# Testar criando um bucket S3
aws s3 mb s3://meu-bucket-local
aws s3 ls

Inicia em cerca de 23 milissegundos. Leu certo: milissegundos. Não precisa de Docker, não precisa de root, não precisa esperar container subir. É um binário nativo que simplesmente funciona.

61 dias, 29.684 commits: a timeline que constrange

Aqui é onde a coisa fica interessante (e um pouco assustadora, se você é dev).

O repositório foi criado em 11 de setembro de 2026. Sessenta e um dias depois, no dia 11 de novembro, saiu a versão 1.0.322. Nesse intervalo:

Segundo Matthew Goldberg, Senior Principal Engineer da AWS no projeto, “o time não escreveu nem revisou nenhuma linha de código”. Zero. Nada. Os agentes autônomos fizeram tudo: derivaram testes de fidelidade dos modelos Smithy públicos da AWS, corrigiram esses testes contra a AWS real, e depois construíram o emulador até passar nos testes. Agentes de segurança rodaram revisões adversariais em cada merge gate.

A stack por trás disso usa Amazon Bedrock AgentCore Runtime Instances, AWS CodePipeline e AWS CodeCommit. Ou seja, a AWS usou sua própria infraestrutura de IA pra construir uma ferramenta que emula sua própria infraestrutura. É recursão corporativa no nível mais alto.

Arquitetura: Rust, Smithy e modularidade extrema

O emulador é um workspace Cargo com mais de 160 crates, cada um representando um serviço AWS. A estrutura do repositório é organizada assim:

aws-emulator/
├── services/          # Um crate por serviço (S3, Lambda, DynamoDB...)
│   ├── s3/
│   ├── lambda/
│   ├── dynamodb/
│   └── ... (160+ crates)
├── core/
│   ├── router/        # Binário principal que monta todos os serviços
│   └── embedded/      # Modo in-process para testes Rust
├── vendor/            # Framework (read-only, atualizado por release)
└── issues/            # Gaps de fidelidade documentados
    ├── things-that-do-not-work/
    └── things-that-now-work/

Cada serviço é dirigido por um modelo Smithy, que é o formato que a AWS usa internamente pra definir suas APIs. O modelo gera automaticamente o protocolo de comunicação, então o emulador fala exatamente o mesmo “idioma” que a AWS real. Quando a AWS atualiza uma API, o modelo Smithy atualiza, e os agentes regeneram o crate correspondente.

A escolha de Rust não é acidental. Performance previsível, sem garbage collector, e a possibilidade de compilar tudo num binário estático são vantagens enormes pra uma ferramenta que precisa emular centenas de serviços simultaneamente sem engasgar.

Dois modos de uso: server e embedded

O emulador roda de duas formas, cada uma com seu caso de uso.

Modo Server (qualquer linguagem)

O mais comum. Você inicia o emulador como processo separado e aponta seus SDKs pro endpoint local:

import boto3

# Apontar para o emulador local
session = boto3.Session()
dynamodb = session.resource(
    'dynamodb',
    endpoint_url='https://127.0.0.1:9297',
    verify='/home/user/.aws/emulator/ca.pem'
)

# Criar tabela normalmente
table = dynamodb.create_table(
    TableName='usuarios',
    KeySchema=[
        {'AttributeName': 'user_id', 'KeyType': 'HASH'}
    ],
    AttributeDefinitions=[
        {'AttributeName': 'user_id', 'AttributeType': 'S'}
    ],
    BillingMode='PAY_PER_REQUEST'
)

# Inserir e consultar dados
table.put_item(Item={'user_id': '123', 'nome': 'Lucas'})
response = table.get_item(Key={'user_id': '123'})
print(response['Item'])

Funciona com qualquer SDK, qualquer linguagem. Muda o endpoint, o resto do código fica igual.

Modo Embedded (Rust)

Esse é o diferencial que nenhum concorrente tem. Se você programa em Rust, pode compilar o emulador diretamente nos seus binários de teste. Cada teste roda sua própria instância isolada, sem rede, sem configuração externa.

use aws_emulator::Emulator;

#[tokio::test]
async fn test_s3_upload() {
    let emu = Emulator::builder()
        .telemetry(Telemetry::Off)
        .build()
        .await;

    let client = emu.s3_client();
    client.create_bucket()
        .bucket("test-bucket")
        .send()
        .await
        .unwrap();

    // Teste isolado, sem side effects
}

Isolamento por teste sem overhead de rede. Se você trabalha com Rust na AWS, isso é transformador.

O que funciona (e o que ainda não funciona)

Vamos ser honestos: o emulador não é perfeito. Com 61 dias de vida, seria ingenuidade esperar paridade total com uma nuvem que tem mais de 18 anos. Os números de fidelidade da release 1.0.322 contam a história real:

56% de cobertura pode parecer pouco, mas tem contexto importante aqui. O emulador publica scores de fidelidade por serviço a cada release, num arquivo scores.json.gz. Isso significa que você sabe exatamente o que funciona e o que não funciona antes de usar. Nenhum concorrente oferece esse nível de transparência.

Serviços que funcionam bem

Se sua aplicação é baseada em filas, funções e tabelas, você já consegue testar bastante coisa local:

• SQS: envio e recebimento de mensagens funcional
• SNS: publicações chegam nas filas inscritas
• EventBridge: roteamento de eventos para targets
• Lambda: execução de funções Python inline
• Step Functions: execuções completam corretamente
• DynamoDB: suporte a queries com GSI
• CloudFormation: create, update, delete, change sets, rollback com histórico de eventos
• S3: operações básicas de bucket e objetos

O que ainda engasga

• Falsos positivos: CloudWatch alarms, ElastiCache, CloudFront e load balancers reportam CREATE_COMPLETE mesmo sem implementação real no backend. CloudFront e ALB retornam nomes DNS plausíveis que não levam a lugar nenhum.
• Operações incompletas: API Gateway, ECR e WAFv2 criam recursos com sucesso, mas falham no primeiro update com NotImplemented.
• Segurança: o emulador nunca nega requests. Não avalia políticas IAM. Não faz validação cross-account. É um ambiente de desenvolvimento, não um simulador de segurança.
• Lambda runtime: o SDK dentro do runtime cobre poucos serviços (SNS e S3 notavelmente ausentes).

Uma decisão de design inteligente: operações não implementadas retornam HTTP 503 em vez de sucesso falso. Como diz a documentação: “um emulador que silenciosamente retorna dados plausíveis mas errados é pior que nenhum emulador”. Eu concordo completamente.

LocalStack morreu, longa vida ao AWS Emulator?

Impossível falar do AWS Emulator sem mencionar o elefante na sala: o LocalStack.

O LocalStack era a solução da comunidade desde 2016. Python, container Docker, pip install, e uma base gigante de usuários. 65 mil stars no GitHub. Referências em milhares de respostas no Stack Overflow. Era o padrão de facto pra desenvolvimento local com AWS.

Até março de 2026, quando o repositório open source foi arquivado. A versão Community gratuita parou de receber manutenção. A distribuição atual exige conta e token de autenticação. Os planos pagos vão de $39 a $89 por mês.

O timing da AWS foi cirúrgico. O LocalStack fecha o código, começa a cobrar, e dois meses depois a AWS lança uma alternativa gratuita, oficial e com cobertura absurdamente maior. Coincidência? Pode até ser. Mas é daquelas coincidências que fazem o mercado funcionar.

Dito isso, o LocalStack tem uma década de battle-testing que o AWS Emulator simplesmente não tem. Muita empresa tem pipelines inteiros dependendo do LocalStack. A migração não vai ser instantânea.

O padrão de teste que faz sentido

A galera que já está usando o emulador em produção desenvolveu um padrão que vale compartilhar:

# .github/workflows/test.yml
name: Tests
on: [push, pull_request]

jobs:
  emulator-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install AWS Emulator
        run: |
          curl -LO https://github.com/aws/aws-emulator/releases/latest/download/aws-emulator_amd64.deb
          sudo dpkg -i aws-emulator_amd64.deb
      - name: Start emulator
        run: aws-emulator &
      - name: Run emulator-safe tests
        run: pytest tests/ -m "emulator"
        env:
          AWS_ENDPOINT_URL: https://127.0.0.1:9297

  real-aws-tests:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - name: Run real AWS tests
        run: pytest tests/ -m "real_aws"
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_KEY }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET }}

A ideia: marque seus testes como emulator ou real_aws. Rode os testes do emulador em todo PR (rápidos, grátis, 36 checks em menos de 3 minutos). Mantenha a suite real AWS como árbitro no branch main. Assim, o emulador acelera seu ciclo de desenvolvimento enquanto a AWS real continua sendo a fonte de verdade.

Uma dica crucial: sempre leia de volta o estado real via APIs do serviço. Não confie só no status code. Se o emulador diz que criou um recurso, faça um describe ou get pra confirmar que os dados estão corretos.

CC0: a licença que evita a dor de cabeça da IA

A escolha de licença é esperta. O AWS Emulator usa CC0 1.0 Universal, que é basicamente domínio público. Isso não é acidental.

Código gerado por IA vive num limbo jurídico. Quem é o autor? O modelo? A empresa que treinou o modelo? O agente que executou? Com CC0, a AWS simplesmente diz: “não importa, use como quiser”. Sem restrições, sem atribuição obrigatória, sem dúvidas sobre copyright.

O diretório vendor/ mantém licença Apache 2.0, o que faz sentido: é framework escrito por humanos, com proteção de patente que o CC0 não oferece.

Telemetria: o opt-out que você precisa conhecer

Um detalhe que pegou mal na comunidade: telemetria ativada por padrão. O emulador coleta dados de uso automaticamente ao iniciar. A AWS jura que não inclui conteúdo de requests/responses, credenciais ou dados pessoais, mas dev é desconfiado por natureza (e deveria ser).

Desativar é simples:

# Via flag na linha de comando
aws-emulator --telemetry off

# Via variável de ambiente
export EMULATOR_TELEMETRY=off

# Via arquivo de configuração
echo 'telemetry = "off"' >> ~/.aws/emulator/config.toml

No modo embedded (Rust), passe Telemetry::Off na inicialização. Recomendo desativar em CI/CD e em qualquer ambiente que processe dados sensíveis, mesmo que sejam dados de teste.

O que isso significa pra quem desenvolve na AWS

Três takeaways pra levar pro seu dia a dia:

Adote gradualmente. Não jogue fora seu pipeline de testes atual. Comece com os serviços que têm score alto de fidelidade (SQS, DynamoDB, S3) e vá expandindo conforme o emulador melhora. Com 5 releases por dia, os gaps fecham rápido.

Monitore os scores. A cada release, baixe o scores.json.gz e verifique se os serviços que você usa melhoraram. Automatize isso no CI se possível. Você não quer descobrir que um serviço regrediu no meio de um deploy.

Considere Rust. Se você ainda não olhou Rust pra backend AWS, o modo embedded é um argumento forte. Testes isolados sem rede, compilados junto com o código, rodando em milissegundos. É o tipo de developer experience que muda a forma como você escreve testes.

E se você usa LocalStack hoje, não entre em pânico. Avalie a migração com calma. O AWS Emulator está evoluindo absurdamente rápido, mas o LocalStack tem anos de edge cases resolvidos que o emulador ainda vai encontrar.

A mensagem maior aqui é outra, e vale repetir: uma equipe de agentes de IA construiu, em 61 dias, um emulador funcional de 426 serviços AWS. Sem intervenção humana. Se isso não te faz repensar o que “desenvolvimento de software” vai significar em 2027, eu não sei o que faz.

Fonte de inspiração: aws/aws-emulator no GitHub

Leia também: 48 Agentes de IA Acharam uma Pirâmide Maia que Nenhum Arqueólogo Encontrou | IA Não Está Substituindo SREs: Está Deixando Eles Mais Burros