Os recursos cloud que mais dinheiro desperdiçam em AWS, Azure e Google Cloud, e como encontrá-los com Descobertas ativas

O desperdício na nuvem é surpreendentemente repetitivo. Seja qual for o fornecedor ou o tamanho da fatura, aparecem quase sempre os mesmos recursos esquecidos, que cobram a cada hora sem que ninguém os use. Encontrá-los à mão obriga a percorrer cada consola, região a região. Neste artigo revemos esses padrões, dizemos que regra do AAA Sentinel deteta cada um em AWS, Azure e Google Cloud e mostramos como trabalhar a lista de Descobertas ativas até a transformar em poupança.

Porque é que o desperdício se repete

Quase todo o gasto inútil nasce do mesmo gesto: elimina-se ou para-se o recurso principal e os acessórios sobrevivem. Ao eliminar uma máquina virtual, o disco pode ficar. Ao retirar um ambiente, o IP público reservado, o balanceador ou o NAT continuam ativos. E o que está em uso costuma estar dimensionado para um pico que nunca chegou. Nenhum destes recursos avisa: não falham, não geram incidentes e o seu custo fica diluído numa linha da fatura.

O que ganha com isto

Detetar estes recursos de forma sistemática muda a forma de trabalhar a poupança:

• Uma única lista para as três nuvens, ordenada por severidade e por poupança mensal estimada.
• Critérios fixos e conhecidos: cada descoberta vem de uma regra com um limiar concreto, não de uma opinião.
• Decisões que não se perdem: o que descarta ou dá por resolvido mantém-se assim nos exames seguintes.
• Um caminho claro da descoberta à ação, à mão, com um ticket ou com o agente.

Como o AAA Sentinel o resolve: exames, regras e descobertas

Cada exame lê os recursos e as métricas das suas contas ligadas com permissões só de leitura e aplica-lhes as regras de análise. Hoje são 51 regras de custo: 19 para AWS, 16 para Azure e 16 para Google Cloud. Cada regra que se cumpre gera uma descoberta com severidade, uma recomendação e uma poupança mensal estimada. Três ecrãs cobrem o circuito:

• Regras de análise: o catálogo completo, com o plano que inclui cada regra, a etiqueta «Automatizável» quando o agente pode aplicar a correção e um interruptor para a ativar ou desativar.
• Histórico de análises: cada exame com o seu custo, as suas descobertas e a comparação com o anterior (novas, desaparecidas, inalteradas).
• Descobertas ativas: a lista de trabalho com todas as descobertas do último exame de cada conta.

Cada padrão, a sua regra

Estes são os padrões de desperdício e as regras que os detetam, com os limiares reais. O Free inclui as regras básicas; o Pro acrescenta as que precisam de métricas de utilização mais detalhadas.

• Discos não montados (Free): STORAGE_UNATTACHED_VOLUME em AWS (volume EBS no estado available), AZURE_DISK_UNATTACHED e GCP_DISK_UNATTACHED.
• IPs públicos não associados (Free): NETWORK_UNASSOCIATED_EIP em AWS, AZURE_IP_UNASSOCIATED e GCP_STATIC_IP_UNUSED.
• Máquinas paradas que continuam a pagar disco (Free): COMPUTE_STOPPED_WITH_VOLUME em AWS, AZURE_VM_STOPPED em Azure e GCP_VM_STOPPED em Google Cloud (parada há pelo menos uma semana).
• Máquinas quase ociosas (Free): CPU média abaixo de 5 % em 7 dias, com COMPUTE_LOW_CPU, AZURE_COMPUTE_LOW_CPU e GCP_COMPUTE_LOW_CPU.
• Máquinas sobredimensionadas (Pro): com a CPU média de 7 dias abaixo de 20 %, AWS_COMPUTE_RIGHTSIZE, AZURE_COMPUTE_RIGHTSIZE e GCP_COMPUTE_RIGHTSIZE propõem descer exatamente um tamanho.
• Balanceadores sem tráfego (Pro): NETWORK_IDLE_LB em AWS (ALB com menos de 10 pedidos por dia em média ao longo de 7 dias, ou NLB e GWLB que processam menos de 1 MiB por dia) e AZURE_LB_IDLE (balanceador Standard sem tráfego em 7 dias) e GCP_LB_IDLE (forwarding rule sem tráfego em 7 dias, quando eliminá-la baixa a tarifa de forwarding rules).
• Bases de dados sem ligações (Pro): zero ligações em 7 dias (no Cloud SQL, no máximo ligações esporádicas e breves), com DATABASE_ZERO_CONN_RDS, AZURE_SQL_ZERO_CONN e GCP_SQL_ZERO_CONNECTIONS.
• NAT órfãos ou subutilizados (Pro): NETWORK_ORPHAN_NAT, AZURE_NETWORK_ORPHAN_NAT e GCP_NETWORK_ORPHAN_NAT assinalam o NAT com menos de 1 GB por dia de que não dependem rotas nem sub-redes. Em AWS, NETWORK_UNDERUSED_NAT assinala também o NAT abaixo de 1 GB por dia mesmo que ainda tenha rotas.
• Armazenamento numa classe cara (Pro): buckets com mais de 100 GB na classe Standard, com STORAGE_S3_WRONG_CLASS e GCP_GCS_WRONG_CLASS, e no Azure AZURE_STORAGE_WRONG_TIER, para contas com mais de 100 GB em Hot, sem política de ciclo de vida que baixe de nível toda a conta e com poucas leituras em 30 dias.
• Snapshots órfãos (Free): STORAGE_ORPHAN_SNAPSHOT em AWS, para snapshots EBS cujo volume de origem já não existe, e AZURE_SNAPSHOT_ORPHAN e GCP_SNAPSHOT_ORPHAN, para snapshots com mais de 30 dias cujo disco de origem já não existe.
• Bases de dados NoSQL com capacidade a mais (Pro): DATABASE_DYNAMO_OVERPROV em AWS e AZURE_COSMOS_OVERPROV em Azure, quando em 7 dias usam menos de 20 % do que reservam.
• Discos de geração anterior (Pro, só AWS): STORAGE_EBS_GP2_TO_GP3, para volumes gp2 em uso que custariam menos em gp3 com o mesmo desempenho.
• Versões em suporte alargado pago (Pro): COMPUTE_EKS_EXTENDED_SUPPORT e DATABASE_RDS_EXTENDED_SUPPORT na AWS (EKS, RDS e Aurora), GCP_GKE_EXTENDED_SUPPORT e GCP_SQL_EXTENDED_SUPPORT no Google Cloud (GKE no canal Extended e Cloud SQL) e AZURE_DB_EXTENDED_SUPPORT no Azure (MySQL e PostgreSQL), também 60 dias antes de começar a ser cobrado, e AZURE_AKS_LTS para clusters AKS no nível Premium com suporte de longo prazo.
• Endpoints de ML sem uso (Pro): COMPUTE_SAGEMAKER_ENDPOINT_IDLE, AZURE_ML_ENDPOINT_IDLE e GCP_VERTEX_ENDPOINT_IDLE, para endpoints do SageMaker, do Azure Machine Learning e do Vertex AI com instâncias ou réplicas em execução e nenhum pedido em 14 dias.
• Além disso, em AWS (Pro): recursos com mais de 30 dias sem atividade que não estão etiquetados como produção.

Caso prático: a ACME em três nuvens

A ACME é uma empresa fictícia com a loja em AWS, a plataforma de dados em Azure e a analítica em Google Cloud, no plano Pro. Depois do primeiro exame das suas três contas, estas são as descobertas que nos interessam, com a poupança estimada que cada regra calcula e a decisão da equipa:

Passo 1: lançar um exame

Em Minhas contas cloud, cada conta tem o botão «Escanear». No Free pode lançar até 3 exames por semana; no Pro e no Business as contas são examinadas automaticamente todos os dias e também pode lançá-los à mão. No fim, o exame aparece em Histórico de análises: em «Ver» encontra o custo, a poupança potencial e a comparação com o exame anterior, que separa as descobertas novas, as desaparecidas e as inalteradas.

Passo 2: rever as regras de análise

Antes de trabalhar a lista, convém dar uma vista de olhos às Regras de análise. Pode filtrar por fornecedor e por categoria, e cada cartão mostra o plano que a inclui e se é «Automatizável». As regras fora do seu plano aparecem com um cadeado.

• Desative uma regra com o seu interruptor se não se aplicar ao seu caso. A alteração vale a partir do exame seguinte.
• Desativar uma regra não dá as suas descobertas por resolvidas: a plataforma deixa de olhar, e distingue isso de o problema ter desaparecido.
• Os limiares das regras não são configuráveis: os 5 % de CPU ou os 7 dias são iguais para todos.

Passo 3: filtrar as descobertas ativas

Descobertas ativas reúne as descobertas do último exame de cada conta, ordenadas por severidade e, dentro de cada uma, por poupança. Os filtros estão no topo:

• Separadores de severidade: Todas, Crítico, Alto, Médio e Baixo, cada um com o seu contador.
• Seletor de conta, com «Todas as contas» para ver as três nuvens juntas.
• «Apenas automatizáveis», para ficar com o que o agente pode corrigir.
• «Ver descartados», que volta a mostrar o que marcou como descartado ou resolvido.
• A pesquisa «Pesquisar descoberta...», que procura no título, no nome do recurso e na descrição.

Passo 4: abrir o detalhe

Ao clicar numa descoberta abre-se o painel «Detalhe da descoberta». Aí tem a severidade, a descrição, a «Recomendação», o recurso, a conta, a região e a «Poupança estimada» por mês. A ligação «Ver recurso» leva à ficha do recurso. Se a descoberta tiver correção automática, verá também o botão para a automatizar, que explicamos no passo 7.

Passo 5: decidir o estado

No mesmo painel, o bloco «Estado» tem quatro botões. A decisão guarda-se ao nível da organização e mantém-se nos exames seguintes:

• Aberto: sem decisão. É o estado de partida, e voltar a ele apaga a decisão anterior.
• Aceite: reconhece o problema e vai corrigi-lo. Continua a contar nos indicadores, porque o gasto continua lá.
• Descartado: decidiu não agir (na ACME, o balanceador de staging). Deixa de contar nos indicadores e nos relatórios.
• Resolvido: já o corrigiu. Também não conta nos indicadores.

Passo 6: levá-lo para o Jira ou o Linear

Se a sua equipa trabalha com tickets, ligue o Jira Cloud (com um token de API) ou o Linear em Alertas → Integrações (plano Pro). Em cada integração escolhe «Criar ticket para alertas de severidade», que por omissão é alta. A partir daí:

• Quando um exame deteta descobertas novas de severidade alta e tem ativado o aviso «Novas deteções de alta prioridade» em Canais de alerta, é criado um ticket com o resumo desse alerta. É um ticket por alerta, que agrupa as descobertas do exame, não um por descoberta.
• Para um ticket de uma descoberta concreta, o botão «Criar ticket» aparece nas ações do Agente IA que nascem de uma descoberta (plano Business).

Passo 7: propor a correção (Business)

No Business, as descobertas com correção automática mostram o botão «Automatizar» na lista e no detalhe. Abre uma janela com «O que vai acontecer», «Porquê», «Impacto», «Antes de continuar», «Como reverter» e uma etiqueta «Reversível» ou «Não reversível». Com «Criar automação» a ação fica proposta em Agente IA → Painel, em «Aguardando aprovação». Nada é executado sem a aprovação de alguém com permissão para aprovar, e depois da aprovação há um período de carência antes da execução (48 horas para eliminar um volume, por exemplo) durante o qual a pode cancelar.

• O agente precisa de um papel de escrita à parte, criado no passo «Ativar agente autónomo (opcional)» ao ligar a conta.
• Em AWS, parar, redimensionar ou terminar uma instância EC2 exige que tenha a etiqueta FinOpsSentinelManaged=true.
• Antes de eliminar um volume EBS, o agente cria um snapshot de cópia de segurança. Libertar um IP elástico, pelo contrário, perde-o: pode reservar outro, mas não o mesmo endereço.
• Com «Converter em playbook», a mesma correção é proposta sozinha depois de cada exame para as descobertas dessa regra, sempre pendente de aprovação.

O resultado na ACME

A ACME atua sobre tudo menos o balanceador de staging, que marca como «Descartado». A Lambda é eliminada por higiene e não soma nada. A poupança estimada fica assim: 70 + 50 + 45 + 38 + 33 + 10,80 + 7,30 = 254,10 US$ por mês, cerca de 3.050 US$ por ano a preços de tabela. À medida que cada recurso desaparece, as suas descobertas passam a «Desaparecido» nos exames seguintes. No Business, o painel do agente mostra à parte a «Economia verificada», medida contra o custo real da conta pelo menos 7 dias depois de cada ação.

O que ainda não faz

Para saber o que esperar:

• Não há regras para Kubernetes nem para o custo dentro dos clusters.
• Não há regra de antiguidade de snapshots: as regras de snapshots órfãos procuram snapshots sem disco de origem, não snapshots antigos.
• O Google Cloud não tem regra de balanceadores sem tráfego, e o Azure não tem regra de armazenamento numa classe cara.
• Os limiares das regras não se podem ajustar: só ativar ou desativar cada regra.
• Em Descobertas ativas não há botão de ticket por descoberta: os tickets chegam pelos alertas ou a partir do Agente IA.
• A poupança estimada calcula-se com o custo que a regra atribui ao recurso, não com a sua fatura. Tome-a como ordem de grandeza.

Checklist para começar

Com isto em ordem, o desperdício deixa de se acumular em silêncio:

• As suas contas de AWS, Azure e Google Cloud ligadas em Minhas contas cloud.
• Um primeiro exame lançado e revisto em Histórico de análises.
• As regras que não se aplicam desativadas em Regras de análise.
• Cada descoberta de severidade alta com um estado: aceite, descartada ou resolvida.
• Jira ou Linear ligados em Alertas → Integrações, se trabalha com tickets.
• No Business, o papel do agente criado e as primeiras correções propostas a partir da descoberta.