Aller au contenu

AWS Mis à jour le 2026-07-04

S3 Intelligent-Tiering : quand ça fait économiser et quand ça ne fait qu'ajouter des frais de surveillance

S3 Intelligent-Tiering déplace les objets entre paliers d'accès automatiquement, mais les frais de surveillance par objet font qu'il n'est rentable que pour les gros objets. Voici comment décider.

S3 Intelligent-Tiering fait économiser quand vous stockez de gros objets dont le patron d’accès est réellement imprévisible, et fait perdre de l’argent quand le compartiment est plein de petits objets, parce que les frais de surveillance sont facturés par objet alors que les économies s’accumulent par gigaoctet. La taille moyenne des objets est toute la décision : des objets de plusieurs mégaoctets rendent les frais négligeables, tandis que des millions d’objets sous le mégaoctet peuvent rendre les frais plus gros que tout ce qu’ils font économiser. Si vous connaissez déjà le patron d’accès, de simples règles de cycle de vie font le même travail gratuitement.

Ce que vous décidez

Intelligent-Tiering est une seule classe de stockage avec des paliers internes. Chaque objet surveillé commence dans le palier Frequent Access à un prix comparable à Standard. Après 30 jours consécutifs sans accès, il descend au prix Infrequent Access, et après 90 jours au prix Archive Instant Access — les trois gardent des lectures en millisecondes, et toucher un objet le ramène automatiquement en Frequent. Deux paliers optionnels, Archive Access et Deep Archive Access, vont plus loin mais rendent les objets asynchrones : les lire exige d’abord une restauration, ce qui surprend les applications qui s’attendent à ce qu’un GetObject normal fonctionne.

Ce que vous payez pour l’automatisation : des frais de surveillance et d’automatisation facturés par tranche de 1 000 objets par mois. Ce que vous ne payez pas : des frais de récupération — c’est le véritable avantage de la classe sur Standard-IA, où une rafale de lectures imprévue vous facture au gigaoctet. Les objets de moins de 128 Ko ne sont jamais surveillés, jamais facturés pour la surveillance, et toujours facturés au tarif Frequent Access : les petits objets ne gagnent exactement rien ici. Il y a aussi une durée minimale de stockage de 30 jours pour la classe.

La décision est donc : les frais par objet sont-ils plus petits que les économies par gigaoctet que l’automatisation trouvera vraiment? Ça dépend de la taille moyenne des objets, de la part des données qui refroidit réellement, et de la possibilité que vous auriez eue de connaître le patron et d’écrire une règle de cycle de vie à la place.

Quoi vérifier d’abord

  • La taille moyenne des objets. Octets totaux divisés par le nombre d’objets, par compartiment ou par préfixe. Ce seul chiffre tranche la plupart des cas.
  • Si le patron est réellement inconnu. « Les journaux de plus de 90 jours ne sont jamais lus », c’est un patron connu — c’est une règle de cycle de vie, pas de l’Intelligent-Tiering.
  • La durée de vie des objets. Les objets supprimés en moins de 30 jours sont facturés pour la durée minimale; les données éphémères n’ont pas leur place ici.
  • Si quelque chose lit des objets qui pourraient tomber dans les paliers d’archive optionnels. Si une application s’attend à des lectures synchrones sur tout, laissez les paliers d’archive désactivés.

Comment vérifier

Obtenez le nombre d’objets et la taille totale pour calculer la taille moyenne :

# Nombre et octets totaux pour un compartiment ou un préfixe
aws s3 ls s3://my-bucket --recursive --summarize | tail -2

# Stockage par palier une fois Intelligent-Tiering en service (CloudWatch)
aws cloudwatch get-metric-statistics \
  --namespace AWS/S3 \
  --metric-name BucketSizeBytes \
  --dimensions Name=BucketName,Value=my-bucket Name=StorageType,Value=IntelligentTieringIAStorage \
  --start-time 2026-06-01T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 86400 --statistics Average

Les valeurs de dimension StorageType — IntelligentTieringFAStorage, IntelligentTieringIAStorage et IntelligentTieringAIAStorage — montrent combien de données l’automatisation a réellement rétrogradées : cette distribution, c’est votre économie réalisée. Dans la console, S3 > votre compartiment > Metrics trace la même répartition, et S3 Storage Lens la montre pour tout le parc. Modélisez les deux scénarios avec les vrais prix de votre région sur calculator.aws avant de déplacer quoi que ce soit.

L’approche

  1. Calculez la taille moyenne des objets par préfixe. Comme règle de travail, des objets de plusieurs mégaoctets et plus rendent les frais de surveillance négligeables; des objets de quelques centaines de kilooctets les rendent significatifs. Faites vos propres calculs — les frais et les prix de stockage varient selon la région.
  2. Séparez les compartiments mixtes par préfixe. La plupart des vrais compartiments contiennent à la fois de gros fichiers médias et du petit JSON. Appliquez Intelligent-Tiering aux préfixes de gros objets et laissez les préfixes de petits objets en Standard.
  3. Faites entrer les données par une transition de cycle de vie, pas en les retéléversant. Une règle de transition avec un filtre ObjectSizeGreaterThan déplace les objets admissibles existants et attrape les nouveaux.
  4. Laissez les paliers d’archive optionnels désactivés par défaut. N’activez Archive Access et Deep Archive Access que pour les préfixes où une étape de restauration asynchrone est acceptable, et seulement après avoir vérifié chaque consommateur de ces données.
  5. Mesurez après 90 jours. Comparez la ligne des frais de surveillance à la distribution des paliers. Si presque tout est resté en Frequent Access, les données n’étaient pas froides et les frais n’ont rien acheté.

Quand ce n’est pas la bonne approche

Si vous pouvez énoncer le patron d’accès en une phrase, une règle de cycle de vie vers Standard-IA ou Glacier Instant Retrieval réalise la même économie sans frais de surveillance. Si le compartiment est dominé par des objets de moins de 128 Ko, Intelligent-Tiering n’est que de la gestion de surcoût sans gain. Si les objets vivent moins de 30 jours, la durée minimale efface l’intérêt. Et si les données sont écrites une fois puis conservées légalement pendant des années sans lecture, allez directement vers une classe Glacier — payer des frais mensuels pour « découvrir » que des archives sont froides, c’est de l’argent jeté à l’eau.

Erreurs courantes

  • L’activer sur tout un compartiment plein de vignettes, de fichiers de session ou de petits journaux, puis regarder les frais de surveillance dépasser les économies.
  • Activer les paliers d’archive optionnels et briser une application qui s’attendait à ce que chaque GetObject réponde immédiatement.
  • Le traiter comme un remplacement complet des règles de cycle de vie — Intelligent-Tiering ne supprime jamais rien; l’expiration exige toujours ses propres règles.
  • Le juger après deux semaines. La rétrogradation commence à 30 jours sans accès; la courbe d’économies prend un trimestre complet à montrer sa forme.

Garder le contrôle

  • Révisez les métriques de distribution des paliers chaque trimestre; un préfixe collé à plus de 90 % en Frequent Access n’a pas sa place dans la classe.
  • Gardez un filtre ObjectSizeGreaterThan sur chaque transition vers Intelligent-Tiering.
  • Surveillez la ligne des frais de surveillance dans Cost Explorer (type d’usage contenant Monitoring) à mesure que le nombre d’objets grandit.
  • Revérifiez tout préfixe dont la charge de travail change — une nouvelle tâche d’analytique peut ramener une archive entière au tarif Frequent Access.

Intelligent-Tiering est un bon défaut pour de gros objets à l’accès honnêtement inconnu, et une taxe silencieuse partout ailleurs — la documentation S3 donne les chiffres à jour par région à vérifier avant de vous engager. 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.