Le prix affiché d'une instance est le plus élevé que vous paierez jamais. Cette leçon présente les trois façons d'acheter du calcul et leur compromis souplesse contre prix, la mise à l'échelle automatique qui ajuste la capacité à la charge, les instances vendues sur la capacité excédentaire, et les rares situations qui justifient de sortir du modèle partagé.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Choisir entre paiement à l'usage, engagement et capacité excédentaire.
- Faire varier la capacité automatiquement, sur la bonne métrique.
- Identifier ce qui peut tourner sur de l'interruptible, et ce qui ne le peut pas.
- Reconnaître les trois cas qui justifient un hôte dédié ou du bare metal.
Ce qu'on paie, et les trois façons d'acheter
Section intitulée « Ce qu'on paie, et les trois façons d'acheter »Le même calcul se vend à trois prix, selon l'engagement que vous acceptez. L'écart entre le plus cher et le moins cher dépasse souvent un facteur trois.
| Mode | Principe | Pour quoi |
|---|---|---|
| À la demande | plein tarif, aucun engagement | charges imprévisibles, tests, pointes |
| Réservé ou engagement | remise contre un engagement d'un à trois ans | le socle qui tourne en permanence |
| Interruptible (spot) | forte remise, la machine peut être reprise avec un court préavis | calcul par lots, tolérant à l'interruption |
La faute classique est d'acheter du réservé trop tôt, avant de connaître son socle réel. Un engagement de trois ans sur une machine qu'on redimensionne six mois plus tard coûte plus cher que le plein tarif. Mesurez d'abord, engagez ensuite, et seulement sur ce qui ne bouge plus.
Le détail des modèles tarifaires est traité dans Pay-as-you-go et modèles tarifaires.
Faire varier la capacité automatiquement
Section intitulée « Faire varier la capacité automatiquement »La mise à l'échelle automatique ajoute et retire des machines selon une mesure, et son piège n'est pas le réglage du seuil : c'est le délai. Une instance qui met quatre minutes à démarrer et à devenir utile arrive après un pic de deux minutes. Vous payez le mécanisme, vous subissez quand même la saturation, et vous vous retrouvez ensuite avec des machines en trop.
Trois réglages décident du résultat, et le dernier est celui qu'on oublie :
| Réglage | Ce qu'il fait | La valeur qui marche |
|---|---|---|
| La mesure déclenchante | choisit sur quoi on réagit | rarement le processeur seul : la longueur de file d'attente ou le temps de réponse reflètent mieux la douleur réelle |
| Le délai de stabilisation | empêche d'enchaîner les décisions | assez long pour qu'une machine ajoutée ait produit son effet avant la décision suivante |
| Le temps de préparation | durée avant qu'une nouvelle machine serve | à réduire d'abord, en préparant une image complète plutôt qu'en installant au démarrage |
Réduire le temps de préparation vaut mieux que régler finement les seuils. Une image qui contient déjà l'application démarre en une minute là où une installation au démarrage en demande cinq, et cette seule différence transforme un mécanisme décoratif en mécanisme utile. C'est la raison pratique de préférer une image préconstruite, comme expliqué plus haut.
Les instances interruptibles : jusqu'à 90 % moins cher
Section intitulée « Les instances interruptibles : jusqu'à 90 % moins cher »Les fournisseurs revendent leur capacité inutilisée à prix cassé, à une condition : ils peuvent vous la reprendre. La remise atteint couramment 70 à 90 % selon le fournisseur et le type de machine, ce qui en fait le levier d'économie le plus spectaculaire du cloud, et le plus mal exploité.
Le préavis avant reprise est court, et il diffère d'un fournisseur à l'autre :
| Fournisseur | Nom commercial | Préavis avant reprise |
|---|---|---|
| AWS | instances Spot | deux minutes |
| Google Cloud | machines Spot | trente secondes |
| Azure | machines virtuelles Spot | trente secondes |
Ce préavis dicte à lui seul les usages possibles. Trente secondes suffisent à finir une tâche courte et à rendre la main proprement ; elles ne suffisent pas à vider un serveur de session. La question à se poser n'est donc pas « puis-je économiser », mais « que se passe-t-il si cette machine disparaît maintenant, au milieu de son travail ? ».
Les charges qui s'y prêtent partagent toutes la même propriété, celle d'être reprenables :
- Le traitement par lots découpé en tâches courtes, où perdre une tâche revient à la relancer ailleurs.
- Les tests et l'intégration continue, dont l'échec sur reprise se traduit par une nouvelle exécution, pas par un incident.
- Les nœuds supplémentaires d'un cluster de calcul, à condition que le socle minimal reste sur des machines classiques.
- L'entraînement de modèles avec points de reprise réguliers, où l'on repart du dernier point plutôt que du début.
Ce qui ne s'y prête pas tient en une phrase : tout ce qui détient un état que personne d'autre ne détient. Une base de données, un serveur de sessions en mémoire, l'unique instance qui sert votre site. Le raisonnement est le même que pour la maintenance imposée par le fournisseur, décrit dans exploiter un environnement cloud : une architecture qui survit à la disparition brutale d'une machine ouvre des économies qu'une architecture fragile ne peut pas prendre.
Quand faut-il sortir du modèle partagé ?
Section intitulée « Quand faut-il sortir du modèle partagé ? »Par défaut, votre machine virtuelle partage un serveur physique avec celles d'autres clients. C'est ce qui rend le cloud abordable, et c'est acceptable dans l'immense majorité des cas. Trois raisons, et trois seulement, justifient d'en sortir, chacune vers une offre différente et nettement plus chère.
| Ce que vous cherchez | L'offre correspondante | Ce que ça change vraiment |
|---|---|---|
| Ne pas partager le matériel avec d'autres clients | hôte dédié ou instance dédiée | l'isolation devient physique, ce que certains audits exigent |
| Compter des licences au processeur physique | hôte dédié, avec visibilité sur les sockets | une licence logicielle facturée au socket devient calculable, et souvent moins chère |
| Supprimer entièrement la couche de virtualisation | serveur bare metal | vous récupérez les performances brutes et les fonctions matérielles, vous perdez l'instantané et la recréation en une minute |
Le bare metal se paie surtout en souplesse. La machine ne se recrée pas en quelques secondes, son approvisionnement prend des minutes voire des heures, et les mécanismes d'instantané auxquels vous vous êtes habitué disparaissent. Ne l'envisagez que si vous avez mesuré le gain, pas si vous le supposez.
Le cas des cartes graphiques mérite un avertissement à part. Une instance équipée d'un accélérateur coûte plusieurs euros de l'heure, elle est soumise à des quotas serrés, et sa disponibilité n'est jamais garantie dans toutes les zones. La dérive la plus fréquente est banale et douloureuse : une machine allumée pour un essai, oubliée le vendredi, et deux mille euros de facture le lundi. Posez le budget et l'alerte avant de démarrer la première, pas après.