M365Con 2027 – conférence en ligne gratuite · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

Tarification d’Azure Log Analytics : comment empêcher la flambée des coûts de supervision Azure

By ·

Découvrez comment maîtriser la tarification d’Azure Log Analytics, optimiser les plans de table des espaces de travail, filtrer le bruit de l’ingestion et empêcher la flambée des coûts de supervision cloud.

Automatically translated with AI from the original post. Read the English original

Cover: Log Analytics - Simply Explained

Maîtriser la tarification d’Azure Log Analytics suppose de comprendre le volume d’ingestion, les plans de table et les coûts de conservation à long terme. En filtrant les données dès le départ avec KQL, en choisissant des plans adaptés comme Basic et Auxiliary, et en évitant les plafonds de collecte quotidiens dangereux, les administrateurs peuvent empêcher les factures de supervision Azure de déraper.

Points clés

Les facteurs de coût réels de Log Analytics

Lorsque les organisations déploient pour la première fois une solution de supervision cloud, l’objectif est presque exclusivement la visibilité : faire en sorte que les systèmes communiquent entre eux et que chaque erreur soit capturée. La réalité s’impose pourtant à réception de la facture cloud mensuelle. Log Analytics est facturé principalement selon deux axes de consommation : le volume de gigaoctets envoyés dans l’espace de travail et la durée pendant laquelle ces enregistrements restent disponibles pour les requêtes interactives.

La création d’un espace de travail ne coûte rien, ce qui crée souvent un faux sentiment de sécurité. Les équipes ont tendance à traiter leurs référentiels de journaux comme des tiroirs à tout faire, en déversant dans un même conteneur des données de débogage applicatif verbeuses, des signaux heartbeat redondants et des traces non vérifiées. Comme vous payez chaque gigaoctet qui arrive à destination, qu’une personne consulte ou non cette table précise, une ingestion de données non maîtrisée conduit rapidement à des dépassements budgétaires.

Se repérer parmi les plans de table : Analytics, Basic et Auxiliary

L’une des décisions les plus structurantes qu’un administrateur puisse prendre consiste à affecter le plan tarifaire approprié à chaque table. Toutes les données de journal n’exigent pas le même niveau de performance, et Microsoft propose des plans à plusieurs niveaux qui reflètent ces arbitrages opérationnels.

Le niveau Analytics standard

Le plan Analytics standard est conçu pour les données que vous surveillez de près et que vous devez interroger instantanément. Il prend en charge la détection des menaces en temps réel et le dépannage rapide. En revanche, c’est aussi l’option la plus coûteuse. Il conserve une indexation complète pour permettre l’exécution de requêtes en moins d’une seconde sur des instructions Kusto Query Language (KQL) complexes.

Les niveaux Basic et Auxiliary

Pour les données que vous ne consultez que de manière réactive, lorsque quelque chose tombe en panne, ou pour les enregistrements à fort volume conservés uniquement à des fins d’audit, les plans Basic et Auxiliary permettent des économies considérables. Alors que le plan Analytics standard coûte environ 2,30 $ par Go, le plan Basic peut faire baisser ce prix sensiblement, et le niveau Auxiliary peut ramener les coûts à une fraction des tarifs standard (jusqu’à 46 fois moins cher à l’entrée de gamme).

Le véritable enjeu est fonctionnel. Les formules économiques sont plus lentes à interroger, n’offrent pas l’indexation complète et ne conviennent absolument pas à l’alerte de sécurité en temps réel. En combinant ces formules au sein d’un même espace de travail, vous pouvez acheminer les signaux de sécurité critiques vers des tables coûteuses et rapides, tout en reléguant les journaux de conformité volumineux dans un stockage auxiliaire bon marché.

Réduire fortement les coûts grâce au filtrage précoce et aux règles de collecte de données

L’erreur la plus fréquente des administrateurs consiste à tenter de nettoyer les données une fois qu’elles sont déjà arrivées dans l’espace de travail. Au moment où un enregistrement de journal est stocké, vous payez déjà son ingestion.

La bonne approche repose sur les règles de collecte de données (DCR, Data Collection Rules), associées à l’agent Azure Monitor. Les DCR agissent comme des jeux d’instructions déployés sur vos machines virtuelles et vos clusters de conteneurs. Elles déterminent précisément les événements à collecter, la manière de les mettre en forme et la table dans laquelle ils doivent être stockés. Plus important encore, elles vous permettent d’éliminer le bruit répétitif dès la source.

Si une application génère chaque heure des milliers de journaux d’information répétitifs que votre équipe n’interroge jamais, éliminez-les dès l’entrée. Reformater et filtrer les données avant qu’elles n’atteignent le moteur de stockage vous garantit de ne jamais payer pour une télémétrie que vous n’utilisez pas.

Les risques des plafonds d’ingestion quotidiens

Confrontés à des factures cloud imprévisibles, de nombreux directeurs financiers et responsables informatiques se tournent vers la fonctionnalité de plafond quotidien d’Azure Log Analytics, qu’ils considèrent comme un filet de sécurité absolu. Un plafond quotidien fixe une limite stricte à l’ingestion de données : une fois le seuil atteint, l’espace de travail cesse d’accepter de nouveaux enregistrements pour le reste de la journée.

Si cette mesure évite les pics de dépenses imprévus, Microsoft met explicitement en garde contre son utilisation pour la gestion courante des coûts. Lorsqu’un plafond quotidien est atteint, la collecte de données s’arrête complètement. Vos analystes de sécurité perdent toute visibilité, vos équipes d’exploitation travaillent à l’aveugle et vous passez à côté d’alertes critiques en cas de panne pendant la nuit. Une interruption de visibilité due à une panne coûte presque toujours plus cher qu’une facture de supervision cloud légèrement plus élevée.

Équilibrer la rétention interactive et les archives à long terme

La maîtrise des coûts ne se limite pas à l’ingestion : elle concerne aussi la durée de conservation des données. Par défaut, la rétention interactive permet une interrogation rapide pendant 31 jours (ou 90 jours si Microsoft Sentinel est activé). Une fois cette fenêtre écoulée, les données ne disparaissent pas : elles passent dans le stockage à long terme.

Conserver des données interrogeables de manière interactive coûte nettement plus cher par gigaoctet et par mois que leur archivage dans le stockage à long terme. Pour les obligations de conformité qui imposent une conservation pendant plusieurs années, le stockage d’archives ne coûte que quelques centimes par gigaoctet. Gardez toutefois à l’esprit que la récupération de données archivées nécessite l’exécution de tâches de recherche plutôt que des requêtes interactives instantanées, ce qui rend une stratégie définie en amont indispensable.

Conclusion et prochaines étapes

Maîtriser la tarification d’Azure Log Analytics relève d’une architecture pensée avec intention. En renonçant à une stratégie de collecte indifférenciée, en exploitant les formules propres à chaque table et en appliquant des règles de collecte strictes au plus près de la source, vous pouvez conserver une visibilité de niveau entreprise sans faire exploser votre budget cloud.

Pour approfondir les fondements du fonctionnement de ces systèmes, écoutez l’épisode complet du podcast M365 FM, une présentation accessible des espaces de travail, des tables et des bases des requêtes KQL.

Questions fréquentes

La création d’un espace de travail Azure Log Analytics est-elle gratuite ?

Oui, la création d’un espace de travail n’entraîne aucun frais de base. Vous ne payez que le volume de données ingérées dans l’espace de travail et la durée de conservation de ces données.

Quelle est la différence entre les formules Analytics, Basic et Auxiliary ?

La formule Analytics offre un stockage rapide, entièrement indexé, optimisé pour les alertes de sécurité en temps réel et les requêtes interactives rapides. Les formules Basic et Auxiliary proposent des options de stockage nettement moins coûteuses, destinées aux données rarement interrogées ou conservées principalement à des fins de conformité et d’archivage.

Pourquoi devrais-je éviter les plafonds d’ingestion quotidiens ?

Les plafonds d’ingestion quotidiens interrompent totalement la collecte de données dès que le seuil de dépenses est atteint. Vos systèmes de sécurité et de supervision sont alors aveugles pour le reste de la journée, ce qui crée des risques inacceptables en cas de panne système ou de violation de sécurité.

Comment réduire mes coûts d’ingestion de données Log Analytics ?

La stratégie de réduction des coûts la plus efficace consiste à filtrer les données de journaux inutiles à la source à l’aide de règles de collecte de données (DCR, Data Collection Rules), afin que les journaux de débogage bruyants et jamais consultés soient éliminés avant d’atteindre votre espace de travail facturable.

Fabric workspace Kusto Query Language (KQL)

Related articles

RSS