Pourquoi la facture dérive
- Des diagnostic settings activés avec « toutes les catégories », par défaut, sur des centaines de ressources.
- De nouvelles sources branchées au fil des projets : firewalls, proxies, Entra ID, endpoints, applications.
- Des applications qui loguent en mode debug en production, parfois en boucle.
- Des logs envoyés en double vers plusieurs workspaces.
- Sur un workspace où Sentinel est activé, les Go ingérés en Analytics logs sont facturés une seconde fois par Sentinel.
Un incident de ce type peut coûter plusieurs dizaines de milliers d'euros par jour. C'est pourquoi l'alerting sur l'ingestion fait partie de la méthode.
Étape 1 : mesurer ce qui est ingéré
Avant de couper quoi que ce soit, il faut savoir d'où vient le volume. La table Usage du workspace donne le volume facturable par table :
Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize Go = sum(Quantity) / 1000 by DataType
| sort by Go descOn identifie en général très vite une poignée de tables qui pèsent l'essentiel : AzureDiagnostics, logs de firewall, de proxy, de containers, événements de sécurité Windows. On descend ensuite au niveau de la ressource ou de la catégorie, par exemple avec la colonne _BilledSize.
Étape 2 : filtrer à la source
- Diagnostic settings : ne sélectionner que les catégories réellement utilisées.
- Data Collection Rules (DCR) : avec l'agent Azure Monitor, filtrer ce qui est collecté sur les VM (par exemple seulement certains événements Windows), et appliquer des transformations à l'ingestion pour supprimer des lignes ou des colonnes inutiles.
- Doublons : envoyer chaque log vers un seul workspace.
- Niveau de log applicatif : pas de debug en prod, sauf temporairement et de façon contrôlée.
Étape 3 : choisir le bon plan de table
| Plan | Coût d'ingestion | Usage idéal |
|---|---|---|
| Analytics logs | Le plus élevé | Logs interrogés souvent, règles de détection, alertes |
| Basic logs | Beaucoup plus bas | Logs volumineux consultés ponctuellement, pour du troubleshooting |
| Auxiliary logs | Le plus bas | Très gros volumes conservés pour l'audit ou l'investigation |
Les Basic et Auxiliary logs ont des contreparties : requêtes plus limitées, facturées à la donnée scannée, et pas toutes les fonctionnalités. Le choix se fait table par table, avec les équipes qui exploitent ces logs.
Étape 4 : adapter le commitment tier
En pay-as-you-go, chaque Go est facturé au tarif plein. À partir d'environ 100 Go par jour, un commitment tier apporte une remise, et des paliers supérieurs existent pour les gros volumes. Sentinel a ses propres commitment tiers. Le bon palier se recalcule régulièrement, surtout après une campagne de filtrage qui a fait baisser le volume.
Étape 5 : ajuster la rétention
La rétention interactive est incluse jusqu'à 31 jours (90 jours sur un workspace où Sentinel est activé). Au-delà, elle est facturée. Pour la conformité, la rétention longue durée (archive) coûte beaucoup moins cher. La rétention se règle table par table : inutile de garder deux ans de logs de debug.
Étape 6 : travailler avec le SOC
Sur Sentinel, une économie mal pensée peut faire perdre une alerte de sécurité. Chaque filtre est donc validé avec l'équipe sécurité, au regard des règles de détection réellement utilisées. Certaines sources sont d'ailleurs gratuites dans Sentinel, comme les Azure Activity logs : il n'y a aucune raison de s'en priver.
Garder le contrôle
- Une alerte sur l'ingestion journalière par workspace, pour détecter une dérive dans la journée.
- Une revue trimestrielle des plus grosses tables et du commitment tier.
- Une règle de FinOps by design : chaque nouveau diagnostic setting n'active que les catégories nécessaires.
Le daily cap d'un workspace peut servir de garde-fou ponctuel, mais il arrête la collecte une fois atteint : à proscrire sur un workspace de sécurité.