Snapshots orphelins : la facture cachée des sauvegardes et comment la nettoyer avec approbation

Les snapshots sont la ressource cloud la plus facile à oublier. Ils n'apparaissent dans aucun tableau de bord des ressources actives, ne produisent aucune métrique d'usage et leur coût augmente si lentement que personne ne le remarque. Jusqu'au jour où quelqu'un examine la facture et découvre des années de copies de disques qui n'existent plus. Dans cet article, nous montrons comment AAA Sentinel détecte ces snapshots orphelins sur AWS et comment les nettoyer avec l'Agent IA sans perdre le contrôle : chaque suppression est proposée, approuvée, attend une période de grâce puis est mesurée.

Comment ils s'accumulent

Presque toujours par l'une de ces quatre voies :

• Des sauvegardes automatiques sans rétention : quelqu'un a programmé un snapshot quotidien sans jamais fixer combien en garder.
• Des copies « au cas où » : on prend un snapshot avant une migration ou une mise à jour, tout se passe bien et personne ne le supprime.
• Des AMI anciennes : sur AWS, chaque AMI crée un snapshot par volume. Les vieilles versions d'une image traînent leurs snapshots.
• Des volumes supprimés : le disque disparaît, mais pas ses snapshots. Ce sont les snapshots orphelins, que plus personne ne rattache à rien.

Ce qu'ils coûtent

Sur AWS, un snapshot EBS standard coûte environ 0,05 US$ par Go et par mois en us-east-1, et Azure et Google Cloud sont du même ordre. Cela paraît peu, mais cela s'additionne : 3 To de snapshots oubliés représentent environ 150 US$ par mois, chaque mois, sans que personne n'en profite.

Ce que vous y gagnez

Avec la détection et l'agent qui travaillent ensemble :

• Vous voyez tous les snapshots orphelins de vos comptes AWS dans Résultats actifs, avec leur coût estimé.
• Vous les supprimez sans passer par la console, et sans que personne ne supprime quoi que ce soit de son côté : une personne approuve chaque suppression.
• Vous disposez d'une marge pour changer d'avis avant l'exécution et d'un historique de qui a approuvé quoi.
• Vous savez ensuite si la dépense du compte a vraiment baissé, et pas seulement ce qui était estimé.

Ce que détecte AAA Sentinel

La règle STORAGE_ORPHAN_SNAPSHOT, incluse dans tous les plans et dans l'essai de 30 jours, examine les snapshots EBS dont vous êtes propriétaire dans chaque région AWS et signale ceux qui ont été créés à partir d'un volume qui n'existe plus dans le compte. Chacun produit un résultat de sévérité haute, « Snapshot orphelin », avec une économie estimée égale à la taille du volume source multipliée par 0,05 US$ par Go et par mois.

• Il n'y a aucune règle d'ancienneté. Un snapshot de trois ans dont le volume existe toujours ne produit pas de résultat ; celui d'hier dont le volume a été supprimé, si.
• C'est une règle AWS. Les snapshots Azure et Google Cloud, ceux de RDS et les AMI ne sont pas analysés.
• Un snapshot qui sert de base à une AMI enregistrée apparaît aussi comme orphelin si son volume n'existe plus. AWS refuse de le supprimer tant que l'AMI existe : vérifiez-le avant.

Cas pratique : les snapshots d'ACME

ACME, une entreprise fictive au plan Business, connecte son compte AWS de production. La première analyse trouve ceci :

Étape 1 : trouver les snapshots orphelins

Dans Résultats actifs, choisissez le compte dans le sélecteur et l'onglet Haut. Les snapshots orphelins apparaissent comme « Snapshot orphelin », suivi du nom ou de l'identifiant du snapshot. En en ouvrant un, le « Détail de l'alerte » affiche la « Recommandation » : supprimez-le si vous n'en avez pas besoin pour la reprise après sinistre, mais vérifiez d'abord que ce n'est pas la seule copie de données critiques. Si vous décidez d'en garder un, marquez-le « Écarté » pour qu'il ne compte plus dans les KPI.

Étape 2 : préparer l'agent

L'Agent IA fait partie du plan Business et a besoin de droits d'écriture. Lors de la connexion du compte, l'étape « Activer l'agent autonome (optionnel) » crée un second rôle, distinct de celui en lecture seule. Ce rôle peut supprimer des snapshots et des volumes détachés ; contrairement aux actions sur les instances EC2, supprimer un snapshot n'exige pas l'étiquette FinOpsSentinelManaged=true, l'approbation est donc votre principal contrôle.

Étape 3 : activer le playbook

Dans Agent IA → Playbooks, tant que vous n'avez aucun playbook, vous voyez les « Modèles prédéfinis ». Celui qui nous intéresse est old-snapshots-cleanup, affiché sous le nom « Limpieza de snapshots antiguos ». En l'utilisant, vous choisissez le compte et le playbook est créé avec cette configuration :

• Il est évalué à la fin de chaque analyse de ce compte, sur ses résultats de sévérité moyenne ou supérieure.
• Il sélectionne les résultats sur des snapshots EBS de plus de 90 jours depuis leur création. Comme le seul résultat sur les snapshots est celui de snapshot orphelin, il s'agit en pratique de snapshots orphelins de plus de 90 jours.
• Il propose l'action de suppression du snapshot, toujours en attente d'approbation et avec une période de grâce de 48 heures.
• Il propose au maximum 10 actions par analyse. Le bouton « Exécuter » l'évalue immédiatement sur la dernière analyse et retient les 10 avec la plus forte économie.

Étape 4 : approuver ou rejeter

Les propositions apparaissent dans Agent IA → Tableau de bord, sous « En attente d'approbation », avec la ressource, le motif et l'économie estimée. Les personnes ayant le rôle de propriétaire, d'administrateur ou d'approbateur reçoivent aussi un e-mail avec un lien pour les examiner dans la plateforme.

• « Approuver » la place dans la file d'exécution. « Rejeter » l'écarte et enregistre le motif. « Annuler la proposition » la retire.
• Une proposition que personne n'approuve en 7 jours expire d'elle-même.
• Certaines actions exigent une seconde approbation par une autre personne. Aujourd'hui, ce sont les corrections de sécurité, comme fermer des ports d'administration ou bloquer l'accès public à un bucket. Supprimer un snapshot n'en demande qu'une.
• Chez ACME, l'approbateur rejette les deux snapshots qui servent de base à une AMI utilisée et approuve les sept autres.

Étape 5 : la période de grâce

L'approbation n'exécute encore rien. L'action passe dans « Approuvées — en attente d'exécution », avec la date sous « S'exécutera le : », et attend la période de grâce : 48 heures pour supprimer un snapshot. Quand il reste 4 heures ou moins, les approbateurs reçoivent un rappel par e-mail. Jusque-là, « Annuler la proposition » l'arrête sans conséquence.

Étape 6 : l'exécution, et ce qu'on ne peut pas défaire

Une fois la période de grâce écoulée, l'agent vérifie que le snapshot existe toujours et le supprime. En cas d'échec, les approbateurs reçoivent un e-mail avec l'erreur. Chaque action est enregistrée dans Agent IA → Historique, et son détail comprend une rubrique « Rollback » qui indique ce qu'il est possible de faire pour revenir en arrière.

• Supprimer un snapshot ne peut pas être défait. L'historique le dit lui-même : le snapshot a été supprimé définitivement. Sauf si vous avez configuré la corbeille AWS, il n'y a pas de retour possible.
• Le bouton « Défaire » n'apparaît que sur les actions qui ont conservé la valeur précédente, comme l'application d'étiquettes.
• Supprimer un volume détaché, c'est différent : avant de le supprimer, l'agent crée un snapshot de sauvegarde et l'historique vous donne la commande pour recréer le volume à partir de celui-ci.

Étape 7 : vérifier les économies

Le tableau de bord sépare deux chiffres : « Économies estimées (exécutées) », qui additionne ce qu'estimaient les règles, et « Économies vérifiées », mesurées par rapport au coût réel. Comme il n'existe pas de facturation par ressource, la vérification compare le rythme de dépense quotidien de tout le compte avant et après l'action, à partir des analyses.

• Elle n'est tentée qu'au moins 7 jours après l'exécution.
• Si la dépense du compte ne baisse pas, l'action reste non confirmée, jamais comptée comme une économie négative.
• Si d'autres actions ont été exécutées sur le même compte pendant ces jours, la confiance dans le chiffre baisse, car on ne peut pas isoler l'effet de chacune.

La prévention : les politiques de rétention

Nettoyer l'existant, c'est la moitié du travail ; l'autre moitié, c'est éviter que cela ne s'accumule de nouveau. Les trois fournisseurs le gèrent avec leurs propres outils :

• AWS : Data Lifecycle Manager ou AWS Backup créent les snapshots et les suppriment par nombre ou par ancienneté. Pour ce que vous devez garder longtemps, le niveau d'archive des snapshots coûte environ 0,0125 US$ par Go et par mois, avec un minimum de 90 jours et des frais de restauration.
• Azure : les stratégies d'Azure Backup définissent combien de temps chaque copie est conservée.
• Google Cloud : les planifications de snapshots incluent les jours de rétention.
• Un point de départ : en production, des copies quotidiennes sur 7 jours, hebdomadaires sur 4 semaines et mensuelles sur 3 mois ; en staging, 3 jours ; en développement, en général aucune ; et les snapshots manuels avec une étiquette de date d'expiration.

Ce qu'il ne fait pas encore

Pour savoir où sont les limites :

• Il n'y a pas de règle d'ancienneté, ni pour les snapshots dont le volume existe toujours.
• Uniquement les snapshots EBS d'AWS : ni Azure, ni Google Cloud, ni RDS, ni les AMI.
• Chaque analyse lit jusqu'à 500 snapshots par région.
• L'économie estimée utilise la taille du volume source et ne tient pas compte du caractère incrémental des snapshots.
• Un playbook ne repropose pas une action déjà en attente ou approuvée, et n'agit pas sur les résultats ignorés ou résolus. Si vous refusez une proposition, le scan suivant peut la refaire : pour qu'il cesse de la proposer, ignorez le résultat.
• Le modèle unused-volumes-cleanup (« Limpieza de volúmenes sin usar ») propose de supprimer les volumes non attachés depuis plus de 30 jours. Le délai commence au premier scan qui a vu le volume détaché, pas à sa création, et repart de zéro s'il est rattaché. Sur les trois clouds, un snapshot de sauvegarde est pris avant la suppression ; s'il ne peut pas être créé, rien n'est supprimé.

Checklist pour démarrer

Avec tout cela en place, les snapshots ne sont plus une facture que personne ne vérifie :

• Vos comptes AWS connectés et une analyse passée en revue dans Résultats actifs.
• Les snapshots qui servent de base à des AMI utilisées, et les copies à conserver, identifiés.
• Le plan Business, le rôle de l'agent créé et, si vous voulez un filet de sécurité, une règle de corbeille AWS.
• Le playbook old-snapshots-cleanup activé, ou un playbook créé depuis le résultat avec « Convertir en playbook ».
• Une personne avec le rôle d'approbateur attentive au tableau de bord et aux e-mails.
• Une politique de rétention sur chaque cloud pour qu'ils ne s'accumulent plus.