Snapshots órfãos: a fatura oculta dos backups e como limpá-la com aprovação

Os snapshots são o recurso cloud mais fácil de esquecer. Não aparecem em nenhum painel de recursos ativos, não geram métricas de utilização e o seu custo cresce tão devagar que ninguém repara. Até que alguém revê a fatura e descobre anos de cópias de discos que já não existem. Neste artigo mostramos como o AAA Sentinel deteta esses snapshots órfãos em AWS e como limpá-los com o Agente IA sem perder o controlo: cada eliminação é proposta, aprovada, espera um período de carência e depois é medida.

Como se acumulam

Quase sempre por uma destas quatro vias:

• Backups automáticos sem retenção: alguém programou um snapshot diário e nunca definiu quantos guardar.
• Cópias «para o caso de»: antes de uma migração ou de uma atualização faz-se um snapshot, corre tudo bem e ninguém o apaga.
• AMIs antigas: em AWS, cada AMI cria um snapshot por cada volume. As versões antigas de uma imagem arrastam os seus snapshots.
• Volumes eliminados: o disco desaparece, mas os seus snapshots não. São os snapshots órfãos, que já ninguém associa a nada.

Quanto custam

Em AWS, um snapshot EBS standard custa cerca de 0,05 US$ por GB por mês em us-east-1, e o Azure e o Google Cloud têm preços da mesma ordem. Parece pouco, mas acumula-se: 3 TB de snapshots esquecidos são cerca de 150 US$ por mês, todos os meses, sem que ninguém beneficie deles.

O que ganha com isto

Com a deteção e o agente a trabalhar em conjunto:

• Vê todos os snapshots órfãos das suas contas AWS em Descobertas ativas, com o custo estimado.
• Elimina-os sem entrar na consola, e sem que ninguém apague nada por conta própria: cada eliminação é aprovada por uma pessoa.
• Tem uma margem para mudar de ideias antes da execução e um histórico de quem aprovou o quê.
• Sabe depois se o gasto da conta baixou de facto, e não apenas o que se estimava.

O que o AAA Sentinel deteta

A regra STORAGE_ORPHAN_SNAPSHOT, incluída em todos os planos e no teste de 30 dias, revê os snapshots EBS próprios de cada região de AWS e assinala os que foram criados a partir de um volume que já não existe na conta. Cada um gera uma descoberta de severidade alta, «Snapshot órfão», com uma poupança estimada igual ao tamanho do volume de origem vezes 0,05 US$ por GB por mês.

• Não há nenhuma regra por antiguidade. Um snapshot de há três anos cujo volume continua a existir não gera descoberta; um de ontem cujo volume foi eliminado, gera.
• É uma regra de AWS. Os snapshots de Azure e de Google Cloud, os de RDS e as AMIs não são analisados.
• Um snapshot que suporta uma AMI registada também aparece como órfão se o seu volume já não existir. A AWS não permite eliminá-lo enquanto a AMI existir, por isso reveja-o antes.

Caso prático: os snapshots da ACME

A ACME, uma empresa fictícia no plano Business, liga a sua conta AWS de produção. O primeiro exame encontra isto:

Passo 1: encontrar os snapshots órfãos

Em Descobertas ativas, escolha a conta no seletor e o separador Alto. Os snapshots órfãos aparecem como «Snapshot órfão», seguido do nome ou do identificador do snapshot. Ao abrir um, o «Detalhe da descoberta» mostra a «Recomendação»: elimine-o se não precisar dele para recuperação de desastres, mas confirme antes que não é a única cópia de dados críticos. Se decidir conservar algum, marque-o como «Descartado» para que deixe de contar nos indicadores.

Passo 2: preparar o agente

O Agente IA faz parte do plano Business e precisa de permissões de escrita. Ao ligar a conta, o passo «Ativar agente autónomo (opcional)» cria um segundo papel, separado do de só leitura. Esse papel pode eliminar snapshots e volumes desanexados; ao contrário das ações sobre instâncias EC2, eliminar um snapshot não exige a etiqueta FinOpsSentinelManaged=true, por isso a aprovação é o seu controlo principal.

Passo 3: ativar o playbook

Em Agente IA → Playbooks, enquanto não tiver nenhum playbook verá os «Modelos predefinidos». O que nos interessa é o old-snapshots-cleanup, apresentado como «Limpieza de snapshots antiguos». Ao usá-lo escolhe a conta e o playbook fica criado com esta configuração:

• É avaliado no fim de cada exame dessa conta, sobre as suas descobertas de severidade média ou superior.
• Seleciona as descobertas de snapshots EBS com mais de 90 dias desde a criação. Como a única descoberta de snapshots é a de snapshot órfão, na prática são snapshots órfãos com mais de 90 dias.
• Propõe a ação de eliminar o snapshot, sempre pendente de aprovação e com 48 horas de período de carência.
• Propõe no máximo 10 ações por exame. O botão «Executar» avalia-o no momento contra o último exame e escolhe as 10 com mais poupança.

Passo 4: aprovar ou rejeitar

As propostas aparecem em Agente IA → Painel, em «Aguardando aprovação», com o recurso, o motivo e a poupança estimada. As pessoas com papel de proprietário, administrador ou aprovador recebem também um email com uma ligação para as rever na plataforma.

• «Aprovar» passa-a para a fila de execução. «Rejeitar» descarta-a e regista o motivo. «Cancelar proposta» retira-a.
• Uma proposta que ninguém aprove em 7 dias caduca sozinha.
• Algumas ações exigem uma segunda aprovação de outra pessoa. Hoje são as correções de segurança, como fechar portas de administração ou bloquear o acesso público a um bucket. Eliminar um snapshot precisa de apenas uma.
• Na ACME, quem aprova rejeita os dois snapshots que suportam uma AMI em uso e aprova os outros sete.

Passo 5: o período de carência

A aprovação ainda não executa nada. A ação passa para «Aprovadas — aguardando execução», com a data em «Será executado:», e espera o período de carência: 48 horas para eliminar um snapshot. Quando faltam 4 horas ou menos, os aprovadores recebem um lembrete por email. Até lá, «Cancelar proposta» trava-a sem consequências.

Passo 6: a execução, e o que não se pode desfazer

Terminado o período de carência, o agente confirma que o snapshot ainda existe e elimina-o. Se algo falhar, os aprovadores recebem um email com o erro. Cada ação fica em Agente IA → Histórico, e o seu detalhe inclui a secção «Rollback» com o que se pode fazer para a reverter.

• Eliminar um snapshot não se pode desfazer. O próprio histórico o diz: o snapshot foi eliminado de forma permanente. A não ser que tenha a Reciclagem da AWS configurada, não há volta atrás.
• O botão «Desfazer» só aparece nas ações que guardaram o valor anterior, como aplicar etiquetas.
• Eliminar um volume desanexado é diferente: antes de o eliminar, o agente cria um snapshot de cópia de segurança e o histórico deixa-lhe o comando para recriar o volume a partir dele.

Passo 7: verificar a poupança

O Painel separa dois valores: «Economia estimada (executada)», que soma o que as regras estimavam, e «Economia verificada», medida contra o custo real. Como não há faturação por recurso, a verificação compara o ritmo de gasto diário de toda a conta antes e depois da ação, a partir dos exames.

• Só é tentada depois de passarem pelo menos 7 dias desde a execução.
• Se o gasto da conta não baixar, a ação fica como não confirmada, nunca como uma poupança negativa.
• Se nesses dias foram executadas outras ações na mesma conta, a confiança no valor desce, porque não é possível isolar o efeito de cada uma.

A prevenção: políticas de retenção

Limpar o que existe é metade do trabalho; a outra metade é impedir que volte a acumular-se. Os três fornecedores resolvem-no com ferramentas próprias:

• AWS: o Data Lifecycle Manager ou o AWS Backup criam os snapshots e eliminam-nos por número ou por antiguidade. Para o que tem de guardar muito tempo, o nível de arquivo de snapshots custa cerca de 0,0125 US$ por GB por mês, com um mínimo de 90 dias e um custo de restauro.
• Azure: as políticas do Azure Backup definem quanto tempo se conserva cada cópia.
• Google Cloud: as programações de snapshots incluem os dias de retenção.
• Um ponto de partida: em produção, cópias diárias durante 7 dias, semanais durante 4 semanas e mensais durante 3 meses; em staging, 3 dias; em desenvolvimento, normalmente nenhuma; e os snapshots manuais com uma etiqueta de data de validade.

O que ainda não faz

Para saber onde estão os limites:

• Não há regra por antiguidade nem para snapshots cujo volume continua a existir.
• Só snapshots EBS de AWS: nem Azure, nem Google Cloud, nem RDS, nem AMIs.
• Cada exame lê até 500 snapshots por região.
• A poupança estimada usa o tamanho do volume de origem e não tem em conta que os snapshots são incrementais.
• Um playbook não volta a propor uma ação que já está pendente ou aprovada, nem atua sobre descobertas descartadas ou resolvidas. Se recusar uma proposta, a análise seguinte pode voltar a fazê-la: para que deixe de a propor, descarte a descoberta.
• O modelo unused-volumes-cleanup («Limpieza de volúmenes sin usar») propõe apagar volumes que estão há mais de 30 dias sem montar. O prazo conta desde a primeira análise que viu o volume desmontado, não desde a sua criação, e volta a zero se for montado de novo. Nas três nuvens, antes de apagar é guardado um snapshot de cópia de segurança; se não for possível criá-lo, nada é apagado.

Checklist para começar

Com isto em ordem, os snapshots deixam de ser uma fatura que ninguém revê:

• As suas contas AWS ligadas e um exame revisto em Descobertas ativas.
• Os snapshots que suportam AMIs em uso e as cópias que quer guardar, identificados.
• Plano Business, o papel do agente criado e, se quiser rede de segurança, uma regra da Reciclagem da AWS.
• O playbook old-snapshots-cleanup ativado, ou um criado a partir da descoberta com «Converter em playbook».
• Alguém com papel de aprovador atento ao Painel e aos emails.
• Uma política de retenção em cada nuvem para que não voltem a acumular-se.