Modèles de tarification du cloud

Payer le même tarif, qu'on ait besoin de flexibilité ou non

Faites tourner un serveur de base de données 24 heures sur 24, tous les jours, pendant 3 ans d'affilée, et vous payez toujours exactement le même tarif horaire qu'une équipe qui pourrait éteindre son serveur demain. Le tarif à la demande est construit pour cette seconde équipe, celle qui a besoin de la liberté de partir à tout moment. Si une charge de travail ne part jamais, cette flexibilité intégrée n'est pas gratuite. L'équipe qui la fait tourner chaque heure paie silencieusement pour une option qu'elle n'utilise jamais.

À la demande : payer exactement ce que vous utilisez, quand vous l'utilisez

Le tarif à la demande n'exige aucun paiement d'avance ni engagement de longue durée. AWS facture les instances EC2 On-Demand à l'heure ou à la seconde, avec un minimum de 60 secondes, à un tarif fixé par le fournisseur et indépendant de l'ancienneté du client. C'est le modèle construit exactement pour le problème que la première leçon de ce domaine a ouvert : deviner combien de capacité une charge de travail toute neuve ou imprévisible va réellement demander. Devinez mal en mode à la demande, et la correction prend quelques clics, pas un retour de matériel.

Réservé et par engagement : échanger de la flexibilité contre une remise

Engagez-vous sur un usage stable pendant 1 ou 3 ans, et un fournisseur intègre cette certitude dans un tarif plus bas. AWS appelle ça Reserved Instances ou Savings Plans, avec une remise allant jusqu'à 72 % par rapport au tarif à la demande, un engagement de 3 ans offrant toujours une remise plus importante qu'un engagement d'un an parce qu'il retire davantage d'incertitude à la planification du fournisseur. Le paiement peut se répartir de 3 façons : intégralement d'avance, partiellement d'avance, ou sans rien d'avance, et en général, plus vous payez d'avance, plus la remise est profonde.

Les Reserved Instances existent en 2 catégories, et la différence entre elles vaut la peine d'être connue précisément. Les Standard Reserved Instances verrouillent la remise la plus importante, mais la famille d'instance et la région restent fixes pour toute la durée de l'engagement ; elles peuvent être modifiées dans certaines limites, mais jamais échangées contre autre chose. Les Convertible Reserved Instances sacrifient une partie de cette remise en échange du droit d'échanger la réservation plus tard contre une famille d'instance différente, utile pour une équipe qui prévoit que ses besoins vont évoluer avant la fin de l'engagement.

D'autres fournisseurs vendent la même idée sous des noms différents. Azure appelle sa version Reserved VM Instances, avec également jusqu'à 72 % de remise sur le tarif à l'usage, et ajoute quelque chose de spécifique à son propre modèle économique : Azure Hybrid Benefit permet à une entreprise qui possède déjà des licences Windows Server ou SQL Server de les appliquer dans le cloud, en cumul avec une réservation, pour une remise combinée pouvant atteindre 85 %. Google Cloud appelle l'équivalent Committed Use Discounts, jusqu'à 55 % de remise sur les types de machine standard et jusqu'à 70 % sur les types optimisés en mémoire, en échange du même engagement de 1 ou 3 ans.

Google Cloud ajoute une seconde remise qu'AWS et Azure n'offrent pas du tout : le Sustained Use Discount, appliqué automatiquement, sans engagement d'aucune sorte. Faites tourner une VM éligible pendant plus de 25 % d'un mois de facturation, et Google Cloud commence à la remiser tout seul, la remise augmentant à mesure que le temps d'exécution de la VM approche le mois complet, jusqu'à environ 30 % de remise. Chez AWS et Azure, une remise n'existe que si vous vous y engagez à l'avance. Chez Google Cloud, faire simplement tourner une charge de travail assez longtemps en gagne une automatiquement. C'est une vraie différence structurelle entre la façon dont les 3 fournisseurs tarifient l'engagement, pas seulement 3 noms pour le même mécanisme.

Spot et préemptible : la remise la plus profonde, avec un vrai piège

Le tarif spot vend de la capacité inutilisée qu'un fournisseur préfère fortement remiser plutôt que de la laisser inactive. Les instances EC2 Spot d'AWS offrent une remise allant jusqu'à 90 % par rapport au tarif à la demande, mais AWS peut reprendre cette capacité avec seulement 2 minutes de préavis dès qu'il en a besoin pour un client à la demande ou par engagement. Les Azure Spot Virtual Machines offrent jusqu'à 90 % de remise sur le tarif à l'usage et ne proposent aucune option de réservation. Les Google Cloud Spot VMs offrent jusqu'à 91 % de remise, et peuvent être préemptées à tout moment.

Ce modèle correspond à un travail tolérant aux pannes et aux interruptions : traitement de données par lots, pipelines CI/CD, rendu, tout ce qui enregistre sa progression assez souvent pour qu'une interruption coûte quelques minutes, pas une tâche entièrement ratée.

Il est tentant de traiter le tarif spot comme une simple version moins chère du tarif à la demande. Ce n'en est pas une. C'est de la capacité non engagée que le fournisseur peut reprendre dès qu'un client à la demande ou par engagement en a besoin à sa place. Placer une base de données de production, quelque chose qui ne tolère pas un arrêt soudain, sur du tarif spot est une des erreurs d'optimisation de coûts les plus fréquentes que commettent les équipes, et un piège classique dans les scénarios de type examen, précisément pour cette raison.

Les 3 modèles, côte à côte

Exemple chiffré : ce que vaut réellement un engagement

Prenons une charge de travail dont le tarif à la demande coûte 1 000 dollars par mois. Engagez-la sur un Savings Plan de 3 ans au plafond annoncé par AWS, jusqu'à 72 % de remise, et la même charge de travail coûte environ 280 dollars par mois, une économie d'environ 720 dollars par mois, soit environ 8 640 dollars sur une année, en échange de renoncer à la possibilité de partir sans pénalité.

Cette remise ne se rentabilise que si l'engagement est réellement utilisé. Une Reserved Instance de 3 ans dimensionnée pour un projet annulé après 8 mois devient un coût fixe avec 28 mois restants à payer et plus rien à faire tourner dessus, ce qui explique exactement pourquoi un engagement doit suivre un usage mesuré et stable, pas un pari sur une croissance future, le même problème de pari qui rendait l'informatique traditionnelle sur site si coûteuse au départ.

Ce que vous en retenez

Faites correspondre l'engagement à votre degré de certitude, et à ce que coûterait réellement une interruption. Une charge de travail qui tourne tous les jours pendant les 3 prochaines années mérite un tarif par engagement. Une charge de travail qui peut perdre une heure de progression et simplement redémarrer relève du spot. Tout ce qui se trouve entre les deux reste à la demande jusqu'à ce qu'il y ait assez d'historique d'usage pour s'engager avec confiance. Aucun de ces tarifs horaires ne raconte toute l'histoire, cependant : le prix affiché ici n'est pas la même chose que ce qu'une charge de travail coûte réellement à une entreprise pour tourner, une fois comptés les gens, les outils et tout ce qui se construit autour. Cet écart est exactement ce que mesure le coût total de possession, et c'est là que ce sujet va ensuite.