Por que a fatura da AWS sobe sem que ninguém tenha decidido gastar mais

Um NAT Gateway que ninguém decidiu criar

Auditoria de infraestrutura encontra, com regularidade suficiente para virar item fixo de checagem, um padrão parecido com este cenário ilustrativo: um NAT Gateway processando terabytes de tráfego por mês, criado durante a configuração inicial de uma rede privada e nunca reavaliado depois que a arquitetura em volta dele mudou. Ninguém decidiu, em nenhum dia específico, pagar por aquele tráfego. A decisão foi tomada por omissão, meses antes, quando alguém configurou a rede da forma mais rápida disponível e passou para a tarefa seguinte.

Multiplicado por dezenas de escolhas pequenas e igualmente razoáveis no momento em que foram feitas, esse mecanismo explica por que a fatura de nuvem cresce sem que exista um evento único a que atribuir o aumento.

As fontes de desperdício que se repetem

Um conjunto reduzido de padrões aparece em revisão após revisão, com frequência que justifica checagem específica em toda auditoria:

• instância dimensionada para um pico que não se repetiu e mantida no mesmo tamanho pelo resto do mês, o rightsizing pendente;
• NAT Gateway processando volume que poderia permanecer dentro da própria rede, cobrado por hora ativa e por gigabyte processado;
• tráfego cruzando zona de disponibilidade quando os componentes que mais conversam entre si poderiam estar na mesma zona, já que a transferência entre zonas é cobrada por gigabyte;
• dado parado na classe padrão do S3 muito depois de o padrão de acesso justificar uma classe de acesso menos frequente;
• volume EBS que sobreviveu à instância que o criou e continua cobrado sem que ninguém o utilize;
• egress, o tráfego de saída para a internet, que tende a ser a linha mais cara e menos visível, porque não aparece como recurso ligado e sim como consumo diluído ao longo do mês.

Nenhum desses itens isolado justifica um projeto de reestruturação. O ganho vem de tratá-los como revisão recorrente, a cada poucos meses, porque infraestrutura que cresce recria os mesmos pontos de desperdício depois de qualquer limpeza, por melhor que ela tenha sido.

O que uma auditoria de fatura examina antes da arquitetura

A auditoria, no mesmo formato aplicado na frente de Infraestrutura & Cloud, começa pela fatura discriminada por serviço e por tag de projeto, quando essas tags existem e foram aplicadas com consistência. O passo seguinte cruza gasto com uso efetivo: CPU e memória consumidos contra o que foi provisionado, volume de dado que de fato sai da rede contra o que se imaginava sair, recursos sem tag de dono identificável. A ausência de dono identificável não indica recurso sem uso: é gatilho para inventário e validação de dependência, não para desligamento direto, já que desligar sem confirmar as dependências é o que derruba produção.

O modelo de compra entra na mesma análise. Workload previsível rodando sob preço sob demanda, quando um plano de economia ou uma instância reservada cobriria o mesmo uso por uma fração do custo, é dos achados mais recorrentes e dos mais rápidos de corrigir, porque depende apenas de uma decisão de compra, sem alterar uma linha de configuração. Todo esse levantamento sustenta qualquer proposta de redução apresentada depois: sem o número de antes, medido com método, não existe como demonstrar o número de depois.

O risco de comprometer capacidade demais

Contratar Savings Plans ou Reserved Instances sem confiança no padrão de uso futuro cria o problema inverso. Um compromisso de um ou três anos continua sendo pago se o workload encolher ou migrar para outro desenho antes do fim do prazo, e quem compara apenas o percentual de desconto anunciado ignora esse risco por completo na hora de aprovar a compra.

A prática defensável é comprometer capacidade apenas sobre a parcela de uso que se manteve estável por vários meses seguidos, tipicamente a carga mínima abaixo da qual o sistema nunca opera, deixando o excedente variável sob preço sob demanda ou sob instância pontual (Spot), que custa bem menos e pode ser interrompida pela AWS com apenas dois minutos de aviso, em caráter de melhor esforço, o que recomenda seu uso apenas para carga tolerante a interrupção. Compromisso malfeito custa tanto quanto o desperdício que deveria eliminar, com o agravante de ficar distribuído ao longo de um contrato difícil de desfazer no meio.

Por que migrar para Kubernetes raramente reduz a fatura

Quando a fatura cresce, uma proposta frequente no mercado é migrar para Kubernetes, como se orquestração de contêiner corrigisse desperdício de infraestrutura por conta própria. Raramente corrige. Kubernetes acrescenta uma camada de complexidade operacional, exige equipe capaz de operar o cluster e, sem ajuste fino de requisição e limite de recurso por serviço, reproduz o mesmo desperdício de antes dentro de um formato consideravelmente mais difícil de auditar.

A orquestração se justifica quando o número de serviços torna deploy e escala manuais inviáveis, tipicamente dezenas de serviços com padrões de tráfego distintos entre si, como no case de plataforma de telemedicina com onze serviços independentes. Para uma aplicação com meia dúzia de serviços e tráfego previsível, instância dimensionada corretamente com auto scaling básico custa menos para rodar e para manter do que um cluster subutilizado que exige conhecimento especializado apenas para permanecer de pé.

Quando o desperdício vira problema de arquitetura

Existe um ponto a partir do qual o gasto deixa de ser desperdício pontual e passa a refletir uma arquitetura inadequada ao volume atual, seja porque o sistema roda sobre um desenho pensado para uma escala muito menor, seja porque foi superdimensionado para uma escala que nunca chegou a existir. Nesses casos, reduzir custo depende de redesenhar o fluxo de dado entre os componentes, trabalho de outra ordem de grandeza quando comparado a desligar recurso ocioso.

Redesenho se justifica quando a economia projetada, calculada antes de qualquer mudança começar e apresentada com a metodologia de cálculo à vista, cobre o custo do próprio redesenho num prazo que o cliente considere aceitável para o negócio dele. Projeto de otimização incapaz de mostrar essa conta antes de começar está pedindo confiança no lugar de apresentar um business case, e a diferença entre as duas coisas costuma ficar clara na terceira fatura depois da mudança.