AWS Savings Plans vs Reserved Instances 2026 : le guide de décision dont les Engineers ont vraiment besoin

Par Dima Kramskoy — Senior Cloud Architect chez DoiT International

La question que tout le monde pose de travers

À l'époque où je traitais les tickets d'optimisation cloud, c'était la question n°1 des clients : "Faut-il partir sur des Savings Plans ou des Reserved Instances ?" Je la voyais revenir trois ou quatre fois par semaine, chez des clients différents.

C'est la mauvaise question.

La bonne, c'est : à quoi ressembleront vos workloads dans 12 mois ?

Pourquoi ce recadrage compte : une organisation qui prépare une migration Graviton va gaspiller de l'argent sur des Standard RIs incapables de suivre ses workloads vers de nouvelles familles d'instances. Une équipe avec un cluster RDS taillé dans le marbre, dont la configuration n'a pas bougé depuis deux ans, laisse de l'argent sur la table en optant pour des Compute Savings Plans, là où un Standard RI offrirait 6 à 9 points de remise supplémentaires.

La décision SP vs RI n'est pas une affaire de produit. C'est une affaire d'orientation architecturale. Votre stratégie de commitments doit épouser votre roadmap d'infrastructure — et non l'inverse.

Et voici la vérité qui dérange : la plupart des clients que j'accompagne ne savent pas à quoi ressembleront leurs workloads dans 12 mois. Ils ignorent s'ils migreront vers Graviton le trimestre prochain, passeront aux conteneurs ou doubleront leur capacité de calcul. Ce n'est pas un défaut de planification — c'est la réalité. Si vous ignorez où vont vos workloads, c'est DÉJÀ votre réponse. Incertitude = flexibilité. Optez au minimum pour des Compute Savings Plans — ou mieux, laissez un outil porter intégralement le risque de commitment à votre place (j'y reviens à la fin).

Voici le cadre que j'utilise avec mes clients grands comptes, mis à jour avec tout ce qui a bougé en 2025–2026.

Réponse rapide : l'arbre de décision

Avant d'entrer dans le détail, voici la voie express :

DÉPART : quel est votre principal workload de compute ?
│
├─ EC2 uniquement, une seule famille d'instances, stable depuis 12+ mois
│   └─ → EC2 Instance Savings Plan ou Standard RI
│       ├─ Besoin d'une réservation de capacité ? → Zonal Standard RI
│       └─ Gestion plus simple ? → EC2 Instance SP
│
├─ EC2 sur plusieurs familles d'instances
│   └─ → Compute Savings Plan
│
├─ Migration Graviton prévue (x86 → arm64)
│   └─ → Compute Savings Plan (s'applique automatiquement à la nouvelle famille)
│
├─ Fargate, Lambda ou approche serverless-first
│   └─ → Compute Savings Plan (seul type qui les couvre)
│
├─ RDS / Aurora / couche base de données
│   └─ Config stable, remise max ? → Standard RI (jusqu'à 69 %)
│   └─ Multi-moteurs, Gen 7+, flexibilité ? → Database SP (jusqu'à 35 %)
│
└─ Re-architecture en cours ou migration hors AWS
    └─ → Ne vous engagez pas. Restez sur On-Demand/Spot jusqu'à stabilisation.

Tableau comparatif rapide

Ce qui a changé en 2025–2026

Quatre évolutions majeures depuis ma dernière revue d'optimisation des coûts :

1. Lancement des Database Savings Plans (décembre 2025)

La plus grosse annonce FinOps de re:Invent 2025. Les Database Savings Plans couvrent 10 services — Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS et OpenSearch.

Le hic : uniquement des engagements sur 1 an (pas de 3 ans), No Upfront uniquement, et ils exigent des instances Gen 7+ (db.r7g, db.m7g). La remise maximale tourne autour de 35 %, bien en deçà des 69 % atteignables avec des Standard RDS RIs. Ce n'est donc pas un remplaçant des DB RIs — c'est un levier de flexibilité pour les organisations dont le parc de bases de données est varié et en pleine évolution.

2. Restrictions de partage RI/SP (juin 2025)

AWS a interdit aux MSP et aux revendeurs de partager les remises RI/SP entre plusieurs clients finaux. Si vous achetez via un partenaire, vos commitments sont désormais limités à votre propre usage. Pour les acheteurs entreprise en direct : impact quasi nul.

3. Group Sharing — disponibilité générale (novembre 2025)

Celle-ci est passée sous les radars, mais elle résout un vrai point de friction. Vous pouvez désormais contrôler précisément quels comptes de votre Organization bénéficient des commitments partagés, avec deux modes :

• Prioritized Group Sharing : le commitment s'applique d'abord au groupe désigné, puis déborde vers le reste de l'organisation.
• Restricted Group Sharing : isolation totale — seul le groupe désigné en profite.

Cela enterre le sempiternel problème du "ce n'est pas la bonne équipe qui profite de notre RI" qui empoisonnait le consolidated billing depuis des années. Les groupes se définissent via les Cost Categories. Si vous pilotez une organisation multi-BU avec des modèles de refacturation interne, ça change la donne.

4. Les RIs ne sont PAS dépréciées

Malgré les spéculations récurrentes, les Reserved Instances restent pleinement supportées. Les pages tarifaires AWS sont activement maintenues (dernière mise à jour : mai 2026), Cost Explorer génère toujours des recommandations RI, et la RI Marketplace reste opérationnelle. AWS privilégie clairement les Savings Plans dans le développement de nouvelles fonctionnalités et la documentation, mais les RIs ne sont pas près de disparaître.

Un dernier point : les Savings Plans dont l'engagement dépasse 100 $/heure ne peuvent pas être retournés. En dessous de 100 $/heure, vous disposez d'une fenêtre de 7 jours dans le même mois calendaire, avec un maximum de 10 retours par an. À l'échelle d'une entreprise, ces engagements sont définitifs. Planifiez en conséquence.

En profondeur : Compute SP vs EC2 SP vs Standard RI vs Convertible RI

Voici le comparatif complet que j'aurais aimé avoir sous la main quand je prenais ces décisions :

*Les clients EDP ne peuvent pas vendre sur la RI Marketplace.

Ordre d'application des remises (à ne pas négliger)

AWS applique les remises dans cet ordre de priorité :

1. Les Reserved Instances s'appliquent en premier (sur les usages correspondants)
2. Les EC2 Instance Savings Plans s'appliquent ensuite
3. Les Compute Savings Plans s'appliquent en dernier (le filet le plus large)

Au sein de chaque niveau, les usages au pourcentage d'économies le plus élevé sont couverts en priorité. Vous pouvez donc empiler les trois sans risque de conflit — AWS optimise l'application automatiquement.

Portabilité des workloads : quand la flexibilité prime sur la remise

L'écart de remise entre Compute SP (66 %) et EC2 Instance SP (72 %) est d'environ 6 points. Dans les conditions entreprise typiques (1 an, no-upfront), il se réduit à 2–4 points. Voyons quand payer ce premium de flexibilité s'impose à l'évidence.

Migration Graviton

Passage de x86 (m5, c5, r5) à Graviton (m7g, c7g, r7g) :

• Compute SP : transparent. La remise s'applique automatiquement aux instances Graviton dès leur lancement.
• EC2 Instance SP : ça casse. m5 ≠ m7g — famille d'instances différente.
• Standard RI : totalement inutilisable pour les nouvelles instances. Engagement perdu.
• Convertible RI : nécessite un échange manuel, à valeur égale ou supérieure, et reste verrouillé à la région.

Si vous êtes sur la trajectoire Graviton (et vous devriez l'être — 20 à 40 % de meilleur rapport prix/performance), les Compute SPs sont structurellement supérieurs.

Conteneurisation / transition serverless

Passage d'EC2 vers ECS/Fargate ou Lambda :

• Compute SP : couvre Fargate et Lambda automatiquement. Votre remise vous suit.
• Tout le reste : zéro couverture sur le compute conteneurisé ou serverless.

Expansion multi-région

Ouverture d'une nouvelle région ou consolidation de 4 régions à 2 :

• Compute SP : la remise s'applique mondialement sur toutes les régions.
• Tous les autres : verrouillés à la région. Une consolidation rend vos commitments orphelins.

Le calcul

Sur 5 M$ de dépense compute annuelle, un écart de 6 points coûte environ 300 K$ sur 3 ans. Cela paraît significatif — jusqu'au moment où une migration Graviton ratée (parce que vous ne pouvez pas vous extraire de RIs verrouillés) vous prive du gain de 20 à 40 % de performance sur l'ensemble de votre parc. Le premium de flexibilité, c'est une assurance — et une assurance bon marché.

Les anti-patterns (ce qui se passe quand on se trompe)

En plus de 10 ans d'optimisation des coûts cloud, j'ai vu ces erreurs coûter des millions à des organisations. Voici les cinq plus chères :

Anti-pattern 1 : s'engager sur le pic plutôt que sur la baseline

L'erreur : acheter des commitments calés sur l'usage maximum observé.

Ce qui se passe : vous vous engagez sur 50 $/heure parce que c'est votre pic du lundi matin. Votre baseline soutenue est de 35 $/heure. Vous tournez à 70 % d'utilisation sur votre commitment — les 30 % restants sont du pur gaspillage.

Le coût : sur un commitment de 50 $/heure, 30 % de gaspillage = 131 K$/an partis en fumée.

La solution : engagez-vous sur 70 à 80 % de votre plancher soutenu (sur la base de 60 à 90 jours de données). Couvrez les pics avec du Spot et de l'On-Demand.

Anti-pattern 2 : Standard RIs sur des workloads sur le point de migrer

L'erreur : acheter des Standard RIs sur 3 ans pour une flotte m5 avec une migration Graviton inscrite à la roadmap.

Ce qui se passe : six mois plus tard, vous êtes prêt à passer sur m7g. Vos Standard RIs ne peuvent pas suivre. Ils ne sont pas convertibles. Si vous êtes client EDP, vous ne pouvez même pas les revendre sur la Marketplace. Vous payez pour des instances que vous ne faites plus tourner.

Le coût : un RI 3 ans orphelin sur r5.4xlarge : environ 278 $/mois de commitment pour zéro bénéfice pendant les 30 mois restants = 8 340 $ gaspillés par instance. Multipliez sur toute une flotte.

La solution : si un changement architectural est prévu pendant la durée du commitment, utilisez des Compute SPs.

Anti-pattern 3 : laisser des commitments expirer en silence

L'erreur : aucune surveillance des expirations ni de file de renouvellement.

Ce qui se passe : un lot de RIs expire un mardi. Personne ne s'en rend compte avant la facture de fin de mois. Votre taux effectif bondit de 278 $/mois à 736 $/mois par r5.4xlarge — soit plus de 62 % d'augmentation du jour au lendemain.

Le coût : une flotte de 20 instances repassant en On-Demand pour ne serait-ce qu'un mois : environ 9 160 $ de dépense imprévue.

La solution : alertes d'expiration via AWS Budgets + achats de Savings Plans mis en file avant la date d'expiration.

Anti-pattern 4 : ignorer le compute hors EC2

L'erreur : ne s'engager que sur EC2, alors que plus de 40 % de la dépense compute est sur Lambda, Fargate ou EKS.

Ce qui se passe : une part significative de la dépense serverless/conteneurs reste au tarif On-Demand plein. Les organisations qui n'optimisent que les commitments EC2 pensent avoir "fini le travail" alors qu'elles laissent 20 à 30 % d'économies sur la table pour leurs workloads à la croissance la plus rapide.

Le coût : 200 K$/an sur Lambda + Fargate en On-Demand, là où un Compute SP économiserait 20 à 66 % = 40 K$ à 132 K$/an d'économies manquées.

La solution : auditez TOUS les services éligibles. Un seul Compute SP couvre EC2, Lambda et Fargate à la fois.

Anti-pattern 5 : s'engager pendant une re-architecture active

L'erreur : acheter des commitments pendant un right-sizing, un re-platforming ou une migration.

Ce qui se passe : vous vous engagez sur 80 $/heure aujourd'hui. Sur les 6 mois suivants, l'optimisation ramène votre baseline à 55 $/heure. Vous voilà verrouillé sur 25 $/heure de gaspillage pour le reste du terme.

Le coût : 25 $/heure × 8 760 heures restantes sur un terme d'1 an = 219 K$ de commitment orphelin.

La solution : stabilisez d'abord, engagez-vous ensuite. Utilisez des commitments étagés alignés sur votre niveau de confiance — petits engagements pendant la migration, plus gros une fois les patterns d'usage consolidés.

Cadre de décision

Voici le tableau à mettre en capture d'écran :

La stratégie en couches (ce que je recommande à la plupart des organisations)

Ne choisissez pas un seul type. Empilez-les :

1. Couche 1 — Compute SPs (60 à 80 % de la baseline) : couvrez votre plancher de compute minimum avec une flexibilité maximale
2. Couche 2 — EC2 Instance SPs : superposez pour les familles dont vous êtes sûr (6 points de remise supplémentaires à la clé)
3. Couche 3 — Standard RIs : réservez-les aux workloads de couche données ultra-stables et aux besoins de capacité
4. Couche 4 — On-Demand/Spot : laissez les workloads variables et incertains sans commitment

Commencez par des termes d'1 an pour valider les patterns. Après 12 mois de données d'usage stables, superposez des termes de 3 ans sur votre baseline éprouvée (15 à 22 points de remise supplémentaires).

Comment DoiT automatise tout cela

Souvenez-vous de ce que je disais sur l'incertitude. La plupart des clients ne savent pas à quoi ressembleront leurs workloads dans 12 mois. C'est précisément pour ce cas d'usage que FlexSave for Compute a été conçu.

Le pitch en une phrase : vous bénéficiez des taux de remise des Savings Plans 1 an, sans aucun commitment de votre part. DoiT porte le risque.

Concrètement, voici ce qu'il fait :

• Surveille votre usage à la demande — analyse ce qui tourne, ce qui est stable, ce qui évolue
• Applique automatiquement les mécanismes de remise optimaux — couvre les workloads éligibles qui ne le sont pas déjà par vos propres RIs/SPs
• S'ajuste en continu — migration vers Graviton ? Scale down ? Passage à Fargate ? FlexSave s'adapte sans que vous ouvriez un tableur
• Aucun commitment de votre part — DoiT porte le risque. Vous touchez la remise. Vous partez quand vous voulez.
• Couvre toute la stack compute — EC2, ECS, EKS, Fargate, Lambda, SageMaker (pas seulement EC2)

Pour les bases de données : les nouveaux Database Savings Plans d'AWS (déc. 2025) sont votre meilleure option pour RDS et Aurora. FlexSave se concentre sur le compute — là où l'incertitude et les besoins de flexibilité sont les plus forts.

Pour avoir une vue d'ensemble sur votre portefeuille de commitments, DoiT Cloud Analytics vous donne les métriques d'utilisation, de couverture et de gaspillage au même endroit — vous savez à tout moment si votre stratégie tient la route.

La combinaison résout les deux problèmes : FlexSave prend en charge l'exécution face au "je ne sais pas ce qui m'attend", Cloud Analytics fournit le pilotage. L'incertitude cesse d'être un problème quand votre outillage s'adapte avec vous.

TL;DR

1. Les Compute SPs sont le choix par défaut pour la plupart des organisations — le premium de flexibilité (2 à 4 points dans les conditions typiques) en vaut presque toujours la peine pour les équipes ayant un changement architectural à la roadmap.

2. Les Standard RIs restent gagnants pour les workloads ultra-stables — couches base de données, réservations de capacité dictées par la conformité, et workloads avec 18+ mois de stabilité prouvée.

3. Les Database Savings Plans (nouveauté déc. 2025) sont un levier de flexibilité, pas de remise — 35 % contre 69 % pour les Standard RIs. Choisissez-les pour des parcs multi-moteurs en Gen 7+.

4. Superposez vos commitments — Compute SP comme socle, EC2 Instance SP pour les familles fiables, Standard RIs pour les bases stables, On-Demand pour le reste.

5. Ne vous engagez jamais pendant une migration active — stabilisez d'abord, engagez-vous ensuite. Le coût des commitments orphelins dépasse toujours celui de l'attente.

La bonne stratégie de commitments ne vise pas à maximiser la remise — elle vise à aligner vos engagements sur votre orientation architecturale.

Prêt à arrêter de gérer tout cela à la main ? Réservez une démo pour découvrir comment FlexSave optimise automatiquement vos commitments AWS.

Dima Kramskoy est Senior Cloud Architect chez DoiT International, avec plus de 20 ans d'expérience en software engineering, 10 certifications AWS et le statut d'AWS Community Builder (2026). Il est spécialisé en FinOps et optimisation des coûts cloud pour les grandes entreprises.