Segui o guia oficial do AWS Amplify e recebi uma cobrança de US$ 1.100

 (elliott-king.github.io)
1 pontos por GN⁺ 2024-11-15 | 1 comentários | Compartilhar no WhatsApp
  • Depois de testar a integração oficial do OpenSearch no AWS Amplify, os custos do Amazon OpenSearch Service subiram para US$ 1.124,88 em um mês, apesar de o uso não ter sido alto
  • O custo se acumulou porque o domínio do OpenSearch criado por npx ampx sandbox continuou existindo mesmo após encerrar/excluir o sandbox, e uma nova execução adicionava outro domínio
  • A configuração oficial cria por padrão uma instância r5.large.search, e esse padrão, com custo mínimo na faixa de US$ 134 por mês, não ficava evidente no código boilerplate nem no guia
  • O AWS Support ofereceu créditos únicos para OpenSearch e armazenamento, e exigiu a configuração do AWS Budgets para evitar reincidência
  • Ao usar Amplify junto com OpenSearch, é preciso verificar manualmente os recursos remanescentes após excluir o sandbox e o tipo de instância padrão para evitar cobranças inesperadas

Cobrança inesperada do OpenSearch

  • Depois de seguir o guia oficial de integração com OpenSearch no AWS Amplify, algumas semanas depois a fatura da AWS veio acima de US$ 1.200
  • O serviço identificado na solicitação ao Support foi o Amazon OpenSearch Service, com total mensal de US$ 1.124,88
  • A pessoa já havia usado Amplify e OpenSearch em 2020 e considerava que, para uso pessoal, normalmente era caro, em torno de US$ 50 por mês, mas não algo no nível de US$ 1.200
  • Após uma análise detalhada, o AWS Customer Support processou um ajuste de cobrança na forma de one time courtesy para os custos inesperados
  • Durante o processo com o Support, foram oferecidos créditos para OpenSearch e serviços de armazenamento, e também foi exigida a configuração do AWS Budgets
    • O AWS Budgets permite prever gastos futuros de serviços específicos ou de toda a AWS e enviar alertas caso seja previsto que o orçamento será excedido

Recursos criados pelo guia oficial

  • O quickstart do Amplify cria um app simples de notas TODO com código fornecido pela AWS, e o Amplify gera um banco de dados DynamoDB e requisições CRUD autenticadas
  • Também é possível rodar localmente, mas o Amplify cria junto um domínio acessível
  • Na etapa de configuração do OpenSearch, escreve-se boilerplate em TypeScript para declarar os recursos do Amplify
    • Uma tabela do DynamoDB é atribuída a uma variável e referenciada no pipeline
    • São criados uma instância do OpenSearch, um index e um indexMapping
    • São escritas queries para acessar dados no OpenSearch
    • É criado um pipeline OpenSearchIngestionService para copiar dados do DynamoDB para o OpenSearch
  • A configuração relacionada é gerenciada como TypeScript/JavaScript dentro do repositório, junto com o código do frontend
  • npx ampx sandbox inicializa serviços da AWS e detecta mudanças de configuração para modificar automaticamente os serviços existentes na AWS

Domínios que permaneceram após excluir o sandbox

  • Essa configuração inclui vários recursos, como um banco de dados DynamoDB, um serviço OpenSearch, um pipeline OSIS, funções IAM e outros
  • O boilerplate oficial cria por padrão uma instância OpenSearch r5.large.search
    • Esse padrão não ficava explicitamente visível no código boilerplate nem no guia
    • r5.large.search custa no mínimo US$ 134 por mês
  • Ao terminar um dia de trabalho e interromper o sandbox com CTRL-C, aparece um prompt perguntando se deve excluir permanentemente, e o usuário pode escolher Y
  • Nesse momento, o DynamoDB é excluído, mas, ao olhar no console da AWS, o domínio do OpenSearch continua lá
  • No dia seguinte, ao executar npx ampx sandbox novamente, uma nova instância do OpenSearch é criada, e npx ampx sandbox delete também não exclui a instância original
  • Repetir o mesmo processo deixa vários domínios OpenSearch do mesmo projeto em segundo plano, acumulando custos

Possível bug e tipo de instância padrão

  • Esse comportamento pareceu uma grande footgun, e na época ainda não havia sido resolvido mesmo após o chamado ao AWS Support
  • Havia relatos antigos de bugs relacionados, mas não foram encontrados itens de menos de um ano
  • É possível que o domínio do OpenSearch fosse excluído corretamente na v1, mas não na v2, embora essa não seja uma causa confirmada
  • O fluxo atual não é executado pelo Amplify CLI, mas via npx
  • O fato de r5.large.search ser o tipo de máquina padrão também continua sendo um fator de risco
    • Seria melhor torná-lo um campo obrigatório, sem valor padrão
    • Se o guia mostrasse r5.large.search como valor padrão, os usuários perceberiam isso com mais facilidade
    • Esse padrão não é exclusivo do Amplify, mas parte do AWS CDK, então não é visto como responsabilidade apenas da equipe do Amplify

Cuidados ao usar Amplify com OpenSearch

  • Era esperado que ferramentas que aceleram o desenvolvimento com novas tecnologias pudessem ser mais caras do que bare metal, mas este custo foi considerado acima desse patamar
  • Usar o console de budgets da AWS permite receber alertas quando o gasto previsto ultrapassar o orçamento
  • Mesmo seguindo apenas a seção de OpenSearch, são criados uma conta IAM, um domínio OpenSearch, um pipeline OSIS, um log group e armazenamento S3, aumentando a quantidade de recursos ocultos
  • O OpenSearch é um serviço usado com frequência por clientes corporativos, por isso pode ser considerado um serviço “avançado”, com a expectativa de que o usuário entenda melhor o ecossistema da AWS
  • O OpenSearch foi usado por causa do suporte a consultas bounding-box com geo_point, mas não há certeza se isso poderia ter sido feito com um produto mais simples
  • Segundo a atualização, o guia da AWS foi corrigido depois; ele ainda não havia sido atualizado três meses antes, quando o problema foi levantado pela primeira vez, mas parece que o trabalho em um PR da documentação começou antes da publicação do post

Leituras relacionadas

1 comentários

 
GN⁺ 2024-11-15
Opiniões no Hacker News

  • Alertas de cobrança são praticamente uma piada; na prática, deveriam oferecer um limite rígido de gastos
    Também deveriam explicar, durante o onboarding, como configurar esse limite
    Construir um negócio em cima de cheques em branco e cobranças acidentais é suspeito e também cria uma grande barreira de adoção
    Quanto mais desenvolvedores veem casos como “segui um tutorial de 20 minutos e fui cobrado no valor das economias de uma vida; desta vez o suporte ao cliente isentou a cobrança, mas na próxima parecia que iam levar até minha casa”, menos vontade dá de explorar produtos da AWS

    • Isso não é um problema exclusivo da AWS; provedores de nuvem, em geral, parecem cair em apenas dois grupos
      Os que transferem o risco para o cliente, como AWS ou DigitalOcean, e os que vendem planos suspeitos de “ilimitado”/“sem medição”
      Nenhum dos dois é o que eu quero
      Gostaria que existisse um provedor que permitisse fazer planejamento de capacidade de forma adequada, com limites claros e documentados, em que o cliente assumisse o risco de disponibilidade, mas o fornecedor assumisse o risco financeiro
      Se não fosse exagerado, eu até aceitaria pagar uma tarifa fixa mais alta
    • Um limite rígido de gastos é quase contraproducente para os clientes enterprise, que são o público principal da AWS
      Poucas cobranças acidentais baratas são piores do que causar downtime ou perda de dados em uma aplicação crítica
      Mesmo que existisse apenas como opção, a equipe de contabilidade poderia pressionar pelo uso, e há risco de isso virar um incidente de perda de dados quando desse problema
      Pode fazer sentido para provedores de nuvem focados em desenvolvedores independentes ou pequenas e médias empresas
    • Já apareceu várias vezes em comentários do HN a história de que o código de cobrança da AWS é um enorme código espaguete, e que internamente há muito medo de mexer em mudanças grandes
      Está entre as informações internas mais interessantes que fiquei sabendo por aqui
    • Eu tinha interesse na AWS, mas por motivos como esse nunca consegui entrar de verdade
      É mais seguro usar um VPS barato e de preço fixo do que se arrepender depois
    • Isso deveria ser regulado
      Não adianta muito pedir que a Amazon faça alguma coisa
      A Amazon e outras empresas precisam ser obrigadas por lei a respeitar o dinheiro dos usuários
      Empresas, por padrão, não fazem o que é ético ou bom para a economia; fazem o que dá dinheiro

  • Em comparação, é pouca coisa, mas tentei implantar uma aplicação no ECS, recebi uma fatura de 100 dólares e decidi nunca mais usar AWS
    O erro que impedia o serviço de subir era problema da minha aplicação, mas os logs do CloudWatch apareciam só uns 20%; para conseguir logs, tive de reimplantar cinco vezes, corrigir, e depois reimplantar mais cinco vezes
    Cada implantação com falha foi cobrada e, depois de uns dois dias sofrendo, excluí a conta e implantei no DigitalOcean App Platform
    Lá a implantação também falhou por causa do erro na aplicação, mas os logs apareciam todas as vezes; corrigi e coloquei para rodar em menos de 10 minutos, e a cobrança total foi de alguns centavos
    Desde aquele dia, prometi a mim mesmo que, se houver opção, nunca usarei AWS e também não recomendarei

    • Só usei Azure, mas o ECS parece corresponder ao Azure Container Apps
      Para desenvolvimento e testes, o modelo de cobrança baseado em consumo foi muito barato
      Não sei como fica em workloads maiores, mas cobrar por implantação é estranho
    • Desisti da AWS quando descobri que, ao contrário do GCP, não dá para implantar contêineres diretamente no EC2
      Em projetos grandes, o suporte talvez seja melhor, mas, em escala pequena a média, o GCP é muito melhor
      Ele tem componentes básicos que combinam com a forma como contêineres são usados hoje, além do BigQuery

  • Parece haver um bug evidente no script executado por aquele comando npx
    O autor está certo: se é um tutorial, deveria escolher 100% dos recursos mais baratos, e ao executar o subscritp delete deveria limpar os recursos
    Não é justo esperar que, depois de rodar algo assim, o desenvolvedor vasculhe paranoicamente a conta inteira da AWS procurando recursos perdidos
    Se uma startup funcionasse desse jeito, as pessoas deixariam passar dizendo “esse tipo de coisa acontece, é preciso tomar cuidado”?
    Não sei por que aplicam outro padrão à AWS

    • Essa é justamente a parte mais irritante da AWS
      Não há uma forma fácil de ver todos os recursos pelos quais estou pagando no momento
      Se existe, eu não consegui encontrar
      Sem uma visão geral fácil de entender, sinto que não tenho controle total da minha conta
    • A primeira coisa que verifico quando preciso usar algo novo é se posso receber uma fatura fixa todo mês
      Também vejo o que acontece se eu passar disso e se dá para limitar cobranças inesperadas
      Se não der, procuro outra coisa
      Desde a mudança de cobrança do Google Maps alguns anos atrás, também temos tomado muito cuidado para não nos prender profundamente a serviços “gratuitos” do Google, e isso acabou saindo caro
    • Existe mesmo alguma forma simples de listar todos os recursos existentes em uma conta AWS?
      Sempre tive que verificar por serviço e por região, o que era tedioso e sujeito a erros
    • Do ponto de vista da Amazon, como isso permite ganhar 1000 dólares facilmente, não é bug, é feature
      Mesmo que considerem um bug, provavelmente terá prioridade muito menor do que outras coisas que afetem diretamente o resultado financeiro deles
    • Concordo que não é justo esperar uma verificação paranoica do desenvolvedor
      Mas, na prática, é razoável
      Quando crio algo na AWS, trato a AWS como uma instituição financeira hostil fora de controle

  • Por causa de casos como esse, venho adiando há anos me aprofundar na AWS
    Deveria haver um curso educacional padrão que não exigisse dados de cartão de crédito e permitisse que as pessoas experimentassem gratuitamente
    Em vez disso, parece haver burocratas calculando que dá para arrancar milhares de dólares aqui e ali por “erro do usuário”
    Esse tipo de cobrança é difícil de contestar e, em alguns casos, totalmente impossível
    Acho que não sou a única pessoa que evitou o ambiente da AWS por um medo racional de se deparar com uma conta enorme

    • Numa situação dessas, é muito incomum a AWS não conceder reembolso, então é difícil ver isso como uma estratégia para extrair milhares de dólares de erros de usuários
      É bem provável que eles tenham concluído que processar reembolsos dá menos trabalho do que fornecer tutoriais precisos e baratos
      Isso não justifica a conduta, mas eu já consegui cancelar até uma cobrança legítima de 600 dólares gerada ao usar o AWS Textract
      Na época eu trabalhava em uma empresa de dezenas de bilhões de dólares
    • Acho que as pessoas caem nesse tipo de situação de pagamento porque, na prática, não se aprofundam de verdade na AWS
      As tabelas de preço são fáceis de acessar e nem sempre fáceis de entender, mas a maioria dos custos cresce de forma quase linear, então é relativamente fácil testar
      É melhor evitar serviços wrapper como AWS Amplify, CloudFormation e os vários tipos de Stack
      Basta usar os serviços principais diretamente
      Todos os serviços têm API, e obter uma chave de API vinculada a um usuário IAM é tão simples quanto clicar em um botão
      O resto dá para gerenciar com caching adequado e alinhando o modelo de custos ao modelo de receita
      É fazer com que o custo dos serviços com autoscaling se torne uma proporção quase fixa da receita, independentemente da demanda atual
      Largura de banda é o verdadeiro pesadelo na AWS, mas o console oferece descontos automáticos de longo prazo, e por meio de um representante comercial dá para conseguir descontos contratuais um pouco melhores
      Por isso eu evitaria EC2; como a largura de banda interna do EC2 também é mais cara, acho melhor usar Lambda + S3 + CloudFront diretamente
      Depois de uns 3 meses, ficou bem fácil prever qual combinação de serviços seria mais econômica ao implementar uma nova funcionalidade voltada ao usuário
    • A Cloud Guru / Pluralsight tem um recurso que chamam de “Cloud Playground” ou “sandboxes”
      Talvez sirva para esse uso, mas não usei diretamente, então não tenho certeza
    • O dinheiro gerado por esse tipo de erro de usuário deve ser uma gota no oceano para a AWS como um todo
      Pela minha experiência, a AWS tendia mais a evitar problemas que pudessem custar caro em dano reputacional
      A AWS não é barata e, em alguns casos, especialmente em custos de transferência de dados, é absurdamente cara, mas não acho que a forma deles seja enganar clientes para gastarem acidentalmente algumas centenas de dólares a mais

  • Bem típico da AWS
    Alguns meses atrás, segui o guia oficial de início rápido do SageMaker para rodar o Llama 2; ele realmente subiu muito rápido, mas no dia seguinte vi que estava gastando 400 dólares por dia
    Consegui cancelar a cobrança, mas aprendi claramente que não dá para confiar em guia oficial

    • O SageMaker é um dos produtos mais decepcionantes do ponto de vista de produto e um exemplo claro de enshittification
      No início do produto, em 2017–2018, a configuração era bastante intuitiva
      Ficava claro que havia instâncias de notebook, inferência, API REST para serving, um pouco de EFS, e que o centro do serviço era o S3
      O preço também era fechado, então não havia surpresas
      No geral parecia algo como DigitalOcean, e até um cientista de dados com conhecimento básico e curiosidade sobre infraestrutura conseguia montar uma configuração barata, previsível e simples
      Agora há Wrangler, Feature Store, RStudio, a experiência de uso do console de notebooks é horrível, e internamente vários serviços movem dados e cobram por isso

  • Por necessidade, precisei enviar requisições HTTP brutas em vez do SDK inchado da AWS; com o header content-type: application/json falhava, e com content-type: application/x-amz-json-1.0 funcionava
    Gostaria muito que parassem com esse nonsense

    • Senti algo parecido em quase todas as partes da AWS com que mexi ao longo da carreira
      Excessivamente inchada sem benefício claro, excessivamente complexa ou cheia de implementações próprias estranhas
    • Sinceramente, são detalhes internos vazando
      Porque internamente a maioria dos apps usa o antigo framework Coral e esse formato JSON, com formas bem definidas para entrada, saída e erros

  • Todos os guias oficiais da AWS são projetados para fazer você usar o máximo possível de serviços da AWS, e com isso o risco de gasto aumenta
    É preciso olhar de forma extremamente crítica para o que a AWS recomenda: padrões da GUI, ferramentas CLI, guias, arquiteturas recomendadas etc.
    Há um motivo para existirem cargos muito bem pagos em empresas orientando colegas a usar AWS de forma econômica e de baixo risco

    • Exato
      Em implantações pequenas ou testes, a parte mais cara quase sempre são coisas acessórias, ou serviços mais recentes recomendados em vez de alternativas mais simples

  • Se você está usando OpenSearch por causa de consultas de caixa delimitadora em geo_point, que tal PostgreSQL + PostGIS?
    https://postgis.net/docs/using_postgis_query.html

  • Acho que essa configuração sem atrito, a experiência/interface de usuário pouco intuitiva, a baixa cautela em registrar cartão de crédito e a cobrança agrupada entre serviços como AWS Batch + Lambda + EC2 fazem parte do modelo de negócio
    Não sei bem como expressar, mas é parecido com um parque de diversões moderno em que você paga ingresso para entrar e depois paga separadamente por todos os brinquedos e até pelo banheiro

    • Também sinto isso
      O modelo de cobrança da nuvem transfere a responsabilidade para o usuário em nome da “flexibilidade” e da “customização”
      Imagine uma locadora de carros cobrando cada componente por milissegundo, como rotação do comando de válvulas do motor, giro dos pneus, acionamento do limpador de para-brisa e tempo de aquecimento dos bancos, dizendo que o cliente “controla” uso e orçamento porque pode configurar alertas para cada item
      É um modelo de custos hostil e perigoso para o usuário desde os padrões iniciais