Membre depuis le 04/06/2024
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.
Membre depuis le 27/09/2023
oui un scheduler c'est la base. pour les rds t'as les
stop-db-instance et start-db-instance api calls. ec2 pareil. s3 c'est plus chaud si c'est du storage. si c'est pour des buckets temporaires voir des lifecycle rules pour purger les vieux objets.
Membre depuis le 14/01/2024
on a déjà des tags
env:dev partout. on pourrait l'utiliser pour cibler les ressources non ? on veut pas éteindre les staging ou prod par erreur.
Membre depuis le 04/06/2024
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.
Membre depuis le 04/06/2024
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.
Membre depuis le 27/09/2023
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.
Membre depuis le 14/01/2024
ok donc un script centralisé qui utilise les tags
env:dev et auto-shutdown:true pour éteindre les rds et ec2 la nuit. et voir pour les ip élastiques non utilisées. et les s3 on va mettre des lifecycles. ça me semble pas mal.
Membre depuis le 04/06/2024
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.
Membre depuis le 14/01/2024
oui c'est prévu la comm. et je vais leur donner la possibilité de mettre un tag
auto-shutdown:false pour des cas exceptionnels mais avec une review régulière. merci à tous pour les idées !
Vous devez être connecté pour poster un message !
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
cecile24
Membre depuis le 14/01/2024
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.