Sur AWS, de nombreuses instances EC2 et bases RDS (Relational Database Service) restent actives 24 h/24, alors qu’elles ne sont utilisées que quelques heures par jour. C’est particulièrement vrai pour les environnements de développement et de test, souvent inactifs la nuit ou le week-end : une partie importante des coûts générés par ces instances pourraient être économisés grâce à l’automatisation de leur arrêt et démarrage.
Pour répondre à ce besoin, AWS propose une solution clé en main, l’Instance Scheduler, déployable via CloudFormation et qui sera détaillée dans un prochain article. Cependant, pour les petits projets ou ceux nécessitant plus de flexibilité, il est possible de mettre en place une alternative plus légère et entièrement gérable via Terraform. Cette solution offre plus de possibilités de personnalisation, et une gestion transparente des coûts associés.
Introduction à l’AWS Instance Scheduler : l’automatisation simplifiée des arrêts et démarrages
L’AWS Instance Scheduler est une solution managée qui automatise le démarrage et l’arrêt des instances EC2 et RDS selon des horaires définis. Elle permet ainsi de réduire les coûts en ne maintenant les ressources actives que lorsqu’elles sont réellement utilisées. Par exemple, une instance EC2 configurée pour fonctionner uniquement de 9 h à 18 h du lundi au vendredi démarre et s’arrête automatiquement à ces horaires, évitant ainsi des heures d’exécution inutiles chaque jour.
Le service repose principalement sur :
-
Des tags appliqués aux instances pour définir les plannings ;
-
Une table DynamoDB centralisant les horaires et règles ;
-
Des fonctions Lambda exécutées selon un calendrier configuré dans EventBridge ;
-
Et CloudWatch Logs pour le suivi des actions.
Grâce à cette architecture, l’Instance Scheduler offre une solution clé en main, sans code ni maintenance spécifique, pour automatiser la gestion du cycle de vie des instances grâce à plusieurs déclarations de plannings.
Pourquoi AWS Instance Scheduler peut être inadapté à certains projets
Voici le schéma d’architecture officiel de l’Instance Scheduler :
C’est une orchestration complexe, prenant en compte de nombreux cas de personnalisation optionnelle, comme l’Auto-Scaling ou la gestion d’AWS Organizations. Pour les environnements homogènes, stables, ou de taille significative, l’Instance Scheduler est une solution idéale. Cependant, une alternative personnalisée peut être préférable dans deux cas principaux.
- Projets légers ou hétérogènes
Dans les petites infrastructures, ajouter un template CloudFormation à un projet géré intégralement avec Terraform et déclarant des ressources externes à AWS peut s’avérer inefficace et surdimensionné. - Besoins de planification spécifiques
L’Instance Scheduler ne prend pas en charge les priorités entre plannings, les expressions CRON avancées ou les déclenchements basés sur des évènements externes. Par exemple, en cas de coupure ponctuelle pour les vacances, plusieurs plannings récurrents doivent donc être modifiés. Pour le démarrage d’une instance suite à la réussite d’une chaîne CI/CD, ce n’est tout simplement pas possible.
Construire une alternative Terraform : une architecture simple et modulable pour vos instances
La solution présentée ici permet de déclarer l’ensemble des services AWS nécessaires depuis Terraform, et en assure la maîtrise complète. Les fonctionnalités couvertes ici sont les suivantes :
- Planification des arrêts et démarrages selon des jours de la semaine ou des dates spécifiques
- Prises en compte de plannings ponctuels prioritaires (vacances, jours fériés, pics d’activité)
- Centralisation des tags de l’ensemble des instances
Des tags centralisés dans DynamoDB et rattachés à chaque instance définissent les règles de planification.
Deux fonctions Lambdas assurent le fonctionnement de cette solution. L’une propage les ajouts, modifications et suppressions de tags depuis DynamoDB vers les instances concernées. L’autre exécute la logique de planification pour démarrer ou arrêter les instances selon les règles en vigueur.
Implémentation pratique : automatiser les arrêts et démarrages avec Terraform
Dans notre exemple, l’architecture repose sur une table DynamoDB qui centralise les règles de planification pour chaque ressource. Chaque entrée associe une instance (EC2 ou RDS) à ses horaires de fonctionnement, exprimés sous forme de tags. Cette approche permet de gérer aussi bien des plannings récurrents que des exceptions ponctuelles (vacances, pics d’activité), le tout depuis une seule source de vérité.
Une première fonction Lambda propage la déclaration des tags pour chaque ressource AWS pour toute addition, modification ou suppression dans la table. Pour son déclenchement, activer l’option DynamoDB Stream et l’associer à la fonction est nécessaire.
Une seconde Lambda, déclenchée chaque minute par EventBridge, évalue en temps réel si l’heure actuelle correspond à un créneau de démarrage ou d’arrêt pour chaque ressource. La Lambda est conçue pour être idempotente, robuste face aux erreurs, et produit des logs détaillés dans CloudWatch pour un suivi transparent. Le code ci-dessous correspond à sa fonction principale. La logique derrière les appels est à implémenter en fonction des besoins.
Terraform déploie l’ensemble de l’architecture, ainsi que sa configuration (droits et profils utilisateurs). Cela permet de versionner, reproduire et adapter la solution à différents environnements sans dépendre de CloudFormation. La gestion centralisée des tags permet également une déclaration simple et lisible des règles de planification, avec gestion d’exceptions et de priorités (comme les périodes de vacances). Voici un exemple de déclaration de ces ressources :
Il est cependant important de noter que cette implémentation, si flexible et personnalisable, reste sujette à maintenance, et exige une connaissance en programmation pour être mise en place efficacement.
Evoluer au-delà de l’Instance Scheduler : flexibilité, personnalisation et contrôle
Cette solution légère et entièrement pilotée par Terraform constitue donc une alternative pragmatique à AWS Instance Scheduler dans les projets à petite échelle, indépendants de CloudFormation, et capables de maintenir le code produit dans le temps. L’AWS Instance Scheduler reste cependant une solution intéressante dans certains cas. Pour des besoins entièrement no-code ou des projets plus importants nécessitant une solution plus directement industrialisée, un prochain article détaillera sa mise en place.
L’alternative décrite offre une architecture simple et transparente, une flexibilité totale dans la définition des règles, et la possibilité de centraliser la gestion des tags pour d’autres usages. Elle s’intègre facilement dans des environnements multi-comptes ou à petite échelle, tout en restant extensible vers des architectures plus complexes.
En somme, une approche efficace, lisible et personnalisable, pour automatiser vos instances AWS en toute simplicité.
