9 commentaires
c'est classique faut commencer par le basique instance ec2 les tailles sont-elles justifiées ? utilisation cpu/mem des instances ? tu peux downsize beaucoup sans impact perf. et les dev/staging faut les éteindre la nuit et le week-end avec des lambdas ou instance scheduler
pour rds regarde les performances iops et cpu. souvent on prend des instances trop grosses surtout pour les bases de dev/staging qui ont pas besoin de la même perf qu'en prod. et les s3 regarde si t'as pas des buckets avec des objets pas accédés depuis longtemps qui pourraient passer en glacier ou infrequency access
on a des gros monolithes donc les tailles ec2 sont difficiles à réduire. on est en train de migrer vers du microservices mais c'est long. l'idée d'éteindre les env de dev c'est pas bête mais faudrait qu'on automatise ça. on a des rds en provisioned iops pour la prod mais c'est vrai que pour la dev on pourrait être plus légers
le data transfer c'est souvent les egress. si tu sors beaucoup de données d'aws vers l'extérieur ou entre régions ça coûte cher. vois si tu peux pas garder les données dans la même région ou az si possible
pour ec2 et rds si t'as une charge stable envisage les savings plans ou reserved instances ça réduit beaucoup les coûts. faut s'engager sur 1 ou 3 ans mais ça vaut le coup si ton infra est pérenne
et tagger tagger tagger. c'est la base. par service par équipe par environnement. ça permet de savoir où part l'argent et de responsabiliser les équipes. utilise des policies aws pour forcer le tagging
Laisser une réponse
Vous devez être connecté pour poster un message !
hello la team ! nos factures aws sont hors de contrôle on a l'impression de jeter de l'argent par les fenêtres. on a des instances ec2 des rds s3 des services managés partout. l'infra grossit vite et on arrive plus à suivre
on a essayé de tagger un peu mais c'est pas très bien suivi. on a des environnements de dev/staging qui tournent h24. y'a des outils magiques ou des méthodologies pour s'en sortir ?