Dès qu'une partie de votre infrastructure tourne en continu, la payer au tarif On-Demand revient à louer une voiture à la journée pour un trajet quotidien. AWS propose deux mécanismes d'engagement pour baisser ce coût. Voici comment les départager.
Reserved Instances : l'engagement précis
Vous réservez une capacité précise (type d'instance, région) sur 1 ou 3 ans, en échange d'une forte remise. C'est le plus économique quand votre usage est très prévisible et stable dans sa forme — mais c'est aussi le plus rigide : changer de type d'instance peut réduire le bénéfice.
Savings Plans : l'engagement flexible
Vous vous engagez sur un montant horaire de dépense (ex. 10 $/h) plutôt que sur une instance précise. La remise s'applique automatiquement à la consommation correspondante, quelle que soit la famille ou la région (pour les Compute Savings Plans). Un peu moins agressif que la RI maximale, mais bien plus souple si votre stack évolue.
La règle de décision
- Usage très stable et figé → Reserved Instances pour la remise maximale.
- Usage stable mais stack qui évolue → Compute Savings Plans pour la flexibilité.
- En pratique, un mix des deux couvre le socle en RI et la marge mouvante en Savings Plans.
Le vrai piège : la couverture
L'erreur n'est pas de choisir le mauvais instrument, c'est de mal calibrer le taux de couverture. Trop d'engagement gèle de la trésorerie sur une capacité que vous n'utilisez pas ; trop peu laisse filer l'économie. On vise la base stable et réelle, jamais des prévisions optimistes.
À retenir
- RI = remise maximale mais rigide ; Savings Plans = un peu moins, mais flexible.
- La plupart des scale-ups gagnent avec un mix des deux.
- Le facteur décisif est le taux de couverture, calibré sur la charge stable réelle.