Aller au contenu

AWS Mis à jour le 2026-10-07

Classes de stockage S3 décodées : Standard, IA, One Zone, paliers Glacier et les factures de récupération

Choisissez la bonne classe de stockage Amazon S3 pour chaque type de données. Voyez ce que Standard, Standard-IA, One Zone-IA et les trois paliers Glacier coûtent vraiment une fois ajoutés les frais de récupération, les durées minimales de stockage et le surcoût par objet.

Si vous stockez des données dans Amazon S3, vous devez choisir la classe de stockage de chaque type de données. S3 est le service d’AWS qui conserve les fichiers sous forme d’objets dans des compartiments. Cette comparaison s’adresse aux développeurs et aux équipes d’exploitation qui créent des compartiments ou qui répondent de la facture AWS. Une classe de stockage est le palier de tarification sous lequel S3 facture un objet. Les classes moins chères coûtent moins au gigaoctet stocké. En échange, elles ajoutent des frais de récupération chaque fois que vous relisez les données, et une durée minimale de stockage que vous payez même si vous supprimez l’objet plus tôt. C’est pourquoi un compartiment déplacé vers une classe « moins chère » peut finir par coûter plus cher. Notre recommandation est de garder les données lues souvent ou de façon imprévisible en S3 Standard, qui n’a ni l’un ni l’autre de ces frais. Ne passez à une classe moins chère qu’après avoir mesuré à quel point les données sont rarement lues.

Ce que vous décidez

La vraie question n’est pas « quelle classe est la moins chère », mais « à quelle fréquence ces données seront-elles relues, par quoi, et en quelle quantité quand ça arrivera ». Voici le portrait honnête :

  • S3 Standard — le défaut. Prix de stockage au Go le plus élevé, aucuns frais de récupération, aucune durée minimale, répliqué sur trois zones de disponibilité ou plus. Si les données sont lues régulièrement ou de façon imprévisible, c’est habituellement leur place.
  • S3 Standard-IA (accès peu fréquent) — nettement moins cher au Go stocké, mais vous payez des frais au Go à chaque lecture, il y a une durée minimale de stockage de 30 jours (supprimer avant, c’est payer le reste quand même), et les objets sont facturés comme s’ils faisaient au moins 128 Ko.
  • S3 One Zone-IA — l’économie du Standard-IA avec un rabais additionnel pour vivre dans une seule zone de disponibilité. Si cette zone est perdue, les données le sont aussi. Seulement pour des données que vous pouvez régénérer.
  • S3 Glacier Instant Retrieval — un prix de stockage d’archive avec des lectures en millisecondes. Le piège : des frais de récupération au Go plus élevés que Standard-IA et une durée minimale de 90 jours.
  • S3 Glacier Flexible Retrieval — encore moins cher, mais les lectures sont asynchrones : vous demandez une restauration et vous attendez de quelques minutes à quelques heures selon le palier que vous payez. Minimum de 90 jours. Les restaurations en vrac (bulk) sont gratuites, ce qui compte pour les grosses récupérations planifiées.
  • S3 Glacier Deep Archive — la classe la moins chère, des restaurations de 12 à 48 heures, minimum de 180 jours. Pour des données que vous espérez ne jamais toucher.
  • S3 Intelligent-Tiering — déplace les objets entre paliers automatiquement contre des frais de surveillance par objet; le portrait honnête est dans S3 Intelligent-Tiering : quand ça fait économiser.

Deux mécanismes que les gens manquent. Premièrement, Glacier Flexible Retrieval et Deep Archive ajoutent environ 32 Ko de données d’index plus 8 Ko de métadonnées par objet, et vous payez pour stocker ce surcoût — archiver des millions de petits fichiers peut coûter plus cher que l’économie. Deuxièmement, les prix exacts varient selon la région : une classe qui semble rentable dans us-east-1 peut donner un autre résultat dans ca-central-1. Vérifiez les chiffres de votre région dans la documentation S3 et modélisez-les sur calculator.aws.

Quoi vérifier d’abord

  • Le vrai patron de lecture. Pas ce que l’équipe croit — ce que les métriques de requêtes montrent. « On n’y touche jamais » veut souvent dire qu’une tâche nocturne relit tout.
  • La distribution des tailles d’objets. Les minimums par objet et le surcoût punissent durement les petits objets.
  • Le versionnement. S’il est activé, les versions non courantes forment peut-être l’essentiel de la facture, et aucun changement de classe ne règle ça sans règles de cycle de vie.
  • Le scénario de restauration. Restaurer un fichier depuis Deep Archive est banal. Restaurer 40 To après un rançongiciel, c’est une facture et 48 heures d’attente — chiffrez ça avant de vous engager.
  • La région. Les prix de stockage, de récupération et de transfert diffèrent tous selon la région.

Comment vérifier

Voyez ce que chaque compartiment contient par classe avec les métriques de stockage CloudWatch gratuites :

# Octets stockés en Standard-IA pour un compartiment (répéter par StorageType)
aws cloudwatch get-metric-statistics \
  --namespace AWS/S3 \
  --metric-name BucketSizeBytes \
  --dimensions Name=BucketName,Value=my-bucket Name=StorageType,Value=StandardIAStorage \
  --start-time 2026-07-01T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 86400 --statistics Average

Vérifiez la classe d’un objet précis et les totaux d’un préfixe :

aws s3api head-object --bucket my-bucket --key backups/db-2026-06-01.tar.gz

aws s3 ls s3://my-bucket/backups/ --recursive --summarize | tail -2

Dans la console, S3 > votre compartiment > Metrics montre le stockage par classe dans le temps, et S3 > Storage Lens > Dashboards le montre pour tout le compte.

L’approche

  1. Laissez les données chaudes ou inconnues en Standard. Les classes à rabais ne rapportent que si le patron d’accès est réellement connu. Se tromper coûte plus cher qu’attendre un mois de vraies données.
  2. Déplacez les sauvegardes et les données de conformité de plus de 30 jours vers Standard-IA. Le point idéal : des objets de plus de 128 Ko, gardés plus de 30 jours, lus quelques fois par année.
  3. Réservez One Zone-IA aux données reconstructibles. Copies secondaires de sauvegardes, médias transcodés, exports de cache. Jamais la seule copie de quelque chose d’important.
  4. Choisissez Glacier Instant Retrieval pour les données froides qui doivent rester lisibles instantanément. Vieux téléversements d’usagers, bibliothèques de médias, preuves d’audit que quelqu’un pourrait consulter demain.
  5. Gardez Flexible Retrieval et Deep Archive pour les vraies archives. Chiffrez d’abord le scénario de restauration complète, et décidez qui approuve une restauration expédiée avant d’en avoir besoin.
  6. Automatisez chaque transition avec des règles de cycle de vie, pas dans le code applicatif. Les patrons sont dans Règles de cycle de vie S3 : réduire la facture sans se blesser.

Quand ce n’est pas la bonne approche

Si le compartiment contient quelques centaines de gigaoctets, l’optimisation de classe économise le prix d’un lunch et coûte des heures d’ingénierie — passez votre tour. Si les données sont relues presque chaque mois, les frais de récupération IA peuvent annuler complètement le rabais de stockage. Si le compartiment contient des millions de petits fichiers, le surcoût par objet et les frais de requêtes de transition peuvent rendre Glacier perdant. Et les données de courte durée (moins de 30 jours) devraient simplement rester en Standard, puisque chaque classe à rabais vous facture de toute façon la durée minimale.

Erreurs courantes

  • Supprimer des objets IA ou Glacier trop tôt et être surpris par les frais de suppression hâtive pour la durée minimale non écoulée.
  • Oublier que la récupération facture deux fois : au Go récupéré et par millier de requêtes.
  • Envoyer des fichiers journaux petits et nombreux vers Glacier, où le surcoût par objet dépasse l’économie.
  • Mettre la seule copie de données de production en One Zone-IA pour économiser quelques pour cent.

Garder le contrôle

  • Révisez Storage Lens chaque mois — distribution des classes par compartiment, tendance de croissance, octets de versions non courantes.
  • Ajoutez des filtres ObjectSizeGreaterThan aux transitions de cycle de vie pour que les petits objets restent en place.
  • Dans Cost Explorer, filtrez sur les types d’usage contenant EarlyDelete et Retrieval — ces deux lignes sont là où les décisions de classe tournent mal.
  • Refaites les calculs après toute grosse restauration ou suppression; la bonne classe change à mesure que les données vieillissent.

Les classes de stockage sont une vraie bonne affaire quand le patron d’accès est mesuré plutôt que supposé, et une fuite lente quand elles sont réglées une fois puis oubliées. 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.