Le problème : la facture Azure explose
Une part du budget cloud part souvent dans des ressources inutilisées ou surdimensionnées. Les causes reviennent régulièrement :
- Ressources zombies : disques orphelins, IPs publiques inutilisées, VMs arrêtées mais non désallouées (donc toujours facturées)
- Oversizing : des VMs surdimensionnées qui tournent à faible charge CPU
- Absence de reserved instances : vous payez le prix fort en Pay-As-You-Go
- Environnements de dev/test qui tournent en permanence
Étape 1 : Audit des ressources zombies
Qu'est-ce qu'une ressource zombie ?
Une ressource Azure qui existe, qui coûte de l'argent, mais qui n'est plus utilisée par personne. Exemples typiques :
- Disques managés détachés de toute VM
- IP publiques non associées
- Network Security Groups sans interfaces
- App Service Plans vides
- Snapshots de plus de 90 jours
Comment les détecter ?
Azure Resource Graph et quelques requêtes KQL permettent de les lister :
Resources
| where type == "microsoft.compute/disks"
| where properties.diskState == "Unattached"
| project name, resourceGroup, sku.name, properties.diskSizeGBL'ampleur varie fortement d'un environnement à l'autre : seul cet inventaire permet de la chiffrer pour le vôtre.
Étape 2 : Rightsizing
Analyse de l'utilisation réelle
Azure Advisor fournit des recommandations, mais elles sont souvent incomplètes. Une approche plus complète :
- Collecter 30 jours de métriques (CPU, RAM, IOPS, réseau)
- Identifier les VMs sous-utilisées (< 20% CPU moyen)
- Recommander la taille optimale avec simulation de coûts
- Implémenter avec zero-downtime via resize ou redeployment
Exemples de lecture (illustratifs)
| Taille actuelle | Utilisation observée | Piste de redimensionnement |
|---|---|---|
| D4s_v3 (4 vCPU) | faible, sans pics | B2ms (2 vCPU, burstable) |
| E8s_v5 (8 vCPU) | faible, mémoire peu sollicitée | D4s_v5 (4 vCPU) |
| D16s_v3 (16 vCPU) | faible, stable | D4s_v3 (4 vCPU) |
L'économie réelle se calcule avec la calculatrice de prix Azure, pour votre région et votre mode d'achat.
Étape 3 : Reserved Instances & Savings Plans
Pour les workloads stables, Microsoft annonce jusqu'à 72 % d'économie par rapport au paiement à l'usage pour une réservation de machines virtuelles sur trois ans. Le gain réel dépend de la série de VM, de la région et de la durée d'engagement.
Quand utiliser quoi ?
- Reserved Instances : VMs avec taille fixe et workload stable
- Savings Plans : workloads variables mais prévisibles
- Spot VMs : batch processing, CI/CD, workloads interruptibles
Étape 4 : Governance & Alertes
Azure Policy
- Bloquer la création de VMs trop grandes
- Forcer le tagging (owner, cost-center, environment)
- Auto-shutdown des environnements de dev à 19h
Budget Alerts
- Alerte à 80% du budget mensuel
- Action à 100% via un groupe d'actions (notification, voire arrêt automatisé de ressources non critiques)
Mesurer le résultat
Pour juger l'effet d'une démarche FinOps, il faut une base de comparaison honnête :
- Période de référence : la facture des trois derniers mois, avant toute action
- Périmètre constant : mêmes abonnements, mêmes applications, en isolant les nouveaux projets
- Journal des actions : chaque suppression, redimensionnement ou réservation, daté et chiffré individuellement
- Revue mensuelle : écart constaté par rapport à la référence, action par action
Conclusion
Le FinOps n'est pas un projet one-shot. C'est une discipline continue qui nécessite des outils, des processus et un suivi régulier. Des alertes budgétaires bien réglées et une revue mensuelle suffisent souvent à l'installer.