Classes de stockage S3 expliquées : choisir l'option adaptée pour optimiser les coûts

Amazon Simple Storage Service (S3) est le stockage d'objets par défaut pour de nombreuses charges de travail AWS car il s'adapte bien et offre plusieurs classes de stockage pour différents schémas d'accès. Cependant, toutes les données ne sont pas accédées de la même manière. Stocker des données critiques fréquemment accédées dans la même classe que des données d'archivage rarement accédées peut entraîner des dépenses cloud importantes et inutiles. Comprendre les nuances entre les différentes classes de stockage S3 est crucial pour concevoir une architecture optimisée en termes de coûts.

Comprendre la durabilité et la disponibilité de S3

Avant de plonger dans les classes, il est important de définir deux métriques clés pour S3 :

• Durabilité : La probabilité que vos données restent intactes au fil du temps. S3 est conçu pour une durabilité de 99,999999999 % (11 neuf) sur l'infrastructure utilisée pour une classe donnée.
• Disponibilité : Le pourcentage de temps pendant lequel vos données sont accessibles pour la récupération. Cela est généralement mesuré annuellement (par exemple, 99,9 %).

Ces métriques varient légèrement en fonction de la classe de stockage spécifique choisie.

Les classes de stockage S3 de base : une comparaison détaillée

AWS propose plusieurs classes de stockage optimisées pour différentes fréquences d'accès et tolérances aux temps d'arrêt. Voici un aperçu détaillé des options les plus courantes.

1. S3 Standard

S3 Standard est la classe de stockage par défaut et à usage général, la mieux adaptée aux données fréquemment accédées.

• Cas d'utilisation : Données actives, distribution de contenu, contenu généré dynamiquement et applications mobiles/de jeux.
• Durabilité : 11 neuf.
• Disponibilité : 99,99 % (Haute disponibilité).
• Temps de récupération : Millisecondes.
• Tarification : Coût de stockage le plus élevé parmi les niveaux fréquemment accédés, mais aucun frais de récupération.

Meilleure pratique : Utilisez cette classe pour les données nécessitant un accès immédiat avec une latence minimale.

2. S3 Intelligent-Tiering (S3-IT)

S3 Intelligent-Tiering est conçu pour les données avec des schémas d'accès inconnus ou changeants. Il déplace automatiquement les objets entre deux ou plusieurs niveaux d'accès en fonction de l'utilisation, optimisant les coûts de stockage sans frais opérationnels.

• Cas d'utilisation : Lacs de données, données avec des schémas d'accès imprévisibles, ou lorsque vous souhaitez garantir un accès immédiat tout en optimisant les coûts au fil du temps.
• Fonctionnement : Il surveille l'accès. Si un objet n'a pas été accédé pendant 30 jours consécutifs, il passe au niveau d'accès peu fréquent (IA). S'il est à nouveau accédé, il revient au niveau d'accès fréquent.
• Niveaux inclus : Accès fréquent, Accès peu fréquent, Archivage à accès instantané (optionnel).
• Facteur de coût : Inclut de petits frais mensuels de surveillance et d'automatisation par objet, en plus des coûts de stockage, qui changent en fonction du niveau où se trouve l'objet.

Conseil actionnable : Si vous n'êtes pas sûr de la fréquence d'accès aux données, S3 Intelligent-Tiering offre souvent le meilleur équilibre entre économies de coûts et cohérence des performances.

3. S3 One Zone-Infrequent Access (S3 One Zone-IA)

Cette classe est idéale pour les données rarement accédées mais nécessitant une récupération rapide, similaire à S3 Standard-IA, mais avec une distinction majeure en termes de disponibilité.

• Cas d'utilisation : Sauvegardes secondaires, données recréables (par exemple, des données pouvant être régénérées à partir d'une source), ou stockage de données qui ne sont pas suffisamment critiques pour justifier une redondance multi-AZ.
• Durabilité : 11 neuf.
• Disponibilité : 99,5 % (Disponibilité inférieure à Standard).
• Emplacement de stockage : Les données sont stockées de manière redondante dans une seule zone de disponibilité (AZ) AWS, contrairement aux autres classes qui s'étendent sur plusieurs AZ.
• Facteur de coût : Coût de stockage nettement inférieur à Standard, mais la récupération des données entraîne des frais.

⚠️ Avertissement concernant One Zone-IA : Comme les données résident dans une seule AZ, si cette AZ spécifique subit un événement catastrophique (par exemple, une panne de courant majeure ou une catastrophe naturelle), vos données dans ce niveau pourraient être perdues. C'est pourquoi il est crucial de ne l'utiliser que pour des données non critiques et facilement remplaçables.

4. Classes de stockage S3 Glacier (Archivage)

Les classes de stockage Glacier sont optimisées pour l'archivage à long terme où des temps de récupération de quelques minutes à quelques heures sont acceptables.

S3 Glacier Instant Retrieval (S3 Glacier IR)

Cela comble le fossé entre l'accès peu fréquent et l'archivage profond.

• Cas d'utilisation : Données accédées une fois par trimestre ou moins, mais nécessitant une récupération en millisecondes lorsque nécessaire (par exemple, images médicales, archives de médias d'actualité).
• Temps de récupération : Millisecondes (latence similaire aux classes IA).
• Facteur de coût : Coût de stockage très bas, avec des frais de récupération.

S3 Glacier Flexible Retrieval (anciennement S3 Glacier)

Il s'agit d'une option d'archivage à long terme lorsque la récupération en quelques minutes à quelques heures est acceptable.

• Cas d'utilisation : Archives de conformité réglementaire, données de reprise après sinistre rarement, voire jamais, nécessaires.
• Options de récupération (et latence) :
  • Accélérée : 1 à 5 minutes
  • Standard : 3 à 5 heures
  • En masse : 5 à 12 heures
• Facteur de coût : Coût de stockage extrêmement bas, mais des frais de récupération s'appliquent et prennent du temps.

S3 Glacier Deep Archive

L'option de stockage la moins chère d'AWS S3.

• Cas d'utilisation : Données qui pourraient n'être accédées qu'une ou deux fois par an, généralement pour la conformité.
• Options de récupération (et latence) :
  • Standard : 12 heures
  • En masse : 48 heures
• Facteur de coût : Taux de stockage le plus bas disponible, frais de récupération les plus élevés et fenêtres de récupération les plus longues requises.

Comment choisir : un cadre de décision

Le choix de la bonne classe dépend de la réponse à trois questions clés sur le cycle de vie de vos données :

Question	Considération principale	Chemin de classe recommandé
À quelle fréquence est-elle accédée ?	Fréquence d'accès	Fréquent $\rightarrow$ Standard ; Peu fréquent $\rightarrow$ IA ou Glacier
Quel est le temps d'arrêt/perte acceptable ?	Durabilité/Disponibilité	Critique $\rightarrow$ Standard/Intelligent-Tiering ; Jetable $\rightarrow$ One Zone-IA
À quelle vitesse dois-je la récupérer ?	Exigence de latence	Millisecondes $\rightarrow$ Standard/Intelligent-Tiering/Glacier IR ; Heures $\rightarrow$ Glacier Flexible/Deep Archive

Exemple de scénario : Actifs médiatiques d'une entreprise

Une équipe marketing télécharge des centaines de fichiers vidéo bruts chaque jour :

1. Montages/promotions en cours (30 derniers jours) : S3 Standard (Accès élevé, faible latence).
2. Actifs plus anciens nécessitant une révision occasionnelle (30 jours à 1 an) : S3 Intelligent-Tiering (Pour réaliser des économies après la période initiale à chaud).
3. Masters finaux terminés et audités (Plus d'un an) : S3 Glacier Deep Archive (Coût le plus bas, uniquement nécessaire pour les audits de conformité).

Exemple de scénario : Journaux, sauvegardes et téléchargements utilisateur

Une même entreprise a souvent trois schémas S3 très différents.

Pour les journaux d'application, les données récentes sont précieuses car les ingénieurs les recherchent lors des incidents. Une fois la fenêtre d'incident passée, la plupart des journaux deviennent des données de conformité ou de tendance. Un cycle de vie raisonnable pourrait conserver 30 à 90 jours dans Standard ou Standard-IA, déplacer les journaux plus anciens vers un niveau d'archivage et faire expirer les journaux de débogage de faible valeur après une période de conservation fixe. Les chiffres exacts doivent provenir de votre politique de conservation et de la fréquence à laquelle les gens interrogent réellement les anciens préfixes.

Pour les sauvegardes de base de données, la classe de stockage doit suivre la promesse de restauration. Si l'équipe indique qu'une restauration de production doit commencer en quelques minutes, conservez les sauvegardes les plus récentes dans une classe avec récupération immédiate. Les copies mensuelles ou annuelles plus anciennes peuvent passer au froid si elles sont destinées à la conservation d'audit plutôt qu'à une récupération rapide. Testez les restaurations à partir de la classe choisie ; une politique de sauvegarde qui n'a jamais été restaurée est principalement une règle de facturation.

Pour les téléchargements utilisateur, l'accès est plus difficile à prévoir. Une photo de profil peut être minuscule mais extraite constamment. Une grande vidéo originale peut être téléchargée une fois, transcodée et rarement retouchée. Stockez les actifs dérivés et les originaux sous des préfixes séparés afin que les règles de cycle de vie puissent les traiter différemment. Ne faites pas en sorte que la politique des miniatures hérite de la même règle d'archivage que les originaux de plusieurs gigaoctets, à moins que ce ne soit vraiment ce dont le produit a besoin.

Questions à se poser avant de modifier un bucket

Avant d'ajouter une règle de cycle de vie, demandez-vous qui lit les données, comment elles sont lues et ce qui se passe si la récupération est retardée. Les ingénieurs connaissent souvent mieux le chemin d'écriture que le chemin de lecture car les téléchargements font partie de l'application, tandis que les lectures se produisent plus tard via l'analytique, les outils de support, les exportations de conformité ou la réponse manuelle aux incidents.

Recherchez les tâches par lots qui analysent les anciens préfixes. Un travail nocturne qui liste chaque objet, ouvre les métadonnées ou échantillonne les anciens fichiers peut annuler une partie des économies réalisées grâce à une classe plus froide. Si le travail n'a besoin que d'un manifeste, S3 Inventory peut être meilleur que de lister le bucket à plusieurs reprises. Si les analystes interrogent les journaux avec Athena, tenez compte de la disposition des partitions et de la compression avant de déplacer les données vers une classe qui nécessite des étapes de restauration.

Faites attention à la taille des objets. Les classes de stockage avec des tailles d'objet facturables minimales peuvent être de mauvais choix pour un grand nombre de très petits fichiers. Dans ces cas, la compaction des données en objets plus grands, l'utilisation de Parquet pour l'analytique ou l'expiration des objets inutiles peuvent être plus efficaces qu'un changement de classe de stockage.

Enfin, rédigez les règles de cycle de vie de manière à pouvoir les expliquer lors d'un incident. Une règle de préfixe nommée archive-old-logs-after-90-days est plus facile à comprendre qu'une règle à l'échelle du bucket qui déplace silencieusement tout après 30 jours. L'optimisation des coûts devrait rendre le système moins cher sans rendre la récupération mystérieuse.

Un autre contrôle pratique est la propriété. Dans les comptes réels, le propriétaire du bucket, le compte de téléchargement, le rôle de réplication et le compte d'analytique ne sont pas toujours les mêmes. Avant de déplacer des données vers une classe d'archivage, confirmez qui peut les restaurer et qui paie pour la récupération. Les buckets multi-comptes avec chiffrement KMS peuvent échouer au moment de la restauration si le rôle qui a besoin de l'objet peut lister le bucket mais ne peut pas utiliser la clé. C'est une mauvaise surprise lors d'un audit.

Le versioning modifie également le calcul. Les règles de cycle de vie peuvent faire la transition ou faire expirer les versions actuelles et les versions non actuelles différemment. Si une application écrase la même clé toutes les heures, les versions non actuelles peuvent devenir la plus grande partie du bucket. Examinez-les séparément au lieu de supposer que le nombre d'objets actuels raconte toute l'histoire.

Implémentation des politiques de cycle de vie

Déplacer manuellement des objets entre les classes est inefficace. La manière la plus efficace de gérer les coûts entre ces niveaux est d'utiliser les politiques de cycle de vie S3.

Les politiques de cycle de vie vous permettent de définir des règles qui font automatiquement la transition des objets vers des niveaux de stockage plus froids ou les font expirer définitivement après un nombre défini de jours.

Exemple de règle de cycle de vie (Transition) :

<Rule>
    <ID>Move_to_IA_After_30_Days</ID>
    <Status>Enabled</Status>
    <Filter>
        <Prefix>logs/</Prefix>
    </Filter>
    <Transition>
        <Days>30</Days>
        <StorageClass>GLACIER_IR</StorageClass>
    </Transition>
</Rule>

Cette configuration déplace automatiquement tout objet dans le préfixe logs/ vers Glacier Instant Retrieval 30 jours après sa création, réduisant considérablement les coûts de stockage à long terme tout en maintenant des capacités de récupération rapides si nécessaire.

Pièges de coûts que les gens négligent

La décision de classe de stockage n'est pas seulement une comparaison mensuelle par Go. Les frais de récupération, les frais de demande, la durée de stockage minimale, la taille d'objet facturable minimale, la réplication, les demandes de transition de cycle de vie et les frais de surveillance peuvent modifier la réponse. Une archive de petits objets avec des millions de clés peut se comporter très différemment d'un petit nombre de gros fichiers de sauvegarde.

Par exemple, les journaux d'application sont souvent écrits une fois et rarement lus, donc une règle de cycle de vie de Standard vers Glacier Instant Retrieval ou Glacier Flexible Retrieval peut avoir du sens. Mais si votre processus d'incident analyse fréquemment les anciens journaux avec Athena, un archivage agressif peut créer des restaurations lentes et des coûts de récupération surprises. Dans ce cas, partitionner les journaux par date, faire expirer les préfixes de faible valeur bruyants et conserver les mois récents dans une classe adaptée aux requêtes peut permettre d'économiser plus d'argent que de tout déplacer à froid après 30 jours.

Les sauvegardes ont une forme différente. Un dump de base de données que vous testez une fois par mois a besoin d'un comportement de restauration prévisible. Si votre objectif de temps de récupération est mesuré en minutes, Deep Archive n'est probablement pas le bon endroit pour la seule copie restaurable, même si elle est bon marché au repos. Si le même dump est la troisième copie conservée uniquement pour la conservation d'audit, Deep Archive peut être raisonnable.

Les équipes médiatiques ont souvent besoin d'actifs anciens de manière imprévisible. Intelligent-Tiering peut être un bon choix par défaut pour ces schémas inconnus, surtout lorsque les objets sont suffisamment grands pour que les frais de surveillance ne soient pas le facteur décisif. Pour un grand nombre de petites miniatures, les frais et le comportement de taille d'objet minimale méritent un examen plus approfondi avant de l'activer partout.

Une manière pratique de choisir est d'échantillonner un bucket, d'exporter S3 Inventory, de regrouper par préfixe, nombre d'objets, octets totaux, date de dernière modification et schéma d'accès connu, puis d'écrire des règles de cycle de vie par préfixe. Évitez une règle à l'échelle du bucket à moins que le bucket ne contienne vraiment un seul type de données.