Alertas de custo na nuvem: como configurá-los no AAA Sentinel para não ter surpresas na fatura

A surpresa na fatura cloud segue sempre o mesmo guião: fecha-se o mês, chega a fatura, o valor é mais alto do que o esperado e começa a investigação. Nessa altura, o recurso que disparou já está a faturar há semanas. Os alertas existem para encurtar esse tempo, mas só funcionam se avisarem cedo, a pessoa certa e com algo concreto para fazer. Neste artigo mostramos como montá-los com o AAA Sentinel e com os orçamentos nativos de cada nuvem, que se complementam.

O problema: um único alerta, e tarde

Muitas equipas têm, no máximo, um aviso quando o gasto do mês atinge o orçamento. Quando chega, o mês já está gasto e só resta explicar o que aconteceu. Outras têm alertas que caem numa caixa de correio que ninguém lê, ou tantos alertas que a equipa aprendeu a ignorá-los.

O que ganha com isto

Com os alertas bem distribuídos por camadas:

• Vê um pico de gasto na análise seguinte, não na fatura.
• Cada aviso chega ao canal onde a equipa trabalha: e-mail, Slack ou um sistema próprio.
• O que é preciso corrigir acaba como ticket no Jira ou no Linear, com dono e prioridade.
• Quem não precisa do detalhe recebe um resumo diário ou semanal em vez de cada alerta.

Antes de mais: o AAA Sentinel não substitui os orçamentos da sua nuvem

Convém dizê-lo com clareza: o AAA Sentinel não tem orçamentos de nuvem. Não fixa um teto mensal por conta nem avisa aos 80 % de um valor. Os orçamentos que gere são os de IA, que é outra história. Para o teto mensal, use o orçamento nativo de cada fornecedor, que tem os dados de faturação em primeira mão. O AAA Sentinel acrescenta o que o orçamento não vê: subidas entre análises, deteções novas que explicam a subida, anomalias por serviço e um único sítio para avisar sobre as três nuvens.

A estratégia em três camadas

Esta é a combinação que recomendamos:

• Camada 1 · O teto do mês: um orçamento nativo em cada nuvem, com avisos sobre o gasto previsto e o real (por exemplo, a 80 % do previsto e a 100 % do real). Diz-lhe se o mês vai a caminho de se exceder.
• Camada 2 · Os desvios: o alerta de picos de gasto do AAA Sentinel, que compara cada análise com a anterior, e o relatório de anomalias, que desce ao detalhe de cada serviço.
• Camada 3 · As causas: os alertas de deteções novas críticas ou de alta prioridade, que chegam com o recurso concreto e podem abrir um ticket sozinhos.

Camada 1: os orçamentos nativos em cada nuvem

Os três fornecedores resolvem-no de forma parecida:

• AWS: AWS Budgets, em Billing and Cost Management. Orçamentos de custo por conta, serviço ou etiqueta, com avisos sobre o gasto real ou previsto por e-mail ou Amazon SNS. Para picos inesperados, o AWS Cost Anomaly Detection usa aprendizagem automática e avisa pelos mesmos meios.
• Azure: Cost Management → Orçamentos. Por subscrição ou grupo de recursos, com condições de alerta sobre o custo real ou previsto, que enviam e-mail ou disparam um grupo de ações. O Cost Management oferece também alertas de anomalias por subscrição.
• Google Cloud: Faturação → Orçamentos e alertas. Regras de limiar sobre o gasto real ou previsto (por omissão a 50, 90 e 100 %), com e-mail aos administradores de faturação e Pub/Sub se quiser automatizar algo.

Como funcionam os alertas do AAA Sentinel

Os alertas são gerados nos planos Pro e Business, no fim de cada análise de cada conta. Nesses planos a análise é automática e diária, por isso, na prática, a plataforma revê cada conta uma vez por dia. Isto é o que pode disparar um aviso:

• Cada alerta fica guardado em Alertas durante 90 dias, tenha ou não sido enviado para algum canal.
• As ligações de IA usam os mesmos interruptores: um pico de gasto de IA ou um orçamento de IA prestes a esgotar-se também chega como alerta.

Caso prático: ACME

A ACME, uma empresa fictícia com o plano Pro, tem três contas ligadas: a loja na AWS, uma subscrição do Azure e um projeto do Google Cloud. Quer saber no próprio dia de qualquer subida séria e que o que for acionável acabe no Jira. Esta é a sua configuração:

Passo 1: ligar os canais

Tudo se configura em Alertas → Canais de alerta, que só o proprietário e os administradores podem alterar. Cada canal tem o seu botão de teste: use-o antes de dar algo por certo.

• E-mail: ativa-se com um interruptor e envia para o endereço com que a pessoa que guarda a configuração acede ao AAA Sentinel.
• Slack: em api.slack.com/apps crie uma app, ative Incoming Webhooks, carregue em «Add New Webhook to Workspace», escolha o canal e copie a URL, que começa por hooks.slack.com. Cole-a em «URL Webhook do Slack» e carregue em «Testar webhook».
• Microsoft Teams: no canal, abra Mais opções → Workflows, escolha o modelo «Enviar alertas de webhook para um canal», confirme a equipa e o canal, guarde e copie a URL. Leva uma assinatura dentro: trate-a como uma palavra-passe. As URL dos antigos connectors do Office 365 (webhook.office.com) são rejeitadas, porque a Microsoft os desligou em maio de 2026.
• Webhook genérico: uma URL HTTPS pública (os endereços de rede interna são rejeitados) que recebe um POST JSON com o tipo, a severidade, o título, a mensagem, a conta e a análise. Se precisar de assinatura, os webhooks de Developer → Aplicações OAuth2 emitem o evento alert.triggered com o cabeçalho X-Sentinel-Signature.

Passo 2: ajustar os limiares de deteção

Na mesma página, o bloco Limiares de detecção decide quando vale a pena avisar:

• Limiar de pico de gastos: entre 5 e 100 %, em passos de 5; por omissão, 20 %.
• Gastos mínimos para alertar: de 0 a 1.000 USD/mês; por omissão, 5. Evita avisos em contas quase vazias.
• Subida do custo unitário: entre 5 e 100 %; por omissão, 20 %. Só se aplica se usar custo unitário.
• Notificar quando detectado: um interruptor por tipo (Novas deteções críticas, Novas deteções de alta prioridade, Picos de despesa, Novos achados de segurança, Queda do Security Score e Subida do custo unitário). Vêm todos ativados.

Passo 3: o resumo periódico

Nem toda a gente precisa de cada alerta. O Resumo periódico é um e-mail diário ou semanal (escolhe o dia da semana e a hora de envio, em UTC) com o custo da última análise, as deteções, a poupança potencial e quantos alertas críticos e altos houve no período. É enviado por conta e só se tiver havido alguma análise concluída nesse período. A ACME programa-o às segundas-feiras às 07:00 UTC para a direção, e deixa os alertas em tempo real para a equipa de plataforma.

Passo 4: do alerta ao ticket

No dia 14, a análise da conta AWS da ACME regista 3.100 USD face aos 2.400 USD da análise anterior: uma subida de 29 %. Como ultrapassa os 25 % e o mínimo de 100 USD, dispara um pico de gasto de severidade alta. Isto é o que acontece a seguir:

• O aviso chega ao e-mail e a #finops-alertas, com uma ligação para a plataforma.
• Como o Jira está configurado para severidade Alto ou superior, é criado um ticket no projeto FINOPS com a prioridade correspondente e a etiqueta finops-sentinel. O Linear funciona da mesma forma. Ambos se configuram em Alertas → Integrações, cada um com o seu botão «Testar conexão».
• Na página Alertas, a equipa vê o aviso junto dos restantes, pode filtrar por severidade ou por conta e marca-o como lido depois de o rever.
• A partir de uma deteção concreta também pode abrir o ticket à mão, sem esperar por nenhum alerta.

Passo 5: Anomalias, para saber que serviço foi

Uma subida de 29 % diz que algo mudou, mas não o quê. Com o plano Business, Relatórios → Anomalias compara as duas últimas análises de cada conta, serviço a serviço, e deteta quatro tipos de anomalia:

• Pico ou queda de gasto da conta: mais de 15 % e mais de 5 USD de diferença.
• Serviço novo: um serviço que não existia e aparece com mais de 10 USD.
• Pico num serviço existente: mais de 25 % e mais de 5 USD de subida.
• Cada anomalia pode ser marcada como revista, descartada ou reaberta. As descartadas não contam para o Impacto total.

O que ainda não faz

Para que saiba onde estão os limites:

• Não tem orçamentos de nuvem nem avisos por percentagem de um orçamento: para isso existem o AWS Budgets, os orçamentos do Azure Cost Management e os do Google Cloud.
• Não deteta picos ao longo do dia: compara análise com análise, normalmente uma vez por dia.
• A configuração de canais e limiares é comum a toda a organização; se gere clientes com o plano Business, cada cliente pode ter a sua.
• Os limiares do relatório de anomalias são fixos; os que define em Limiares de detecção só afetam os alertas.

Checklist para começar

Com estas peças no lugar, a fatura do fim do mês deixa de ser o primeiro aviso.

• Um orçamento nativo em cada nuvem, com aviso sobre o gasto previsto e sobre o real.
• Plano Pro ou Business, com as contas ligadas e analisadas todos os dias.
• Pelo menos um canal testado em Canais de alerta: e-mail, Slack ou webhook.
• Limiar de pico e gasto mínimo ajustados ao seu gasto, para que cada aviso signifique algo.
• O resumo periódico para quem não precisa de cada alerta.
• Jira ou Linear ligados em Integrações para que o importante acabe num ticket.
• Com Business, o relatório de Anomalias revisto depois de cada pico.