Aller au contenu
English
Cloud high

Pay-as-you-go : décrypter les modèles tarifaires cloud

17 min de lecture

Quand un débutant lance sa première VM cloud, il croit payer « la VM ». En réalité, dès la première seconde, le compteur tourne sur huit axes simultanés : temps de calcul, espace disque, trafic sortant, requêtes I/O, licences, snapshots, sauvegardes, support. Cette page décortique chaque axe, explique les granularités de facturation entre fournisseurs, compare les trois modèles d'engagement (on-demand, reserved, spot) et liste les cinq pièges qui font exploser les factures sans que personne ne s'en rende compte avant le 5 du mois suivant.

  • Les 8 axes de facturation simultanés que vous payez à chaque seconde
  • La granularité de facturation par fournisseur et son impact réel
  • Les 3 modèles d'engagement (on-demand, reserved, spot) et leurs économies respectives
  • Les 5 pièges classiques de facturation à anticiper
  • Comment lire une facture cloud sans paniquer

Prérequis : avoir compris la bascule comptable du cloud. Si besoin, démarrez par CAPEX vs OPEX.

L'erreur de cadrage la plus fréquente est de raisonner à la VM. Le prix affiché d'une instance (par exemple « c5.xlarge à 0,17 €/h ») ne couvre que le compute. À côté, sept autres compteurs tournent en parallèle, parfois invisibles sur la page produit, mais bien présents sur la facture.

Le temps de calcul est l'axe le plus médiatisé. Vous payez la VM tant qu'elle est dans l'état running. Le tarif dépend du type d'instance (CPU, RAM, GPU), de la région (Paris coûte ~10 % plus cher que Ohio), et de l'OS (Windows ajoute la licence Microsoft, ~50 % de surcoût). Une c5.xlarge en eu-west-3 coûte ~0,19 €/h à la demande, soit ~140 €/mois si elle tourne 24/7.

Tout disque attaché à une VM se paye tant qu'il existe, même si la VM est arrêtée. Un volume EBS gp3 de 100 Go vous coûte ~8 €/mois, peu importe qu'il soit utilisé ou non, branché ou non. Cette mécanique explique pourquoi un environnement de test « éteint le soir » continue de coûter de l'argent, la facture mensuelle ne tombe à zéro que si on détruit les ressources, pas si on les arrête.

Les données qui entrent dans le cloud sont gratuites, celles qui en sortent sont facturées. Les tarifs varient drastiquement entre fournisseurs : ~0,09 €/Go chez AWS hors CDN, ~0,08 €/Go Azure, ~0,12 €/Go GCP, mais seulement ~0,01 €/Go chez Outscale. Une application qui sert 10 To/mois à ses utilisateurs paye 900 € par mois juste en bande passante chez AWS. Ce piège mérite sa propre page : voir Egress et data transfer economics.

Sur les services managés (S3, DynamoDB, RDS), chaque requête est facturée. S3 facture ~0,005 € pour 1 000 requêtes PUT et ~0,0004 € pour 1 000 GET. À petite échelle, c'est négligeable. À l'échelle d'une application qui fait 50 millions de GET par jour, on parle de ~600 € par mois rien qu'en requêtes, sans compter le stockage des objets ni l'egress.

Une VM Windows facture la licence en plus du compute. Une instance RDS Oracle Enterprise inclut une licence Oracle qui peut multiplier le coût de base par 3. Les bases SQL Server avec Always On sur Azure incluent des frais de licence considérables. Vérifier systématiquement si la licence est incluse ou facturée séparément avant de signer un design.

Un snapshot n'est pas une copie complète du volume, sauf le premier. C'est le point que la plupart des chiffrages ratent, et il change tout : les snapshots EBS sont incrémentaux, seuls les blocs modifiés depuis le snapshot précédent sont stockés. Le tarif est de 0,053 USD/Go-mois dans la région de Paris.

La conséquence pratique est qu'un snapshot quotidien ne coûte pas la taille du volume chaque jour. Sur un volume de 200 Go dont 5 Go changent par jour, une année de snapshots quotidiens représente :

premier snapshot 200 Go
364 incréments x 5 Go 1 820 Go
---------
total stocké 2 020 Go, soit environ 2 To

Multiplier 200 Go par 365 donnerait 73 To, soit 36 fois trop. La facture réelle dépend donc de votre taux de changement quotidien, une donnée que vous mesurez, pas d'une règle de trois sur la taille du volume.

Le support de base est gratuit chez tous les hyperscalers, mais il ne donne accès qu'à la documentation et aux forums : ouvrir un ticket sur un incident de production relève d'un plan payant. Chez AWS, la facturation est dégressive par tranches de dépense mensuelle, ce qui interdit de retenir un pourcentage unique.

Plan AWSMinimum mensuelTranches sur la dépense mensuelle
Business+29 USD9 % jusqu'à 10 000 USD, 7 % de 10 000 à 80 000, 5 % de 80 000 à 250 000, 3 % au-delà
Enterprise5 000 USD10 % jusqu'à 150 000 USD, 7 % de 150 000 à 500 000, 5 % de 500 000 à 1 M, 3 % au-delà

Le calcul se fait tranche par tranche, pas en appliquant le taux du dernier palier à la totalité. Sur un compte qui consomme 50 000 USD par mois en Business+ :

9 % x 10 000 USD = 900 USD
7 % x 40 000 USD = 2 800 USD
---------
3 700 USD par mois

Soit plus du double de ce que donnerait un taux unique de 3 %. C'est un poste régulièrement oublié des budgets initiaux. Tarifs relevés sur la page de tarification du support AWS le 10 septembre 2026.

2. La granularité de facturation : seconde, minute, milliseconde

Section intitulée « 2. La granularité de facturation : seconde, minute, milliseconde »

Tous les fournisseurs n'ont pas la même précision de facturation. Cette différence est technique en surface, financière en profondeur : sur un workload qui démarre et s'arrête souvent, l'écart de granularité change radicalement la facture.

Fournisseur / serviceGranularitéAnnée d'introduction
AWS EC2 Linuxseconde (min 60 s)octobre 2017
AWS EC2 Windows et SQL Serverseconde (min 60 s)juin 2021
AWS EC2 Red Hat Enterprise Linuxseconde (min 60 s)avril 2024
Azure Computeminutedepuis 2014
GCP Compute Engineseconde (min 60 s)depuis 2017
Outscale OAPI VMsheure2026
AWS Lambdamillisecondedepuis 2014
Azure Functions Consumptionmillisecondedepuis 2017
GCP Cloud Rundizaine de millisecondesdepuis 2019

La granularité fine (seconde, ms) avantage les workloads CI/CD, batch courts, fonctions événementielles. La granularité grossière (heure) pénalise les usages courts : une instance Outscale lancée pendant 5 minutes coûte la même chose qu'une instance lancée pendant 60 minutes, c'est le minimum facturé.

Conséquence pratique sur une CI : un job qui démarre 50 fois par jour pendant 6 minutes coûte ~50 € par mois en facturation seconde et ~500 € par mois en facturation heure. L'écart est d'un facteur 10, pour exactement le même calcul effectué.

Le prix on-demand est rarement celui que payent les entreprises matures. Trois modèles se superposent, chacun avec un compromis flexibilité/coût.

Vous lancez, vous payez à l'usage, vous arrêtez quand vous voulez. Aucun engagement, aucune réservation. C'est le défaut quand on lance une instance pour la première fois, c'est aussi le plus cher. Convient parfaitement aux MVP, à la R&D, aux pics imprévisibles, aux workloads qui meurent dans 2 mois.

Reserved Instances et Savings Plans : -30 % à -72 %

Section intitulée « Reserved Instances et Savings Plans : -30 % à -72 % »

En vous engageant sur 1 ou 3 ans d'usage, vous obtenez des remises massives. Un Reserved Instance 3 ans All Upfront chez AWS sur une c5.xlarge passe de 0,17 €/h à 0,063 €/h, soit −63 %. Les Savings Plans sont plus flexibles (engagement sur un montant horaire, pas sur un type d'instance), avec des remises légèrement inférieures.

Le piège : un engagement 3 ans est aussi rigide qu'un achat de serveur. Vous ne pouvez pas changer de région, vous payez même si vous arrêtez la VM, vous ne récupérez quasi rien si vous voulez sortir. C'est le CAPEX déguisé en OPEX dont je parle dans CAPEX vs OPEX.

Les instances Spot (AWS), Preemptible (GCP), Low-Priority (Azure) sont des VMs vendues sur le marché de la capacité excédentaire. Vous payez 5 à 30 % du prix on-demand, mais le fournisseur peut les couper avec 2 minutes de préavis quand il a besoin de la capacité ailleurs.

Convient parfaitement aux workloads tolérants à l'interruption : entraînement ML, traitement batch, encodage vidéo, CI/CD parallèle, fuzzing. Inadapté aux workloads stateful (bases de données, sessions utilisateur live), sauf à mettre en place une couche de tolérance aux pannes lourde.

ModèleRéduction vs on-demandEngagementRisque
On-demand0 %aucunaucun
Reserved 1 an-30 à -45 %1 anengagement long
Reserved 3 ans All Upfront-60 à -72 %3 ans + paiement avanceengagement très long
Savings Plan 3 ans-54 à -66 %3 ans (montant horaire)engagement long, plus flexible
Spot / Preemptible-60 à -91 %aucuninterruption 2 min préavis

Voici les cinq dérives que je retrouve systématiquement lors d'un audit de coûts cloud chez un client qui découvre la facture, classées par fréquence.

💸 Instance stoppée, EBS facturé

Le piège : on stoppe une instance le vendredi soir pour économiser, mais le disque EBS reste attaché et facturé 24/7. L'économie est partielle, pas totale.

Le calcul réel : une c5.xlarge à Paris coûte 147 USD par mois de calcul, et 200 Go de gp3 coûtent 18,56 USD. Éteindre la machine supprime le calcul mais pas le disque, donc vous économisez environ 89 % de la facture de cette machine, pas la totalité. L'écart devient significatif quand le volume est gros : sur 2 To de disque, le stockage pèse plus que le calcul et arrêter la machine ne fait presque plus baisser la note.

Mitigation : pour vraiment libérer les coûts, il faut détruire la VM (snapshot avant), pas juste l'arrêter. Auto Scaling Group avec scale-to-zero ou pipeline IaC qui detruit/recrée.

🌉 NAT Gateway facturée 24/7

Le piège : une NAT Gateway AWS coûte ~32 €/mois, plus ~0,045 € par Go traité. Beaucoup d'architectures en plantent une par AZ par environnement par défaut.

Mesure réelle : 3 environnements × 2 AZ × 1 NAT Gateway = 6 NAT Gateways = 192 €/mois rien que pour le NAT, hors trafic.

Mitigation : 1 seule NAT Gateway sur l'environnement de dev/test (pas par AZ), retirer pour les workloads sans besoin de sortie internet, alternative vpc-endpoint pour l'accès aux services AWS.

📸 Snapshots cumulatifs sans lifecycle

Le piège : politique de sauvegarde mise en place sans rétention. Les snapshots étant incrémentaux, la facture ne suit pas la taille du volume mais le cumul des blocs modifiés, qui croît indéfiniment tant que rien n'expire.

Ce qui dérive vraiment : ce n'est pas le premier snapshot, c'est la chaîne. Un parc où chaque machine produit un incrément quotidien conservé sans limite voit sa ligne de facturation snapshot croître de façon linéaire, mois après mois, sans qu'aucun événement ne la signale. Et supprimer les plus anciens ne la fait pas redescendre tant que les suivants référencent leurs blocs.

Mitigation : politique de rétention décidée avant la première sauvegarde, par exemple 7 quotidiens, 4 hebdomadaires, 3 mensuels et 1 annuel, automatisée via Data Lifecycle Manager côté AWS. Pour l'archivage long, le niveau archive descend à 0,0132 USD/Go-mois, au prix d'un délai et d'un coût de restauration.

🔀 Cross-AZ traffic invisible

Le piège : le trafic entre AZ est facturé ~0,01 €/Go dans chaque sens. Une application 3-tier mal conçue peut traverser les AZ à chaque requête, doublant ou triplant la facture réseau.

Mesure réelle : un cluster Kubernetes mal configuré avec scheduling aléatoire des pods peut générer 50 % de trafic cross-AZ inutile.

Mitigation : topology aware routing, zone-aware load balancing, placement strategies pour grouper les pods qui se parlent.

📜 Logs accumulés indéfiniment

Le piège : CloudWatch Logs facturé ~0,50 €/Go ingéré + ~0,03 €/Go-mois stocké. Un log applicatif verbose peut générer 100 Go/jour, soit ~50 € d'ingestion par jour.

Mesure réelle : équipe dev qui logge en DEBUG en production : 1 200 €/mois de CloudWatch Logs sur un service unique.

Mitigation : niveau de log INFO en prod, retention automatique 30 jours sur logs applicatifs, archive S3 Glacier au-delà.

5. Trois bonnes pratiques pour garder le contrôle de la facture

Section intitulée « 5. Trois bonnes pratiques pour garder le contrôle de la facture »

Pour ne pas subir la facture cloud, trois pratiques se sont imposées comme des fondamentaux de la gouvernance financière cloud (FinOps). Elles s'implémentent dans l'ordre logique suivant.

Le tagging obligatoire dès le démarrage. Une politique de tagging cohérente (CostCenter, Project, Environment, Owner, ManagedBy) appliquée par policy bloquante au moment du provisioning. Sans tags, on ne peut pas allouer la facture aux équipes ou aux projets, on paye globalement sans visibilité fine. Le coût de mettre en place le tagging tardivement est nettement supérieur à le faire dès le départ, parce qu'il faut alors rétro-tagger des ressources existantes.

L'audit mensuel humain de la facture. Un dashboard auto-rafraîchi que personne ne regarde n'a aucun effet, il faut un rituel mensuel d'une heure où une personne désignée ouvre la console de coûts, identifie le top des postes, justifie l'évolution mensuelle, et liste les actions correctives prioritaires du mois.

Les budgets cloud avec alarmes dès le démarrage. Tous les fournisseurs proposent un service de budget avec alertes (AWS Budgets, Azure Cost Management, Google Cloud Billing, équivalents chez les fournisseurs souverains). Paramétrer des seuils à 50 %, 80 % et 100 % du budget mensuel attendu, avec notification email et messagerie d'équipe, évite les mauvaises surprises liées à une fuite ou un usage anormal.

  • Une instance cloud se facture sur 8 axes simultanés : compute, stockage, egress, I/O, licence, snapshot, backup, support, pas seulement la VM affichée.
  • La granularité de facturation varie par fournisseur (seconde, minute, milliseconde) et impacte directement les workloads courts d'un facteur 10.
  • Les 3 modèles d'engagement offrent des arbitrages flexibilité/coût : on-demand pour le variable, Reserved/Savings Plans pour le socle stable, Spot pour le tolérant à l'interruption. Le mix optimal cible 60 à 70 % d'engagement.
  • Cinq pièges récurrents font dériver les factures : EBS oubliés, NAT Gateways non rationalisées, snapshots cumulatifs, cross-AZ traffic invisible, logs sans rétention.
  • Trois réflexes structurels au J1 : tagging obligatoire par policy, audit mensuel humain, budgets avec alarmes hard.

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracking. Un soutien, même symbolique, m'aide à couvrir l'hébergement et à garder ces ressources gratuites. Merci pour votre appui.

Le formulaire ne s'affiche pas ? Ouvrir Ko-fi dans un onglet.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn