Optimisation pratique des coûts S3 : du décryptage de la facturation aux 7 mesures exploitables

De nombreuses équipes se contentent de regarder « combien de To sont stockés » lorsqu’elles analysent leur facture S3, mais les coûts réels de S3 résultent généralement de la superposition de quatre catégories de frais : la capacité de stockage, le nombre de requêtes, le transfert de données et les fonctionnalités de gestion. L’optimisation doit également être abordée sous l’angle de ces quatre dimensions, plutôt que de simplement migrer tous les buckets vers des classes de stockage plus froides.

Les tarifs suivants sont donnés à titre d’exemple pour us-east-1, les prix réels dépendant de la région AWS concernée : S3 Standard coûte environ $0.023/GB-month pour les 50 premiers To ; Standard-IA coûte environ $0.0125/GB-month ; Glacier Instant Retrieval environ $0.004/GB-month ; et Glacier Deep Archive environ $0.00099/GB-month. Bien que Deep Archive semble beaucoup moins cher, il impose une durée minimale de stockage, des délais de récupération et des frais de récupération. Il ne faut donc pas y migrer ses données aveuglément.

1. Identifier d’abord les sources de facturation

Il est recommandé de commencer par ventiler les coûts dans Cost Explorer par Usage type :

• TimedStorage-ByteHrs : capacité de stockage des objets.
• Requests-Tier1/Tier2 : requêtes PUT, LIST, GET, etc.
• DataTransfer-Out-Bytes : transfert vers Internet ou inter-régions.
• Monitoring-Automation, Inventory, StorageLens : fonctionnalités de gestion et d’analyse.

Une erreur courante consiste à penser que les coûts de stockage sont bas alors que les requêtes LIST/GET sont très nombreuses, ou que les accès à S3 depuis des sous-réseaux privés transitent par une NAT Gateway, ce qui fait grimper la facture réseau. L’optimisation de S3 ne doit pas se limiter à la taille du bucket.

2. Intelligent-Tiering et règles de cycle de vie

Si les patterns d’accès aux objets sont instables, S3 Intelligent-Tiering constitue un point de départ à faible risque. Il déplace automatiquement les objets entre les niveaux Frequent, Infrequent et Archive Instant. Il n’y a pas de frais de récupération entre ces niveaux automatiques, mais des frais de surveillance et d’automatisation s’appliquent, avec un prix typique de $0.0025/1,000 objects-month. Si les objets sont très petits et extrêmement nombreux, ces frais de gestion peuvent s’avérer peu rentables.

Les règles de cycle de vie conviennent aux données dont les patterns d’accès sont bien définis, comme les logs, les sauvegardes ou les échantillons d’entraînement :

{
  "Rules": [
    {
      "ID": "logs-to-glacier",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER_IR" },
        { "Days": 180, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 730 }
    }
  ]
}

Attention à la durée minimale de stockage : généralement 30 jours pour Standard-IA, 90 jours pour Glacier Instant Retrieval / Flexible Retrieval, et 180 jours pour Deep Archive. Les objets ayant un cycle de vie court ne doivent pas être archivés trop tôt.

3. Glacier IR et Deep Archive : uniquement pour les données « réellement froides »

Glacier Instant Retrieval convient aux archives « peu fréquentes mais nécessitant un accès en quelques millisecondes », comme les audits de conformité ou les rapports historiques. Deep Archive convient aux données qui ne seront presque jamais lues et pour lesquelles on peut attendre plusieurs heures pour la récupération, comme les sauvegardes sur plusieurs années.

Le critère de décision peut être très simple : si un objet a une forte probabilité de ne pas être lu dans les 6 prochains mois, alors Deep Archive mérite d’être envisagé. Si les équipes métier ne peuvent pas tolérer les délais de récupération, ne forcez pas la migration simplement pour embellir la facture.

4. Nettoyage des anciennes versions et des Multipart Uploads incomplets

Lorsque le Versioning est activé, la suppression d’un objet ne fait que créer un delete marker, et les anciennes versions continuent d’être facturées. Les « coûts fantômes » de nombreux buckets proviennent de ces versions historiques.

Il est possible de lister d’abord les versions :

aws s3api list-object-versions --bucket my-bucket --prefix app/

Puis d’utiliser le cycle de vie pour nettoyer les versions non actuelles :

{
  "Rules": [
    {
      "ID": "expire-old-versions",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

AbortIncompleteMultipartUpload est souvent négligé. Après l’échec du chargement d’un fichier volumineux, les fragments peuvent rester stockés indéfiniment dans S3 et continuer à être facturés.

5. Optimisation des requêtes : LIST est plus cher que vous ne le pensez

Dans S3 Standard, le tarif habituel des requêtes de type PUT/COPY/POST/LIST est d’environ $0.005/1,000 requests, tandis que les requêtes GET coûtent environ $0.0004/1,000 requests. Le prix unitaire semble bas, mais lorsque le nombre d’objets atteint des centaines de millions, les requêtes LIST par balayage deviennent très coûteuses et ralentissent le système.

Conseils pratiques :

• Éviter d’utiliser ListObjectsV2 comme une requête de base de données.
• Concevoir la clé d’objet en y incluant la date, le locataire ou des préfixes métier afin de réduire les balayages inutiles.
• Utiliser S3 Inventory pour remplacer les requêtes LIST complètes.
• Fusionner ou mettre en cache les petits objets fréquemment accédés afin de réduire les vagues de requêtes GET.

6. Utiliser un VPC Endpoint pour éviter le détour par la NAT Gateway

Lorsque des instances EC2, ECS ou des fonctions Lambda dans un sous-réseau privé accèdent à S3, si le routage passe par une NAT Gateway, des frais de traitement de données NAT sont générés. Dans us-east-1, le tarif classique d’une NAT Gateway est d’environ $0.045/hour plus $0.045/GB processed. Pour 1TB/mois, les seuls frais de traitement NAT s’élèvent déjà à environ $45.

Pour accéder à S3 et DynamoDB, configurez en priorité un Gateway VPC Endpoint :

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxx \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-xxxx \
  --vpc-endpoint-type Gateway

Le Gateway Endpoint lui-même ne facture généralement pas de frais horaires et réduit le trafic transitant par la NAT. Après modification, il convient de vérifier la table de routage (route table) et de s’assurer que la liste de préfixes S3 (S3 prefix list) pointe bien vers l’endpoint.

7. Compression : compression côté applicatif vs passerelle transparente

La compression est l’optimisation de capacité la plus directe, mais tout dépend du type de données. Les formats Parquet, ORC, les logs compressés avec gzip, les images et les vidéos sont généralement déjà compressés, le gain est donc limité. En revanche, le JSON, le CSV, les logs textuels, les objets non compressés et certains fichiers de sauvegarde peuvent offrir des gains significatifs.

L’avantage de la compression côté applicatif est sa simplicité d’architecture sans passerelle supplémentaire ; l’inconvénient est qu’elle nécessite de modifier le code, de gérer la compatibilité et de migrer les données historiques. Une autre approche consiste à utiliser une passerelle de compression transparente : l’application continue d’utiliser l’API S3, mais son client pointe vers la passerelle, qui se charge de compresser les données avant de les écrire dans S3.

S4 (Squished S3) appartient à cette seconde catégorie. Il s’agit d’une AMI EC2 intégrant le codec GPU NVIDIA nvCOMP, fonctionnant sur des instances GPU telles que g4dn/g5/g6. Une fois le client S3 redirigé vers cette passerelle transparente, l’espace de stockage occupé dans S3 pour les données compressibles est généralement réduit de 50% à 80%, sans aucune modification du code applicatif. Cette solution ne convient pas à tous les scénarios : si les données sont déjà compressées, si les objets sont très petits ou si les requêtes sont extrêmement nombreuses mais que la capacité globale reste faible, les gains peuvent être minimes. Les scénarios idéaux pour une évaluation sont ceux où S3 héberge de grands volumes de données textuelles ou semi-structurées, où le coût de stockage est le problème majeur, et où l’on souhaite éviter de modifier l’application.

Il est possible d’utiliser d’abord l’outil d’estimation des coûts S4 pour obtenir une estimation rapide ; il ne requiert pas l’importation de vos fichiers CSV de facturation et peut être testé avec des données d’exemple.

Enfin : mesurer d’abord, modifier la stratégie ensuite

Ordre de mise en œuvre recommandé :

1. Utiliser Cost Explorer pour identifier le type d’usage (usage type) principal de S3.
2. Utiliser S3 Storage Lens pour analyser la répartition des buckets, des préfixes (prefix), des versions et des tailles d’objets.
3. Commencer par nettoyer les versions et les multipart uploads incomplets.
4. Appliquer ensuite les règles de cycle de vie, configurer les VPC Endpoints et optimiser les requêtes.
5. Évaluer enfin la compression ou des architectures alternatives.

La réduction des coûts S3 ne se résume pas à « tout archiver au froid ». Une démarche réellement efficace consiste à analyser conjointement les patterns d’accès aux données, la taille des objets, les chemins d’accès des requêtes et la durée de rétention.

Divulgation : L’auteur de cet article fait partie de l’équipe de abyo software (développeur de S4, une solution d’optimisation des coûts disponible sur AWS Marketplace).