Lorsqu'il s'agit de réduire votre facture AWS, deux leviers dominent la stratégie FinOps : les AWS Savings Plans et les Instances Réservées (Reserved Instances). Les deux permettent d'économiser jusqu'à 75 % par rapport aux tarifs On-Demand — sur le papier, ça paraît simple. Mais en pratique, choisir le mauvais modèle peut vous enfermer dans un engagement coûteux ou, pire, vous faire passer à côté d'économies substantielles.
Honnêtement, j'ai vu des équipes FinOps expérimentées se tromper sur ce choix. En 2026, avec l'essor des architectures serverless, conteneurisées et multi-régions, la décision est devenue encore plus stratégique qu'elle ne l'était il y a trois ans. Ce guide vous donne les clés pour choisir — ou combiner — ces deux modèles selon votre profil de workload, avec des exemples CLI concrets à l'appui.
Comprendre les modèles de tarification engagée AWS
Les deux modèles partagent un principe commun : vous vous engagez à utiliser des ressources AWS sur 1 ou 3 ans en échange de remises substantielles par rapport aux tarifs On-Demand. La différence fondamentale ? La nature de l'engagement.
- Savings Plans : vous vous engagez sur un montant de dépense horaire (en $/heure), quelle que soit la ressource utilisée.
- Reserved Instances : vous vous engagez sur une configuration précise — type d'instance, taille, région, système d'exploitation.
Cette distinction a des implications majeures sur la flexibilité, le niveau de remise et la charge opérationnelle de gestion de vos engagements. Alors, plongeons dans les détails.
Les AWS Savings Plans : trois types pour couvrir l'ensemble de votre compute
Lancés en 2019, les Savings Plans sont devenus le modèle d'engagement privilégié d'AWS pour la majorité des workloads. Il en existe désormais trois types en 2026.
1. Compute Savings Plans — Jusqu'à 66 % de remise
C'est l'option la plus flexible — et franchement, celle que je recommande comme point de départ pour la plupart des équipes. Le Compute Savings Plan s'applique automatiquement à toute utilisation éligible d'EC2, AWS Fargate et AWS Lambda, quelle que soit la région, la famille d'instance, le système d'exploitation ou la taille. Il offre jusqu'à 66 % de remise par rapport aux tarifs On-Demand.
Exemple concret : Si vous migrez vos instances C4 vers M5, basculez d'une région EU (Irlande) vers EU (Londres), ou déplacez des workloads d'EC2 vers Fargate, votre remise Compute Savings Plan continue de s'appliquer automatiquement — sans aucune action requise de votre part. C'est exactement le genre de flexibilité qui change la vie lors d'une refonte d'architecture.
⚠️ Limitation Lambda : Seul le coût de durée d'exécution Lambda bénéficie de la remise. Les frais de requêtes (0,20 $ par million) ne sont pas couverts. De même pour Fargate, la remise ne s'applique pas aux frais de licence OS.
2. EC2 Instance Savings Plans — Jusqu'à 72 % de remise
Ce plan offre la remise la plus élevée des Savings Plans (jusqu'à 72 %), en contrepartie d'un engagement sur une famille d'instances spécifique dans une région donnée. Vous pouvez librement changer la taille de l'instance (large, xlarge, 2xlarge...) et le système d'exploitation, mais pas la famille ni la région.
Il ne couvre pas Fargate ou Lambda — uniquement EC2 dans la famille et région choisies. C'est un excellent complément aux Compute SPs si vous avez des familles d'instances bien identifiées et stables.
3. Database Savings Plans — Jusqu'à 35 % de remise (nouveau depuis fin 2024)
Annoncés à AWS re:Invent 2024, les Database Savings Plans apportent pour la première fois des remises par engagement aux services de bases de données gérées. Pour un engagement d'un an, vous obtenez jusqu'à 35 % de remise sur Aurora, RDS (tous moteurs), DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces et Timestream — sans contrainte de région, de famille d'instance ou de moteur de base de données.
Beaucoup d'équipes ignorent encore ce type de plan. C'est une opportunité d'économie facile à saisir si votre facture de base de données est significative.
Les Instances Réservées : remise maximale pour les charges stables
Les Reserved Instances (RIs) restent parfaitement pertinentes en 2026 pour les workloads stables et prévisibles. Elles offrent la remise la plus élevée du catalogue AWS, mais exigent une planification précise de vos besoins futurs. Ne vous laissez pas tenter par les remises alléchantes sans avoir fait vos devoirs d'analyse d'usage d'abord.
Standard Reserved Instances — Jusqu'à 75 % de remise
Les Standard RIs offrent la remise maximale : jusqu'à 75 %. En contrepartie, elles sont strictement liées à un type d'instance, une taille, une région et un OS spécifiques. Elles ne peuvent pas être modifiées, mais elles peuvent être revendues sur l'AWS Reserved Instance Marketplace si votre architecture change — un avantage clé par rapport aux Savings Plans.
Les Standard RIs Zonales (Zonal RIs) offrent en plus une réservation de capacité physique dans une zone de disponibilité spécifique, ce qui est crucial pour les applications critiques qui ne peuvent pas se permettre une indisponibilité de capacité lors de pics de demande.
Convertible Reserved Instances — Jusqu'à 66 % de remise
Les Convertible RIs offrent des remises de 31 à 66 % et peuvent être échangées contre des instances d'autres familles de valeur égale ou supérieure. C'est une option de protection contre les cycles de renouvellement technologique — par exemple, si vous prévoyez de migrer de x86 vers ARM/Graviton dans les 12 prochains mois.
⚠️ Depuis janvier 2024, les clients sous le programme Enterprise Discount Program (EDP) ne peuvent plus vendre des RIs à prix réduit sur le Marketplace. Vérifiez votre contrat avant d'acheter des Standard RIs en grande quantité.
Tableau comparatif complet 2026
| Critère |
Compute SP |
EC2 Instance SP |
Standard RI |
Convertible RI |
| Remise maximale |
66 % |
72 % |
75 % |
66 % |
| Couvre Lambda / Fargate |
✅ Oui |
❌ Non |
❌ Non |
❌ Non |
| Flexibilité région |
✅ Totale |
❌ Fixe |
❌ Fixe |
⚠️ Échangeable |
| Flexibilité famille instance |
✅ Totale |
❌ Fixe |
❌ Fixe |
⚠️ Échangeable |
| Revendable |
❌ Non |
❌ Non |
✅ Oui |
❌ Non |
| Réservation de capacité |
❌ Non |
❌ Non |
✅ (Zonal) |
❌ Non |
| Adapté à l'autoscaling |
✅ Parfait |
⚠️ Limité |
❌ Déconseillé |
❌ Déconseillé |
| Couvre RDS / ElastiCache |
❌ Non |
❌ Non |
✅ Oui |
✅ Oui |
Comment AWS applique les remises : l'ordre de priorité
AWS applique les remises dans un ordre précis — et le comprendre est essentiel pour éviter les doublons ou les gaps de couverture :
- Reserved Instances sont appliquées en premier sur l'utilisation correspondante.
- EC2 Instance Savings Plans couvrent l'utilisation EC2 restante dans la famille et région engagées.
- Compute Savings Plans comblent le reste de l'utilisation EC2, Fargate et Lambda.
- L'utilisation non couverte est facturée au tarif On-Demand.
Cette hiérarchie empêche les chevauchements et maximise le bénéfice total des remises. Veillez cependant à ne pas sur-engager en combinant RIs et Savings Plans qui couvriraient les mêmes workloads — c'est l'une des erreurs classiques que j'observe régulièrement.
Exemples pratiques : analyse et achat via l'AWS CLI
Avant d'acheter tout engagement, analysez votre utilisation historique. Voici quelques commandes CLI qui méritent d'être dans votre boîte à outils FinOps.
Étape 1 : Obtenir les recommandations de Savings Plans (Cost Explorer)
# Recommandations basées sur les 60 derniers jours d'utilisation
aws ce get-savings-plans-purchase-recommendation \
--savings-plans-type COMPUTE_SP \
--term-in-years ONE_YEAR \
--payment-option NO_UPFRONT \
--lookback-period-in-days SIXTY_DAYS \
--region us-east-1 \
--query 'SavingsPlansPurchaseRecommendation.{EstimatedROI:SavingsPlansDetails,Summary:SavingsPlansPurchaseRecommendationSummary}'
Étape 2 : Vérifier vos Savings Plans actifs
# Lister tous vos Savings Plans actifs avec leur taux d'utilisation
aws savingsplans describe-savings-plans \
--states active \
--region us-east-1 \
--query 'savingsPlans[*].{
ID:savingsPlanId,
Type:savingsPlanType,
Commitment:commitment,
Debut:start,
Fin:end,
Region:region
}' \
--output table
Étape 3 : Identifier les offres disponibles et acheter
# Trouver les Offering IDs disponibles pour un Compute SP 1 an
aws savingsplans describe-savings-plans-offerings \
--product-type EC2 \
--plan-types COMPUTE_SP \
--durations 31536000 \
--region us-east-1 \
--query 'searchResults[*].{ID:offeringId,Type:planType,Remise:discountPercentage}' \
--output table
# Acheter un Compute Savings Plan (engagement exemple : 0.50 $/heure)
aws savingsplans create-savings-plan \
--savings-plan-offering-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
--commitment 0.50
💡 Conseil FinOps : N'achetez jamais un engagement avant d'avoir mis en place une gouvernance des coûts cloud robuste. Acheter des Savings Plans sans visibilité claire sur votre utilisation réelle est l'une des erreurs les plus coûteuses en FinOps — vous risquez de sur-engager et de payer pour une couverture inutilisée.
Scénarios d'usage : quand choisir quoi
Scénario 1 : Workloads conteneurisés avec autoscaling (EKS / ECS)
→ Recommandation : Compute Savings Plans
Si vos pods Kubernetes ou conteneurs ECS s'ajustent dynamiquement, les Savings Plans sont l'option idéale. La remise suit la dépense, pas la machine. Que votre cluster scale de 10 à 100 nœuds, vos Compute SP continuent de s'appliquer sans configuration supplémentaire. Simple, efficace.
Scénario 2 : Bases de données RDS stables (PostgreSQL, MySQL, Aurora)
→ Recommandation : Reserved Instances Standard (ou Database Savings Plans)
Un serveur RDS db.r6g.2xlarge tournant 24h/24 depuis plusieurs années ne bougera pas de sitôt. Les Standard RIs offrent jusqu'à 75 % de remise sur ce type de workload prévisible. Depuis 2024, évaluez aussi les Database Savings Plans si vous utilisez plusieurs moteurs ou régions. Combinez avec des instances Spot pour vos environnements de développement et de staging pour maximiser les économies globales.
Scénario 3 : Applications serverless (Lambda + API Gateway)
→ Recommandation : Compute Savings Plans
Lambda bénéficie des Compute Savings Plans. Si votre budget Lambda mensuel dépasse 500 $, un engagement modeste peut générer 20–30 % d'économies supplémentaires. Rappel : seuls les coûts de durée d'exécution sont couverts, pas les frais de requêtes.
Scénario 4 : Migration x86 → Graviton (ARM)
→ Recommandation : Compute Savings Plans
Si vous planifiez une migration de vos instances M5 (x86) vers M7g (Graviton), un Compute Savings Plan suit automatiquement ce changement architectural. Un EC2 Instance Savings Plan ou un Standard RI resterait inutilisé pendant la transition, générant du gaspillage — ce serait dommage après avoir fait tous ces efforts de migration.
Scénario 5 : Applications critiques avec SLA strict et réservation de capacité
→ Recommandation : Standard RIs Zonales + On-Demand Capacity Reservations
Pour des applications qui ne peuvent pas subir d'indisponibilité de capacité lors de pics (e-commerce, finance), les Zonal Reserved Instances offrent une réservation de capacité physique dans une zone de disponibilité. Les Savings Plans ne fournissent pas cette garantie de capacité — c'est un point critique souvent négligé.
La stratégie hybride recommandée en 2026
La majorité des équipes FinOps expérimentées n'adoptent pas une approche exclusive. Elles privilégient une stratégie en couches — et honnêtement, c'est la seule approche qui tient la route à long terme. Voici le modèle recommandé pour les équipes AWS en 2026 :
-
Couche 1 — Compute Savings Plans (principal véhicule d'engagement)
Couvrez 70–80 % de votre dépense compute plancher (les 60 derniers jours) avec des Compute SPs sur 1 an. C'est la base de toute stratégie d'engagement moderne.
-
Couche 2 — EC2 Instance Savings Plans (familles stables)
Pour les familles d'instances stables et identifiées (ex. : m6i en us-east-1 pour vos serveurs applicatifs), ajoutez des EC2 Instance SPs pour profiter des 72 % de remise.
-
Couche 3 — Standard RIs et Database SPs (données et services spécialisés)
Utilisez les Standard RIs pour RDS, ElastiCache et Redshift. Évaluez les Database Savings Plans pour les architectures multi-moteurs. C'est la seule couche d'optimisation disponible pour ces services.
-
Couche 4 — On-Demand (overflow et flexibilité)
Conservez 20–30 % de votre utilisation en On-Demand pour absorber les pics imprévus et les nouvelles initiatives sans risque de sur-engagement.
L'objectif est clair : couvrir votre baseline garantie avec des engagements, pas votre pic d'utilisation. Engager sur un pic, c'est la garantie de payer pour de la capacité sous-utilisée.
Erreurs courantes à éviter absolument
- Sur-engager par rapport à votre baseline réelle. Si votre utilisation diminue (right-sizing, économies d'optimisation), votre engagement continue de s'appliquer. Engagez-vous toujours sur 70–80 % de votre plancher historique, jamais sur votre pic.
- Ignorer la fenêtre de remboursement de 7 jours. C'est votre seule porte de sortie pour les Savings Plans (limitée aux plans ≤ 100 $/heure). Au-delà, l'engagement est irrévocable.
- Acheter des RIs pour des workloads avec autoscaling actif. Les RIs ne s'ajustent pas dynamiquement et peuvent devenir largement inutilisées si les instances scalent vers d'autres tailles ou familles.
- Oublier les Database Savings Plans. Depuis leur lancement fin 2024, c'est une opportunité manquée pour toute équipe qui n'optimise que le compute EC2.
- Négliger Lambda dans les calculs d'engagement. Si votre dépense Lambda mensuelle est significative (>500 $), elle doit être intégrée dans votre stratégie Compute Savings Plans.
Outils AWS natifs pour prendre la bonne décision
Avant d'acheter le moindre engagement, exploitez ces outils gratuits — ils font le gros du travail d'analyse à votre place :
- AWS Cost Explorer → Savings Plans Recommendations : Analyse vos 7, 30 ou 60 derniers jours d'utilisation et recommande le montant d'engagement optimal avec le ROI estimé.
- AWS Compute Optimizer : Identifie les instances sur-provisionnées via ML avant que vous n'achetiez des engagements sur des ressources à redimensionner. Évitez de commettre sur du "gras".
- AWS Trusted Advisor : Alerte sur les RIs et Savings Plans sous-utilisés (taux d'utilisation < 80 %).
- AWS Cost Anomaly Detection : Surveillez les pics de dépense On-Demand qui pourraient indiquer de nouvelles opportunités d'engagement.
Questions Fréquemment Posées
Quelle est la différence principale entre un AWS Savings Plan et une Reserved Instance ?
Un Savings Plan est un engagement sur un montant de dépense horaire ($/heure), flexible et applicable à plusieurs services (EC2, Lambda, Fargate). Une Reserved Instance est un engagement sur une configuration précise (type d'instance, région, OS) qui offre une remise plus élevée mais moins de flexibilité architecturale.
Peut-on combiner des AWS Savings Plans et des Reserved Instances ?
Oui, et c'est même la stratégie recommandée. AWS applique d'abord les RIs, puis les EC2 Instance Savings Plans, puis les Compute Savings Plans. Une stratégie hybride — Compute SP pour le compute variable et RIs pour les bases de données stables — maximise généralement les économies globales.
Les AWS Savings Plans couvrent-ils AWS Lambda ?
Oui, les Compute Savings Plans couvrent la durée d'exécution Lambda. En revanche, les frais de requêtes Lambda (0,20 $ par million d'invocations) ne bénéficient d'aucune remise Savings Plans. Les Reserved Instances ne couvrent pas Lambda.
Est-il possible de revendre un AWS Savings Plan non utilisé ?
Non. Contrairement aux Standard Reserved Instances qui peuvent être revendues sur l'AWS Reserved Instance Marketplace, les Savings Plans n'ont pas de marché secondaire. La seule sortie est la fenêtre de remboursement de 7 jours après l'achat, limitée aux plans dont l'engagement horaire est inférieur ou égal à 100 $/heure.
Quel est le meilleur AWS Savings Plan pour les environnements Kubernetes (EKS) ?
Le Compute Savings Plan est idéal pour EKS. Puisqu'il s'applique à la dépense EC2 quelle que soit la taille ou la famille d'instance, il suit naturellement l'autoscaling de vos nœuds Kubernetes — que votre cluster scale de quelques nœuds m5.large à des dizaines de m5.2xlarge, la remise reste appliquée.
