4 commentaires
quand les api requests montent et que le stockage non c'est souvent un problème d'accès fréquent à des objets glacier ou des transitions en masse tu as des process qui listent souvent le bucket ou accèdent à des objets archivés ? les retrieval fees de glacier sont chères
t'as pas une nouvelle appli ou un script qui fait des HEAD ou GET sur des millions d'objets sans le vouloir un scan de sécurité ou un outil de monitoring mal configuré ça peut générer des millions de requêtes en peu de temps
vérifie tes lifecycle rules encore une fois des fois une règle mal configurée ou un changement de préfixe fait que des objets sont archivés puis immédiatement restaurés ce qui génère des coûts de transfert et de récupération massifs
// exemple de règle
{
"Rules": [
{
"ID": "MoveToGlacier",
"Filter": {
"Prefix": "logs/"
},
"Status": "Enabled",
"Transitions": [
{
"Days": 30,
"StorageClass": "GLACIER"
}
]
}
]
}
c'était bien un script ! une nouvelle feature de monitoring qui listait le bucket complet chaque heure pour vérifier l'intégrité des archives sauf qu'il accédait aussi aux metadata des objets glacier. des millions de get object acl et HEAD Object en plus. j'ai désactivé le script et les coûts se stabilisent. merci les gars
Laisser une réponse
Vous devez être connecté pour poster un message !
salut la team on a une hausse de dingue des coûts s3 sur un bucket de logs on est passé de genre 50$ à 500$ ce mois-ci sans que le volume de logs ait explosé on utilise des
lifecycle rulespour passer englacieraprès 30 joursj'ai regardé les métriques cloudwatch le stockage est stable mais les
api requestsont monté en flèche et lesdata retrievalsaussi