Pourquoi votre facture Azure est élevée même quand vos resources sont correctement dimensionnées

Dans cet article

• Votre partenaire ne gagne pas de credit en votre nom
• Le Log Ingestion est votre centre de coûts invisible
• Les Private Endpoints inutilisés s’additionnent discrètement
• Des coûts d’egress que personne n’avait budgétés
• Des Diagnostic Settings que personne n’audite
• Orphaned Resources
• Un audit de coûts pratique en cinq étapes

En résumé : Le rightsizing et les reserved instances captent peut-être 20 à 30% des économies disponibles. Le reste se cache dans la configuration partenaire (PEC), l’explosion du log ingestion, les private endpoints inutilisés, les surprises d’egress, les diagnostic settings que personne n’audite et les orphaned resources. La plupart sont corrigeables en 1 à 2 semaines de revue des coûts.

La plupart des optimisations de coûts Azure commencent et finissent avec les deux mêmes leviers : le rightsizing des VMs et l’achat de reserved instances. Les deux sont valides. Azure Advisor vous en parlera. Votre outil FinOps les affichera dans le premier dashboard. Si c’est tout ce que vous faites, vous capterez peut-être 20 à 30% des économies disponibles.

Le reste se cache dans des endroits qu’Advisor ne signale pas et que les dashboards FinOps ne font pas remonter. Ce sont des problèmes de configuration, des effets de bord architecturaux et des oublis opérationnels qui s’accumulent silencieusement sur des mois. Ils n’apparaissent pas comme un seul poste de coût important. Ils se répartissent sur des dizaines de petits frais qui semblent normaux individuellement mais totalisent des milliers d’euros par mois.

Voici où nous trouvons systématiquement de l’argent qui fuit dans les environnements Azure d’entreprise.

Fuite de coûts	Impact mensuel typique	Comment la trouver
PEC manquant (partner credit)	7 500-15 000+ EUR	Vérifier accord CSP + assignations RBAC
Log ingestion sur le mauvais tier	2 000-5 000 EUR	Comparer utilisation tables Basic vs Analytics
Private endpoints inutilisés	350-1 000 EUR	Requête Azure Resource Graph
Egress et NAT Gateway	500-4 000+ EUR	Network Watcher flow analytics
Explosion des diagnostic settings	1 000-3 000 EUR	Auditer les diagnostic settings par resource type
Disks et NICs orphelins	500-2 000 EUR	Requête Resource Graph pour les resources non attachées

Votre partenaire ne gagne pas de credit en votre nom

Si votre Azure passe par un partenaire CSP, Microsoft offre un Partner Earned Credit (PEC) quand le partenaire a un accès opérationnel actif à votre environnement. La réduction sur la consommation éligible est souvent d’environ 15%, et selon votre accord commercial, ce bénéfice peut vous revenir sous forme de prix Azure réduits ou de services financés.

Nous avons traité ce sujet en détail dans notre article sur les économies partenaires. La version courte : la plupart des entreprises sous accord CSP ne reçoivent pas le bénéfice PEC parce que le partenaire n’a pas l’accès RBAC requis, le modèle de facturation est mal configuré, ou personne ne l’a mis en place.

Pour une entreprise qui dépense 150 000 EUR/mois en Azure, avec environ 80 000 EUR éligibles au PEC après soustraction des reservations et savings plans, l’écart est d’environ 12 000 EUR/mois. C’est 144 000 EUR/an de bénéfice qui s’évapore à cause d’un problème de configuration.

Vérifiez les assignations RBAC de votre partenaire. Demandez si le PEC est acquis. S’ils ne savent pas ce qu’est le PEC, cela vous dit quelque chose d’important sur la relation.

Le Log Ingestion est votre centre de coûts invisible

Log Analytics et Microsoft Sentinel facturent au volume de données. Aux tarifs pay-as-you-go en West Europe, les Analytics Logs coûtent environ 2,50 EUR/GB. Un environnement Azure de taille moyenne qui ingère 80 GB/jour dépense environ 6 000 EUR/mois rien qu’en stockage de logs.

Le problème n’est pas que le logging est cher. C’est que la plupart des environnements ingèrent tout au tier le plus élevé sans aucune stratégie de filtrage. Nous avons écrit sur ce schéma dans notre article sur le contrôle des coûts d’ingestion Sentinel, et nous le voyons dans pratiquement chaque environnement que nous examinons.

Trois facteurs génèrent des dépenses de logs inutiles.

Des diagnostic settings qui envoient tout. Quand quelqu’un active les diagnostic settings sur une resource, le défaut dans beaucoup de templates IaC est “envoyer toutes les catégories à Log Analytics.” Pour une Application Gateway chargée, cela signifie des access logs, performance logs et firewall logs, le tout atterrissant dans le tier Analytics à plein volume. Pour un storage account, cela signifie chaque opération read, write et delete. Un seul storage account avec un trafic blob important peut générer 5-10 GB/jour de transaction logs que personne n’interroge.

Pas d’utilisation des Basic Logs. Microsoft offre un tier Basic Logs à environ 0,50 EUR/GB pour les données dont vous avez besoin pour les investigations mais sur lesquelles vous n’exécutez pas de scheduled queries. Les NSG flow logs, les firewall logs verbeux, le container stdout et les storage access logs sont tous de bons candidats. Déplacer 40 GB/jour d’Analytics vers Basic économise environ 80 EUR/jour, soit environ 2 400 EUR/mois.

Pas de filtrage avec les Data Collection Rules. Les DCRs vous permettent de filtrer et transformer les données avant qu’elles n’atteignent le workspace. Un flux Windows Security Event qui ingère chaque event ID génère 10-20 GB/jour par centaine de serveurs. Filtrer uniquement les event IDs que vos règles de détection référencent réduit ce volume de 60-80%. Si votre workspace a été mis en place avant l’existence des DCRs et que personne n’a revu la configuration, vous payez pour des données que vous n’utilisez jamais.

Les Private Endpoints inutilisés s’additionnent discrètement

Un seul private endpoint coûte environ 7 EUR/mois. Cela semble négligeable. Dans un environnement d’entreprise avec 300+ private endpoints, le coût de base dépasse 2 100 EUR/mois avant même de compter les frais de data processing.

Le coût caché, ce ne sont pas les endpoints que vous utilisez. Ce sont ceux que vous n’utilisez pas. Nous trouvons régulièrement des private endpoints pour des resources qui ont été décommissionnées, des endpoints créés dans plusieurs VNets pour la même resource alors qu’un seul VNet a réellement besoin d’un accès, et des endpoints provisionnés “au cas où” lors des déploiements initiaux qui n’ont jamais été connectés à des workloads applicatifs.

Une requête Azure Resource Graph rapide fait apparaître les private endpoints orphelins :

resources
| where type == "microsoft.network/privateendpoints"
| extend connectionState = properties.privateLinkServiceConnections[0].properties.privateLinkServiceConnectionState.status
| where connectionState != "Approved" or isnull(connectionState)

Pour les endpoints approuvés mais potentiellement inutilisés, croisez avec les données de network flow ou les logs de DNS queries. Un endpoint provisionné depuis six mois avec zéro DNS query est un candidat à la suppression.

Au-delà de l’endpoint lui-même, chaque private endpoint crée une network interface avec une allocation d’IP privée et nécessite au moins un enregistrement DNS dans une private DNS zone. Sur les grands environnements, la multiplication des coûts est réelle : 300 private endpoints signifie 300 NICs consommant de l’espace d’adressage IP et 300+ enregistrements DNS répartis sur plusieurs zones. La surcharge NIC et DNS est gratuite en isolation, mais le coût opérationnel de la gestion d’enregistrements obsolètes, la pression sur l’espace d’adressage IP dans les subnets chargés, et la complexité du troubleshooting quand des enregistrements DNS pointent vers des endpoints décommissionnés se retrouvent dans les heures d’ingénierie plutôt que sur la facture Azure.

A 7 EUR/mois chacun, nettoyer 50 endpoints orphelins économise 350 EUR/mois. Pas spectaculaire en soi, mais ces petites fuites se cumulent sur l’ensemble d’un environnement.

Schéma récurrent : Les trois premières fuites de coûts (PEC, log ingestion, private endpoints) sont des problèmes de configuration, pas des problèmes d’architecture. Elles peuvent être corrigées sans modifier les workloads, redéployer des resources ou toucher au code applicatif.

Des coûts d’egress que personne n’avait budgétés

L’ingress Azure est gratuit. L’egress ne l’est pas, et la tarification varie considérablement selon la destination du trafic.

L’egress internet depuis une région Azure standard coûte environ 0,08 EUR/GB pour les premiers 10 TB/mois. Le trafic cross-region au sein d’Azure coûte environ 0,02 EUR/GB. Le trafic de VNet peering dans la même région est de 0,01 EUR/GB dans chaque direction.

Ces tarifs semblent modestes jusqu’à ce que vous regardiez les volumes réels. Une Application Gateway servant une API publique peut facilement générer 500 GB/mois d’egress internet, soit environ 40 EUR/mois. Un profil Azure Front Door chargé servant du contenu statique en ajoute davantage. La réplication cross-region pour les storage accounts ou databases génère des frais de transfert continus.

Les surprises viennent du trafic cross-region involontaire. Un workload en West Europe appelle une API hébergée en North Europe parce que personne n’a vérifié dans quelle région se trouve la dépendance. Un workspace Log Analytics dans une région reçoit des données diagnostiques de resources dans trois autres régions, générant des frais d’ingress cross-region sur chaque GB.

Application Gateway et Front Door ont aussi leurs propres frais de data processing en plus de l’egress sous-jacent. App Gateway v2 facture environ 0,007 EUR/GB de data processing. Les frais Front Door varient selon le tier mais ajoutent des frais par requête et par GB.

NAT Gateway est un autre facteur de coûts d’egress qui passe sous le radar. Quand tout le trafic sortant d’un subnet passe par un NAT Gateway, chaque octet de trafic internet engendre des frais d’egress plus des frais de data processing NAT Gateway (environ 0,04 EUR/GB). Pour les workloads qui font beaucoup d’appels API externes, pullent fréquemment des container images ou transfèrent des données vers des plateformes SaaS tierces, le coût combiné monte vite. Un subnet poussant 2 TB/mois de trafic sortant via NAT Gateway paie environ 240 EUR/mois en frais de processing seuls, en plus de l’egress internet standard. La plupart des équipes budgètent le coût horaire de NAT Gateway (environ 32 EUR/mois par gateway) mais ignorent complètement le frais de processing par GB.

Cartographiez vos flux de trafic. Identifiez les chemins cross-region qui existent par accident plutôt que par conception. Colocalisez les workloads avec leurs dépendances. Ces changements ne nécessitent pas de nouveaux services ou outils, juste une conscience de l’endroit où le trafic va réellement.

Des Diagnostic Settings que personne n’audite

Chaque resource Azure peut envoyer des données diagnostiques à Log Analytics, un storage account, Event Hubs ou une solution partenaire. Les policies de landing zone déploient généralement des diagnostic settings automatiquement avec des effets DeployIfNotExists.

L’intention est bonne. Le résultat, après deux ans, est souvent une explosion de diagnostic settings que personne n’a examinée. Nous trouvons couramment des resources envoyant les mêmes logs à deux workspaces Log Analytics différents (un via une policy de landing zone, un ajouté manuellement pendant du troubleshooting). Des resources envoyant toutes les catégories diagnostiques quand seules deux sont nécessaires. Et des diagnostic settings de storage account générant des volumes massifs de transaction logs pour des comptes servant de tiers d’archivage avec un accès minimal.

Une seule Azure SQL Database avec toutes les catégories diagnostiques activées peut envoyer 2-5 GB/jour à Log Analytics. Multipliez par 40 databases dans l’environnement et vous obtenez 80-200 GB/jour de diagnostics SQL, dont la majorité n’est jamais interrogée.

L’audit est simple : listez tous les diagnostic settings dans l’environnement via Azure Resource Graph, identifiez quelles catégories sont activées par resource type, et comparez avec ce que vos équipes monitoring et sécurité utilisent réellement. Supprimez les catégories qui ne nourrissent pas de dashboards, alertes ou règles de détection.

resources
| where type contains "microsoft.insights/diagnosticsettings"
| extend resourceId = tostring(properties.storageAccountId)
| summarize count() by type, tostring(properties.logs)

Cet exercice seul économise souvent 20-30% des dépenses Log Analytics.

Orphaned Resources

La catégorie classique de gaspillage, mais elle persiste parce que personne n’est propriétaire du nettoyage.

Les managed disks détachés de VMs s’accumulent quand les VMs sont supprimées mais leurs disks sont configurés pour persister. Un Premium SSD P30 (1 TB) coûte environ 100 EUR/mois, qu’il soit attaché ou non. Nous trouvons régulièrement 20 à 50 orphaned disks dans des environnements de taille moyenne, représentant 500-2 000 EUR/mois de gaspillage.

Les adresses public IP non associées à une resource coûtent environ 3,50 EUR/mois chacune (Basic SKU) ou 4,40 EUR/mois (Standard). Les network interfaces détachées de VMs ne coûtent rien en soi mais indiquent un nettoyage incomplet. Les Network Security Groups non associés à un subnet ou NIC sont gratuits mais ajoutent de la confusion opérationnelle.

Les postes de coûts plus importants parmi les orphaned resources sont souvent moins évidents : des Azure Bastion hosts (140 EUR/mois) provisionnés pour une migration terminée depuis des mois, des VPN Gateways (130+ EUR/mois) pour des connexions remplacées par ExpressRoute, et des App Service Plans sans apps déployées (facturés pour le plan, pas les apps).

Un audit de coûts pratique en cinq étapes

Si votre facture Azure semble plus élevée qu’elle ne devrait l’être et que les conseils habituels de rightsizing n’ont pas comblé l’écart, suivez ces étapes.

1. Vérifiez la configuration de votre partenaire CSP. Vérifiez l’éligibilité PEC, confirmez l’accès RBAC, et demandez comment la valeur PEC est reflétée dans vos conditions commerciales. Le correctif est une conversation, pas un exercice technique.

2. Auditez l’ingestion Log Analytics. Exécutez la requête sur la table Usage pour voir les GB/jour par type de données. Identifiez les cinq tables au plus fort volume. Pour chacune, confirmez qu’une règle de détection, un dashboard ou un processus opérationnel en dépend. Déplacez les tables à haut volume et faible signal vers Basic Logs.

3. Listez tous les private endpoints et croisez avec les DNS queries et les network flows. Supprimez les endpoints pour les resources décommissionnées et consolidez les endpoints en double.

4. Cartographiez les chemins d’egress. Utilisez les flow logs de Network Watcher ou Cost Management pour identifier l’egress cross-region et internet. Cherchez le trafic cross-region accidentel entre les workloads et leurs dépendances.

5. Exportez tous les diagnostic settings via Resource Graph. Comparez les catégories activées avec l’utilisation réelle. Désactivez les catégories qui ne nourrissent pas les exigences de monitoring, sécurité ou conformité.

Chaque étape cible un domaine de coûts que l’outillage FinOps standard rate. Parcourez-les chaque trimestre. Les environnements Azure ne sont pas statiques, et les fuites de coûts qui n’existent pas aujourd’hui apparaîtront dans six mois quand les workloads changeront et que de nouvelles resources seront provisionnées.

Mission typique : Une revue des coûts et de la plateforme Azure va au-delà du rightsizing de VMs. Nous analysons la configuration partenaire, les schémas d’ingestion de logs, la prolifération de private endpoints, les flux d’egress, les diagnostic settings et les orphaned resources. Le livrable est une carte d’économies priorisée avec des estimations en EUR et des étapes d’implémentation. La plupart des revues prennent 1 à 2 semaines.

En lien : Votre facture Azure est plus élevée parce que votre partenaire ne gère rien PEC et responsabilité partenaire · Microsoft Sentinel en 2026 et comment contrôler les coûts d’ingestion optimisation du log ingestion · Ce que révèle un audit Azure Landing Zone lacunes de gouvernance qui génèrent des coûts