Comment choisir une classe de stockage S3 sans faire exploser les coûts

La principale cause de dépassement des coûts S3 consiste à considérer le tarif de stockage par Go comme l’intégralité de la facture. Ce n’est pas le cas. Votre coût réel correspond à la combinaison des Go-mois de stockage, des requêtes, des transitions, de la récupération et du transfert.

Pour les données dont la courbe de vieillissement est connue, les règles Lifecycle qui déplacent les objets vers Standard-IA ou Glacier selon un calendrier constituent le choix par défaut. Pour les données dont le mode d’accès est inconnu ou évolue, AWS recommande S3 Intelligent-Tiering « indépendamment de la taille de l’objet ou de la durée de conservation », selon Gestion des coûts de stockage avec Amazon S3 Intelligent-Tiering. Aucun de ces choix n’a de sens tant que vous ne l’avez pas confronté aux tarifs régionaux actuels, à une date que vous pouvez préciser.

Les principales mesures de maîtrise des coûts, par ordre d’importance

1. Établissez l’équation complète des coûts avant même de comparer les classes de stockage
2. Règles Lifecycle vers Standard-IA et Glacier pour un vieillissement et une suppression prévisibles
3. Intelligent-Tiering comme choix par défaut pour les accès imprévisibles ou évolutifs
4. Glacier Flexible Retrieval et Deep Archive pour les archives mesurées en mois ou en années, après avoir modélisé le comportement des restaurations
5. La liste de contrôle hors classe de stockage pour les charges avec beaucoup de requêtes, de transferts ou de régions

Comment nous avons évalué les approches de maîtrise des coûts

Nous avons évalué chaque approche selon cinq critères : son adéquation à la prévisibilité de votre mode d’accès, son exposition aux frais par objet compte tenu de la distribution réelle des tailles d’objets, les restrictions liées aux durées minimales et aux chemins de transition, la prise en compte des postes de coûts qui dépassent le tarif de stockage (requêtes, transfert, réplication, chiffrement, supervision), et l’existence d’outils de gouvernance permettant de vérifier que les actions ont effectivement été exécutées et d’attribuer correctement les dépenses.

Ces critères proviennent des mécanismes de service documentés par AWS, et non d’arguments marketing. La documentation AWS explique précisément le fonctionnement de Lifecycle, Intelligent-Tiering et Glacier. Elle ne constitue pas une étude indépendante des économies réalisées. Tout chiffre d’économie précis présenté en réunion budgétaire doit provenir d’un modèle propre à la charge de travail, exécuté avec les tarifs publiés actuels et vérifié à une date indiquée.

Établissez l’équation des coûts avant de choisir une classe de stockage

Les dépenses S3 d’une entreprise sont une somme, pas un poste unique. Elles comprennent les Go-mois de stockage pour chaque classe, le coût des requêtes (PUT, COPY, LIST, GET et requêtes de transition Lifecycle facturées par objet), les frais de récupération (Go et requêtes pour les niveaux Glacier, avec une facturation distincte pour les récupérations Bulk et Expedited), le transfert de données (sortant vers Internet, entrant et régional vers ou depuis EC2 et les autres ressources AWS, chacun étant suivi comme un type d’utilisation distinct), ainsi que des fonctions facultatives comme la supervision Intelligent-Tiering, les inventaires S3, le routage des Multi-Region Access Points et le traitement des métadonnées S3. Tous ces éléments apparaissent comme des postes distincts dans vos rapports d’utilisation, selon Comprendre vos rapports de facturation et d’utilisation AWS pour Amazon S3.

Les transitions Lifecycle n’entraînent elles-mêmes aucun frais de récupération de données. En revanche, chaque PUT, COPY ou déplacement déclenché par Lifecycle vers une classe de stockage quelconque entraîne des frais d’ingestion par requête, et chaque transition vers une classe différente compte comme une requête de transition facturable, en plus du tarif de la classe de stockage, selon Gérer le cycle de vie des objets et Résoudre les problèmes liés à Amazon S3 Lifecycle.

Faites ce calcul vous-même avant de vous engager. Prenez un compartiment représentatif, par exemple 10 millions d’objets de 2 Mo en moyenne, conservés pendant trois ans, dont 5 % sont récupérés chaque année, puis chiffrez-le de trois façons : Standard avec Lifecycle vers Standard-IA puis Glacier Flexible Retrieval, Intelligent-Tiering directement, et Intelligent-Tiering avec Archive Access activé. Utilisez les tarifs régionaux actuels par Go, par requête et pour la récupération sur les pages tarifaires d’AWS, et notez la date à laquelle vous les avez relevés. Les tarifs varient selon la capacité, la durée d’engagement et le niveau de support, et évoluent dans le temps : considérez donc comme suspects tous les chiffres que vous n’avez pas vérifiés ce trimestre. Le tableau comparatif ci-dessous fournit les paramètres mécaniques nécessaires à ce modèle.

Étape 1 : analysez vos données avant de choisir une classe de stockage

Segmentez vos objets selon leur taille moyenne, leur fréquence d’accès et leur durée de conservation avant même d’ouvrir la liste déroulante des classes de stockage. Depuis septembre 2024, le comportement Lifecycle par défaut d’AWS empêche la transition automatique des objets de moins de 128 Ko vers toute classe de stockage. Les configurations créées avant cette date conservent l’ancien comportement, sauf si vous les modifiez, selon Effectuer la transition d’objets avec Amazon S3 Lifecycle. Si vous avez hérité d’un ancien compartiment, vérifiez le comportement qui y est réellement appliqué.

Commencez par exécuter S3 Storage Lens ou S3 Inventory afin de déterminer combien d’objets et quelle capacité se situent sous le seuil de 128 Ko. AWS explique clairement pourquoi c’est important : « pour les objets plus petits, les coûts de transition peuvent dépasser les économies de stockage », car une requête de transition est facturée par objet, quelle que soit la taille de celui-ci.

Signalez séparément les compartiments versionnés et l’utilisation d’Object Lock. Dans un compartiment où la gestion des versions est activée, l’expiration de la version actuelle ne supprime pas l’objet. Elle crée un marqueur de suppression, et ces marqueurs comptent toujours comme des objets, selon Résoudre les problèmes liés à Amazon S3 Lifecycle. Si vous ne les traitez pas, ils font indéfiniment augmenter le stockage et le nombre de requêtes. Vous avez besoin d’une seconde règle Lifecycle pour supprimer les versions précédentes, les marqueurs de suppression arrivés à expiration et les chargements multipart incomplets.

Étape 2 : choisissez la classe de stockage de destination

Choisissez la classe correspondant à la durée minimale d’engagement que vous pouvez réellement accepter. Standard-IA et One Zone-IA conviennent à des accès réguliers, peu fréquents et prévisibles, avec un minimum de 30 jours. Glacier Instant Retrieval et Flexible Retrieval conviennent aux archives avec un minimum de 90 jours. Glacier Deep Archive est adapté au stockage froid pluriannuel, avec un minimum de 180 jours, selon Résoudre les problèmes liés à Amazon S3 Lifecycle.

Glacier Flexible Retrieval et Deep Archive peuvent réduire sensiblement le coût de stockage des données archivées pendant des mois ou des années, mais les objets « ne sont pas disponibles en temps réel », selon Effectuer la transition d’objets avec Amazon S3 Lifecycle. Vous devez restaurer une copie temporaire avant de pouvoir accéder aux données, et les chemins de transition ne fonctionnent que dans un sens : Flexible Retrieval peut passer à Deep Archive, mais Deep Archive ne peut être converti vers aucune autre classe via Lifecycle. Une erreur de choix enferme donc les données froides derrière un processus de restauration, sans moyen automatisé de revenir en arrière.

Intelligent-Tiering mérite d’être choisi comme classe de stockage à part entière, et pas seulement comme raccourci de planification, lorsque les accès sont réellement imprévisibles. Le service répartit automatiquement les données entre trois niveaux à faible latence, sans frais de récupération ni frais supplémentaires pour les déplacements entre ses propres niveaux, avec en plus des niveaux facultatifs Archive Access et Deep Archive Access pour les données qui peuvent rester accessibles en quelques minutes ou quelques heures, selon Gestion des coûts de stockage avec Amazon S3 Intelligent-Tiering et Utiliser S3 Intelligent-Tiering - Amazon Simple Storage Service.

Étape 3 : choisissez votre automatisation, règles Lifecycle ou supervision intégrée d’Intelligent-Tiering

Lifecycle est un mécanisme de planification, pas une classe de stockage à part entière. Il peut cibler Standard-IA, One Zone-IA, Intelligent-Tiering ou n’importe quel niveau Glacier selon un calendrier d’ancienneté défini (30 jours vers Standard-IA, un an vers Glacier Flexible Retrieval, par exemple), et peut également faire expirer automatiquement les objets, selon Gérer le cycle de vie des objets.

Les changements de facturation s’appliquent dès qu’une règle Lifecycle est satisfaite, même si le déplacement physique n’est pas encore terminé. Deux exceptions méritent d’être retenues. Les transitions vers Intelligent-Tiering ne modifient pas la facturation tant que l’objet n’a pas réellement transité. Les transitions vers les niveaux Glacier déclenchent la surcharge de 40 Ko par objet et le décompte de la durée minimale dès que la règle est satisfaite, et non une fois le déplacement physique terminé, selon Résoudre les problèmes liés à Amazon S3 Lifecycle. Cette distinction compte si vous planifiez une sortie anticipée pour éviter une pénalité de durée minimale.

La supervision intégrée d’Intelligent-Tiering remplace la planification manuelle, mais ajoute de petits frais mensuels de supervision et d’automatisation par objet. AWS qualifie ces frais de « faibles », mais ils augmentent avec le nombre d’objets : un portefeuille de plusieurs millions de petits objets peut générer de vrais coûts de supervision, même si la récupération est gratuite. Autre point à connaître : les évaluations Lifecycle fondées sur des balises s’exécutent quotidiennement, et les mises à jour des règles peuvent prendre jusqu’à 15 minutes pour se propager ; supprimer une balise ne garantit donc pas l’arrêt immédiat d’une transition déjà en attente.

Étape 4 : modélisez la récupération des archives et l’exposition aux sorties anticipées

Avant de vous engager dans une classe assortie d’une durée minimale, modélisez la fréquence à laquelle vous devrez réellement récupérer les données et le degré d’urgence. Les requêtes Bulk et Expedited de Glacier Flexible Retrieval sont facturées séparément en Go, et le choix d’un niveau de vitesse de récupération inadapté modifie à la fois votre facture et votre délai d’attente.

Une suppression, un remplacement ou une transition anticipés avant la durée minimale d’une classe déclenchent des frais calculés au prorata de la durée restante. Les rapports d’utilisation les suivent séparément pour Standard-IA et One Zone-IA (30 jours), Glacier Instant et Flexible Retrieval (90 jours), ainsi que Deep Archive (180 jours). La question de savoir si une seule restauration anticipée annule les économies prévues dépend de la taille des objets, du moment de la sortie et du volume de récupération. Le résultat n’est pas fixe. C’est un chiffre que vous obtenez en exécutant votre propre modèle de seuil de rentabilité, et non en lisant une promesse d’économies mise en avant par un fournisseur.

Chaque transition Glacier ajoute également une surcharge de 40 Ko par objet : 8 Ko facturés aux tarifs Standard et 32 Ko au tarif Glacier de destination. Pour les portefeuilles contenant de nombreux petits objets, AWS recommande lui-même de les regrouper en objets moins nombreux et plus volumineux avant d’appliquer les règles Lifecycle, car cette surcharge peut totalement dépasser les économies de stockage.

Les coûts extérieurs à la classe de stockage : la liste de contrôle que les entreprises oublient

Transfert de données. Les rapports d’utilisation suivent séparément le transfert sortant vers Internet, le transfert entrant et le transfert régional vers ou depuis EC2 ou d’autres ressources AWS au sein de la même région. Le transfert interrégional et la sortie vers Internet constituent souvent le poste le plus important que les calculateurs de coûts natifs d’AWS sous-estiment.

Multi-Region Access Points et réplication. Les données acheminées via un point de terminaison MRAP depuis des compartiments situés dans une région, ainsi que les données transférées entre groupes de régions hors du réseau AWS, sont facturées et déclarées séparément du stockage de base. Ce point est important pour toute architecture de résilience ou de conformité multirégionale, et facile à manquer si vous ne modélisez que les tarifs des classes de stockage.

Charges avec beaucoup de requêtes et de métadonnées. Les tâches S3 Batch Operations, les inventaires S3, les frais par mise à jour de S3 Metadata et les données traitées dans les tables d’annotations, ainsi que le nombre d’objets supervisés par Intelligent-Tiering, sont tous facturés séparément. Les charges à fort volume d’objets et à forte activité, comme les lacs de données et l’ingestion IoT, doivent intégrer ces éléments avant de supposer que l’écart entre classes de stockage explique tout. Les objets chiffrés avec SSE-KMS restent chiffrés lors de toute transition, mais chaque requête KMS ajoute son propre coût, entièrement en dehors de la facturation S3.

Tableau comparatif : classes de stockage, durée minimale et adéquation à l’automatisation

Lifecycle et Intelligent-Tiering ne sont pas des solutions concurrentes. Lifecycle est un mécanisme d’automatisation que vous pouvez appliquer à Standard-IA, One Zone-IA, Intelligent-Tiering ou n’importe quel niveau Glacier. Intelligent-Tiering est en soi une classe de stockage intégrant la hiérarchisation. Un compartiment peut tout à fait utiliser une règle Lifecycle pour acheminer les objets Standard vieillissants vers Intelligent-Tiering, selon Utiliser S3 Intelligent-Tiering.

Gouvernance : balisage, attribution des coûts et vérification de l’exécution effective des actions Lifecycle

Activez les balises d’attribution des coûts au niveau de la clé de balise afin que les dépenses associées aux balises de compartiment apparaissent dans les rapports de facturation. Après l’application d’une balise, son apparition sur la page des balises d’attribution des coûts peut prendre jusqu’à 24 heures, puis son activation peut nécessiter jusqu’à 24 heures supplémentaires, selon Activer les balises d’attribution des coûts définies par l’utilisateur - AWS Billing. Le balisage des compartiments n’entraîne aucun frais supplémentaire au-delà des tarifs standard des requêtes d’API S3, selon Utiliser les balises avec les compartiments S3 à usage général - Documentation AWS.

Utilisez les tableaux de bord S3 Storage Lens, et non les métriques CloudWatch, pour observer les changements quotidiens de stockage liés aux actions Lifecycle. AWS recommande explicitement Storage Lens plutôt que CloudWatch pour cela. Effectuez un recoupement avec S3 Inventory afin de vérifier le niveau d’accès réellement attribué aux objets, avec les notifications d’événements S3 pour les événements d’expiration et de transition, et avec les journaux d’accès au serveur. Les transitions et expirations Lifecycle sont asynchrones : un délai entre l’éligibilité et l’action effective est donc toujours possible.

AWS Service Catalog AppRegistry applique automatiquement une balise awsApplication qui est activée automatiquement pour le suivi des coûts, ce qui est réellement utile pour suivre les dépenses totales d’une application. Considérez-la comme une couche pratique, et non comme un remplacement d’une taxonomie de balises conçue avec soin. Si vous la désactivez, elle ne se réactivera pas automatiquement.

Comment choisir : adapter l’approche à votre charge de travail

Si votre courbe de vieillissement est connue, que votre politique de suppression est claire et que la taille de vos objets est largement supérieure à 128 Ko, utilisez des règles Lifecycle les acheminant vers Standard-IA puis Glacier selon un calendrier, après validation par votre propre modèle de seuil de rentabilité concernant la récupération et l’exposition aux sorties anticipées.

Si vos accès sont imprévisibles ou évolutifs, que vos tailles d’objets sont hétérogènes ou que vous exécutez une charge nouvelle ou non éprouvée comme un lac de données ou un pipeline analytique, choisissez par défaut Intelligent-Tiering et acceptez les frais de supervision par objet comme une assurance contre une mauvaise hiérarchisation manuelle.

Si vous exécutez une charge avec beaucoup de requêtes, de transferts, de régions, ou fortement chiffrée et répliquée, passez en revue la liste de contrôle complète des coûts hors classe de stockage ci-dessus avant de finaliser votre choix. Les coûts de transfert, de requêtes et de supervision peuvent totalement dépasser l’écart entre classes de stockage, et choisir la « bonne » classe ne résoudra rien si le problème réel se situe dans les autres postes.