nos env de dev bouffent le budget à cause des inactifs

Posté par cecile24 le 25/06/2024
RÉSOLU

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.

Commentaires

anais-rodrigues

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.

gerard03

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.

cecile24

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.

anais-rodrigues

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.

kpotier

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.

gerard03

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.

cecile24

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.

anais-rodrigues

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.

cecile24

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 !

Laisser une réponse

Vous devez être connecté pour poster un message !

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire