Teve uma época em que a AWS era sinônimo de inovação. Lá por 2008, 2009, quando você precisava de um servidor, a alternativa era alugar uma máquina física por meses, pagar setup fee, esperar dias. Aí veio o EC2 e, de repente, você tinha uma máquina rodando em 3 minutos. Era mágico.

Eu lembro da sensação de rodar meu primeiro aws s3 cp e pensar “isso muda tudo”. E mudava mesmo. S3, SQS, EC2 — serviços simples, com APIs claras, que faziam exatamente o que prometiam. A AWS democratizou a infraestrutura e permitiu que startups competissem com gigantes sem precisar de data centers.

Mas algo aconteceu no caminho.

A AWS de 2026 Não É a AWS de 2010

Um desenvolvedor australiano chamado Andrew Stuart publicou um post essa semana que explodiu no Hacker News com mais de 500 upvotes. O título? “I returned to AWS and was reminded why I left.” Depois de anos longe, ele voltou para a plataforma para rodar uns benchmarks com Claude via AWS Bedrock. Em quatro dias, já estava planejando a migração de volta para fora.

A história dele ressoou com milhares de devs porque toca num ponto que muita gente sente mas poucos verbalizam: a AWS ficou complexa demais para o próprio bem.

O que era um conjunto de serviços simples e poderosos virou um labirinto de 200+ serviços, cada um com seu modelo de billing, suas pegadinhas de preço e suas armadilhas de vendor lock-in. É como voltar para um restaurante favorito depois de anos e descobrir que o cardápio tem 47 páginas, os preços estão em código e o garçom quer te vender um seguro junto com a comida.

O Pesadelo do Billing: Onde a AWS Realmente Machuca

Vamos falar de números. Porque é nos números que a coisa fica feia.

Andrew rodou um DynamoDB por um dia. Um dia. A conta? $75 dólares. Para um banco de dados NoSQL que ele usou para testes.

Mas o DynamoDB é só a ponta do iceberg. O verdadeiro vilão da AWS tem nome: egress costs.

Leu certo. A AWS cobra 9 centavos de dólar por cada gigabyte que sai dos servidores dela. Parece pouco? Faz a conta: um site que serve 10TB por mês paga $920 só de transferência de dados. No Hetzner, pagaria zero.

Segundo a Gartner, custos de egress representam entre 10% e 15% da conta total de cloud da maioria das empresas. Em alguns casos, chegam a 40%. E aqui está o golpe de mestre: para migrar seus dados para fora da AWS, você precisa pagar… egress. Ou seja, quanto mais dados você tem na AWS, mais caro fica sair. Lock-in financeiro na veia.

# Quanto você está pagando de egress agora?
aws ce get-cost-and-usage \
  --time-period Start=2026-04-01,End=2026-04-30 \
  --granularity MONTHLY \
  --metrics "BlendedCost" \
  --filter '{
    "Dimensions": {
      "Key": "USAGE_TYPE_GROUP",
      "Values": ["EC2: Data Transfer - Internet (Out)"]
    }
  }' | jq '.ResultsByTime[].Total.BlendedCost'

Roda esse comando e se prepara para o susto.

IAM: O Sistema de Permissões que Precisa de Permissão para Ser Entendido

Se billing é onde a AWS machuca o bolso, o IAM é onde ela machuca a alma.

O Identity and Access Management da AWS é, sem exagero, um dos sistemas mais desnecessariamente complexos já criados na computação moderna. Andrew Stuart descreveu como “hideously complex auth and access rules system”, e ele está sendo gentil.

Para dar permissão a uma Lambda para ler um bucket S3, você precisa:

1. Criar uma IAM Role
2. Criar uma IAM Policy com as permissões específicas
3. Attachar a Policy à Role
4. Configurar a Trust Policy para que Lambda possa assumir a Role
5. Associar a Role à Lambda
6. Verificar que o bucket S3 não tem uma Bucket Policy que contradiz tudo isso
7. Rezar

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::meu-bucket",
        "arn:aws:s3:::meu-bucket/*"
      ]
    }
  ]
}

Isso é a versão simples. Agora imagina quando você tem 50 Lambdas, 30 buckets, 10 filas SQS, 5 bancos de dados, e precisa que cada serviço tenha o mínimo de permissões necessárias. Você precisa de um time dedicado só para gerenciar IAM. E esse time precisa de um manual de 400 páginas que a própria AWS mantém.

Na Vercel, você deploya uma função e ela acessa o que precisa. No Railway, idem. No Supabase, as permissões são Row Level Security no Postgres — algo que qualquer dev com SQL básico entende. Na AWS, você precisa de um certificado AWS Solutions Architect para não se perder.

Lambda: A Promessa que Virou Armadilha

Serverless era para ser o futuro. “Não se preocupe com servidores, só escreva código.” Era o pitch do Lambda quando foi lançado. E fazia sentido — pagar só pelo que usa, escalar automaticamente, zero manutenção.

Na prática? Lambda é uma das maiores armadilhas de vendor lock-in que a indústria já criou.

Andrew descreve a complexidade de desenvolvimento como “MASSIVE”. E eu concordo. Uma Lambda simples que processa uploads precisa de:

• API Gateway (billing separado)
• CloudWatch Logs (billing separado)
• Layers para dependências
• Variáveis de ambiente gerenciadas via Parameter Store ou Secrets Manager (billing separado, é claro)
• Cold starts que podem chegar a 10+ segundos com Java ou .NET

# Uma Lambda "simples" que lê do S3 e salva no DynamoDB
import boto3
import json

def handler(event, context):
    s3 = boto3.client('s3')
    dynamo = boto3.resource('dynamodb')
    table = dynamo.Table('minha-tabela')

    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']

    obj = s3.get_object(Bucket=bucket, Key=key)
    data = json.loads(obj['Body'].read())

    table.put_item(Item=data)

    return {'statusCode': 200}

Parece simples? Agora deploya isso. Você precisa de um template.yaml do SAM ou um serverless.yml, configurar as permissões IAM (voltamos ao pesadelo anterior), configurar o trigger do S3, definir o timeout, o memory size, as layers… Um container Docker com FastAPI faz a mesma coisa com 1/10 da complexidade e roda em qualquer lugar.

O pior: todo o código que você escreve para Lambda é acoplado ao ecossistema AWS. Quer migrar para Google Cloud Functions? Reescreva tudo. Quer rodar on-premise? Boa sorte. Você não construiu um software — construiu uma extensão da AWS.

A Conta Suspensa: 4 Dias Sem Email

Essa parte da história do Andrew é a mais absurda. Ele voltou para a AWS, lançou umas instâncias EC2 mais caras para benchmark, e a AWS suspendeu a conta dele por “suspected security breach”. Faz sentido como medida de segurança, certo?

O problema: a conta incluía o AWS WorkMail, que era o email de negócios dele. A suspensão derrubou o email por quatro dias. O suporte prometeu responder em 24 horas e não respondeu. Ele ficou sem email comercial porque decidiu testar uns servidores.

Imagina isso acontecendo com uma empresa. Sexta-feira à noite, a AWS detecta “atividade suspeita” (aka: você decidiu usar um serviço mais caro do que o habitual), suspende tudo, e segunda-feira de manhã ninguém recebe email. Quanto custa isso para um negócio?

Esse é o tipo de risco que não aparece em nenhum pricing calculator.

AWS vs Open Source: Uma Relação Tóxica

Tem outro aspecto que muita gente esquece: o histórico da AWS com open source é, no mínimo, predatório.

O padrão é conhecido:

1. Comunidade open source cria um projeto incrível (Elasticsearch, Redis, MongoDB)
2. Projeto ganha tração, empresas começam a usar
3. AWS pega o código, cria um serviço gerenciado (OpenSearch, ElastiCache, DocumentDB)
4. AWS cobra pelo serviço sem contribuir significativamente com o projeto original
5. Projeto original perde receita e precisa mudar de licença para sobreviver

O Elasticsearch mudou para SSPL. O Redis mudou para uma licença dual. O MongoDB já tinha ido para SSPL antes. Tudo por causa da mesma empresa.

Andrew resume bem: “AWS stomped on open source projects… capturing hosted-service money after those communities had built the markets.” A AWS construiu um império de $100 bilhões/ano em receita em cima do trabalho de comunidades que ela não financiou.

O Cloud Exit: A Tendência de 2026

E aqui a coisa fica interessante. Porque não é só o Andrew. Existe um movimento real e crescente de empresas saindo da AWS — e da cloud em geral.

A galera do 37signals (criadores do Ruby on Rails e Basecamp) fez as contas em 2023 e estimaram economizar $7 milhões em 5 anos saindo da cloud. Em 2026, essa tendência ganhou um nome: Cloud Repatriation.

Dados recentes mostram que:

• Empresas que saem da AWS reportam redução de até 80% nos custos de cloud
• O cargo mais valorizado do mercado em 2026 não é AWS Solutions Architect — é Platform Engineer que sabe montar Private Cloud
• A Polônia declarou cloud repatriation como questão de segurança nacional
• O Hetzner e a DigitalOcean estão crescendo como alternativas para quem quer simplicidade

Para quem não precisa da escala da AWS (e a verdade inconveniente é que a maioria das empresas não precisa), um servidor dedicado no Hetzner por €50/mês entrega mais performance do que uma instância EC2 de $300/mês. Com Docker Compose e um reverse proxy, você tem tudo que precisa.

# docker-compose.yml - sua "cloud" por €50/mês
version: "3.8"
services:
  app:
    image: meu-app:latest
    ports:
      - "8080:8080"
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/app
    deploy:
      resources:
        limits:
          cpus: "4"
          memory: 8G

  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=segura123

  redis:
    image: redis:7-alpine

  caddy:
    image: caddy:2
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile

volumes:
  pgdata:

App, banco, cache e HTTPS automático. Sem IAM, sem billing surpresa, sem 200 serviços para gerenciar. É claro que isso não serve para todo mundo — se você é a Netflix ou o Spotify, precisa de auto-scaling global. Mas se você é uma startup com 10.000 usuários? Esse docker-compose.yml resolve.

Quando a AWS Ainda Faz Sentido

Seria desonesto dizer que a AWS é ruim para todo mundo. Existem cenários onde ela ainda é a melhor opção:

• Escala massiva e imprevisível — se você tem picos de 100x o tráfego normal, auto-scaling sob demanda é valioso
• Regulamentação específica — setores como saúde e finanças às vezes exigem certificações que só os big clouds têm
• Serviços sem equivalente — AWS Bedrock para rodar modelos de IA, ou SageMaker para ML, ainda são difíceis de replicar on-premise
• Time que já domina o ecossistema — se sua equipe tem 5 anos de experiência AWS, migrar tem um custo de aprendizado

O problema é que a AWS se vende como solução para todo mundo, quando na realidade é otimizada para empresas que gastam $1 milhão por mês ou mais. Para o resto de nós, ela é complexidade desnecessária com preço premium.

As Alternativas que Merecem Sua Atenção

Se você está considerando sair — ou simplesmente nunca entrar — aqui estão as opções mais interessantes em 2026:

O Cloudflare merece destaque especial: o R2 (storage compatível com S3) tem zero egress cost. Isso mesmo, zero. Você pode servir petabytes sem pagar um centavo de transferência. Para muitos casos de uso, isso sozinho já justifica a migração.

O Que Isso Significa Para Você

A AWS não vai morrer. Ela fatura mais de $100 bilhões por ano e tem contratos enterprise de longo prazo com metade das Fortune 500. Mas a narrativa mudou.

Em 2015, não usar cloud era visto como atraso tecnológico. Em 2026, sair da cloud é visto como maturidade. Empresas maduras fazem contas, e as contas frequentemente não fecham a favor da AWS.

Se você está começando um projeto novo, minha sugestão: comece simples. Um VPS no Hetzner ou DigitalOcean, Docker Compose, Postgres, Redis. Quando (e se) você realmente precisar de auto-scaling global, multi-região e serviços gerenciados, aí sim considere a AWS. Mas faça isso como uma decisão consciente baseada em necessidade real — não porque “todo mundo usa” ou porque o tutorial do YouTube usava.

O Andrew Stuart voltou para a AWS e saiu em 4 dias. Talvez a pergunta certa não seja “por que ele saiu tão rápido?” — mas sim “por que demorou tanto para perceber que não precisava voltar?”

—

Fonte de inspiração: I returned to AWS and was reminded why I left — Andrew Stuart