Como reduzir a conta de nuvem sem perder estabilidade

A conta de nuvem chega todo mês um pouco maior. Ninguém decidiu gastar mais: um ambiente de teste ficou ligado, os logs cresceram, o banco foi aumentado durante um incidente e nunca voltou, os backups se acumulam sem prazo de validade. Quando o financeiro pergunta o motivo, a resposta é uma lista de serviços com nomes técnicos que ninguém consegue ligar a um sistema ou a uma decisão.

Reduzir custo de nuvem não é cortar recursos às cegas. Quem faz isso economiza no primeiro mês e paga no segundo, com lentidão, incidente ou perda de dados. O caminho seguro é organizar as ações por nível de risco, das que não afetam nada às que exigem engenharia, sempre com medição antes e depois. Este texto segue essa ordem. Os exemplos usam termos da AWS, mas os conceitos valem para Google Cloud e Azure.

Por que a conta sobe sem ninguém ter decidido nada

Os padrões se repetem em quase todas as contas:

• Superdimensionamento. Máquinas e bancos escolhidos "com folga" no lançamento, que usam uma fração da capacidade.
• Recursos órfãos. Discos de máquinas apagadas, snapshots antigos, IPs reservados sem uso, balanceadores sem destino.
• Ambientes que nunca desligam. Desenvolvimento, homologação e demonstrações rodando 24 horas por dia, 7 dias por semana, para uso em horário comercial.
• Armazenamento sem política. Arquivos, backups e logs guardados para sempre na classe de armazenamento mais cara.
• Tráfego de saída. Dados saindo da nuvem para a internet, entre regiões ou entre zonas, cobrados por volume e raramente acompanhados.
• Serviços gerenciados sem revisão. Configurações padrão que fazem sentido em escala e são exageradas para o seu volume.
• Preço de tabela. Uso estável pago pelo preço sob demanda, sem nenhum compromisso de uso.

Nenhum desses itens é um erro grave isolado. Somados, e sem ninguém olhando, eles viram uma parte relevante da conta.

Visibilidade: etiquetas de custo por sistema e por time

Você não reduz o que não consegue atribuir. O primeiro passo não corta nada, mas torna todo o resto possível.

Etiquetas (tags) em todos os recursos, com um padrão mínimo:

• sistema: qual aplicação usa este recurso;
• ambiente: produção, homologação, desenvolvimento;
• responsável: time ou pessoa que responde por ele;
• centro de custo, quando o financeiro precisa ratear.

Recursos sem etiqueta devem ser bloqueados na criação, por política, ou pelo menos listados num relatório semanal. Etiquetar o que já existe é trabalho braçal, mas feito uma vez.

Contas separadas por ambiente (produção separada de desenvolvimento) ajudam na visibilidade e na segurança ao mesmo tempo.

Orçamentos e alertas por conta, sistema e time, com aviso quando o gasto projetado passar do esperado. Detecção de anomalias, disponível nos três grandes provedores, avisa quando um serviço dispara de um dia para o outro.

Um relatório mensal que responda, em linguagem de negócio: quanto custa cada sistema, o que mudou em relação ao mês anterior e por quê.

O que dá para cortar sem risco nenhum

Com visibilidade, as primeiras ações são as que não tocam em nada que esteja em uso:

• Apagar recursos órfãos: discos sem máquina, snapshots de máquinas que não existem mais, IPs sem uso, balanceadores sem destino, ambientes de projetos encerrados. Antes de apagar, um último snapshot ou exportação, se houver dúvida.
• Desligar ambientes não produtivos fora do horário: desenvolvimento e homologação ligados só em horário comercial, com agendamento automático e forma simples de religar.
• Políticas de ciclo de vida no armazenamento: arquivos que não são acessados há tempo passam automaticamente para classes mais baratas, e o que passou do prazo de retenção é apagado.
• Retenção de logs: definir por quanto tempo cada tipo de log fica disponível para consulta rápida e quando vai para armazenamento de arquivo ou é descartado.
• Retenção de backups e snapshots, alinhada ao plano de recuperação, não ao "guardar tudo por precaução".

Essas ações costumam ser as de melhor relação entre esforço e resultado, e nenhuma delas afeta o usuário.

Dimensionamento correto com base em métricas reais

Aqui começa o risco. Reduzir o tamanho de uma máquina ou banco que está superdimensionado economiza; reduzir um que está no limite causa incidente.

A regra é medir antes de mudar:

• colete uso de processador, memória, disco e rede por um período que inclua os picos reais: fechamento de mês, campanhas, sazonalidade;
• olhe para os picos e os percentis altos, não para a média;
• reduza um degrau de cada vez, com plano de volta;
• acompanhe latência e erros depois da mudança.

Métricas de uso e de experiência do usuário são o que separa economia de incidente. Sem observabilidade com logs, métricas e traces, redimensionar é aposta.

Gerações e famílias de instância. Famílias mais novas costumam oferecer mais desempenho pelo mesmo preço, e processadores de arquitetura ARM, quando a aplicação é compatível, podem reduzir custo. Teste antes de trocar.

Bancos de dados merecem atenção separada. Muitas vezes o banco foi aumentado para resolver um problema de desempenho que era, na verdade, uma consulta sem índice. Corrigir a consulta permite voltar ao tamanho anterior. Esse tipo de investigação está em sistema lento: diagnóstico de performance.

Compromisso de uso e capacidade sob demanda

Depois que o dimensionamento está correto, o preço também pode mudar.

Compromisso de uso. Os provedores oferecem descontos em troca de compromisso de consumo por um período (na AWS, Savings Plans e instâncias reservadas; no Google Cloud e no Azure, mecanismos equivalentes). Faz sentido para a carga estável, a base que roda sempre. Comprometer antes de dimensionar é travar o desperdício por anos. Comece cobrindo uma parte da base e aumente conforme o uso se confirma.

Capacidade ociosa com desconto. Instâncias spot (ou equivalentes) usam capacidade ociosa do provedor com grande desconto, mas podem ser interrompidas com pouco aviso. Servem para processamento em lote, filas de trabalho, ambientes de teste e aplicações preparadas para perder uma máquina a qualquer momento. Não servem para o banco de dados de produção.

Escala automática. Aplicações com demanda variável podem aumentar e diminuir o número de máquinas conforme a carga, em vez de ficar dimensionadas para o pico o tempo todo. Isso exige que a aplicação não guarde estado na memória da máquina, o que é também uma boa prática de arquitetura.

Armazenamento, logs e tráfego de saída

Três itens que crescem em silêncio:

Armazenamento de objetos. Classes de armazenamento com custo menor para dados pouco acessados, com políticas de transição automáticas. Cuidado com o custo de recuperação e com prazos mínimos de permanência nas classes de arquivo: mover dados muito acessados para elas pode sair mais caro.

Logs e métricas. Ferramentas de observabilidade cobram por volume ingerido e retido. Log em nível de depuração em produção, logs duplicados e métricas com dimensões demais inflam a conta. Defina níveis de log por ambiente, amostragem para rastreamento e retenção por tipo.

Tráfego de saída. Dados que saem da nuvem para a internet são cobrados; dados entre regiões e, em alguns casos, entre zonas de disponibilidade também. Pontos a revisar:

• arquivos estáticos e mídias servidos por uma CDN, com cache;
• serviços que conversam muito entre si na mesma zona sempre que possível;
• tráfego para serviços do próprio provedor por caminhos privados, em vez de passar pela internet;
• replicações e cópias entre regiões que ninguém lembra por que existem;
• exportações de dados volumosas para fora da nuvem.

Consultas analíticas pesadas rodando no banco de produção, em horário de pico, são outra fonte comum de custo e lentidão. Separar a carga analítica num ambiente próprio, como um data warehouse para empresas médias, reduz a pressão sobre o banco transacional e deixa o custo de análise visível.

Mudanças de arquitetura que reduzem custo de forma estrutural

As maiores reduções costumam vir de mudanças de desenho, que exigem engenharia e devem ser avaliadas caso a caso:

• Serviços gerenciados no lugar de máquinas administradas à mão, quando o custo operacional de manter a máquina é maior que a diferença de preço.
• Processamento assíncrono com filas, absorvendo picos sem dimensionar tudo para o pior momento.
• Funções sob demanda para tarefas esporádicas, que custam só quando rodam.
• Cache para consultas repetidas, reduzindo carga no banco.
• Consolidação: vários sistemas pequenos, cada um com seu banco e sua máquina subutilizados, compartilhando infraestrutura.
• Revisão de réplicas e alta disponibilidade: ambientes não críticos com a mesma redundância da produção.

Cada mudança tem custo de engenharia e risco. Faça as contas do retorno e comece pelas que também melhoram a operação.

Erros comuns

• Cortar sem medir, trocando economia por incidente.
• Comprar compromisso de uso antes de dimensionar.
• Usar capacidade interrompível em carga crítica.
• Ignorar tráfego de saída e logs.
• Um esforço de redução pontual, sem processo contínuo, e a conta volta a crescer em poucos meses.
• Nenhum dono para o custo de cada sistema.

Checklist de redução

• Etiquetas obrigatórias e contas por ambiente.
• Orçamentos, alertas e detecção de anomalias ativos.
• Recursos órfãos removidos e ambientes não produtivos com horário.
• Ciclo de vida para armazenamento, logs e backups.
• Dimensionamento revisado com métricas de pico.
• Compromisso de uso para a base estável.
• Tráfego de saída mapeado e otimizado.
• Revisão mensal de custos com os donos de cada sistema.

Conta menor, sistema igualmente estável

A Pervian Tech revisa e otimiza ambientes de nuvem no nosso trabalho de cloud e DevOps: visibilidade por sistema, limpeza, dimensionamento com base em métricas, estratégia de compromisso de uso e mudanças de arquitetura quando elas se pagam. Não prometemos percentual de economia antes de olhar a sua conta, porque cada ambiente é diferente.

Começamos por um diagnóstico inicial gratuito do seu ambiente e da sua fatura. Com ele definimos as ações em ordem de risco, as fases e o investimento, que é sob consulta. Se a sua conta de nuvem cresce sem explicação, conte como está o seu ambiente.