Instances réservées sur Outscale : le calcul que personne ne fait

Un account manager Outscale, à un moment donné, vous suggérera de réserver des instances. Le pitch sonne bien : 30 à 60 % de remise sur le tarif on-demand, engagement 1 à 3 ans, dépense prévisible. Signez ici.

Les instances réservées, ce n'est pas une arnaque. Mais le calcul est plus nuancé que "30 % de remise, qu'est-ce qu'on peut bien y trouver à redire". Voici quand elles gagnent vraiment, quand elles ne gagnent pas, et comment penser le choix.

Les chiffres affichés

Les remises actuelles d'Outscale dépendent de la durée d'engagement et du mode de paiement :

• 1 mois, paiement upfront — environ 30 % de remise sur on-demand
• 1 an — 40 à 50 % selon le mode de paiement
• 2 ans — 45 à 55 %
• 3 ans — 50 à 60 %

Ça a l'air solide. Ça l'est. Mais ces chiffres supposent quelque chose qui n'est pas toujours vrai : que l'instance va tourner 24/7 sur toute la durée.

Les petits caractères

Une réservation, c'est un engagement financier sur un type d'instance précis, dans une région précise, pour une durée précise. Vous payez le tarif réduit que l'instance tourne ou pas. Trois choses à intérioriser :

Vous payez 730 heures/mois, tous les mois. Même si la VM ne tourne en réalité que 200 heures. La remise porte sur le tarif horaire, pas sur la facture mensuelle.

La réservation ne bouge pas. Liée au type d'instance et à la région. Vous redimensionnez le workload sur une VM plus petite — la réservation appartient toujours à l'ancienne. Vous migrez vers une autre région — même problème.

La politique de réservation Outscale a rétréci. Les réservations 3 ans étaient autrefois standard ; beaucoup de types de comptes plafonnent maintenant à 1 ou 2 ans. Chaque coupe réduit la durée sur laquelle la remise se cumule.

Quand la réservation gagne vraiment

Trois formes de workload rendent les instances réservées sincèrement correctes :

1. Production toujours active avec demande stable. Une base de données qui tourne 24/7 pour les deux prochaines années. La remise réservée se cumule sur la durée. La planification ne peut pas aider (vous ne pouvez pas l'éteindre). Le redimensionnement peut, mais si vous l'avez déjà fait, la réservation est le levier suivant.

2. Workloads qui ne peuvent pas être planifiés. Certaines choses sont 24/7 par nature : l'API gateway, le serveur d'auth, le tier web derrière un load balancer. Ils tournent les 730 heures par design. La réservation est le bon outil.

3. Baseline prévisible + pic variable. Réservez la baseline, laissez le pic en on-demand. La plupart des workloads de prod ont un "nombre minimum d'instances" stable sur des années — c'est la portion réservable. Le delta d'autoscaling reste on-demand et se réduit naturellement aux heures creuses.

Quand la planification bat la réservation

Trois formes de workload où la planification gagne, parfois largement :

1. Dev / staging / QA. Utilisé 8 heures par jour, 5 jours par semaine. C'est 50/168 du temps total = 70 % de réduction de compute via planification. La réservation vous donne 50 % de remise, appliquée à 730 heures. La planification vous donne 100 % de remise sur les heures non utilisées, appliquée aux mêmes 730. La planification gagne par un facteur deux sur ce workload, à chaque fois.

2. Batch et ETL. Tourne 4 heures la nuit, reste idle 20. La réservation paie les 20 idle. La planification les éteint complètement.

3. Tout ce que vous pourriez redimensionner, refactoriser ou tuer dans la durée du contrat. La réservation ne suit pas le changement. Si vous êtes à 9 mois d'une réservation 3 ans quand quelqu'un refactore le service sur un type d'instance plus petit, la réservation initiale devient un sunk cost.

L'approche hybride

La bonne réponse pour la plupart des équipes n'est pas "réservation ou planification". C'est les deux, sur des parties différentes de la flotte.

1. Planifiez tout ce qui peut être planifié. Dev, staging, batch, tout ce qui est piloté par des humains. Ça réduit la facture on-demand de 30 à 70 % sur ces ressources.
2. Pour ce qui reste (la baseline toujours active), réservez. Production stable, bases de données, les choses qui tournent vraiment 730 heures/mois. Appliquez la remise de réservation.
3. Réévaluez tous les trimestres. Les formes de workload changent. La chose qui était toujours active il y a six mois pourrait avoir maintenant un creux clair aux heures creuses. La chose que vous avez réservée pourrait être en passe de disparaître.

La règle de décision

Voici un test simple. Pour tout workload candidat, demandez :

Est-ce que ça tourne plus de 730 × pourcentage-de-remise heures par mois ?

Pour une réservation à 50 %, c'est 365 heures. Si le workload consomme plus de 365 heures/mois — réservez-le (ou redimensionnez d'abord, puis réservez). S'il consomme moins, planifiez-le.

Pour une réservation à 30 %, le seuil est 511 heures. Pour 60 %, c'est 292.

Ce n'est pas une règle parfaite (elle ignore les bénéfices du redimensionnement, le risque de durée et le risque de migration), mais c'est un premier découpage solide. Tout ce qui tourne moins que le seuil est candidat à la planification. Tout ce qui tourne plus est candidat à la réservation.

La plupart des workloads ne sont pas au seuil. Ils sont soit clairement toujours actifs (bases de données prod) soit clairement périodiques (dev, batch, QA). Les cas vraiment ambigus sont rares. Ne vous noyez pas dedans — choisissez un défaut, faites tourner un trimestre, réévaluez.