Optimisation des coûts S3 : Automatiser vos économies avec AWS CDK et les lifecycle policies

Amazon S3 est souvent le service AWS le plus sous-estimé en matière d’optimisation des coûts. Pourtant, dans la majorité des comptes AWS que nous auditons chez Unicorne, le stockage S3 représente un gisement d’économies immédiates et sans risque. Versions d’objets non courants accumulées depuis des années, fragments d’uploads multipart abandonnés, données jamais migrées vers des classes de stockage économiques, ces coûts invisibles s’additionnent silencieusement, mois après mois.

Selon les observations de la communauté FinOps, les organisations qui adoptent une discipline d’optimisation cloud réalisent typiquement entre 25 et 40 % d’économies annuelles sur leurs factures. Sur S3 spécifiquement, les lifecycle policies sont le levier le plus accessible : elles ne touchent pas aux données de production, s’implémentent en quelques lignes de code, et préviennent l’accumulation future de coûts inutiles.

Dans cet article, nous allons explorer les principales sources de gaspillage sur S3, comment les identifier avec Storage Lens, et surtout comment les éliminer de façon systématique en codifiant vos politiques avec AWS CDK, l’approche Infrastructure as Code qui garantit reproductibilité et gouvernance.

Identifier les sources de gaspillage avec S3 Storage Lens

Avant d’optimiser, il faut mesurer. Amazon S3 Storage Lens offre gratuitement (pour les métriques de base) une vue consolidée de votre utilisation S3 à l’échelle d’un compte ou d’une organisation entière. Deux métriques méritent une attention immédiate.

Les Noncurrent Object Version révèlent le volume de stockage consommé par les anciennes versions de vos objets. Lorsque le versioning est activé sur un bucket, ce qui est recommandé pour les données de production, S3 conserve chaque version de chaque fichier jamais uploadé. Un bucket de 100 Go de données actives peut facilement accumuler 500 Go ou plus de versions non courantes si aucune politique d’expiration n’est en place. Le coût est identique : 0,023 $/Go/mois en S3 Standard (région us-east-1).

Les Incomplete Multipart Uploads représentent des fragments d’uploads qui n’ont jamais abouti. Interruptions réseau, crashs applicatifs, scripts de test oubliés, ces orphelins servent zéro utilité et S3 continue de les facturer. C’est du gaspillage pur.

Pour activer Storage Lens, rendez-vous dans la console S3, créez un dashboard en sélectionnant votre compte (ou votre organisation AWS), et conservez les métriques gratuites. Après 24 à 48 heures, concentrez-vous sur les buckets affichant un ratio élevé de versions non courantes par rapport au stockage total (au-delà de 30 %, c’est un signal fort) et tout volume non nul d’uploads multipart incomplets.

Codifier le nettoyage des versions non courantes avec CDK

L’approche Infrastructure as Code avec AWS CDK permet de déployer des lifecycle policies de façon standardisée, testable et versionable. Voici comment implémenter l’expiration des versions non courantes.

Pour un nouveau bucket avec versioning activé :

import * as s3 from ‘aws-cdk-lib/aws-s3’;

import * as cdk from ‘aws-cdk-lib’;

const bucket = new s3.Bucket(this, ‘DataBucket’, {

  versioned: true,

  lifecycleRules: [{

    noncurrentVersionExpiration: cdk.Duration.days(90),

    noncurrentVersionsToRetain: 3,

  }],

});

Cette configuration conserve les 3 dernières versions non courantes comme filet de sécurité, puis supprime automatiquement toute version plus ancienne que 90 jours. C’est un bon point de départ pour les buckets de production où vous souhaitez maintenir une capacité de rollback raisonnable.

Pour les buckets de développement ou de CI/CD où les versions historiques ont peu de valeur, vous pouvez être plus agressif :

lifecycleRules: [{

  noncurrentVersionExpiration: cdk.Duration.days(7),

  noncurrentVersionsToRetain: 1,

}],

L’avantage majeur de cette approche : la politique est codifiée dans votre repository, révisée en pull request, et appliquée uniformément à travers vos environnements. Plus de configuration manuelle oubliée dans la console.

Éliminer les uploads multipart abandonnés

Les uploads multipart incomplets sont le cas le plus simple : il n’existe pratiquement aucune raison de les conserver au-delà de quelques jours. Un upload légitime en cours devrait se compléter en quelques heures, pas en semaines.

const bucket = new s3.Bucket(this, ‘UploadBucket’, {

  lifecycleRules: [{

    abortIncompleteMultipartUploadAfter: cdk.Duration.days(7),

  }],

});

Sept jours est une valeur conservatrice qui convient à la majorité des cas. Pour les environnements où vos uploads sont prévisibles et rapides, 1 à 3 jours suffisent. Cette seule règle peut éliminer des gigaoctets de stockage fantôme sur des comptes qui n’ont jamais eu cette politique en place.

Bonnes pratiques de déploiement et pièges à éviter

Avant de déployer ces politiques à grande échelle, quelques recommandations essentielles.

Commencez par 2 ou 3 buckets non critiques comme pilote. Monitorer les résultats dans Storage Lens pendant une à deux semaines pour valider que le comportement correspond à vos attentes. Ne sur-optimisez pas les données de production : un stockage S3 Standard à 0,023 $/Go/mois reste relativement peu coûteux. L’effort d’optimisation doit être proportionnel aux économies réalisées.

Documentez vos politiques de rétention standard et communiquez-les aux équipes. Prévoyez un mécanisme d’exception (par exemple via des tags S3) pour les buckets ayant des exigences de conformité spécifiques. La conformité réglementaire prime toujours sur l’optimisation des coûts.

Enfin, mesurez l’impact. Après déploiement, suivez l’évolution dans Storage Lens et dans AWS Cost Explorer. Les résultats sur les uploads multipart sont souvent immédiats, tandis que la réduction des versions non courantes se manifeste progressivement au fil des jours.

Conclusion

L’optimisation des coûts S3 par les lifecycle policies représente ce que la communauté FinOps appelle des « quick wins » : un effort minimal pour un impact mesurable, sans risque pour vos données de production. En codifiant ces politiques avec AWS CDK, vous transformez une optimisation ponctuelle en gouvernance permanente, chaque nouveau bucket hérite automatiquement des bonnes pratiques.

Le vrai défi, cependant, dépasse les lifecycle policies. L’optimisation avancée, analyse des patterns d’accès pour le tiering intelligent, optimisation des coûts de requêtes et de transfert de données, stratégies de réplication cross-région, nécessite une compréhension approfondie de vos workloads et de l’écosystème tarifaire AWS. C’est dans cette complexité que l’expertise fait la différence entre des économies superficielles et une optimisation structurelle de votre facture cloud.

Chez Unicorne, nous accompagnons les entreprises dans cette démarche complète d’optimisation des coûts AWS, de l’audit initial avec Storage Lens jusqu’à l’implémentation automatisée avec Infrastructure as Code. Parce que chaque dollar économisé sur le stockage est un dollar réinvesti dans l’innovation.

Pour en savoir plus :

AWS Documentation — S3 Lifecycle Configuration : https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html

AWS CDK API Reference — S3 LifecycleRule : https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3.LifecycleRule.html

AWS Documentation — S3 Storage Lens : https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens.html

AWS S3 Pricing — Tarification par classe de stockage : https://aws.amazon.com/s3/pricing/

FinOps Foundation — Framework et principes FinOps : https://www.finops.org/framework/