optimisation couts eks gros cluster y a des economies a faire

le plus gros levier souvent c'est le redimensionnement des pods et des nodes. utilise kube-cost ou goldilocks pour analyser les request/limit et voir où tu peux réduire. beaucoup de gens sur-provisionnent le cpu et la ram "au cas où"

vertical pod autoscaler (vpa) est pas mal pour les requests/limits mais faut faire gaffe en prod. sinon pour les nodes cluster autoscaler avec des groupes de noeuds variés (spot on-demand arm x86) ça aide. et karpenter c'est la Rolls pour l'optim auto des nodes

regarde aussi les ebs volumes si t'as des gp2 qui traînent passe en gp3 c'est moins cher pour les mêmes perfs de base. et vire les volumes non attachés ou super vieux. ça paraît con mais ça s'accumule vite

ouais vpa j'ai un peu peur mais faut que je me penche dessus. karpenter on l'a pas encore on est sur cluster autoscaler standard. les volumes ebs j'ai déjà un peu nettoyé mais je peux faire un audit plus poussé. bonne idée gp3

si t'as des bases de données rds check les types d'instances. on-demand vs reserved vs savings plans. et regarde si t'as pas des vieux snapshots qui dorment. aussi les logs cloudwatch si tu les gardes trop longtemps ça coûte. faut une bonne rétention policy

pour les workloads batch tu peux les basculer sur fargate si le profiling le permet. pas de nodes à gérer tu paies juste la conso des pods. ou si c'est vraiment des jobs court tu les fais tourner sur lambdas ou step functions

pense au network egress. si tes pods ou tes services envoient beaucoup de données vers internet ou entre régions différentes ça monte très vite. utilise un vpc endpoint si c'est vers un service aws pour rester dans le réseau aws

ok plein de bonnes pistes là. je vais prioriser le redimensionnement des pods avec goldilocks voir ce que ça donne. et audit des snapshots/logs et le passage en gp3. fargate c'est intéressant pour le batch faudra creuser. merci à tous pour l'aide ça va bien m'aider à justifier mon budget !