11 commentaires
salut
1.2 milliard d'objets pour 2.5To ça fait des objets super petits. s3 te facture par requête (get put list delete) et par volume de stockage. les objets petits sont plus coûteux en requêtes. et si tu es en STANDARD c'est le plus cher pour les accès fréquents. tu devrais voir si tu peux archiver en IA ou Glacier pour les objets moins accédés
oui on a pas mal de petits objets c'est clair. mais on doit les accéder régulièrement pendant les 30-60 premiers jours. après c'est plus rare. l'archivage c'est une piste. mais ça explique pas tout le coût de dingue
t'as le versioning d'activé sur ton bucket ? si oui chaque modification d'un objet crée une nouvelle version et s3 te facture pour toutes les versions stockées. si tes lambdas écrivent beaucoup sur les mêmes objets ça peut faire exploser le coût de stockage sans que la taille "logique" augmente tant que ça
et le data transfer out ? si tes users ou tes services accèdent aux objets s3 depuis l'extérieur d'aws ou d'une autre région ça coûte cher en egress. regarde les metrics cloudwatch pour bytesdownloaded et bytesuploaded et filtre par region et apiname
t'as pas de replication cross-region d'activée sur le bucket ? ça double le stockage et les coûts de transfert. et les s3 lifecycle rules tu les as bien configurées pour passer les vieux objets en IA ou les supprimer ? sinon tu paies des objets que personne ne lit
ha le versioning... j'avais pas pensé. oui il est activé. et nos lambdas font pas mal d'updates d'objets existants pour ajouter des métadonnées. ça doit être ça une grosse partie du problème. pour la réplication non j'ai pas ça. les lifecycle rules sont en place mais ptete pas assez agressives
si le versioning est actif et que tu update beaucoup le même objet ça coûte cher. tu peux aussi configurer une lifecycle rule pour purger les anciennes versions d'objets après x jours ou x versions. ça réduira drastiquement le coût de stockage lié au versioning
et même si tu as beaucoup de petits objets qui sont accédés souvent les 30-60 premiers jours tu pourrais potentiellement les passer en intelligent-tiering. s3 s'occupe de bouger les objets entre standard et ia en fonction des patterns d'accès. ça peut faire des économies substantielles sans effort
ok le versioning c'est clair c'est une piste chaude. j'ai vu des objets avec 200 versions ! je vais mettre une lifecycle rule pour ça. et intelligent-tiering c'est une super idée pour les objets récents. pour les list requests je vais investiguer aussi
alors verdict : le versioning était bien le coupable numéro 1. j'ai mis une règle de cycle de vie pour ne garder que les 5 dernières versions après 30 jours et ça a déjà coupé la facture de moitié. en plus j'ai activé intelligent-tiering pour les nouveaux objets. les coûts de list étaient aussi un peu élevés mais moins critiques. merci à tous pour les excellents tips !
Laisser une réponse
Vous devez être connecté pour poster un message !
hello la commu finops
on a mis en place une infra serverless complète avec des lambdas qui génèrent pas mal de data stockée sur s3. ça tourne depuis quelques mois et les coûts s3 sont juste incroyables genre 5k$ par mois. on stocke que des petits fichiers json et images. j'ai vérifié les metrics et on a quelques To stockés mais ça justifie pas un tel coût. des idées de ce qui pourrait plomber le budget s3 ?