9 commentaires
hello. classique. le plus simple c'est de mettre en place des schedulers. soit des fonctions lambda qui s'activent la nuit et le week-end pour stopper ou faire passer les instances en t3a.nano. soit un outil comme cloud custodian ou un custom script.
absolument. tes scripts ou lambdas doivent filtrer sur ce tag. tu peux même ajouter un tag
auto-shutdown:true ou schedule:9to5 pour plus de granularité. ça donne du contrôle aux équipes si elles veulent qu'un env particulier tourne H24 temporairement.
pense aussi aux snapshots. si tu stoppes des rds ou ec2, tu dois quand même garder les disques. mais les snapshots peuvent être moins chers que les volumes eux-mêmes si tu les gardes longtemps. faut juste relancer avec la bonne taille et type de disque.
pour les ressources qui sont pas des instances genre des load balancers ou des ip élastiques, faut faire attention. certains load balancers ont un coût même s'il y a pas de trafic. les ip élastiques non utilisées aussi. si c'est pas attaché à une instance et que c'est pas nécessaire, faut les virer.
faut aussi communiquer ça aux devs. si tu éteins tout d'un coup ils vont pas être contents. explique les bénéfices et comment ils peuvent override temporairement le shutdown si besoin. la culture finops c aussi important que la tech.
Laisser une réponse
Vous devez être connecté pour poster un message !
yop la team ! j'ai fait le reporting mensuel des coûts cloud et nos environnements de dev sont une catastrophe. les devs oublient de les éteindre et ça tourne H24 pour rien. on paye une blinde pour des instances rds ec2 s3 qui sont pas utilisées la nuit ou le week-end. il faut qu'on trouve un moyen d'optimiser ça ASAP.