Voltei para a AWS e lembrei de novo por que fui embora

• Embora tenha apoiado a AWS desde o início, deixou de gostar dela por causa de insatisfações acumuladas, como a estrutura de cobrança complexa e a complexidade geral da plataforma
• Considera que o alto custo do DynamoDB, as taxas de egress que chegam a 9 centavos por gigabyte e as cobranças duplas ou triplas por movimentação interna de dados continuam caras e difíceis de entender
• Voltou para testar o Claude no AWS Bedrock e fazer benchmarks em uma máquina de 192 núcleos, mas a atividade repentina em uma conta inativa gerou um alerta de suspeita de violação de segurança, e a conta foi suspensa
• Com a suspensão da conta, até o AWS WorkMail usado para o negócio foi interrompido, e a recuperação da conta não aconteceu por 4 dias no plano de suporte gratuito
• Chegou à conclusão de que precisa migrar até os serviços que ainda havia deixado na AWS e sair de vez

---

Do apoio inicial à AWS até o afastamento

• Defendia fortemente a AWS desde a época em que ela era um conjunto menor de serviços centrado em SQS, S3, EC2 e SimpleDB, e chegou a organizar em Melbourne o primeiro evento em que um responsável da AWS dos EUA veio apresentar a AWS
• A computação em nuvem foi uma grande mudança, permitindo que startups colocassem seus próprios sistemas no ar em minutos sem precisar instalar e operar infraestrutura em um datacenter
• Confiou fortemente na AWS por cerca de 15 anos, mas, com o tempo, elementos incômodos foram se acumulando e, em certo momento, ele simplesmente deixou de gostar da AWS

Insatisfações com a AWS que se acumularam com o tempo

• Bibliotecas cliente e a transição do Python

  • Durante os primeiros 6 anos, a AWS não criou suas próprias bibliotecas cliente e deixou que a comunidade implementasse bibliotecas para linguagens como Python, o que foi percebido como transferir o peso para programadores trabalhando de graça
  • O tempo excessivo que a AWS levou para migrar do Python 2 para o Python 3 também ficou como uma grande insatisfação

• DynamoDB e a experiência com custos

  • No primeiro dia usando o DynamoDB, recebeu uma cobrança de US$ 75, e não só o custo, mas o próprio sistema pareceu funcionar da pior forma imaginável

• Custos de transferência de dados e cobrança complexa

  • O custo de saída de dados da AWS já foi de 20 centavos por GB e depois caiu para 9 centavos por GB, mas ele ainda o considera muito caro
  • Há cobrança até pela movimentação de dados entre sistemas internos da AWS e, em alguns casos, a estrutura parece uma cobrança dupla ou tripla, tornando difícil evitar armadilhas de faturamento sem um entendimento profundo

• IAM e a complexidade geral

  • O IAM (sistema de autenticação e controle de acesso) é extremamente complexo
  • Defensores da AWS dizem que é preciso usar a AWS porque operar Linux, hardware, rede e segurança por conta própria é complexo demais, mas ele considera que quase todas as áreas da própria AWS também trazem uma complexidade enorme e, no fim, exigem uma equipe cara de especialistas

• AWS Lambda e lock-in

  • Ficou atraído pela promessa de que “escala”, mas os cold starts lentos e a enorme complexidade de desenvolvimento foram um problema
  • Não vê vantagem prática em relação a um servidor web próprio, só mais desvantagens, e o Lambda era justamente a parte mais difícil de desmontar ao sair da AWS, num exemplo grave de lock-in de fornecedor

• Projetos open source e receita com hospedagem

  • Considera que a AWS levou adiante OpenSearch, Valkey e DocumentDB mesmo quando projetos como Elasticsearch, Redis e MongoDB demonstraram que não queriam que seus produtos fossem copiados e monetizados
  • Depois que essas comunidades e empresas criaram o mercado, a AWS ficou com a receita dos serviços hospedados e, como resultado, aumentaram licenças defensivas como SSPL, Elastic License e RSAL, além do modelo source-available

Alguns serviços deixados para trás após sair da AWS

• Depois de perder o apego à AWS, tirou tudo da plataforma e praticamente fechou todas as contas
• Ainda assim, manteve apenas alguns serviços que, na época, considerava realmente a solução certa
• Os domínios ficaram no Route53, alguns backups no S3 e o e-mail corporativo no AWS WorkMail
  • O AWS WorkMail já havia sido notificado de que o serviço seria encerrado em 12 meses

Por que voltou temporariamente para a AWS

• Recentemente, fez login novamente na AWS para pesquisa e testes
• Queria verificar o quão bem Claude/Anthropic funcionava no AWS Bedrock e, no caso do Claude Code, funcionava igual, mas mais devagar e muito mais caro do que a assinatura da Anthropic
• O equipamento doméstico mais rápido que tinha era um CPU de 20 núcleos com 32 GB de RAM, e ele queria medir com benchmarks quão rápido o código rodava em uma máquina com 192 núcleos e 1 TB de RAM
• Cerca de um mês antes, os testes com AWS Bedrock terminaram sem problemas, e depois ele desligou tudo
• O AWS Bedrock pode ser útil quando a privacidade é necessária, mas, por causa do custo, ele não pretende voltar a usar Claude pelo AWS Bedrock

Restrição de conta durante teste com EC2 Spot

• Depois disso, ao iniciar uma instância EC2 Spot de 192 núcleos e rodar testes por cerca de 3 horas, recebeu um e-mail da AWS com o aviso “Suspected security breach of your account”
• Considera que o fato de uma conta praticamente inativa ter começado de repente a usar recursos computacionais caros pode ter acionado um alerta interno de segurança da AWS
• Entende e avalia positivamente a intenção da AWS de proteger os usuários
• Mas a AWS suspendeu ou restringiu a conta e, com isso, a principal conta de e-mail do negócio, usada via AWS WorkMail, parou de funcionar
• Ninguém mais conseguia enviar e-mails, e ele também não podia criar nenhum recurso na AWS, o que impediu a continuação dos testes planejados

Resposta do suporte e demora

• Respondeu ao alerta de suporte da AWS dizendo que a conta não havia sido invadida e que não havia problema nem anomalia de cobrança, mas não recebeu resposta
• Como não usava suporte premium, teve de esperar o prazo de 24 horas informado pela AWS, mas, mesmo após 3 dias, não houve retorno do suporte
• Depois de pedir ajuda no fórum da AWS, recebeu a orientação de seguir as instruções do e-mail e usar o chat em vez da web
• Realizou todas as ações solicitadas, como trocar a senha, apagar tokens de acesso e verificar o histórico de cobrança, e, após esperar cerca de 30 minutos até conectar no chat, conversou por bastante tempo com um atendente da AWS
• O atendente pareceu satisfeito e disse que pediria providências à equipe interna responsável, mas, mesmo após 24 horas, a restrição não foi removida
• Quando fez um acompanhamento 8 horas depois, recebeu apenas a resposta de que precisava esperar

A conclusão confirmada mais uma vez

• Mesmo 4 dias após a conta ter sido restringida, ele ainda tinha tarefas que queria testar em máquinas grandes e já se preocupava em ter de fazer novamente pedidos de “quota” para isso
• O sistema de e-mail corporativo continuava sem funcionar
• Essa experiência de retorno confirmou mais uma vez por que ele havia deixado a AWS, e ele concluiu que deveria sair do AWS WorkMail, transferir também os domínios do Route53 e nunca mais voltar
• Ficou muito aliviado por já ter tirado quase tudo da AWS no passado, mas o sistema de e-mail em que confiou e deixou lá foi interrompido no processo de retorno à AWS, causando prejuízo real
• A AWS pode até remover a restrição da conta em algum momento, mas não há como saber quando isso acontecerá

[GN⁺]

Comentários no Hacker News

• Há alguns anos entrei numa empresa para liderar a equipe de desenvolvimento e me pediram para lançar o produto em 3 meses, mas quando fui adicionar uma nova máquina na AWS, o próprio fato de o preço não aparecer na interface me pareceu um sinal de uma relação hostil e exploratória
  Eu precisava abrir separadamente a tabela de especificações e a tabela de preços para comparar, e pela minha experiência passada, se eu visse esse tipo de sinal e mesmo assim não fosse embora, então as consequências depois seriam minha responsabilidade
  Então criei uma conta na DigitalOcean, migrei tudo para lá e configurei o CI/CD para implantar por lá também, e passei os 2 meses restantes focando no produto, lançando 1 mês antes do prometido
  Uma vez vi um vídeo em que cavavam um buraco na margem de um rio e o conectavam ao rio com um cano para que os peixes entrassem sozinhos na armadilha; essa imagem ficou muito forte para mim como um exemplo de como escolher sempre o caminho de menor resistência e não desfazer erros é a receita para acabar como aqueles peixes

  • Uma das coisas de que gosto no Azure é que, embora ele não esfregue o preço de forma excessiva cada vez que você cria um item individual, em geral existe um equilíbrio em mostrar o preço nos itens que podem ficar caros
    Ainda não tomei susto por causa de cobrança
  • Acho que a cultura de engenharia da Amazon é bastante uma cultura de produto guiada por engenheiros, então talvez seja comum que desenvolvedores também acabem responsáveis pela UX e pelo fluxo
    No passado contratei um desenvolvedor júnior que tinha acabado de concluir um estágio na AWS, e ele me mostrou um dashboard que havia feito sozinho durante o verão, sem ajuda de PM ou designer, e aquilo parecia realmente terrível
    Alguns desenvolvedores têm bom senso de produto/UX, mas a maioria é muito fraca em UX, então em vez de ser algo intencional, provavelmente era só uma cultura de UX ruim
  • A forma correta é escolher um provedor de infraestrutura que ajude você a lançar
    A AWS é boa, mas não serve para todo mundo, e existe um ponto entre serviços como Heroku e bare metal que abstrai bastante a manutenção, mas ainda dá algum controle sobre a arquitetura de escala
    Em outras palavras, como provedor de nuvem a AWS ajuda a escalar, mas não é a ferramenta para montar a configuração mais barata e mais simples
    Se você tem capital de VC e vende crescimento, a AWS pode ser uma escolha segura, e com os créditos de startup de 2 anos via aceleradoras, dá para focar na construção em vez do orçamento de infraestrutura nos primeiros 18 meses
    Se você é bootstrap ou indie, pode escolher algo simples e viável, e Hetzner ou DigitalOcean já funcionam muito bem
  • A AWS tem uma calculadora de preços bem decente e presets úteis, mas é claro que é um aplicativo totalmente separado
    A Amazon provavelmente quer que exista um pouco de atrito para consultar preços com facilidade, mas o principal motivo parece mais a lei de Conway
    A AWS ainda expõe seu organograma em forma de produto
  • Concordo até certo ponto, mas os preços da AWS não são simples o bastante para que um único número estático exibido na UI permita calcular quanto você vai pagar
    Se abrir duas abas para comparar custos já for incômodo, talvez seja melhor evitar não só a AWS, mas qualquer provedor de nuvem
    Quando entram NAT Gateway, CloudFront, S3, auto scaling e load balancer, calcular custo fica mais próximo de arte do que de ciência exata
    Se você não vai usar essas coisas, então também há pouco motivo para usar AWS, e não faltam provedores de VPS baratos

• Considerando apenas OpenSearch e Valkey, a explicação de que “a AWS criou um fork e isso provocou a mudança de licença” está completamente invertida
  A AWS só criou o fork depois que o projeto upstream mudou a licença, e no caso do Valkey em especial, ele foi criado por membros da antiga equipe principal do Redis

  • Muitos desses projetos operam num modelo de negócio em que o produto principal é open source, enquanto o dinheiro vem de serviços premium, instalação, manutenção e serviço totalmente gerenciado
    A AWS passou por cima deles oferecendo um serviço totalmente gerenciado, então nesse caso eu fico do lado de quem criou os projetos
    Basicamente, a AWS tomou o sustento deles, e eles acabaram sendo forçados a mudar a licença
  • A própria mudança de licença foi uma resposta ao fato de a AWS monetizar o trabalho deles no projeto upstream de uma forma insustentável para eles
  • Fico pensando qual seria o impacto se a Amazon pagasse aos criadores e mantenedores do software open source que vende 1 centavo por período de cobrança de uso
    Também me pergunto se isso já não viraria algum dinheiro relevante para as equipes open source, além de incentivá-las a contribuir para melhorar os produtos sem assumir risco
  • Quando enviei meu primeiro patch para o Redis, um committer ignorou minha mensagem, aplicou o patch em nome dele e o colocou com a assinatura dele; desde então perdi grande parte da empatia por muitas filosofias de projetos open source
    Eles mereceram passar pelo Valkey
    Ainda lembro do JBoss e do Marc Fleury
  • É óbvio que a AWS só criou o fork depois que a licença foi mudada para impedir que ela ganhasse dinheiro com o código daquele projeto
    Esse é exatamente o ponto

• Já fui e voltei algumas vezes entre serviços de nuvem e self-hosting
  No começo usei Vercel e, como o projeto era em Next.js, a experiência foi boa, mas pagar US$ 20 por mês por um projeto com menos de 100 usuários parecia caro para um serviço com exigência baixa de desempenho
  Depois montei meu próprio servidor com Hetzner e Coolify; como o Coolify é open source, eu só pagava o custo do VPS, e com US$ 5 por mês já dava para rodar uma instância de PostgreSQL e um servidor web
  Mas ainda dava muito trabalho manter PostgreSQL e Redis, e mesmo dentro de contêineres Docker era chato repassar variáveis de sistema e variáveis de ambiente entre serviços
  Então mais tarde migrei para Cloudflare Workers, D1 Database e Cloudflare KV, e como tudo podia ser chamado diretamente dentro do Worker, não havia necessidade de passar variáveis de ambiente
  A experiência de desenvolvimento local também é boa e o preço é razoável, então desde então sigo usando o ecossistema da Cloudflare como um todo

  • Os recursos oferecidos pela Cloudflare ficaram mais próximos do que eu queria da AWS
    Apps full-stack e deploy de arquivos básicos ficaram muito mais simples, e a AWS passou a ser bem mais difícil até do que self-hosting
  • Fico curioso se o Docker realmente facilitou gerenciar PostgreSQL
    O único problema que tenho com PostgreSQL costuma ser algum trabalho de migração ao mudar para uma nova versão major
    Também fico curioso se repassar variáveis de sistema e ambiente entre serviços não ficou mais difícil justamente por causa do Docker
  • Eu queria gostar de Cloudflare Workers, e pode até haver bons motivos técnicos para isso, mas a forma como tarefas como ativação de e-mail exigem usar um projeto Wrangler me deu a sensação de estar a um passo do lock-in de plataforma
    Para permitir e-mail, é preciso configurar os bindings necessários, mas pelo console isso aparentemente nem pode ser configurado, e depois que o Wrangler configura, parece que você nem consegue ver

• É surpreendente que o autor não goste de DynamoDB
  É um dos serviços da AWS de que eu mais gosto: boa disponibilidade, quase nenhum trabalho operacional e, sempre que usei, custo bem baixo
  Só que você precisa dedicar tempo para modelar os dados de antemão e, para isso, precisa ler e entender a documentação do serviço

  • O DynamoDB é muito bom se você o usar da maneira pretendida
    No fundo ele deve ser visto como um armazenamento chave-valor relativamente simples, com boa durabilidade e expansão praticamente infinita do tamanho da tabela, e não como um banco SQL
    A forma mais fácil de gerar uma conta de US$ 75 com código de protótipo é fazer vibe coding tratando-o como se fosse um banco SQL com JOIN e GROUP BY
    Onde ele realmente brilha é quando você precisa de 1 ou 2 tabelas pequenas para armazenamento persistente sem querer administrar um RDBMS inteiro, ou quando precisa consultar uma tabela enorme de forma simples sem tentar encaixá-la num RDBMS
  • Vários serviços como DynamoDB e Lambda têm casos de uso muito específicos
    Não use um alegre armazenamento chave-valor como se fosse um banco de dados
  • Há alguns anos, ao criar um app, eu precisava de um banco para armazenar cerca de 50 milhões de registros, com algo em torno de 10 mil leituras+gravações por mês e 1 índice
    O custo inicial de carga foi de cerca de US$ 50, e depois disso o custo de manutenção ficou em algo como 10 centavos por mês

• Sempre dou risada quando vejo textos assim
  Eles estão certos e errados ao mesmo tempo, e um sistema deve ser construído “o mais simples possível, mas não mais simples do que isso”
  Se você acha que pode ignorar os detalhes, depois o incômodo volta maior
  IAM é simplesmente complexo
  Não consigo pensar em nenhum caso em que usuários, grupos, funções, políticas, provedores de identidade e OIDC tenham sido implementados de forma realmente simples
  Já vi gente que rejeitava Kubernetes por ser “complexo demais” e acabou reinventando Kubernetes de forma ruim e improvisada com Vault, Consul, systemd, Nomad, iSCSI, Ansible, Jenkins, Puppet, Bash, cuspe e barbante, cometendo um monte de erros
  Algumas funcionalidades parecem desnecessárias até que deixam de ser
  Tendo trabalhado como único responsável por infraestrutura em startup, acho a AWS algo que, em sua maior parte, está dentro do que dá para aprender, e as partes horríveis em geral podem ser evitadas
  Se você odeia Lambda, então não use; use EKS, ECS ou EC2

  • Vendo por dentro, o IAM tem milhares de opções, mas a essência é “o que esta função pode acessar e o que pode fazer com isso (ação + recurso)” e “quem pode acessar esta função”
    Visto de 10 mil pés, é só isso
    O motivo de o IAM ser bom é que ele se aplica do mesmo jeito por fora e por dentro
    Equipes internas da AWS não têm acesso a mais coisas só por serem internas; se elas ganham permissão para fazer algo na conta do cliente a fim de prestar determinado serviço, isso acontece porque o cliente colocou o principal de serviço na relação de confiança do IAM e permitiu esse acesso, e o cliente pode ver e auditar isso
    Por exemplo, o Lambda tem a função do Lambda, porque você não quer que o serviço Lambda leia um bucket S3 só pelo motivo de “somos a AWS, então temos acesso automático”
    Mesmo acesso interno da AWS pode ser claramente visto e controlado pelo cliente
  • Esse padrão de barrar a adoção de X dizendo que “X é complexo demais” e no fim reinventar X de forma ruim é incrivelmente comum em tecnologia e software
    Algumas coisas hoje já são padrão de forma óbvia, mas muita gente ainda se recusa a investir tempo para aprendê-las direito
  • A AWS pode ser mais cara do que self-hosting, mas essa economia fica pequena perto do custo de engenharia
    Se um bom engenheiro de infraestrutura gastar dois meses numa configuração com OVH para “economizar dinheiro”, isso sai mais caro do que o valor economizado por não simplesmente usar Fargate ou RDS

• Fico curioso sobre quando o mesmo tipo de discussão vai começar a surgir sobre empresas como Anthropic e OpenAI
  O movimento atual da IA tem um cheiro parecido com o início da AWS, e parece que todo mundo entrou de cabeça para depois perceber que acumulou uma grande dependência difícil de remover

• Lambda é realmente sensacional, e na minha opinião é a melhor forma de operar serviços implantados com ciclos rápidos de iteração sem dor de cabeça
  Não é obrigatório seguir para microsserviços nem dividir o código em bilhões de repositórios minúsculos
  Se você não espera compartilhar estado no servidor entre requisições, dá para mover um servidor web padrão para Lambda

• Eu não trabalho nessa área, então só mexo na AWS de vez em quando em projetos pessoais por diversão, e toda vez parece um pesadelo
  Eu só quero montar um servidor experimental para um jogo de cartas, não fundar uma nova instituição financeira; ainda assim, tudo parece preparado para escalar infinitamente amanhã e presumindo uma organização de mil pessoas e orçamento de VC
  Ainda bem que serviços como Netlify colocam uma camada por cima para eu não precisar ferver o oceano
  Talvez um dia eu realmente precise aprender IAM, VPN e sabe-se-lá-o-quê, mas até lá sinto que meus olhos vão saltar para fora toda vez que encosto na AWS

  • Basta subir um VPS cru em EC2 ou Lightsail, anexar um IP público e encerrar por aí
    Você não precisa implementar todos os padrões enterprise
  • É impressionante como o Heroku acertou em cheio no que a maioria dos apps web precisava, quase 20 anos atrás
  • Se você nunca lidou com Azure, pode achar que só a AWS é um pesadelo
  • Migrei para a Cloudflare e realmente senti um alívio enorme
    Tem tudo de que preciso e o preço é razoável
  • A AWS mira enterprise, não projetos pessoais
    No fim, em projeto pessoal só importa custo, então isso não gera receita relevante para a AWS

• Desde 2023 a AWS vem sendo esvaziada de forma sistemática em pessoal técnico
  Isso aconteceu por grandes demissões e por duas rodadas de plano de melhoria de desempenho, e muita gente competente que eu conhecia em pré-vendas ou suporte já não está mais na AWS
  Em compensação, vi com frequência permanecer e ser promovidas pessoas com histórico de trabalho muito mais nebuloso
  A AWS deve ser usada por conta e risco de cada um, e Paul Vixie não vai aparecer para salvá-la

• Há muito tempo o ElastiCache me incomoda de forma especial
  O RDS agrega valor com escalabilidade, configurações razoavelmente otimizadas e backups de que você não precisa se preocupar, então dá para aceitar pagar por isso
  Mas o ElastiCache quase não adiciona valor, e o preço parece exploratório
  Comparado a uma instalação básica de Redis, ele é mais lento, menos otimizado, menos estável, e enquanto um Redis sem configuração suporta vários DBs, o ElastiCache suporta apenas um
  Há alguma melhora de escalabilidade, mas como um Redis básico supera o ElastiCache por uma margem tão grande em instâncias semelhantes, casos em que essa melhora realmente faz falta são muito raros

  • ElastiCache é com certeza um daqueles serviços em que vale a pena considerar self-hosting
    A AWS não acrescenta tanto assim em API ou acabamento, e em compensação Redis/Valkey é um dos serviços mais simples de hospedar por conta própria