Savings Plans ou instances réservées : que choisir sur AWS?

Un Compute Savings Plan est l’option la plus souple : selon AWS, il s’applique à EC2, à Fargate et à Lambda sans vous lier à une famille d’instances ni à une région. Les RI standard et les EC2 Instance Savings Plans annoncent un rabais maximal plus élevé (72 % contre 66 %), mais en échange d’une flexibilité moindre. Les bases de données ont leurs propres plans. Voici ce que dit la documentation d’AWS (état en novembre 2026), ce qu’il faut mesurer avant d’acheter et ce que nous vérifierions d’abord.

Qu’est-ce qu’un Savings Plan, au juste?

Selon AWS, un Savings Plan donne un prix inférieur au tarif à la demande (On-Demand) en échange d’un engagement de dépense horaire, mesuré en dollars par heure, pour un an ou trois ans. Vous ne réservez donc pas une machine : vous promettez de dépenser un montant minimal chaque heure.

Vous pouvez payer en totalité d’avance, en partie d’avance ou sans paiement initial. Le prix reste le même pendant toute la durée du plan.

Quels types de plans existent?

AWS en propose quatre. Les rabais ci-dessous sont des maximums annoncés par AWS, jamais une promesse pour votre facture.

Database35%

SageMaker AI64%

Compute66%

EC2 Instance72%

Source : documentation AWS Savings Plans, types de plans, novembre 2026. Ce sont des maximums, pas des économies garanties.

• Compute : jusqu’à 66 % de rabais. S’applique à EC2 peu importe la famille, la taille, la région, le système d’exploitation ou le mode d’hébergement, et aussi à Fargate et à Lambda.
• EC2 Instance : jusqu’à 72 %. Engagement sur une famille d’instances dans une région (par exemple m5 en Virginie), mais la taille, le système d’exploitation et le mode d’hébergement (dédié ou partagé) peuvent changer.
• Database : jusqu’à 35 %. Couvre Aurora, RDS, DynamoDB, ElastiCache et plusieurs autres services de données, mais seulement les dernières générations d’instances provisionnées, selon la documentation.
• SageMaker AI : jusqu’à 64 % pour les instances SageMaker.

Savings Plans ou instances réservées?

Le tableau comparatif d’AWS met en parallèle les plans et les RI :

Les RI convertibles peuvent changer de famille, mais seulement par des échanges manuels. Selon AWS, les Compute Savings Plans offrent un rabais comparable aux RI convertibles, avec plus de souplesse et sans échanges. Les EC2 Instance Savings Plans ressemblent aux RI standard.

Trois points à retenir, tirés de la même page :

• Un Savings Plan ne réserve pas de capacité. Si vous en avez besoin, AWS indique que vous pouvez créer une réservation de capacité à la demande (ODCR) et que le plan s’y appliquera.
• Il ne s’applique pas à l’usage Spot ni à l’usage déjà couvert par des RI.
• Il ne peut pas être annulé pendant la durée de l’engagement.

Qu’est-ce qui n’est pas couvert?

La documentation précise des limites utiles, dont une touche directement les équipes sur Kubernetes. Les plans Compute et EC2 Instance s’appliquent aux instances EC2 qui forment des grappes EMR, EKS et ECS, mais les frais du service Amazon EKS lui-même ne sont pas couverts. Les instances dédiées (Dedicated Instances) facturent aussi 2 $ l’heure dans chaque région où une instance dédiée tourne, et ces frais ne bénéficient pas du rabais des plans.

Combien s’engager?

Notre approche : nous partons du plancher d’usage observé, pas de la moyenne. Un engagement trop élevé vous fait payer des heures que vous n’utilisez pas, et le plan ne se résilie pas. AWS précise que les prix ne changent pas selon le montant horaire engagé, et qu’il est possible d’acheter des plans supplémentaires plus tard si l’usage augmente.

1. 1Mesurer l’usage stable
2. 2Engager le plancher
3. 3Suivre la couverture
4. 4Ajouter au besoin

Notre approche générale, sans chiffres.

Voici comment nous procéderions cette semaine :

1. Regarder les recommandations dans AWS Cost Explorer, que la documentation décrit comme point de départ pour choisir un montant, en le traitant comme une hypothèse, pas comme une réponse.
2. Repérer l’usage stable : bases de données de production, nœuds de grappe toujours allumés, services qui tournent 24 heures sur 24.
3. Écarter ce qui bouge : charges en migration, environnements de test, projets que vous pourriez arrêter dans l’année. Un projet de changement de fournisseur ou de refonte pèse sur le choix de la durée.
4. Commencer par un seul plan, modeste. Suivre pendant un mois la couverture (la part de l’usage couverte par le plan) et l’utilisation (la part de l’engagement réellement consommée), puis ajouter.
5. Connaître la fenêtre de retour. Selon la documentation d’AWS sur le retour, un plan actif dont l’engagement est de 100 $ l’heure ou moins peut être retourné dans les sept jours suivant l’achat et dans le même mois civil (heure UTC), tant que la limite de retours n’est pas atteinte. Les frais initiaux sont alors remboursés, et le retour exige une permission précise. Hors de ces conditions, le plan ne se retourne pas.

Que vérifierions-nous d’abord?

Nous commencerions par ces vérifications :

• Ce qui est déjà couvert. Des RI existantes ou de l’usage Spot peuvent réduire ce qu’un nouveau plan couvrirait.
• La feuille de route technique. Si vous passez d’EC2 à des conteneurs sans serveur ou changez de région, un Compute Savings Plan résiste mieux qu’un engagement sur une famille précise.
• Le poids des bases de données. Si RDS ou Aurora pèse lourd, nous regardons les Database Savings Plans séparément.
• La gouvernance. Qui peut acheter, qui valide, et qui suit la couverture chaque mois? Un engagement non suivi devient vite une dépense oubliée.
• L’étiquetage des coûts. Sans étiquettes, impossible de relier l’économie à un produit ou à une équipe.

Si vous voulez une revue de votre facture infonuagique avec un regard d’ingénierie, consultez nos services.

Cet article offre de l’information générale fondée sur la documentation publique d’AWS en novembre 2026. Il ne constitue pas un conseil financier : vérifiez les prix et conditions actuels et validez avec un professionnel avant tout engagement.