8 commentaires
Salut ! le truc classique c'est les backups. la rétention des snapshots automatiques ? quelqu'un a pu l'augmenter massivement ? ou des snapshots manuels non supprimés ? le stockage backup coûte cher sur RDS
autre piste les read replicas. y'en a pas un qui aurait été créé par erreur ou qui aurait scalé automatiquement ? ou si t'es en multi-AZ vérifie que la config est toujours bonne parce qu'une perte d'AZ peut parfois faire des trucs bizarres de failover qui augmentent les coûts temporairement
et les IOPS ? si t'es en gp2 t'as un burstable credit. si l'activité I/O a soudainement augmenté même sans explosion CPU ça peut te faire payer de l'over-provisioning ou du burst qui est cher. regarde les métriques BurstBalance et DiskQueueDepth
regarde bien le détail dans Cost Explorer par ressource. des fois c'est un truc con genre une instance db.m5.large qui est passée en db.m5.xlarge suite à une manip ou un script d'autoscaling mal configuré. même si t'as pas vu de changelog ça arrive
et si t'as plusieurs environnements vérifie les tags. des fois des ressources de dev ou staging se retrouvent non taguées et se cachent dans le budget global. utilise aws-nuke --no-dry-run pour rigoler un coup
bon c'était un peu tout ce que vous avez dit. en fait quelqu'un a augmenté la rétention des backups automatiques à 30 jours au lieu de 7 "juste au cas où". et une instance de dev non taguée était restée en db.r5.large au lieu d'une petite db.t3.micro et avait pas été supprimée. cumulé ça a fait le double. merci pour les pistes !
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut la team j'ai une mauvaise surprise ce mois-ci nos coûts RDS ont doublé sans qu'on ait fait de changements majeurs sur l'infra ou que la charge applicative ait explosé. on est sur du PostgreSQL en
db.m5.large. j'ai checké les métriques cloudwatch CPU RAM network tout est stable. quelqu'un a déjà vu ça ?