Si vos coûts S3 ont grimpé sans explication apparente, la fonctionnalité Versioning de votre bucket S3 a peut-être été activée. Pas d'inquiétude : vous pouvez la maîtriser et reprendre la main sur votre bucket S3 ainsi que sur les coûts liés au versioning. Cet article apporte un éclairage précieux sur les coûts associés à un bucket S3 versionné et sur la façon de les piloter efficacement. Avec ces clés en main, vous pourrez optimiser votre bucket S3 et ne payer que le stockage réellement utile.
S3 Versioning est une fonctionnalité utile qui permet de conserver plusieurs versions d'un même objet dans un seul bucket. Vous gardez ainsi toujours accès aux versions antérieures des objets supprimés ou écrasés par accident. Avec S3 Versioning, vous pouvez stocker plusieurs versions d'un objet dans un même bucket et restaurer celle dont vous avez besoin.
Par exemple, si vous activez S3 Versioning sur un bucket, tout objet supprimé ne disparaîtra pas définitivement. Amazon S3 insère à la place un marqueur de suppression (delete marker), qui devient la version actuelle de l'objet. Vous pouvez alors restaurer la version précédente si nécessaire.
De même, si vous écrasez un objet, Amazon S3 ajoute une nouvelle version de cet objet dans le bucket. La version précédente reste dans le bucket et devient une version non actuelle (noncurrent). Vous pouvez la restaurer à tout moment. Pour aller plus loin, consultez la documentation sur la suppression des versions d'objets dans un bucket avec versioning activé.
L'activation du Versioning sur un bucket S3 peut intervenir pour différentes raisons, mais une chose est essentielle à retenir : une fois activé, il ne peut plus être désactivé. Vous pouvez toutefois le suspendre et mettre en place une gestion durable du versioning de votre bucket S3. Ne laissez pas des coûts S3 imprévus vous freiner. Vous pouvez reprendre la main sur votre bucket S3 et gérer vos coûts de versioning plus efficacement.
Si vous gérez plusieurs buckets contenant des millions d'objets, la situation peut vite paraître ingérable et il devient nécessaire d'avoir une vue claire de l'existant. AWS met à disposition Storage Lens, qui vous indique quels buckets contiennent des objets versionnés, en quelle quantité, et quel pourcentage de vos objets sont noncurrent. Il vous montre également la classe de stockage des objets noncurrent. Pour en savoir plus, reportez-vous à l'article suivant sur l'utilisation d'AWS Storage Lens.
Ces données vous aideront à comprendre rapidement vos coûts de versioning et à mieux piloter votre stockage en observant le volume occupé par les versions noncurrent et leurs classes. La tarification est identique à celle de la copie versionnée actuelle. L'exemple suivant illustre la rapidité avec laquelle les versions noncurrent peuvent s'accumuler et alourdir la facture.
Prenons un objet de 4 Gio mis à jour cinq fois par jour. Vous obtenez ainsi cinq versions noncurrent par jour et une version actuelle, soit six au total. En multipliant les cinq modifications quotidiennes par une moyenne de 30 jours, on obtient : 5 modifications par jour x 30 jours en moyenne par mois = 150 copies de versions noncurrent. Le volume monte vite, et quelle que soit la classe de stockage des objets non versionnés, c'est ce tarif qui vous est facturé.
Autre exemple : si vous avez un fichier de 1 Mo et 200 copies (versions noncurrent), vous payez pour 200 Mo de stockage.
Une fois les buckets avec Versioning activé identifiés, ainsi que les objets disposant déjà de versions noncurrent, prenez un instant pour évaluer l'utilité réelle de ces copies. Posez-vous la question : ai-je vraiment besoin de copies de cet objet ? Si la réponse est oui, demandez-vous combien de temps il faut les conserver et combien de copies sont nécessaires. Ces réponses vous permettront d'évaluer le coût de leur conservation et l'automatisation requise pour gérer les transitions des objets. Prenez donc le temps de définir ce qui correspond le mieux à vos besoins. Tous les buckets ne se valent pas.
Si le versioning n'est pas nécessaire sur un bucket, suivez la procédure ci-dessous pour le suspendre, supprimer les copies non versionnées et retirer les delete markers superflus. Vous réduirez ainsi vos coûts et obtiendrez un bucket versionné quasi désactivé.
REMARQUE : Avant de lancer la procédure ci-dessous, gardez à l'esprit qu'une fois les fichiers noncurrent supprimés, toutes les copies noncurrent de l'objet seront perdues définitivement et aucun moyen ne permettra de les récupérer. Vérifiez donc bien que vous êtes dans le bon bucket S3 et évaluez la nécessité de conserver les versions noncurrent avant toute suppression. Vous pouvez d'abord faire un essai sur un bucket de test.
- Dans la console AWS S3, recherchez le bucket dont vous souhaitez suspendre le Versioning et sélectionnez-le.
- Allez dans l'onglet Properties.
- Dans l'onglet Properties, repérez la section relative au Versioning et cliquez sur Edit.
Propriétés du bucket S3
4. Sélectionnez le bouton radio Suspend.
5. Cochez la case I acknowledge the outcomes of suspending Bucket Versioning.
6. Cliquez sur Save changes.
7. Le Versioning du bucket est désormais suspendu.
- Suspendre le Versioning empêche la création de toute nouvelle version des objets.
- Suspendre le Versioning n'a aucun impact sur les objets existants dans le bucket.
Suspendre ou activer le Versioning du bucket
L'étape suivante consiste à supprimer les versions noncurrent et les delete markers expirés. La méthode la plus courante, surtout avec des millions de fichiers, consiste à utiliser la Lifecycle Configuration. C'est l'approche que nous suivrons dans notre exemple, comme le recommande AWS, mais d'autres options existent. Voir ci-dessous pour les alternatives.
Toujours dans le bucket S3, sélectionnez l'onglet Management.
Dans la fenêtre Management, vous trouverez une section intitulée Lifecycle Rules. Cliquez sur Create lifecycle rule.
Lifecycle Rules dans S3 Management
- Dans Create lifecycle rule, renseignez les sections suivantes :
Lifecycle rule name : choisissez un nom décrivant l'action de la règle.
Par exemple DeleteNV-1days-DeleteMarker-IMU-7days. Le nom de la règle indique que les copies non versionnées seront supprimées au bout d'un jour, et les DeleteMarkers ainsi que les uploads multipart incomplets après sept jours. 2. Pour Choose a rule scope, sélectionnez le bouton radio Apply to all objects in the bucket. Une boîte s'affichera avec un message d'avertissement. Lisez-le, puis cochez I acknowledge that this rule will apply to all objects in the bucket. L'option Limit the scope of this rule using one or more filters sera abordée plus loin dans l'article. 3. Sous Lifecycle rule actions, cochez les cases Permanently delete noncurrent versions of objects et Delete expired object delete markers or incomplete multipart uploads. 4. Deux nouvelles sections apparaîtront en dessous : Permanently delete noncurrent versions of objects et Delete expired object delete markers or incomplete multipart upload. 5. Sous Permanently delete noncurrent versions of objects, dans le champ Days after objects become noncurrent, saisissez 1. La valeur doit être supérieure à zéro. Cela correspond à l'une des décisions évoquées plus haut sur la durée de conservation des objets noncurrent. Dans le champ situé à droite, Number of newer version to retain — Optional, laissez vide. Souvenez-vous de la question : combien de versions dois-je conserver ? C'est ici que vous fixez ce nombre. Le système conservera systématiquement ce nombre de copies ou de versions noncurrent. 6. Vient ensuite la section Delete expired object delete marker et Delete incomplete multipart uploads. Cochez les cases Delete expired object delete markers et Delete incomplete multipart uploads. Une nouvelle option apparaîtra, intitulée Number of days. Saisissez 7 dans le champ. C'est le délai au bout duquel les uploads multipart incomplets seront supprimés. Cela laisse à un upload multipart incomplet le temps de se terminer s'il doit reprendre.
Configuration de la règle Lifecycle
Lifecycle Rule Actions
Vous vous demandez peut-être pourquoi nous avons activé l'option de suppression des uploads multipart incomplets. C'est un levier simple et efficace de réduction des coûts, qui peut être configuré automatiquement dans la Lifecycle rule de vos buckets S3. N'oubliez pas que toute partie d'upload multipart incomplet vous est facturée selon la classe de stockage spécifiée lors du téléversement des parties. Vous pouvez là encore vous appuyer sur S3 Storage Lens pour analyser les uploads multipart incomplets. Pour aller plus loin sur les uploads multipart incomplets et leur analyse avec Storage Lens, consultez l'article suivant.
Voici quelques précisions complémentaires d'AWS au sujet de la suppression des versions noncurrent d'objets.
A versioning-enabled bucket has one current version and zero or more noncurrent versions for each object. When you delete an object, note the following:
If you don't specify a version ID in your delete request, Amazon S3 adds a delete marker instead of deleting the object. The current object version becomes noncurrent, and the delete marker becomes the current version.
If you specify a version ID in your delete request, Amazon S3 deletes the object version permanently (a delete marker is not created).
A delete marker with zero noncurrent versions is referred to as an expired object delete marker. (source).
Félicitations ! Vous avez repris la main sur un bucket S3 versionné. Selon la configuration Lifecycle retenue pour votre cas d'usage, vous devriez constater une baisse des coûts au bout d'une semaine. Notez toutefois que les Lifecycle Rules s'exécutent de manière asynchrone : la suppression des objets en version noncurrent peut donc prendre un certain temps. Rassurez-vous, AWS ne vous facturera pas les jours supplémentaires nécessaires à la finalisation du processus.
Vous pouvez à présent réactiver le versioning, puisqu'une règle Lifecycle Management gérera automatiquement les versions noncurrent. Vous pouvez aussi le maintenir suspendu si vous ne souhaitez pas conserver de versions des objets. À noter : tout nouvel objet déposé dans le bucket S3 pendant que le versioning est suspendu portera un identifiant null et ne sera pas éligible au versioning.
Il arrive parfois que le versioning soit nécessaire sur un bucket S3, mais avec un Lifecycle Management appliqué uniquement à certains objets. Lifecycle Management permet d'appliquer la règle à des préfixes spécifiques. Cette option s'appelle Limit the scope of this rule using one or more filters. Grâce aux filtres, vous décidez quels objets noncurrent sont concernés par la suppression. Vous pouvez aussi exploiter cette fonctionnalité pour appliquer différentes Lifecycle rules à différents objets.
Vous pouvez filtrer en fonction de l'emplacement des objets. Par exemple, si vos fichiers se trouvent dans un dossier logs, définissez le filtre logs/. La Lifecycle rule s'appliquera alors à logs/log.txt, logs/temp3.txt et logs/test1.txt. Elle ne s'appliquera pas à un objet situé à la racine, comme example.jpg. Vous pouvez aussi filtrer par extension de fichier, par tag ou par taille des objets. Consultez l'article suivant pour plus d'informations sur le filtrage et différents exemples.
Vous disposez désormais des connaissances nécessaires pour maîtriser les coûts S3 liés aux versions noncurrent des objets. Il reste recommandé de tester toute modification dans un environnement de test ou de développement avant un passage en production.
Ressources :
- Amazon S3 cost optimization for predictable and dynamic access patterns.
- Optimize storage costs with new Amazon S3 Lifecycle filters and actions.
- Examples of S3 Lifecycle Configuration.
- How can I reduce unexpected high costs for Amazon S3?
- Deleting object versions from a versioning-enabled bucket.
- Assessing your storage activity and usage with Amazon S3 Storage Lens.
- Options to delete millions of objects from a versioning-enabled AWS S3 bucket