4 commentaires
hello sur glacier deep archive l'explosion des coûts c'est souvent les frais de retrieval et les minimum storage durations si tu supprimes des objets avant 180 jours t'es facturé comme s'ils étaient restés 180 jours. regarde dans les cloudwatch metrics pour s3 les métriques NumberOfObjectsDeleted et surtout les BytesDownloaded par classe de stockage
exactement et aussi les list requests sur des buckets avec des millions d'objets ça peut aussi coûter cher sur s3 même si c'est pour glacier si ton processus d'archivage liste le contenu du bucket trop souvent pour vérifier des choses avant d'envoyer ça peut être une source de coûts pas évidente
et une autre chose les lifecycle policies si par mégarde t'en as une qui déplace des objets de deep archive vers une autre classe de stockage plus chère ou qui déclenche des restaurations non voulues ça peut être catastrophique vérifie bien que tout est comme prévu
vous avez raison c'était un mix de retrieval fees et de list requests le dev a fait un script pour lister et vérifier l'existence de chaque objet avant de le pousser dans le bucket ce qui a généré des millions de list requests et il y avait une petite partie de retrieval non optimisée. on va refaire le script pour optimiser ça. merci les gars pour le coup de main c'est chaud le finops des fois
Laisser une réponse
Vous devez être connecté pour poster un message !
yo la team j'ai une alerte
finopsmajeure les coûtss3 glacier deep archiveont explosé ce mois-ci on a un processus qui archive deslogset des backups mais ça devrait être stable comment ça se fait qu'on paye autant pour dudeep archiveon est censé ne payer que pour la rétention pas pour les accès réguliers