4 commentaires
pour les lambdas, regarde le nombre d'invocations et la durée moyenne d'exécution dans cloudwatch. un bug dans ton code ou une config de trigger peut faire spawner des milliers d'invocations inutiles. et la mémoire allouée. baisser la mémoire quand c'est pas nécessaire réduit les coûts aussi
pour rds, c'est souvent la taille de l'instance ou le stockage qui coûte cher. t'aurais pas scale up l'instance sans faire gaffe ? et les iops provisionnées si tu en utilises. des fois les gens over-provisionnent pour des petites db. et les dev/test env, ils tournent 24/7 ? tu peux les éteindre la nuit/week-end avec des scripts
ok alors pour lambda c'était un mauvais réglage de rétention de logs cloudwatch sur une fonction critique qui générait des millions d'événements, ce qui en cascade ré-exécutait les lambdas en boucle. et pour rds on a un dev qui a activé des iops provisionnées de fou (genre 100k) pour un petit env de test sans s'en rendre compte et c'est resté actif pendant un mois. j'ai corrigé tout ça. le budget devrait revenir à la normale. merci pour les pistes qui m'ont mis sur la voie !
Laisser une réponse
Vous devez être connecté pour poster un message !
bordel j'ai reçu le rapport de dépenses aws du mois et on a fait +30% sur notre facture ! le coût de nos lambdas et d'une rds postgres a explosé sans raison apparente. on a pas eu de pic de trafic. je sais pas par où commencer pour comprendre et couper les coûts rapidement