Monitoramento 24/7 pegou uma surpresa de $7.500/mês durante uma migração de conta

O Número Que Estava Indo Para o Lado Errado

O custo de uma conta subiu. Isso não teria nada de estranho, exceto por um detalhe: era uma conta que estávamos no meio de desligar. Uma conta em desativação ainda carrega custo até o fim, então o número nunca é zero. Mas a direção deveria ser para baixo, não para cima. O agente sinalizou no primeiro dia em que o número foi para o lado errado, antes de alguém do lado do cliente ter percebido qualquer coisa.

É nessa contradição que esta história começa.

O Contexto

O cliente é um grupo global de serviços financeiros rodando na AWS. Quando entramos, eles estavam no meio de uma migração de conta, movendo cargas de trabalho para uma nova conta AWS e desativando a antiga.

A conta antiga estava de saída. Alguém já tinha passado por ela e parado os recursos que não eram mais necessários, bancos de dados incluídos. Só que desativar uma conta grande não é um botão que você aperta. Migrações precisam ser finalizadas, dependências desfeitas e dados apagados com segurança, então a conta ainda carregava gasto real e o custo dela deveria diminuir aos poucos, não sumir. Durante uma migração toda a atenção fica na conta nova, em levar as cargas de trabalho e deixá-las estáveis. A antiga vira uma coisa secundária. É justamente aí que mora o ponto cego.

O Sinal

Nosso agente de IA monitora o custo em todas as contas conectadas de forma contínua. O que importa aqui não é só que ele estava observando, mas que ele entendia o que estava observando. Ele sabia que essa conta estava sendo desativada. Sabia que a curva de custo deveria apontar para baixo.

Então, logo no primeiro dia em que o custo de RDS dessa conta veio maior que no dia anterior, o agente não leu aquilo como variação comum. Leu como uma contradição, e o alerta que ele levantou dizia exatamente isso: os custos de RDS estão aumentando em uma conta em desativação.

Essa especificidade é o ponto. Não "o gasto subiu tantos por cento", mas "o serviço errado está crescendo em uma conta que deveria estar encolhendo". Naquele momento não sabíamos o porquê. Os recursos tinham sido parados. Alguma coisa não fechava, e a única coisa que tinha percebido era o agente, já no primeiro dia.

A Investigação

Então abrimos a conta para ver o que estava puxando o número. Os bancos de dados que tinham sido parados estavam rodando de novo.

Ninguém os tinha iniciado. Nenhum deploy, nenhum change request, nenhuma ação humana de qualquer tipo. Eles simplesmente voltaram sozinhos. Essa é a parte que te faz parar. Um recurso que você desligou de propósito, de volta ao ar, cobrando preço cheio, sem ninguém ter tocado nele.

Aqui está o comportamento que pega as equipes de surpresa. Quando você para uma instância RDS, a AWS não a deixa parada para sempre. Após 7 dias, ela reinicia a instância automaticamente. A AWS usa essa janela para aplicar manutenção e patches pendentes. É documentado, e existe uma razão sensata, mas quase ninguém lembra disso na hora. As instâncias chegaram ao sétimo dia, a AWS as trouxe de volta silenciosamente, e o medidor voltou a rodar.

Deixadas por conta própria, essas instâncias reiniciadas teriam adicionado cerca de $7.500 por mês a uma conta que deveria custar nada. Aproximadamente $90.000 por ano em infraestrutura que ninguém estava usando.

Por que Isso Importa

O que pegou o problema aqui não foi um alarme de limite. Muitas ferramentas conseguem te dizer que o gasto subiu tantos por cento. O que importou foi que o agente entendia a intenção da conta. Gasto subindo em uma conta que está morrendo só faz sentido se você sabe que a conta está morrendo. Esse contexto foi o que transformou um número pequeno e fácil de ignorar em um sinal que valia a pena agir.

É também por isso que o tempo importou. O faturamento nativo da nuvem é retrospectivo. Você fica sabendo do gasto deste mês no mês seguinte, no nível de conta e de serviço, muito depois de o dinheiro ter saído. Durante uma migração, quando um recurso se reiniciando sozinho é a última coisa na cabeça de alguém, esse atraso é exatamente onde as surpresas se escondem. Em vez de descobrir o custo em uma fatura posterior, pegamos no primeiro dia em que ele se moveu, quando ainda era irrelevante. Essa é a diferença entre recuperar um custo depois do fato e evitá-lo antes que ele se acumule.

Vale sinalizar que este não é um caso raro de borda. O auto-restart do RDS após 7 dias afeta qualquer um que pare instâncias esperando que fiquem paradas, o que é comum em migrações, desligamentos e exercícios de custo. Na maioria dos ambientes, a equipe só percebe quando a fatura chega.

Isso é FinOps de nível de engenharia na prática. Conhecer o comportamento da plataforma, observar todas as contas continuamente e em contexto, e agir sobre o sinal enquanto ele ainda custa quase nada.

É esse o tipo de surpresa que a Koritsu foi construída para pegar antes que ela chegue.