Le principe : on ne paie le compute que quand la VM tourne
Une VM est facturée à l'usage. Quand elle est arrêtée, le compute n'est plus facturé : seuls les disques et quelques ressources associées continuent de coûter. Sur Azure, attention à un piège classique : une VM arrêtée depuis le système d'exploitation reste allouée, et donc facturée. Il faut qu'elle soit dans l'état « Arrêtée (désallouée) ».
Les environnements non-prod (développement, test, recette, POC) et les postes virtuels (VDI) n'ont aucune raison de tourner la nuit et le week-end. D'où l'idée du Stop/Start.
Le calcul : pourquoi le planning fixe déçoit
Un mois compte environ 730 heures. Prenons une VM non-prod à 30 € par jour (montant illustratif) et comparons les options :
| Option | Heures facturées / mois | Économie sur le compute |
|---|---|---|
| VM allumée 24/7, sans engagement | 730 | 0 % |
| Reserved Instance ou savings plan | 730, à tarif réduit | ≈ 50 % |
| Stop/Start à heures fixes (8h-20h en semaine) | ≈ 260 en théorie | ≈ 64 % en théorie, 50 à 60 % en pratique |
| Stop automatique + Start on demand | Le temps réellement utilisé | ≈ 90 % |
En pratique, un planning fixe s'élargit vite : on démarre plus tôt pour les équipes matinales, on arrête plus tard pour les batchs, on gère des exceptions. Le gain réel tombe à 50 ou 60 %. C'est à peine mieux qu'une simple réservation, pour beaucoup plus d'efforts : plannings par équipe, demandes d'exception, réclamations quand une VM n'est pas prête.
Le piège : réservation et Stop/Start ne se cumulent pas
Une réservation est un engagement de paiement, que la VM tourne ou non. Une VM réservée qu'on arrête la nuit continue donc de payer sa réservation : l'arrêt ne rapporte rien. Il faut choisir :
- En prod, la VM tourne en continu : c'est la réservation qui s'applique.
- En non-prod et sur les VDI, la VM peut être arrêtée : c'est le Stop/Start qui s'applique, et pas n'importe lequel.
Ce qui marche vraiment : Stop automatique + Start on demand
L'idée est simple : au lieu de deviner quand les équipes auront besoin de leurs VM, on les laisse les démarrer elles-mêmes, et on les arrête automatiquement.
- Stop automatique chaque soir, et idéalement après une période d'inactivité.
- Start on demand : la VM ne redémarre que lorsque quelqu'un en a besoin, via un bouton en self-service, un portail interne, un bot Teams ou un mécanisme natif.
Certains services le proposent nativement. Sur Azure Virtual Desktop, la fonction « Start VM on Connect » démarre le poste virtuel au moment où l'utilisateur se connecte. Sur AWS WorkSpaces, le mode AutoStop arrête le poste après une période d'inactivité. Pour les autres VM, quelques automatisations suffisent.
Résultat : une VM de test utilisée quelques heures par semaine ne coûte plus que ces quelques heures. L'économie atteint environ 90 %.
Mise en œuvre : les bonnes pratiques
- S'appuyer sur le tagging. L'environnement (prod ou non-prod) doit être connu, via un tag ou via la CMDB. Voir notre guide sur le tagging FinOps.
- L'activer par défaut. Le Stop auto + Start on demand devient un building block de la non-prod : toute nouvelle VM en bénéficie dès sa création. C'est le principe du FinOps by design.
- Gérer les exceptions par tag, de façon explicite et limitée dans le temps (par exemple pendant une campagne de tests de performance).
- Prévoir les dépendances : certaines applications demandent de démarrer les VM dans un ordre précis.
- Communiquer auprès des équipes : un bouton simple pour démarrer une VM vaut mieux qu'un long règlement.
Mesurer le résultat
Un indicateur simple : la part des VM non-prod et des VDI dont l'uptime est inférieur à 50 % sur le mois. Une cible de 80 % est un bon objectif. Ce KPI est suivi dans notre dashboard, avec la liste des VM qui tournent encore 24/7.
Où l'appliquer, et où ne pas l'appliquer
- Oui : environnements de développement, de test, de recette, de POC, VDI, outils internes utilisés aux heures de bureau.
- Non : la prod qui doit répondre 24/7, à couvrir par une réservation.
- Au cas par cas : clusters et services managés. Certains peuvent être arrêtés ou mis en pause (par exemple certaines bases de données ou capacités data), souvent avec des contraintes à vérifier.