S3 Inventory et Storage Lens : voir ce qu'il y a vraiment dans vos compartiments

On ne peut pas gérer une dépense S3 qu’on ne voit pas, et aws s3 ls cesse d’être un outil de visibilité autour du million d’objets. Les deux réponses intégrées se partagent le travail : Storage Lens donne des métriques à l’échelle du parc pour chaque compartiment du compte ou de l’organisation — incluant les gouffres d’argent que les listages cachent, comme les versions non courantes et les téléversements multipart incomplets — tandis que S3 Inventory produit un rapport planifié objet par objet que vous interrogez avec Athena quand il faut savoir exactement dans quelles clés, préfixes et classes de stockage vivent les octets. Storage Lens dit où regarder; Inventory dit ce qu’il y a.

Ce qui se passe

Storage Lens agrège des métriques quotidiennes sans toucher à vos objets. Le tableau de bord par défaut est gratuit, couvre tous les compartiments, conserve 14 jours, et inclut déjà les métriques de coûts que la plupart des équipes ne regardent jamais : octets totaux par compartiment, nombre d’objets, taille moyenne, octets de versions non courantes, nombre de marqueurs de suppression, et octets de téléversements multipart incomplets. Les métriques avancées sont une option payante qui ajoute l’agrégation par préfixe, les métriques d’activité (requêtes, téléchargements), 15 mois de rétention et la publication vers CloudWatch. Pour la plupart des comptes, le palier gratuit répond à la première question, la plus payante : quels compartiments détiennent les octets, et quelle part est du surpoids invisible.

S3 Inventory fonctionne autrement : sur un horaire quotidien ou hebdomadaire, S3 écrit un manifeste plus des fichiers de données (CSV, ORC ou Parquet) dans un compartiment de destination de votre choix, listant chaque objet — ou chaque objet sous un filtre — avec des champs optionnels comme la taille, la classe de stockage, la date de modification, l’état de chiffrement, l’état de réplication et l’ETag. Il est à cohérence éventuelle (le rapport reflète un instantané approximatif, pas le compartiment en direct), le premier rapport peut prendre jusqu’à 48 heures, et le rapport coûte de petits frais par objet plus le stockage où il atterrit. Ses deux usages majeurs : des requêtes Athena sur des millions d’objets sans payer les requêtes LIST, et des manifestes prêts pour des tâches S3 Batch Operations comme les restaurations Glacier de masse. Les détails champ par champ sont dans la documentation S3.

Quoi vérifier d’abord

Si Storage Lens est déjà en marche. Le tableau de bord par défaut existe automatiquement — la plupart des équipes ne l’ont simplement jamais ouvert.
La question réellement posée. « Quel compartiment coûte le plus » : Storage Lens. « Quels préfixes de 2019 sont encore en Standard » : Inventory plus Athena.
Un compartiment de destination pour les rapports Inventory. Même région que la source, avec une politique permettant à S3 de livrer.
Si le versionnement est en jeu. Si oui, configurez Inventory pour inclure toutes les versions — les rapports « versions courantes seulement » cachent exactement le surpoids que vous chassez.

Comment vérifier

Ouvrez S3 > Storage Lens > Dashboards > default-account-dashboard et vérifiez trois chiffres par gros compartiment : octets totaux, octets de versions non courantes, octets de téléversements multipart incomplets. Les deux derniers sont des candidats au gaspillage pur. Depuis le CLI, listez les configurations Inventory déjà en place sur un compartiment :

aws s3api list-bucket-inventory-configurations --bucket my-bucket

Montez-en une (Parquet, hebdomadaire, toutes les versions, les champs utiles) :

aws s3api put-bucket-inventory-configuration \
  --bucket my-bucket \
  --id weekly-audit \
  --inventory-configuration '{
    "Id": "weekly-audit",
    "IsEnabled": true,
    "IncludedObjectVersions": "All",
    "Schedule": {"Frequency": "Weekly"},
    "Destination": {"S3BucketDestination": {
      "Bucket": "arn:aws:s3:::my-inventory-reports",
      "Format": "Parquet"
    }},
    "OptionalFields": ["Size","LastModifiedDate","StorageClass","IsLatest","EncryptionStatus"]
  }'

Le compartiment de destination a besoin d’une politique permettant au principal de service s3.amazonaws.com de faire PutObject pour les rapports; la console offre de l’ajouter quand vous configurez Inventory à partir de là.

Le runbook

Commencez par le tableau de bord Storage Lens gratuit. Classez les compartiments par taille, puis balayez les octets de versions non courantes et de MPU incomplets. Cette passe de dix minutes trouve habituellement les premières cibles de nettoyage — souvent réglables le jour même avec des règles de cycle de vie.
Activez Inventory sur les compartiments qui comptent. Les gros et les sensibles à l’audit. Format Parquet — Athena le balaie bien moins cher que le CSV.
Créez la table Athena sur les rapports. La page Inventory de la console fournit un gabarit prêt à l’emploi. Posez ensuite les questions auxquelles les listages ne répondent pas :
```
SELECT storage_class,
       count(*) AS objects,
       round(sum(size)/1073741824.0, 1) AS gib
FROM my_bucket_inventory
WHERE dt = '2026-06-29-01-00'
GROUP BY storage_class
ORDER BY gib DESC;
```
Remplacez le GROUP BY par une expression de préfixe (split_part(key, '/', 1)) pour trouver quels préfixes de premier niveau détiennent les octets.
Agissez sur ce que vous trouvez, en utilisant le rapport comme manifeste. La sortie d’Inventory alimente S3 Batch Operations directement — étiqueter, copier, restaurer ou changer de classe pour exactement les clés que la requête a révélées.
Considérez les métriques avancées de Storage Lens seulement quand le palier gratuit est épuisé. L’agrégation par préfixe et les métriques d’activité sont vraiment utiles sur les gros parcs; sur un compte de cinq compartiments, c’est payer pour confirmer ce qu’on sait déjà.

Quand ce n’est pas la bonne approche

Pour un compartiment de quelques milliers d’objets, aws s3 ls --summarize et la console répondent à tout plus vite que de monter des rapports. Si la question est « qui a accédé à quoi », c’est CloudTrail (événements de données) ou les journaux d’accès serveur S3 — ni Inventory ni Storage Lens n’enregistrent les accès par identité. Et s’il vous faut une liste garantie complète à un instant exact (un instantané légal), la cohérence éventuelle d’Inventory est le mauvais instrument.

Erreurs courantes

Configurer Inventory avec les versions courantes seulement sur un compartiment versionné, puis conclure que le surpoids du versionnement n’existe pas.
Attendre le premier rapport sans savoir qu’il peut prendre jusqu’à 48 heures, et recréer la configuration en boucle entre-temps.
Livrer les rapports dans le compartiment inventorié lui-même sans filtre de préfixe — chaque rapport inventorie alors les rapports précédents.
Lire les totaux de Storage Lens comme exacts au sens de la facturation; c’est un système de métriques pour trouver les problèmes, et la facture reste la source de vérité.

Garder le contrôle

Faites du tableau de bord Storage Lens un rituel mensuel de quinze minutes : gros compartiments, tendance de croissance, métriques de gaspillage.
Gardez Inventory actif sur tout compartiment au-delà de la taille où le listage devient impraticable, et expirez les vieux rapports du compartiment de destination par cycle de vie.
Conservez les trois ou quatre requêtes Athena que l’équipe utilise vraiment à côté du code d’infrastructure.
Passez les actions de nettoyage issues des manifestes Inventory par Batch Operations plutôt que par des scripts improvisés, pour avoir un rapport de tâche quand quelqu’un demande ce qui a changé.

La visibilité est la moitié ingrate du travail sur les coûts S3, et c’est la moitié qui transforme chaque autre correctif de cette série en action ciblée plutôt qu’en pari. 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.