JRJérôme RaguilletFinOps · Cloud & AI
← Toutes les analyses
FINOPS · CLOUD & AI

Snapshots EBS : quand l'archivage augmente la facture au lieu de la réduire

Un cas AWS avec 94 000 snapshots et 1,9 Po référencés montre que le critère de décision n'est pas l'âge d'un snapshot, mais son rôle dans la chaîne de restauration et son coût complet après archivage. Analyse des mécanismes, du raisonnement de tri et des garde-fous à mettre en place.

Un constat d'inventaire qui dit tout

Avant même de parler d'économies, il faut poser le décor tel que le décrit la publication d'origine : chaque machine virtuelle sauvegardait son disque, chaque environnement recréait des snapshots, et personne ne pilotait leur cycle de vie. Le résultat annoncé sur AWS est parlant : 94 000 snapshots et 1,9 Po de données référencées. Ce type de situation ne résulte pas d'une erreur ponctuelle, mais d'une absence de gouvernance : tant qu'un snapshot existe, il est facturé, qu'il serve encore à quelque chose ou non.

L'enseignement principal est que la croissance du stockage de snapshots est souvent silencieuse. Contrairement à une instance surdimensionnée que l'on remarque dans un tableau de bord, les snapshots s'accumulent par milliers sans alerter personne. C'est précisément ce qui rend un inventaire initial indispensable avant toute action d'optimisation.

Le piège de l'archivage : les snapshots complets

La publication d'origine soulève un point technique important et souvent méconnu. Les snapshots du niveau Standard sont incrémentaux : chaque snapshot ne stocke que les blocs modifiés depuis le précédent. Lorsqu'un snapshot est déplacé vers EBS Snapshots Archive, AWS le convertit en snapshot complet. Autrement dit, le bénéfice apparent du stockage incrémental disparaît au moment où l'on pensait économiser.

Autre contrainte : une facturation minimale de 90 jours s'applique aux snapshots archivés. Une suppression ou une restauration permanente anticipée reste possible, mais les jours restants sont facturés. Combinée à la conversion en snapshot complet, cette règle peut augmenter le coût d'un archivage systématique des anciens points. L'archivage est donc une décision au cas par cas, et non une obligation de conservation technique de 90 jours.

Le bon critère : le rôle dans la chaîne de restauration

L'idée centrale de la publication d'origine mérite d'être soulignée : le bon critère n'est pas l'âge du snapshot, mais son rôle dans la chaîne de restauration et son coût complet après archivage. Un snapshot récent peut être inutile s'il est redondant, tandis qu'un point mensuel ou annuel peut être précieux même s'il est ancien.

Le raisonnement de tri qui en découle est le suivant. D'abord, identifier les snapshots orphelins, mais uniquement après validation du propriétaire et des règles de rétention : un snapshot orphelin sur le papier peut être le seul point de restauration d'un système critique documenté nulle part. Ensuite, conserver en Standard les chaînes incrémentales encore actives, car c'est là que le format incrémental reste le plus rentable. Enfin, n'archiver que certains points de restauration mensuels, annuels ou réglementaires, c'est-à-dire ceux dont la valeur justifie le surcoût d'un snapshot complet. Dans la publication, cette approche a été complétée par l'automatisation de la rétention et de la suppression avec Data Lifecycle Manager, afin que le problème ne se reproduise pas.

Chiffres annoncés et lecture financière

Les résultats indiqués dans la publication d'origine sont les suivants : une facture de 16 200 $ par mois avant optimisation, ramenée à 4 700 $ par mois après, soit un écart de 11 500 $ par mois. Sur une année, cela représente 11 500 $ multipliés par 12, c'est-à-dire 138 000 $ par an. Ces chiffres sont ceux de l'auteur de la publication ; ils ne sont pas indépendamment vérifiés et dépendent évidemment du contexte : volumétrie de départ, politique de rétention applicable et tarification en vigueur au moment de l'opération.

Ces montants illustrent le résultat global de l'opération décrite, sans permettre d'attribuer une part chiffrée à chaque levier. La logique à retenir combine suppression des snapshots devenus inutiles, après validation, et archivage sélectif des points à conserver. Les gains doivent être recalculés dans chaque environnement.

Les arbitrages et les questions à poser en interne

Chaque décision de tri comporte des arbitrages. Archiver trop tôt expose à des coûts de snapshot complet et engage une facturation minimale de 90 jours. Supprimer trop vite expose à la perte d'un point de restauration réglementaire. Garder tout en Standard évite ces risques mais entretient la facture. Le bon niveau dépend de vos obligations légales, de vos objectifs de reprise après sinistre et de la fréquence réelle des restaurations.

Quelques questions pratiques à poser avant d'agir : qui est le propriétaire fonctionnel de chaque chaîne de snapshots ? Quelles règles de rétention s'appliquent, et sont-elles écrites quelque part ? Quels points de restauration mensuels, annuels ou réglementaires sont réellement exigés ? Existe-t-il un processus de validation en amont de toute suppression ? Ces questions ne relèvent pas seulement de la technique : elles impliquent la conformité, les équipes applicatives et les exploitants.

Une checklist pour piloter le cycle de vie

Pour traduire le tout en actions, voici une checklist suggérée, à adapter à votre contexte. Elle est présentée comme une proposition et non comme une méthode validée indépendamment.

1. Réaliser un inventaire complet des snapshots et de la volumétrie référencée. 2. Attribuer un propriétaire et une politique de rétention à chaque chaîne, avec validation des équipes concernées. 3. Classer les snapshots : actifs dans une chaîne incrémentale, points de restauration mensuels, annuels ou réglementaires, ou orphelins à supprimer. 4. Évaluer le coût complet de chaque scénario avant archivage, en tenant compte de la conversion en snapshot complet et de la facturation minimale de 90 jours. 5. Archiver uniquement les points dont la valeur le justifie. 6. Automatiser la rétention et la suppression, par exemple avec Data Lifecycle Manager comme mentionné dans la publication d'origine. 7. Revoir périodiquement l'inventaire, car le cycle de vie d'un snapshot n'est jamais réglé une fois pour toutes.

La question posée en conclusion par la publication d'origine résume bien l'enjeu : combien de vos snapshots anciens ont encore un propriétaire et une politique de rétention ? Tant que la réponse n'est pas claire, la facture continuera de croître.

Le post à l’origine de cette analyse

Article développé à partir du post LinkedIn. Les liens ci-dessous sont ceux du post d’origine ; leur présence ne constitue pas une vérification indépendante.

LinkedIn ↗

Liens présents dans le post