Savings Plans vs Reserved Instances en 2026 : l'arbre de décision complet

Quatre mécanismes d’engagement coexistent aujourd’hui sur AWS pour réduire la facture compute : Compute Savings Plans, EC2 Instance Savings Plans, Reserved Instances Standard et Reserved Instances Convertibles. Sur le papier, ils font tous la même chose — échanger un engagement de durée contre un tarif réduit. En pratique, ils ne se comportent pas du tout pareil face à un changement de génération d’instance, un pivot d’architecture ou un besoin de capacité garantie.

Résultat en mission FinOps : la majorité des organisations auditées ont soit un mix hérité d’achats ponctuels sans logique d’ensemble, soit — pire — aucun engagement du tout sur un baseline pourtant stable depuis des années, par peur de se tromper de mécanisme. Les deux situations coûtent cher. Cet article pose la méthode : un arbre de décision, pas une liste de définitions.

Les 4 mécanismes, ce qu’ils couvrent réellement

Avant l’arbre de décision, il faut fixer les faits. Ce sont les chiffres publiés par AWS, pas des estimations tierces.

Deux points passent régulièrement sous le radar dans les comparatifs génériques qu’on trouve en ligne :

Un Savings Plan ne réserve pas de capacité. Il réduit la facture, point. Si vous avez besoin d’une garantie que des instances seront disponibles dans une AZ donnée — cas fréquent sur du GPU (p4d, p5) en période de tension d’approvisionnement — seule une Reserved Instance zonale le fait. C’est la confusion la plus coûteuse qu’on rencontre en audit : une équipe pense avoir sécurisé de la capacité avec un Compute SP, et découvre le jour J que ce n’est pas le cas.

Seul le RI Standard est revendable. Le RI Marketplace permet de céder les mois restants d’un engagement si le projet change de direction. Aucun autre mécanisme — ni EC2 Instance SP, ni Convertible RI, ni Compute SP — n’offre cette porte de sortie. C’est un vrai filet de sécurité pour un engagement 3 ans sur une organisation dont la roadmap à 3 ans n’est jamais garantie.

L’arbre de décision

La méthode qu’on applique en mission tient en quatre questions, dans cet ordre :

1. Le workload est-il stable depuis plus de 6 mois ?

Non — pas d’engagement. Un baseline non confirmé engagé à 1 ou 3 ans est le scénario qui génère le plus de gaspillage constaté en audit : instances réservées qui tournent à moitié vides parce que le produit a pivoté entre-temps. Restez On-Demand (ou Spot pour les workloads tolérants à l’interruption) jusqu’à avoir 3 à 6 mois de métriques stables via Cost Explorer.

2. Le mix instance/service peut-il changer avant l’échéance ?

Oui — famille d’instance, région, ou bascule vers Fargate/Lambda envisagée → Compute Savings Plan. C’est le seul mécanisme qui suit le workload automatiquement, sans perte de discount, quand il change de forme. C’est aussi le choix par défaut recommandé pour une organisation qui n’a pas encore une visibilité fine à 3 ans sur son architecture — la flexibilité vaut plus que les quelques points de discount supplémentaires d’un engagement plus rigide.

3. Besoin d’une garantie de capacité ?

Oui (GPU, instance spécialisée en zone tendue) → RI Standard zonale, seul mécanisme qui combine réduction tarifaire et réservation de capacité. Non → passez à la question 4.

4. Le projet peut-il changer de configuration avant l’échéance ?

Oui, mais vous voulez garder l’engagement (juste échanger la config) → RI Convertible, échangeable contre une autre famille ou région de valeur égale ou supérieure. Non, la configuration est figée pour la durée → arbitrage final entre EC2 Instance SP et RI Standard, qui offrent le même plafond de réduction (72 %). Le critère de choix à ce stade n’est plus le prix, mais l’optionalité : le RI Standard peut être revendu si le projet change quand même de direction, l’EC2 Instance SP ne le peut pas.

Le piège du renouvellement de génération

Un facteur souvent absent des comparatifs : le rythme de sortie des nouvelles générations d’instances. AWS a lancé les familles C8i/C8a en 2025 et poursuit ce rythme en 2026 (C8in/C8ib annoncées au printemps), avec un gain de prix/performance qui rend les engagements sur d’anciennes générations (C6i, C7i) de plus en plus discutables à mesure que le cycle avance.

Deux mécanismes seulement absorbent ce risque sans perte : le Compute Savings Plan, qui suit n’importe quelle famille, y compris une nouvelle génération lancée en cours d’engagement, et le RI Convertible, échangeable manuellement contre la nouvelle génération. Un RI Standard ou un EC2 Instance SP acheté sur une famille C6i en 2024 reste facturé sur cette famille jusqu’à l’échéance, même si C8i devient économiquement supérieur entre-temps — c’est un coût d’opportunité rarement chiffré, mais réel sur un engagement 3 ans.

Règle pratique : sur un engagement 3 ans, privilégier le Compute SP ou le Convertible RI dès que la famille d’instance a plus de 18 mois d’ancienneté au moment de l’achat — le risque d’obsolescence pendant l’engagement dépasse le gain de discount du mécanisme rigide.

Cas chiffré : baseline de 20 instances m6i.xlarge

Prenons un exemple représentatif d’une organisation avec un backend stable depuis plus d’un an, 20 instances m6i.xlarge (4 vCPU, 16 Go) tournant 24/7. Au tarif On-Demand public (0,192 $/h), la facture mensuelle de référence est d’environ 2 803 $ (20 × 0,192 × 730 h).

Sur ce profil précis — un baseline confirmé, une seule famille d’instance, pas de changement d’architecture prévu à 3 ans — le RI Standard 3 ans reste l’option la plus rentable en valeur absolue, avec en prime la porte de sortie du RI Marketplace si la roadmap change. C’est exactement le cas où la question 4 de l’arbre de décision penche vers RI plutôt qu’EC2 Instance SP : à discount comparable, l’optionalité gagne.

Ce qu’on recommande en pratique

1. Ne jamais engager 100 % du baseline. Couvrez 70 à 80 % du plancher observé sur 90 jours, laissez le reste en On-Demand pour absorber la variance saisonnière — l’ajustement se refait chaque trimestre via Cost Explorer.
2. Commencer en 1 an, pas en 3 ans, tant que l’historique de stabilité est inférieur à 12 mois — le delta de discount entre 1 et 3 ans (environ 20 points sur un RI Standard) ne compense pas le risque d’obsolescence ou de pivot produit sur une jeune stack.
3. Privilégier le Compute SP par défaut sur toute charge qui n’a pas un besoin documenté de réservation de capacité — c’est le choix qui minimise le risque opérationnel, même s’il n’est pas toujours le plus économique au dernier point de pourcentage.
4. Auditer le portefeuille d’engagements existant tous les trimestres via l’AWS Cost Explorer Savings Plans / RI utilization report — un engagement sous-utilisé (couverture < 90 %) signale un changement de workload qui n’a pas été suivi d’un ajustement.

aws ce get-savings-plans-utilization \
  --time-period Start=2026-06-01,End=2026-09-01 \
  --granularity MONTHLY \
  --query 'SavingsPlansUtilizationsByTime[].Total.{Coverage:UtilizationPercentage,Savings:NetSavings}' \
  --output table

Conclusion

Le choix entre Savings Plans et Reserved Instances n’est pas une question de “lequel est le moins cher” — sur un engagement 3 ans comparable, les deux plafonds se rejoignent à 72 %. La vraie question est celle du risque : risque de changement d’architecture (Compute SP), risque d’obsolescence de génération (Convertible RI ou Compute SP), besoin de capacité garantie (RI zonale), besoin d’une porte de sortie (RI Standard revendable). L’arbre de décision de cet article couvre ces quatre axes dans l’ordre où ils doivent réellement être posés.

Si votre portefeuille d’engagements AWS n’a pas été revu depuis plus d’un trimestre, ou si vous hésitez encore entre les deux mécanismes sur un nouveau projet, parlons-en — un audit FinOps type identifie en 3 à 5 jours la couverture optimale et le mix d’engagements adapté à votre trajectoire.