S3 Intelligent-Tiering : niveaux, coûts et accès aux archives

S3 Intelligent-Tiering est une classe de stockage Amazon S3 qui déplace les objets admissibles entre plusieurs niveaux d’accès selon leur utilisation. Elle peut réduire les frais de stockage des données moins actives, mais le résultat dépend de leur taille, de leur nombre et du temps passé dans chaque niveau.

La première décision concerne l’accès immédiat. Les trois niveaux automatiques le conservent. Les niveaux facultatifs Archive Access et Deep Archive Access exigent une restauration avant la lecture. Ce guide distingue ces choix, calcule un exemple régional et présente une configuration d’archivage limitée à un préfixe.

Comprendre les cinq niveaux d’accès

Un objet entre dans Intelligent-Tiering au niveau Frequent Access. Sa classe reste INTELLIGENT_TIERING lorsqu’il change de niveau. La référence AWS explique la progression automatique :

Niveau	Condition	Lecture
Frequent Access	Données nouvellement entrées ou consultées	Immédiate
Infrequent Access	30 jours consécutifs sans accès	Immédiate
Archive Instant Access	90 jours consécutifs sans accès	Immédiate
Archive Access, facultatif	Seuil d’inactivité configuré entre 90 et 730 jours	Restauration nécessaire
Deep Archive Access, facultatif	Seuil d’inactivité configuré entre 180 et 730 jours	Restauration nécessaire

Archive Instant Access et Archive Access ne sont pas interchangeables. Activer Archive Access à 90 jours fait passer directement à ce niveau, sans séjour dans Archive Instant Access. La définition de Tiering précise les seuils facultatifs ; choisissez-les selon le délai de récupération acceptable.

Ces niveaux appartiennent à une seule classe AWS. Notre guide du stockage cloud Amazon traite du choix entre S3, EBS, EFS et FSx. La compatibilité avec l’API S3 ne prouve pas qu’un autre fournisseur propose le mécanisme Intelligent-Tiering d’AWS.

Vérifier l’admissibilité et les accès

Les objets de moins de 128 Ko peuvent utiliser la classe, mais restent dans Frequent Access, sans frais de surveillance. Intelligent-Tiering n’impose aucune durée minimale de stockage. Ces règles diffèrent des tailles facturables et durées minimales d’autres classes ; la FAQ S3 explique ces distinctions.

Examinez le volume et le nombre d’objets. De gros exports et des millions de petits fichiers applicatifs peuvent représenter un volume similaire avec des coûts différents. Isolez les petits objets avant d’estimer les frais de surveillance.

L’inactivité dépend des opérations, pas seulement de la date de création. Une lecture GET peut ramener un objet dans Frequent Access ; HEAD et les opérations de liste ne le font pas à eux seuls. La copie et la réplication peuvent aussi intervenir. Consultez la liste des opérations AWS lorsqu’une tâche planifiée semble maintenir les données actives.

Si l’application ne tolère pas un délai de restauration, commencez par les niveaux automatiques. Décidez séparément de l’archivage facultatif : désignez le responsable de la restauration, fixez le délai attendu et testez la manière dont l’application attend ou signale l’indisponibilité.

Calculer le stockage et la surveillance ensemble

Les tarifs publics suivants, en dollars américains, concernent US East (N. Virginia), us-east-1. Ils ont été vérifiés le 9 novembre 2026 dans la grille régionale AWS, publiée le 4 novembre. Les tarifs Frequent Access et Standard utilisent la première tranche de 50 To. AWS nomme GB son unité de facturation binaire ; l’exemple porte sur 1 000 Gio, soit 1 000 × 2³⁰ octets.

Poste	Tarif
Frequent Access / S3 Standard	0,023 $ par GB-mois
Infrequent Access	0,0125 $ par GB-mois
Archive Instant Access	0,004 $ par GB-mois
Archive Access facultatif	0,0036 $ par GB-mois
Deep Archive Access facultatif	0,00099 $ par GB-mois
Surveillance et automatisation	0,0025 $ par mois pour 1 000 objets admissibles

Prenons un jeu de données hypothétique déjà stabilisé : 1 000 Gio répartis sur 100 000 objets, tous d’au moins 128 Ko. Supposons une occupation moyenne mesurée sur un mois complet de 20 % en Frequent Access, 30 % en Infrequent Access et 50 % en Archive Instant Access. Les niveaux d’archivage facultatifs sont désactivés.

Poste	Calcul	Coût mensuel
Frequent Access	200 × 0,023 $	4,60 $
Infrequent Access	300 × 0,0125 $	3,75 $
Archive Instant Access	500 × 0,004 $	2,00 $
Surveillance	100 000 ÷ 1 000 × 0,0025 $	0,25 $
Total de ces postes	10,35 $ + 0,25 $	10,60 $

Le stockage des mêmes 1 000 Gio dans S3 Standard coûterait 23 $, soit un écart de 12,40 $ dans ce scénario. Il s’agit d’un calcul, pas d’une facture observée ni d’une prévision du premier mois. Les données entrent dans Frequent Access. Si elles y restent toutes pendant un mois complet, stockage et surveillance coûteraient 23,25 $.

Ajoutez les requêtes de migration, les requêtes ordinaires, les transferts, les frais liés aux clés de chiffrement et les services de reporting utilisés. La page tarifaire S3 distingue l’entrée dans la classe des déplacements entre niveaux. Chaque objet archivé dans un niveau facultatif ajoute aussi 8 Ko de métadonnées au tarif Standard et 32 Ko au tarif d’archive correspondant. Ces coûts facultatifs sont exclus du calcul.

Faire entrer les données dans la classe

Une configuration d’archivage ne convertit pas les objets Standard en Intelligent-Tiering. AWS documente deux méthodes : choisir cette classe lors d’un nouvel envoi ou utiliser Lifecycle pour déplacer les objets existants admissibles. Suivez les instructions de configuration adaptées.

Pour les objets existants, examinez toute la politique Lifecycle avant modification. Les règles de transition actuelles excluent par défaut les objets de moins de 128 Ko ; d’anciennes configurations peuvent conserver un comportement différent. Une exception de taille ne rend pas ces objets admissibles aux déplacements automatiques d’Intelligent-Tiering. Notre guide du cycle de vie S3 couvre transitions, versions et expiration.

Commencez par un petit préfixe. Relevez tailles, versions, classes actuelles et règles existantes. Estimez les coûts d’entrée et comparez ensuite les factures sur une même population, pour ne pas attribuer au tiering une baisse due à des suppressions ou masquer l’effet de nouvelles données.

Limiter une configuration d’archivage facultative

Cet exemple vise uniquement les clés commençant par tiering-lab/ dans un compartiment de test à usage général existant. Il choisit Archive Access après 180 jours sans accès et Deep Archive Access après 365 jours. Ce sont des choix d’exemple, pas des paramètres universels de conservation. Cette opération ne prend pas en charge les compartiments de répertoire.

Enregistrez ce contenu dans archive-config.json :

{
  "Id": "tiering-lab-archive",
  "Filter": {
    "Prefix": "tiering-lab/"
  },
  "Status": "Enabled",
  "Tierings": [
    {
      "Days": 180,
      "AccessTier": "ARCHIVE_ACCESS"
    },
    {
      "Days": 365,
      "AccessTier": "DEEP_ARCHIVE_ACCESS"
    }
  ]
}

Le schéma de configuration définit l’identifiant, l’état, le filtre et les niveaux. Examinez les configurations existantes et choisissez un identifiant inutilisé : PUT peut remplacer celle qui porte le même identifiant. Remplacez le compartiment, le compte propriétaire, le profil et la région par les valeurs de votre environnement de test.

aws s3api put-bucket-intelligent-tiering-configuration --bucket amzn-s3-demo-tiering --expected-bucket-owner 111122223333 --profile tiering-lab --region us-east-1 --id tiering-lab-archive --intelligent-tiering-configuration file://archive-config.json

La commande PUT exige s3:PutIntelligentTieringConfiguration. Le contrôle du propriétaire attendu évite de cibler un compartiment appartenant à un autre compte ; il ne remplace pas des droits IAM limités. Relisez la configuration :

aws s3api get-bucket-intelligent-tiering-configuration --bucket amzn-s3-demo-tiering --expected-bucket-owner 111122223333 --profile tiering-lab --region us-east-1 --id tiering-lab-archive

Comparez l’identifiant, le préfixe, l’état et les deux seuils renvoyés par la commande GET. Une réponse conforme confirme l’enregistrement de la configuration, pas le déplacement d’un objet. Les délais automatiques ne peuvent pas être démontrés pendant une courte séance de configuration.

Observer le niveau et préparer la restauration

Consultez les métadonnées d’un objet de test connu :

aws s3api head-object --bucket amzn-s3-demo-tiering --expected-bucket-owner 111122223333 --profile tiering-lab --region us-east-1 --key tiering-lab/sample.bin --query "{storageClass:StorageClass,archiveStatus:ArchiveStatus,restore:Restore}"

HeadObject renvoie l’état d’archivage et de restauration lorsqu’ils s’appliquent. L’absence de ArchiveStatus ne distingue pas Frequent Access, Infrequent Access et Archive Instant Access. Pour un rapport sur une population, activez le champ du niveau Intelligent-Tiering dans S3 Inventory ; le rapport reste un instantané daté.

Pour un objet dont l’archivage dans un niveau facultatif est confirmé, enregistrez cet objet JSON vide dans restore-request.json :

{}

aws s3api restore-object --bucket amzn-s3-demo-tiering --expected-bucket-owner 111122223333 --profile tiering-lab --region us-east-1 --key tiering-lab/sample.bin --restore-request file://restore-request.json

La commande suit l’exemple de restauration Intelligent-Tiering d’AWS. N’ajoutez pas Days : l’objet revient dans Frequent Access, sans création d’une copie temporaire accessible pendant cette durée. Le mode de récupération par défaut est Standard. Pour une version non courante, indiquez son identifiant de version.

Répétez HEAD pour suivre la restauration, puis vérifiez une lecture réussie. L’acceptation de la demande ne prouve pas sa fin. AWS indique généralement 3 à 5 heures en Standard pour Archive Access et une récupération dans les 12 heures pour Deep Archive Access ; ces indications ne garantissent pas le délai de reprise de l’application. Les récupérations Standard et Bulk sont gratuites dans Intelligent-Tiering ; Expedited est une option payante lorsqu’elle est disponible.

Décider à partir du résultat mesuré

Comparez stockage et surveillance avant et après le pilote, sur la même population et une période utile. Examinez les objets restés actifs, ceux qui n’étaient pas admissibles, les délais de restauration et les erreurs applicatives. Gardez l’archivage facultatif désactivé là où le délai de récupération requis n’a pas été démontré.

Pour ce guide, nous avons vérifié le calcul tarifaire régional et validé localement la structure des requêtes. Nous n’avons envoyé aucune requête à un compte AWS, observé aucun changement de niveau ni testé la restauration. Les exemples servent à préparer un test limité ; ils ne prouvent pas la réussite d’un déploiement en production.