Éteindre dev et staging la nuit : comment le planifier avec AAA Sentinel et ce que vous économisez vraiment

À vingt heures, l'équipe ferme ses ordinateurs portables. Les machines de développement et de staging, elles, restent allumées toute la nuit et tout le week-end, et facturent chaque heure alors que personne ne s'en sert. C'est l'une des fuites les plus simples à colmater, car elle ne demande aucun changement d'architecture : il suffit d'arrêter et de démarrer au bon moment. Dans cet article, nous montrons comment faire avec AAA Sentinel : où trouver les candidates, comment chiffrer l'économie sans la gonfler et comment laisser l'arrêt planifié.

Le problème : des machines qui travaillent 60 heures et facturent 168

Une semaine compte 168 heures. Une équipe qui travaille du lundi au vendredi de 08:00 à 20:00 utilise ses environnements pendant 60 d'entre elles. Les 108 autres, soit 64 % de la semaine, sont des nuits et des week-ends pendant lesquels ces machines ne produisent que de la facture :

• Sur AWS, une instance EC2 arrêtée ne paie pas de calcul. Sur Azure, une VM désallouée non plus. Sur Google Cloud, une instance arrêtée cesse de payer le processeur et la mémoire.
• Ce qui reste facturé, ce sont les disques et certaines adresses IP, comme vous le verrez plus bas. C'est pourquoi l'économie réelle est inférieure à 64 % de la facture totale de l'environnement.
• Personne n'arrête des machines à la main tous les jours. Cela tient une semaine, puis on oublie : l'arrêt doit être planifié.

Ce que vous y gagnez

Planifier l'arrêt des environnements hors production apporte plus que le chiffre lui-même :

• Une économie récurrente qui ne dépend pas de la mémoire de quelqu'un.
• Aucun changement de code ni d'architecture : les machines restent les mêmes, seules leurs heures de fonctionnement changent.
• Une liste claire de ce qui relève du développement et de la production, car il faut le décider pour planifier quoi que ce soit.
• Une trace de chaque arrêt et de chaque démarrage, avec son résultat, pour savoir que le plan est respecté.

Avant de commencer : ce que vous payez même machine éteinte

Pour ne pas promettre plus que ce que vous verrez sur la facture, gardez ces points en tête :

• Les volumes EBS (et les disques managés sur Azure ou Google Cloud) restent facturés quand l'instance est arrêtée.
• AWS facture chaque adresse IPv4 publique à l'heure, y compris une Elastic IP associée à une instance arrêtée.
• Si l'instance est couverte par une Reserved Instance ou un Savings Plan, l'arrêter n'économise rien : l'engagement est payé quand même.
• L'arrêt d'une instance efface son stockage d'instance (instance store), et l'IP publique change au démarrage suivant si ce n'est pas une Elastic IP.
• Si l'instance fait partie d'un groupe Auto Scaling, le groupe peut la juger défaillante et la remplacer. Ces instances ne sont pas de bonnes candidates.

Comment AAA Sentinel s'en charge : trois briques

Le parcours complet utilise trois écrans, chacun dans son offre :

• Résultats actifs, dans toutes les offres : le scan détecte les instances à CPU très faible et celles déjà arrêtées dont les disques continuent de facturer. C'est votre liste de candidates.
• Simulateur d'économies, dans l'offre Pro : avant de toucher à quoi que ce soit, vous calculez ce que rapporterait l'arrêt nocturne de dev et staging.
• Agent IA → Automatisations, dans l'offre Business : vous créez le calendrier d'arrêt et de démarrage, la plateforme l'exécute chaque jour et le consigne dans l'historique.

Cas pratique : les environnements d'ACME

ACME est une entreprise fictive dont l'équipe de développement est à Madrid. Elle a six machines de développement et deux de staging sur AWS, en us-east-1, allumées jour et nuit. Les prix sont approximatifs, tarifs publics à la demande sous Linux :

Étape 1 : trouver les candidates dans Résultats actifs

Après le premier scan du compte, ouvrez Résultats actifs. Trois règles aident à repérer les environnements inutiles la nuit :

• « CPU sous-utilisé » : CPU moyen inférieur à 5 % sur les 7 derniers jours. Une machine de développement qui ne travaille que quelques heures par jour apparaît souvent ici.
• « Instances arrêtées avec volumes » : quelqu'un l'a déjà arrêtée à la main, mais ses disques continuent de facturer. Décidez si vous allez la réutiliser (alors planifiez-la) ou si elle est en trop (alors supprimez-la, après un snapshot si vous voulez garder les données).
• « Ressources sans tags » : la ressource a moins de deux de ces tags : Environment, Project, Owner, CostCenter ou Team. Taguer Environment=dev ou Environment=staging est ce qui permet ensuite de séparer ce qui peut être éteint de ce qui ne le peut pas.

Étape 2 : chiffrer l'économie dans le Simulateur

Dans Résumé des économies → Simulateur d'économies, choisissez le compte et activez le scénario « Éteindre Dev/Staging la nuit ». Il a deux champs :

• « Coût EC2 Dev (USD/mois) » : il est prérempli avec 40 % du coût total du compte, ce qui n'est qu'un point de départ. Remplacez-le par le coût réel de vos machines de développement et de staging ; ACME saisit 645.
• « Heures éteintes/jour » : les heures d'arrêt par jour ouvré. De 20:00 à 08:00, cela fait 12.

Le calcul complet, week-end compris

Avec un calendrier qui arrête à 20:00 et démarre à 08:00 du lundi au vendredi, les machines s'arrêtent le vendredi soir et ne redémarrent que le lundi matin. Voici les chiffres d'ACME :

• L'économie vient du calcul ; les disques coûtent autant. C'est pourquoi 64 % d'heures éteintes donnent 58 % de la facture de l'environnement.
• Si l'une de ces machines était couverte par une Reserved Instance ou un Savings Plan, il faudrait la retirer du calcul.

Étape 3 : préparer le compte pour que l'agent puisse agir

Le rôle avec lequel vous avez connecté le compte est en lecture seule et ne peut rien arrêter. Les automatisations ont besoin de deux choses de plus :

• Sur AWS, le rôle agent. Il s'installe à la dernière étape de l'assistant de connexion, « Activer l'agent autonome (optionnel) », avec le bouton « Installer le rôle agent dans AWS » : une seconde stack CloudFormation qui crée le rôle FinOpsSentinelAgent. Si vous l'avez ignorée, vous pouvez l'installer plus tard depuis Mes comptes cloud.
• Sur AWS, le tag FinOpsSentinelManaged=true sur chaque instance à planifier. Le rôle agent ne peut démarrer et arrêter que les instances portant ce tag, et il ne peut pas se l'attribuer : c'est vous qui le posez.
• Sur Azure et Google Cloud, les permissions d'écriture de la même étape de l'assistant. Sur Azure, la VM est désallouée, pas seulement arrêtée, pour ne plus payer le calcul ; sur Google Cloud, l'instance est arrêtée.

Étape 4 : créer l'automatisation

Dans Agent IA → Automatisations, cliquez sur « Nouveau calendrier ». Voici comment ACME le remplit :

• Les jours valent pour l'arrêt comme pour le démarrage. Du lundi au vendredi, l'arrêt du vendredi n'a pas de démarrage avant lundi : le week-end est couvert sans rien faire de plus.
• « Économies estimées ($/mois) » est le chiffre que vous déclarez, celui de l'étape précédente. La plateforme l'affiche sur la carte et l'additionne au total des automatisations actives ; ce n'est pas une mesure.
• Créer, suspendre ou supprimer une automatisation exige le droit d'écriture sur l'agent, qu'ont les rôles propriétaire et administrateur.

Étape 5 : vérifier qu'elle s'exécute

Une fois créée, l'automatisation apparaît « Actif » avec son horaire, son fuseau, le nombre d'instances et l'économie déclarée. Ensuite :

• La carte indique la dernière exécution et leur nombre.
• Chaque arrêt et chaque démarrage est consigné dans Agent IA → Historique, comme terminé ou en échec, avec l'erreur le cas échéant (par exemple, une instance sans le tag).
• L'interrupteur « Mettre en pause » suspend l'automatisation sans la supprimer. Attention : la pause ne rallume pas les machines ; si quelqu'un a besoin de l'environnement ce soir-là, démarrez-le à la main.
• Supprimer l'automatisation retire ses deux règles planifiées. Les machines restent dans l'état où elles étaient.

Ce qu'elle ne fait pas encore

Pour savoir à quoi vous attendre :

• Elle ne fait que démarrer et arrêter des instances : EC2 sur AWS, machines virtuelles sur Azure et instances Compute Engine sur Google Cloud. Elle ne planifie ni bases RDS, ni groupes Auto Scaling, ni nœuds Kubernetes.
• Pas de calendrier des jours fériés : l'horaire se définit par jours de la semaine.
• Chaque automatisation accepte jusqu'à 50 instances, et une organisation peut en avoir jusqu'à 200.
• Le formulaire propose cinq fuseaux : Europe/Madrid, trois fuseaux des États-Unis et UTC.
• L'économie affichée sur la carte est celle que vous déclarez, pas une mesure tirée de la facture.
• Si l'abonnement expire, les automatisations cessent de s'exécuter.

Check-list pour démarrer

Avec tout cela en place, vos environnements de développement cesseront de payer les nuits et les week-ends sans que personne ait à s'en souvenir :

• Compte connecté et scanné ; candidates passées en revue dans Résultats actifs.
• Environnements tagués Environment=dev ou Environment=staging.
• Économie chiffrée dans le Simulateur d'économies et complétée à la main avec le week-end.
• Vérifié qu'aucune candidate n'est couverte par une réservation ni dans un groupe Auto Scaling.
• Offre Business, rôle agent installé et FinOpsSentinelManaged=true sur chaque instance.
• Automatisation créée et première exécution vérifiée dans l'Historique.