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

• Eu apoiava a AWS desde o início, mas, com o acúmulo de fatores como o período em que deixou as bibliotecas cliente nas mãos da comunidade, a demora na transição para Python 3, a cobrança complexa e o IAM, além do lock-in do AWS Lambda, passei a não gostar mais da AWS
• Depois de usar o DynamoDB, enfrentei uma cobrança de US$ 75 em um único dia; o custo de saída de dados caiu de 20 centavos para 9 centavos por GB, mas a estrutura que cobra até pela movimentação interna de dados continua cara e difícil de entender
• Depois de sair da AWS, fechei a maior parte das contas, mas mantive domínios no Route53, alguns backups no S3 e o AWS WorkMail; depois recebi um aviso de que o WorkMail será encerrado nos próximos 12 meses
• Recentemente, fiz login de novo na AWS para testar o funcionamento do Claude/Anthropic no AWS Bedrock e um EC2 Spot com 192 núcleos e 1 TB de RAM; concluí que o Bedrock funciona da mesma forma, mas é mais lento e muito mais caro do que a assinatura da Anthropic
• Durante cerca de 3 horas de teste com EC2 Spot, recebi um alerta de Suspected security breach e a conta foi restringida, bloqueando meu e-mail comercial no WorkMail e a criação de recursos; mesmo após as medidas pedidas e o atendimento por chat, a restrição não foi removida por 4 dias, então decidi migrar também o AWS WorkMail e o Route53

---

Do apoio inicial à AWS ao afastamento

• Eu apoiava fortemente a AWS desde a época em que ela era um conjunto menor de serviços centrados em SQS, S3, EC2 e SimpleDB, e organizei em Melbourne o primeiro evento em que um representante da AWS dos EUA veio apresentar a AWS
• A computação em nuvem foi uma grande mudança, porque permitiu que startups colocassem seus próprios sistemas para rodar em minutos sem precisar instalar e operar infraestrutura em um datacenter
• Durante cerca de 15 anos, acreditei fortemente na AWS, mas, com o tempo, os incômodos foram se acumulando e, em certo momento, percebi que já não gostava mais da AWS

Insatisfações com a AWS que se acumularam ao longo do 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 visto como transferir esse peso para programadores que cediam seu tempo gratuitamente
  • O fato de a AWS ter demorado demais para migrar do Python 2 para o Python 3 também ficou como uma grande insatisfação

• DynamoDB e a experiência com custos

  • Depois de usar o DynamoDB, apareceu no fim do dia uma cobrança de US$ 75 e, além do custo, o próprio sistema pareceu a pior forma imaginável de fazer isso

• Custo 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 ainda é considerado muito caro
  • Há cobrança até pela movimentação de dados entre sistemas internos da AWS e, em alguns casos, a estrutura passa a sensação de cobrança dupla ou tripla, o que torna difícil evitar armadilhas de faturamento sem entender isso em profundidade

• IAM e a complexidade geral

  • O IAM é um sistema que lida com autenticação e regras de acesso, mas é percebido como excessivamente complexo
  • Defensores da AWS dizem que é preciso usá-la porque operar Linux, hardware, rede e segurança por conta própria é complexo demais, mas quase todas as áreas da própria AWS também carregam uma complexidade enorme, o que no fim exige uma equipe cara de especialistas

• AWS Lambda e lock-in

  • O AWS Lambda vende a ideia de escalabilidade, mas exigia lidar com tempos de inicialização lentos e grande complexidade de desenvolvimento
  • Na comparação com operar um servidor web próprio, não vi vantagem real e vi muitas desvantagens; ao sair da AWS, a parte mais difícil de desfazer foi justamente o AWS Lambda
  • O uso do AWS Lambda deixou a impressão concreta de que vendor lock-in realmente existe e de que era uma escolha que exigia continuar convencendo a si mesmo de que ainda era melhor

• Projetos open source e receita com hospedagem

  • Na minha visão, 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 isso teria contribuído para o aumento de licenças defensivas como SSPL, Elastic License e RSAL, além do modelo source-available

Alguns serviços que ficaram após sair da AWS

• Depois que meu vínculo com a AWS se rompeu, tirei tudo de lá e fechei quase todas as contas
• Ainda assim, mantive apenas alguns serviços que, na época, me pareciam de fato a solução certa
• O que ficou foram os domínios no Route53, alguns backups no S3 e o AWS WorkMail
• Depois recebi um aviso de que o AWS WorkMail será encerrado nos próximos 12 meses

Por que voltei por um tempo à AWS

• Recentemente, fiz login na AWS de novo para pesquisa e testes
• Queria verificar quão bem o Claude/Anthropic funcionava no AWS Bedrock e, no caso do Claude Code, concluí que ele funciona da mesma forma, mas é mais lento e muito mais caro do que uma assinatura da Anthropic
• O equipamento mais rápido que eu tinha em casa era uma CPU de 20 núcleos com 32 GB de RAM, e eu queria medir o quão rápido meu código rodaria em uma máquina com 192 núcleos e 1 TB de RAM
• Cerca de um mês atrás, o teste com AWS Bedrock terminou sem problemas e, depois do teste, desliguei tudo
• O AWS Bedrock pode ser útil quando privacidade é necessária, mas, por causa do custo, não pretendo voltar a usar o Claude no AWS Bedrock

Restrição da conta durante o teste com EC2 Spot

• Depois disso, iniciei uma instância EC2 Spot de 192 núcleos e, durante cerca de 3 horas de teste, recebi um e-mail da AWS com a mensagem “Suspected security breach of your account”
• Acredito que o fato de uma conta quase inativa ter começado de repente a usar recursos computacionais caros pode ter acionado um alerta interno de segurança da AWS
• Entendo e avalio de forma positiva a intenção da AWS de proteger o usuário
• Mas a AWS suspendeu ou restringiu a conta e, como resultado, a conta de e-mail principal do meu negócio, que usava o AWS WorkMail, parou de funcionar
• Ninguém mais conseguia me enviar e-mails e eu também não conseguia criar nenhum recurso da AWS, então não pude continuar o teste que pretendia fazer

Resposta do suporte e demora

• Respondi ao alerta do suporte da AWS dizendo que a conta não havia sido invadida e que não havia problema nem cobrança anormal, mas não recebi resposta
• Como eu não tinha suporte premium, tive de esperar o prazo de resposta de 24 horas informado pela AWS, e, mesmo depois de 3 dias, nenhuma resposta do suporte chegou
• Depois de pedir ajuda no fórum da AWS, recebi a orientação de seguir as instruções do e-mail e usar o chat em vez da web
• Executei todas as ações pedidas, 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é ser atendido no chat, conversei longamente com um representante da AWS
• O atendente pareceu satisfeito e disse que pediria tratamento ao time interno responsável, mas, mesmo após 24 horas, a restrição não foi removida
• Quando fiz um acompanhamento 8 horas depois, recebi apenas a resposta de que eu deveria aguardar

A conclusão que se confirmou de novo

• Mesmo 4 dias após a conta ter sido restringida, eu ainda tinha trabalho que queria testar em máquinas grandes e passei a me preocupar com a necessidade de fazer outro pedido de “quota” para isso
• O sistema de e-mail comercial ainda continuava sem funcionar
• Essa experiência de retorno confirmou de novo por que eu saí da AWS, e concluí que preciso sair do AWS WorkMail e migrar também os domínios do Route53 para nunca mais voltar
• Foi um grande alívio já ter saído da AWS no passado, mas o fato de o sistema de e-mail em que confiei e deixei lá ter sido interrompido durante esse retorno foi visto como um fracasso
• 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