6 commentaires
audit tes bases aussi tu as ptete des tables orphelines des indexes inutiles ou des logs qui prennent bcp de place. vacuum full sur postgres peut aider à récupérer de l'espace mais ça locke la table
regarde aussi les types d'instances des fois on surdimensionne. tu peux utiliser performance insights pour voir si ta base est vraiment limitée par le cpu ou la ram ou les iops. et envisager des reserved instances pour les grosses bases stables sur 1 ou 3 ans c'est une économie massive
gp3 c'est noté je vais tester ça. pour les reserved instances on y pense mais faut voir la pérennité des projets. et oui l'audit des tables c'est un bon point on a du legacy qui traîne. merci pour les tips je vais mettre ça en place
et un truc con mais le monitoring aws cloudwatch sur les métriques rds cpu iops connexions actives etc pour identifier les périodes de sous-utilisation ou les pics anormaux tu pourrais ptete réduire l'instance size pendant les heures creuses si t'as une infra serverless derrière
ouais le monitoring on fait déjà mais pas assez en mode "finops" je vais plus creuser les stats pour le sizing. merci pour les retours
Laisser une réponse
Vous devez être connecté pour poster un message !
yo la team finops j'ai une facture aws qui fait mal sur du rds postgresql. on a 5 instances différentes dont 2 grosses en prod avec réplicas. on est en gp2 et ça commence à coûter une blinde pour le stockage et les iops. vous avez des stratégies pour réduire la note sans flinguer la perf ?