Le stockage est la partie de la facture AWS qui grossit en silence. Personne ne remarque un seul volume gp2, un snapshot oublié, ou un bucket de logs en Standard depuis trois ans. Chaque ligne paraît dérisoire. Mais le stockage est cumulatif par nature. Les données sont créées, presque jamais supprimées, et rarement déplacées vers une classe moins chère une fois que le schéma d’accès se refroidit. Après quelques années, cette accumulation silencieuse représente une part significative de la facture, et presque rien n’y fait un travail utile. La bonne nouvelle, c’est que le stockage est aussi là où se trouvent les économies les moins risquées. Contrairement au compute, où le rightsizing comporte un risque opérationnel, la plupart des optimisations de stockage sont soit entièrement réversibles, soit sans impact sur la production. Migrer un type de volume, déplacer un objet vers une classe plus froide, supprimer une ressource détachée : aucune de ces actions ne touche une application en cours d’exécution si elle est réalisée correctement. Cet article parcourt six actions rapides sur le stockage, dans l’ordre où nous les appliquons lors d’un audit. Aucune n’est exotique. Toutes sont documentées par AWS. La difficulté, comme toujours, n’est pas technique. C’est que personne dans l’organisation n’a explicitement pour mission d’aller regarder.
Six actions rapides sur les données, dans l’ordre d’exécution. La migration des volumes gp2 vers gp3 (mêmes performances de base, 20 % moins cher, en place), le nettoyage du stockage orphelin (volumes détachés, snapshots obsolètes, AMIs inutilisées), l’application de politiques de cycle de vie S3 pour déplacer les données froides vers Standard-IA et Glacier, la définition de la rétention CloudWatch Logs sur les groupes de logs qui conservent les données indéfiniment, le rightsizing du stockage RDS et des sauvegardes, et l’externalisation des fichiers statiques d’EBS vers S3 plutôt que de payer pour des volumes surdimensionnés sur EC2. Les économies cumulées typiques atteignent 20 % à 40 % de la facture de stockage, la majeure partie étant réalisable dès la première semaine. Chaque levier utilise les outils natifs AWS (Cost Explorer, Cost and Usage Report, métriques CloudWatch, S3 Storage Lens) et aucun des six ne nécessite d’interruption sur un workload correctement architecturé.
Le gaspillage de compute s’annonce : une instance inactive apparaît dans le monitoring, un graphique CPU plat est difficile à manquer une fois qu’on regarde. Le gaspillage de stockage, c’est l’inverse. Un volume EBS détaché génère exactement la même ligne sur la facture qu’un volume attaché. Un snapshot issu d’une AMI supprimée est identique à un snapshot encore nécessaire. Un bucket S3 rempli de logs de 2022 coûte le même prix par Go, que quelqu’un les lise ou non. Rien ne signale qu’un problème existe, ce qui explique précisément pourquoi ça s’accumule.
Le travail d’audit est surtout de l’archéologie. On parcourt la couche stockage ressource par ressource, on croise ce qui est réellement attaché, accédé ou référencé, et on sépare les données vivantes du poids mort. Ce n’est pas glamour. Mais ça rapporte.
C’est la première chose que l’on examine, car c’est ce qui ressemble le plus à de l’argent gratuit qu’AWS propose. Les volumes gp3 offrent les mêmes performances de base que gp2 (3 000 IOPS, 125 Mo/s) à 20 % de moins, avec des performances supérieures provisionnables indépendamment de la capacité. La migration se fait en place via modify-volume : pas de détachement, pas de redémarrage, l’application continue de tourner pendant toute l’opération. La détection tient en une seule ligne : aws ec2 describe-volumes --filters Name=volume-type,Values=gp2. Sur un compte mature, on constate couramment que 60 à 90 % des volumes usage général sont encore en gp2, simplement parce qu’ils ont été créés avant l’existence de gp3 et que personne n’est revenu vérifier.
La seule mise en garde : gp2 sur les volumes supérieurs à 1 Tio obtient plus de 3 000 IOPS de base (3 IOPS/Go). Avant de migrer un grand volume, vérifiez l’utilisation réelle des IOPS dans CloudWatch et provisionnez les IOPS gp3 correspondantes si nécessaire. Même avec des IOPS supplémentaires payantes, gp3 revient presque toujours moins cher. Pour la grande majorité des volumes, c’est une réduction directe de 20 % sans aucun inconvénient.
Le stockage orphelin, c’est le poids mort des projets passés. Trois cibles représentent la quasi-totalité du problème. D’abord, les volumes EBS détachés en état available : un volume qui a survécu à l’instance qu’il supportait continue d’être facturé au tarif plein. Ensuite, les snapshots orphelins : snapshots dont l’AMI source a été désenregistrée, ou snapshots manuels pris « juste au cas où » il y a des années. Enfin, les AMIs inutilisées et leurs snapshots sous-jacents, qui conservent silencieusement du stockage longtemps après que l’image n’est plus déployée.
La détection passe par le CLI : describe-volumes filtré sur State=available, describe-snapshots --owner-ids self croisé avec les AMIs actives, et describe-images --owners self croisé avec les instances en cours d’exécution. Sur un compte mature, les trois combinés représentent fréquemment plusieurs centaines d’euros par mois de pur gaspillage.
L’action n’est jamais une suppression aveugle. Les volumes détachés sont snapshotés avant suppression (une assurance bon marché contre le « on en avait en fait besoin »). Les snapshots sont vérifiés par rapport à toute AMI qui les référence encore. Cette discipline coûte un peu de temps et évite la seule erreur catastrophique qui rend tout le monde prudent face au nettoyage.
S3 est là où se cachent les économies de stockage les plus importantes, et là où elles sont le plus souvent ignorées. La plupart des applications écrivent dans un bucket en S3 Standard et n’y repensent jamais. Mais la plupart des données ont un cycle d’accès clair : chaudes les premières semaines, puis progressivement froides. Les logs, sauvegardes, exports analytiques et contenus utilisateur archivés sont presque toujours écrits une fois et rarement relus après le premier mois.
Une politique de cycle de vie déplace automatiquement les objets entre les classes de stockage selon leur ancienneté. La différence de coût est spectaculaire : Standard-IA est environ 45 % moins cher que Standard, Glacier Instant Retrieval environ 80 % moins cher, et Glacier Deep Archive plus de 95 % moins cher, tout en maintenant les données immédiatement ou quasi-immédiatement récupérables selon la classe. Pour les buckets dont le schéma d’accès est réellement imprévisible, S3 Intelligent-Tiering gère les transitions automatiquement pour un petit frais de monitoring.
L’étape de détection est essentielle. Avant de rédiger une politique, analysez les
« Le stockage ne vous dit jamais qu’il est gaspillé. Une instance inactive apparaît comme un graphique CPU plat, un téraoctet oublié ressemble exactement à un téraoctet utile. Tout le travail consiste à aller regarder, ressource par ressource, ce qui est réellement attaché, accédé ou référencé. »
Julien MAUCLAIR
CTO, Co-Foundeur Stralya
Les six actions rapides ci-dessus couvrent le gaspillage de stockage issu de la négligence plutôt que de la conception. Elles sont réversibles, peu risquées et rapides à réaliser. Mais elles laissent délibérément de côté trois sujets de stockage plus profonds qui méritent un effort dédié, car ils nécessitent plus de temps, plus de coordination, et dans certains cas une modification applicative.
Le premier est l’optimisation des transferts de données. Les frais de transfert inter-AZ et inter-région sont souvent une ligne plus importante que le stockage lui-même, et ils découlent généralement d’un mauvais placement des données : une base de données dans une AZ constamment lue par des services dans une autre, ou des jobs analytiques qui tirent des données brutes entre régions. Corriger cela implique de repenser où résident les données par rapport à leur lieu de traitement, une conversation d’architecture plutôt qu’une action rapide.
Le second est la stratégie de sauvegarde et de reprise après sinistre. Centraliser les sauvegardes via AWS Backup, définir des politiques de rétention cohérentes et supprimer les snapshots manuels accumulés au fil des années représente un vrai travail. La difficulté n’est pas technique : c’est de construire une politique de sauvegarde cohérente qui empêche l’expansion de revenir.
Le troisième concerne les choix de format de stockage et de moteur pour les workloads intensifs en données : choisir Parquet plutôt que CSV pour l’analytique, sélectionner le bon moteur RDS et la bonne classe d’instance, ou décider entre DynamoDB en capacité à la demande ou provisionnée. Ces décisions ont de grandes implications sur les coûts, mais appartiennent aux équipes applicatives et data, pas à un nettoyage de stockage généraliste.
Ces trois sujets, nous les laissons à leur place, dans une feuille de route d’optimisation sur trois à six mois, après les actions rapides. Essayer de repenser le placement des données sur un compte où la moitié des volumes sont encore en gp2, c’est, une fois de plus, commencer le marathon au dernier kilomètre.
L’optimisation du stockage est un travail ingrat. Personne ne prononce de keynote sur la suppression de snapshots orphelins, aucun schéma d’architecture ne devient plus élégant parce qu’on a défini une politique de rétention des logs. Mais c’est parmi les travaux les plus rentables et les moins risqués disponibles sur un compte AWS, précisément parce que le gaspillage est invisible et donc intact. Les économies sont là depuis longtemps, elles s’accumulent, en attendant que quelqu’un aille regarder.
Sur un compte de taille significative, l’effet cumulé de ces six actions se situe autour de 20 % à 40 % de la facture de stockage, la majeure partie réalisable dès la première semaine et presque sans risque pour la production. C’est de la maintenance, pas une transformation, et comme toute maintenance, la seule chose qui sépare le compte des économies est la décision de vraiment le faire.
Retrouvez un PDF complet et détaillé concernant cet article pour avoir plus d’informations
By submitting your email you agree to receive this case study and occasional updates from Stralya. We don’t share your data — see our privacy policy.
Un projet, une infra qui dérive, une facture qui explose. Dites-nous ce qui vous bloque à Paris, on revient avec un plan.
