Como Cortamos 15% de uma Conta de Nuvem de $20k que Já Tinha um Plano de FinOps

O cliente é uma empresa SaaS líder nos EUA, do setor de produtividade e colaboração, com sede no Texas. O produto roda no Azure — onde esta história se passa.

O Desafio

Quando nos procuraram, o ambiente Azure rodava em torno de $20.000 por mês. Eles já haviam feito o trabalho óbvio. Reservas estavam em uso, alguém internamente já tinha passado por uma rodada de FinOps, e os ganhos fáceis tinham acabado. Ou pelo menos era o que pensavam.

A primeira coisa que faço em qualquer ambiente é olhar para onde o dinheiro realmente vai, serviço por serviço. Na primeira hora, um número saltou aos olhos: os backups consumiam 15% de toda a conta. Ninguém do lado deles tinha sinalizado isso. Não estava no radar.

É muito dinheiro para algo que a maioria das equipes de engenharia configura uma vez e nunca mais olha.

A Causa Raiz: Retenção do Point in Time Restore

Quando você provisiona Azure SQL, dois mecanismos de backup já vêm rodando por padrão — e eles fazem coisas muito diferentes.

Um backup diário é exatamente o que parece. Uma vez por dia, o sistema tira um snapshot do seu banco. Se algo der errado, você pode restaurar para o estado de ontem, ou de anteontem, dependendo de quantos você guarda.

Point in Time Restore (PITR) é outra coisa. Ele registra continuamente cada transação para que você possa voltar o banco a qualquer segundo específico dentro da janela de retenção. Perdeu uma linha às 14:32:07 de ontem por causa de um deploy ruim? O PITR permite restaurar para 14:32:06. É poderoso e, para a maioria das cargas de produção, realmente útil.

O problema é que todos esses logs de transação ficam armazenados — e você paga por esse armazenamento. Quanto maior a janela de retenção do PITR, mais logs ficam parados, e a conta cresce na mesma proporção.

Esse cliente tinha a retenção de PITR configurada para 35 dias. Não era o padrão — alguém havia aumentado explicitamente anos atrás, e o valor vinha se acumulando silenciosamente desde então. Quando olhamos, ninguém na equipe atual sabia mais por que aquele número tinha sido escolhido.

A Correção

A prática de mercado para PITR é de 7 dias. É o suficiente para cobrir a janela realista em que você notaria uma corrupção de dados, um deploy ruim ou uma exclusão acidental e precisaria de um rollback preciso. Além de 7 dias, você quase sempre estará recorrendo a backups diários ou cofres de backup de longo prazo, que são bem mais baratos para esse fim.

Reduzir de 35 para 7 dias cortou 80% do custo da linha de backups. A mudança em si? Cinco minutos clicando no portal do Azure. Sem alteração de código, sem deploy, sem risco para a aplicação.

Por que Isso Importa

Essa é a parte do FinOps de que os fornecedores de ferramentas não falam. Reservas e rightsizing são as estrelas porque são fáceis de automatizar e fáceis de vender. Também são a primeira coisa que qualquer um com um mandato de FinOps vai fazer — exatamente o que já tinha acontecido aqui.

Mas o desperdício se esconde na arquitetura, e às vezes em uma configuração que alguém alterou anos atrás e esqueceu. A retenção do PITR é um dropdown em um script de provisionamento. Ninguém revisa. Plataformas genéricas de FinOps não sinalizam isso porque não entendem a diferença entre armazenamento de log de transação e armazenamento de snapshot, ou qual é uma janela de retenção sensata para um produto SaaS.

Você só pega isso se já tiver construído e operado esses sistemas. É aí que a Koritsu entra. Vamos além da camada de dashboard, direto às decisões de engenharia que silenciosamente moldam a sua conta.

Uma mudança de cinco minutos. 80% a menos em backups. 12% a menos na conta total. Em um ambiente que já era considerado “otimizado”.