Aller au contenu

AWS Mis à jour le 2026-07-04

Coûts EBS et instantanés : des politiques de cycle de vie avant que la ligne de stockage double en silence

Nettoyage des coûts d'instantanés EBS en pratique : migration gp2 vers gp3, politiques de rétention Data Lifecycle Manager, palier d'archivage et les orphelins laissés par les vieilles AMI.

La dépense EBS ne bondit pas; elle rampe. Les instantanés s’accumulent chaque jour sans expiration, les volumes restent en gp2 parce que personne n’a revisité une décision de 2020, et les AMI désinscrites laissent leurs instantanés derrière pour toujours. Le remède a trois volets : convertir les volumes gp2 en gp3 (un changement en ligne qui réduit habituellement le tarif au Go), poser des politiques de rétention Data Lifecycle Manager sur chaque volume qui produit des instantanés pour que le ménage cesse d’être une tâche humaine, et faire une purge délibérée de l’arriéré historique — incluant les orphelins d’AMI que la plupart des nettoyages manquent.

Ce qui se passe

Deux mécanismes nourrissent la dérive. Côté volumes, le prix et la performance de gp2 suivent tous deux la taille, ce qui a fait du surprovisionnement une habitude : les équipes dimensionnaient pour les IOPS, pas pour la capacité. gp3 les découple — une base de 3 000 IOPS et 125 Mo/s peu importe la taille, la performance supplémentaire achetable à part — à un tarif au Go plus bas. La plupart des flottes gp2 se convertissent sans indisponibilité ni perte de performance; l’exception, ce sont les gros volumes gp2 (environ 1 To et plus) dont les IOPS dépassaient la base gp3 — vous provisionnez la différence explicitement et sortez généralement gagnant quand même.

Côté instantanés, les instantanés sont incrémentaux mais immortels. Chacun ne stocke que les blocs changés depuis le précédent, ce qui garde le coût marginal bas — jusqu’à ce que des années de quotidiens sur un volume occupé totalisent plusieurs fois la taille du volume lui-même. Supprimer un instantané au milieu d’une chaîne ne libère pas nécessairement toute sa taille affichée non plus, parce que les blocs encore référencés par d’autres instantanés sont retenus. Et la fuite silencieuse classique : désinscrire une AMI ne supprime pas ses instantanés sous-jacents. Les comptes qui cuisent des AMI chaque semaine accumulent un cimetière d’orphelins qu’aucun script de ménage ne regarde. La structure de facturation est au Go-mois de données d’instantané stockées (compressées, dédupliquées), avec un palier d’archivage moins cher à part — détails dans la documentation EBS.

Quoi vérifier d’abord

  • Quelle part de la flotte est encore en gp2. Filtrez EC2 > Elastic Block Store > Volumes par Type. Chaque Go de gp2 est un rabais que vous n’avez pas encore cliqué.
  • Si une politique de cycle de vie existe. EC2 > Elastic Block Store > Lifecycle Manager — si c’est vide et que vous avez des milliers d’instantanés, ils ont tous été faits à la main ou par des scripts sans étape de suppression.
  • La tendance du nombre et de la taille des instantanés dans Cost Explorer, type d’utilisation EBS:SnapshotUsage, mensuel, 12 derniers mois. Une droite qui monte sans creux veut dire que rien n’est jamais supprimé.
  • Les instantanés d’AMI orphelins. Des instantanés dont la description référence un ID d’AMI qui n’existe plus.
  • Les volumes détachés. Couverts dans la liste de chasse aux orphelins — faites cette passe d’abord, puisque supprimer un volume mort met aussi fin à ses futurs instantanés.

Comment vérifier

# Volumes gp2 encore dans le compte
aws ec2 describe-volumes --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[].[VolumeId,Size,Iops,State]' --output table

# Tous les instantanés possédés, du plus vieux au plus récent, avec taille
aws ec2 describe-snapshots --owner-ids self \
  --query 'sort_by(Snapshots,&StartTime)[].[SnapshotId,StartTime,VolumeSize,Description]' \
  --output table

# Instantanés créés par l'enregistrement d'AMI (candidats à la vérification d'orphelins)
aws ec2 describe-snapshots --owner-ids self \
  --query 'Snapshots[?contains(Description, `CreateImage`)].[SnapshotId,StartTime,Description]' \
  --output table

# AMI encore existantes — tout ce qui est référencé dans une description mais absent ici est orphelin
aws ec2 describe-images --owners self \
  --query 'Images[].[ImageId,Name,CreationDate]' --output table

# Politiques DLM existantes, s'il y en a
aws dlm get-lifecycle-policies

Croisez les descriptions d’instantanés CreateImage avec la liste des AMI vivantes : les descriptions nomment l’AMI pour laquelle elles ont été créées, et si cette AMI a disparu, l’instantané facture pour rien. Pour la conversion gp3, un seul appel par volume :

aws ec2 modify-volume --volume-id vol-0123456789abcdef0 --volume-type gp3

Le plan d’exécution

  1. Convertissez gp2 en gp3, par lots. La modification est en ligne; le volume reste en état optimizing un moment sans interruption de service. Faites d’abord une poignée de volumes non critiques, surveillez VolumeReadOps et la latence une journée, puis déroulez sur la flotte. Pour les gros volumes gp2, réglez --iops et --throughput explicitement selon ce que la charge utilisait vraiment.
  2. Créez des politiques DLM pour chaque charge qui produit des instantanés. Ciblez les volumes par étiquette, planifiez des quotidiens, retenez un nombre ou un âge fixe — par exemple des quotidiens gardés 14 jours, des hebdomadaires gardés 90. La création et la suppression deviennent toutes deux automatiques, et c’est tout l’intérêt : la rétention par politique, pas par mémoire.
  3. Purgez l’arriéré historique une fois. Les plus vieux d’abord, contre une règle de rétention écrite (disons : rien de plus vieux que 12 mois sauf étiquette retain). Utilisez la corbeille (Recycle Bin) pour instantanés EBS avec une rétention courte comme filet pendant la purge : une suppression erronée reste récupérable quelques jours.
  4. Désinscrivez les AMI mortes, puis supprimez leurs instantanés. L’ordre compte — un instantané derrière une AMI enregistrée refuse la suppression. Désinscription d’abord, suppression ensuite, et scriptez la paire pour qu’elle ne se désynchronise plus jamais.
  5. Archivez ce que vous devez garder sans jamais y toucher. EBS Snapshot Archive stocke des copies complètes (pas incrémentales) à un tarif bien plus bas, avec un minimum de 90 jours et une restauration qui se mesure en heures, pas en secondes. Bon pour la rétention de conformité; mauvais pour tout ce que vous pourriez restaurer en incident.
  6. Tuez les scripts producteurs d’instantanés sans étape de suppression. Chaque tâche cron qui appelle create-snapshot doit avoir un mécanisme de rétention assorti, ou être remplacée par une politique DLM.

Quand c’est le mauvais choix

N’archivez pas les instantanés sur lesquels vous comptez pour une récupération rapide — le délai de restauration depuis l’archive est incompatible avec l’échéancier d’un incident. Ne purgez rien sous obligation légale ou calendrier de rétention de conformité sans approbation écrite; le stockage coûte moins cher qu’un litige. Et si vos instantanés alimentent une copie de relève inter-régions, vérifiez les dépendances du travail de copie avant de supprimer les sources — certains montages de réplication recopient à partir d’un instantané local récent.

Erreurs courantes

  • S’attendre à récupérer toute la taille affichée d’un instantané supprimé en milieu de chaîne — les blocs référencés restent tant que rien ne pointe plus vers eux.
  • Supprimer d’abord les instantanés des AMI et se demander pourquoi l’AMI démarre encore — elle ne démarre pas; vous avez maintenant une AMI brisée qui échoue au lancement.
  • Régler la rétention DLM par nombre sur un volume qui prend un instantané par heure, puis se demander pourquoi 24 x 14 instantanés existent.
  • Archiver un instantané, le restaurer deux semaines plus tard, et être surpris par la charge minimale de 90 jours.

Prévention

  • Tout nouveau volume part en gp3 dans les modèles de lancement et les modules IaC; gp2 devient une erreur de linting.
  • DLM (ou AWS Backup) possède toute la création d’instantanés — les humains n’en créent que pour des événements nommés, étiquetés avec une date de suppression.
  • Un coup d’œil mensuel dans Cost Explorer sur EBS:SnapshotUsage : la ligne doit faire des dents de scie, pas grimper.
  • L’hygiène des AMI sur un horaire : désinscrire les images plus vieilles que votre horizon de retour en arrière et supprimer leurs instantanés dans la même tâche.
  • Étiquetez les exceptions retain et legal-hold explicitement pour que l’automatisation les saute au lieu de caler dans le doute.

Le stockage est la ligne la plus silencieuse de la facture, et c’est exactement pourquoi il lui faut des politiques plutôt que des intentions. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.