Planifier l'arrêt des environnements non productifs hors des heures : le 60 %+ le plus facile sur le calcul dev et recette

Un environnement de dev utilisé 60 heures par semaine et facturé 168 paie 108 heures de rien — environ 64 % de sa ligne de calcul. La planification hors-heures est la rare mesure de coûts qui relève de l’arithmétique pure : arrêter le calcul les soirs et fins de semaine, le repartir avant l’arrivée de l’équipe, et l’économie atterrit sur la prochaine facture sans changement d’architecture. La liste des pièges est courte mais réelle : le stockage continue de facturer pendant que les instances dorment, les instances RDS arrêtées redémarrent d’elles-mêmes après sept jours, et une seule hypothèse d’IP codée en dur peut transformer le premier arrêt automatisé en surprise du lundi matin.

Ce qui se passe

Le calcul sur demande se facture à l’heure où il roule, donc les heures non roulées sont toute l’astuce. Ce qui cesse de facturer à l’arrêt : les heures d’instance EC2, les heures d’instance RDS, les tâches ECS ramenées à zéro et la capacité horaire de la plupart du calcul géré. Ce qui ne cesse pas : les volumes EBS, les Elastic IP, les heures de répartiteur de charge, les heures de NAT Gateway et les instantanés — un environnement « arrêté » facture typiquement encore 10-25 % de son tarif en marche, et c’est pourquoi la promesse honnête est 60 et quelques pour cent sur le calcul, pas 100.

Les mécanismes de planification, du plus simple au plus riche. Les groupes Auto Scaling ont des actions planifiées natives : capacité désirée et minimale à zéro le soir, retour le matin — avec prise en charge des fuseaux horaires, pour que le changement d’heure ne décale pas vos matins. EventBridge Scheduler roule des horaires de type cron qui peuvent appeler les API AWS directement (arrêt/départ EC2, arrêt RDS) ou déclencher une Lambda pour tout ce qui exige un ordre. Instance Scheduler on AWS est la solution AWS emballée : horaires pilotés par étiquettes à travers comptes et régions, rentable dès que les environnements se multiplient. Côté base de données, arrêter RDS fonctionne mais vient avec le fameux astérisque : AWS redémarre automatiquement une instance arrêtée après sept jours, donc l’automatisation doit la rattraper et la ré-arrêter. Les versions récentes d’Aurora Serverless v2 peuvent se mettre en pause à zéro capacité d’elles-mêmes, ce qui règle le même problème autrement quand la version du moteur le permet.

Quoi vérifier d’abord

• Ce qui dort vraiment. Tirez deux semaines de métriques CPU et de connexions sur dev et recette — certaines boîtes « dev » roulent des compilations nocturnes à 2 h et doivent être exclues ou contournées.
• La couverture d’étiquetage. La planification par étiquettes exige une étiquette environment fiable et une étiquette schedule; auditez avant d’automatiser.
• Les dépendances d’ordre de démarrage. Bases de données avant serveurs d’application avant travailleurs; tout ce qui a besoin de sa dépendance au démarrage exige des départs ordonnés, pas un seul cron.
• Les hypothèses d’IP statiques. Les instances sans Elastic IP reçoivent une nouvelle IP publique à chaque arrêt/départ; tout ce qui avait l’ancienne en liste blanche se brise.
• Qui travaille à des heures inhabituelles. Demandez avant de planifier — la personne qui teste depuis Vancouver à 21 h heure de l’Est se présentera autrement d’elle-même.

Comment vérifier

Confirmez que l’environnement dort vraiment avant de le planifier :

# Quelqu'un utilise-t-il la recette la nuit? CPU par heure, deux dernières semaines
aws cloudwatch get-metric-statistics --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time 2026-06-20T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 3600 --statistics Maximum

# Qu'attraperait un horaire? Tout ce qui est étiqueté pour lui
aws ec2 describe-instances \
  --filters Name=tag:environment,Values=dev,staging Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].[InstanceId,InstanceType,Tags[?Key==`Name`]|[0].Value]' \
  --output table

Créez un horaire d’ASG et vérifiez qu’il est enregistré :

# À zéro à 23 h et retour à 7 h, heure de Montréal, jours de semaine
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name staging-asg \
  --scheduled-action-name nightly-stop \
  --recurrence "0 23 * * MON-FRI" --time-zone "America/Montreal" \
  --min-size 0 --desired-capacity 0

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name staging-asg \
  --scheduled-action-name morning-start \
  --recurrence "0 7 * * MON-FRI" --time-zone "America/Montreal" \
  --min-size 2 --desired-capacity 2

aws autoscaling describe-scheduled-actions --auto-scaling-group-name staging-asg

Chemins console : EC2 > Auto Scaling groups > (groupe) > Automatic scaling > Scheduled actions, et Amazon EventBridge > Scheduler > Schedules pour les horaires d’instances autonomes et de RDS. La mécanique des actions planifiées est documentée dans la documentation EC2 Auto Scaling.

Le plan d’exécution

1. Commencez par un environnement et un essai d’une semaine. La recette, pas la boîte de dev partagée dont tout le monde a oublié qu’elle héberge le serveur de démo. Annoncez l’horaire, roulez-le une semaine, ramassez les plaintes, puis étendez.
2. Planifiez les ASG avec les actions planifiées natives. Zéro le soir, retour le matin, fuseau horaire explicite. Ça couvre l’étage applicatif sans Lambda à entretenir.
3. Couvrez les instances autonomes et RDS avec EventBridge Scheduler. Arrêt et départ par étiquettes, soit en appelant l’API directement, soit via une petite Lambda quand il faut un ordre : partir la base, attendre qu’elle soit saine, puis l’étage applicatif. N’oubliez pas le redémarrage automatique RDS aux sept jours — une passe hebdomadaire « ré-arrête tout ce qui est étiqueté arrêté » ferme ce trou.
4. Bâtissez le bouton de réveil avant qu’on le demande. Un départ en un clic — tâche de pipeline, commande de clavardage ou minuscule page interne — fait la différence entre l’adoption et la révolte. Personne n’accepte « l’environnement ouvre à 7 h ».
5. Passez à Instance Scheduler on AWS à l’échelle de la flotte. Quand les horaires traversent comptes et régions, le modèle d’étiquettes de la solution emballée bat un dossier de crons maison.
6. Taillez ce qui dort mais facture encore. Une fois l’environnement arrêté chaque nuit, réduisez son résidu toujours actif : NAT Gateway dans un VPC de dev, EBS surdimensionné sur des boîtes arrêtées, répartiteurs inactifs — la même chasse que la liste des ressources inutilisées.

Quand c’est le mauvais choix

La production est hors de portée, évidemment — mais aussi tout ce qui est dans le chemin de conformité que les auditeurs s’attendent à voir surveillé en continu, et tout environnement qui héberge des tests d’intégration longs qui traversent la frontière d’arrêt. Les équipes réparties sur plusieurs fuseaux peuvent rétrécir la fenêtre jusqu’à l’inutilité : si le dev sert 16 heures par jour, l’économie ne justifie peut-être pas la friction opérationnelle. Et les environnements en voie de démantèlement doivent être supprimés, pas planifiés — le sommeil ne remplace pas la chasse aux orphelins.

Erreurs courantes

• Arrêter RDS une fois et célébrer — le redémarrage automatique aux sept jours relance la facturation en douce jusqu’à ce que l’automatisation ré-arrête.
• Oublier les fuseaux des crons : un horaire en UTC se décale d’une heure au changement d’heure, et l’équipe arrive avant l’environnement.
• Tuer la ferme de compilation nocturne parce qu’elle était étiquetée dev — cherchez les charges planifiées avant de planifier le sommeil.
• Compter le plein prix de l’instance comme économie en oubliant qu’EBS, les EIP et les répartiteurs facturent toute la nuit.

Garder le contrôle

• Suivez l’économie explicitement : comparez la ligne de calcul de l’environnement mois sur mois et publiez-la — les gains visibles protègent l’horaire de l’érosion.
• Alertez sur les instances non productives qui roulent hors des heures d’horaire; les exceptions deviennent permanentes en silence.
• Rendez l’étiquette schedule obligatoire dans l’IaC de dev et recette pour que les nouvelles ressources rejoignent l’horaire à la naissance.
• Revoyez la liste d’exclusions chaque trimestre — l’exception 24/7 « temporaire » de mars roule encore en juillet.
• Jumelez l’horaire au redimensionnement : un environnement qui roule 60 heures par semaine sur des instances plus petites cumule les deux économies.

La planification hors-heures est le levier de coûts au meilleur ratio effort-économie dans la plupart des comptes AWS — le calcul est fixe, seule la discipline varie. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.