Explosion des coûts RDS sans raison apparente

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`

la conso de data transfer out est à surveiller. si une app a commencé à récupérer des Giga/Terra de données depuis RDS vers un service hors de la région ou même hors d'AWS ça peut monter vite

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

si t'es sur Aurora c'est différent mais ça peut être le `backtrack window` qui a été étendu ou le stockage des logs qui a explosé pour une raison X. regarde la facturation spécifique à Aurora

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 !