9 commentaires
pour les GET, si c'est du contenu public ou semi-public, t'as un CDN type cloudfront devant ? ca réduit drastiquement les requêtes directes à s3 et les transferts de données. le caching est ton ami
les GET c'est surtout nos utilisateurs qui downloadent des assets. les PUT c'est le cdn qu'on utilise pour uploader les images créées par les users. on a déjà un cdn mais pas cloudfront
pour les puts du cdn, assure-toi que ton cdn ne fait pas des puts inutiles ou multiples. sinon pour les objets qui sont accédés souvent au début et peu après, regarde s3 intelligent-tiering. ça bouge les objets entre les classes de stockage pour toi en fonction du pattern d'accès
le cdn fait les puts directement. intelligent-tiering ca a l'air pas mal, on a pas mal de données qui sont chaudes au début puis deviennent froides très vite. on les laisse en standard IA pour l'instant
intelligent-tiering est parfait pour ce genre de pattern. ça t'évite de gérer les lifecycle policies toi-même et ça optimise les coûts de stockage et de récupération. par contre ça ne réduit pas les coûts de PUT/GET initiaux, juste le coût de stockage sur le long terme
aussi revois la taille de tes objets. si tu as des millions de tout petits fichiers, chaque PUT/GET a un coût fixe par requête. des fois regrouper des petits fichiers en archives ou objets plus grands peut réduire le nombre total de requêtes
ok donc cloudfront pour les GETs utilisateurs ça c'est prioritaire. intelligent-tiering pour gérer le cycle de vie des données. je vais regarder les logs détaillés pour les PUTs du CDN. merci pour toutes les pistes les gars !
Laisser une réponse
Vous devez être connecté pour poster un message !
hello la commu. on a des couts s3 qui explosent un peu ces derniers temps. j'ai regardé les métriques, c'est principalement les requêtes PUT et GET qui coûtent un bras. on a beaucoup d'objets, genre des dizaines de millions de petites images et fichiers. vous avez des techniques un peu agressives pour réduire ça ?