Reserved Instances ou Savings Plans : décider quoi réserver sur AWS à partir de l'usage réel

S'engager auprès d'AWS est le moyen le plus direct de payer moins pour la même chose : vous réservez de la capacité ou un montant de dépense pendant un ou trois ans et vous obtenez en échange une remise importante sur le prix à la demande. Le revers, c'est que l'engagement se paie même si vous ne l'utilisez pas. Réserver une machine que vous éteignez quatre mois plus tard coûte plus cher que de ne rien réserver. Cet article résume ce que sont les Reserved Instances et les Savings Plans, puis montre, étape par étape, comment décider quoi réserver avec les données d'usage qu'AAA Sentinel collecte déjà sur votre compte.

Reserved Instances et Savings Plans en deux minutes

Les deux formules échangent un engagement contre une remise, mais elles ne portent pas sur la même chose :

• Reserved Instances (RI) : vous vous engagez sur une configuration précise (type d'instance, région, système d'exploitation) pendant 1 ou 3 ans. Elles existent pour EC2 et aussi pour des bases de données comme RDS. Sur EC2, il y a deux variantes : Standard, avec la plus forte remise (AWS annonce jusqu'à 72 %) et peu de flexibilité, et Convertible, avec une remise un peu plus faible (jusqu'à 66 %) en échange de la possibilité de l'échanger contre une autre configuration.
• Savings Plans : vous vous engagez à dépenser un montant fixe par heure (par exemple 10 US$/heure) pendant 1 ou 3 ans, et AWS applique la remise à ce qui correspond. Le Compute Savings Plan couvre EC2, Fargate et Lambda, quelles que soient la famille, la taille ou la région (jusqu'à 66 %). L'EC2 Instance Savings Plan se limite à une famille dans une région et se rapproche de la remise d'une RI Standard (jusqu'à 72 %).
• Modes de paiement, dans les deux cas : tout d'avance (All Upfront), une partie (Partial Upfront) ou rien d'avance (No Upfront). Plus vous avancez, plus la remise est forte ; mais même sans rien payer au départ, vous vous engagez à payer chaque mois de la période.

Laquelle choisir

Il n'y a pas de réponse universelle, mais une règle pratique fonctionne pour la plupart des équipes :

• Architecture qui évolue (conteneurs, migrations entre familles, Lambda ou Fargate) : Compute Savings Plan. Vous perdez un peu de remise, mais l'engagement reste utile même si vous changez de machine.
• Parc stable qui ne changera ni de famille ni de région pendant la période : RI Standard ou EC2 Instance Savings Plan, qui offrent la plus forte remise.
• Bases RDS : les Compute Savings Plans ne couvrent pas RDS, la voie classique reste donc les RI RDS.
• Durée : trois ans doublent presque la remise d'un an, mais aussi le risque. Cela ne vaut la peine que pour des charges dont vous êtes très sûr.

Le problème : s'engager à l'aveugle

Une réservation n'économise de l'argent que si la machine aurait de toute façon tourné. Une m5.large à eu-west-1 coûte environ 73 US$ par mois à la demande ; la même avec une RI d'un an sans paiement initial, environ 45 US$. Autrement dit, la RI coûte autour de 62 % du prix à la demande. Si cette instance devait tourner moins de 62 % des heures du mois, la réservation vous fait perdre de l'argent. La bonne question n'est donc pas « quelle remise m'accorde-t-on ? », mais « quelles charges sont assez stables pour que je m'y engage ? ». Et pour y répondre, il faut des données d'usage, pas des intuitions.

Ce que vous y gagnez

Décider des réservations avec des données change la discussion avec la finance :

• Vous savez quelles instances précises sont candidates et pourquoi, au lieu de réserver « un pourcentage de la facture ».
• Vous voyez l'économie à 1 an et à 3 ans côte à côte, avec un niveau de confiance pour chaque recommandation.
• Vous connaissez l'engagement réel que vous signez : ce que vous paierez chaque mois quoi qu'il arrive.
• Vous pouvez valider l'impact dans le simulateur avant d'acheter quoi que ce soit.

Ce que couvre AAA Sentinel (et ce qu'il ne couvre pas)

Autant être clair dès le départ : les recommandations de réservation d'AAA Sentinel couvrent aujourd'hui les Reserved Instances AWS pour les instances EC2 et les bases RDS. La plateforme ne recommande ni Savings Plans, ni réservations Azure, ni Committed Use Discounts (CUD) de Google Cloud. Si vous utilisez ces formules, évaluez-les avec les outils natifs de chaque fournisseur :

• Savings Plans AWS : dans la console Billing and Cost Management, Savings Plans → Recommendations. AWS calcule l'engagement horaire à partir de votre usage récent.
• Réservations Azure : Azure Advisor, dans ses recommandations de coût, propose des réservations selon l'usage de vos machines virtuelles et d'autres services.
• CUD Google Cloud : le Recommender de Google Cloud (visible dans la console de facturation) propose des engagements selon votre consommation.

Cas pratique : le parc stable d'ACME

ACME, une entreprise fictive, a un compte AWS à eu-west-1, sous Linux, avec tout allumé le mois entier. Sa dépense totale sur ce compte tourne autour de 2 400 US$ par mois. Voici la partie qui nous intéresse :

Étape 1 : partir du Résumé des économies

Une fois le compte connecté et au moins une analyse terminée, ouvrez Optimisation → « Résumé des économies ». Cette page est disponible dans tous les plans et réunit le potentiel d'économies de la dernière analyse : « Total économies/mois » (Reserved Instances à 1 an plus rightsizing), le nombre de « Candidats RI » et le « Détail des économies potentielles ». De là, vous accédez aux trois pages de détail : Instances réservées, Rightsizing et « Simulateur d'économies », qui nécessitent le plan Pro (l'essai gratuit de 30 jours inclut Pro).

Étape 2 : lire la page Instances réservées

Dans Optimisation → « Instances réservées » (/savings/reservations), vous verrez, pour le compte sélectionné (si vous en avez plusieurs, un sélecteur se trouve en haut à droite) :

• Un sélecteur de durée, « 1 an » ou « 3 ans », qui recalcule toute la page.
• Trois indicateurs : « Économies 1 an » (ou « Économies 3 ans »), avec l'économie mensuelle totale ; « Candidats », les instances qui remplissent les critères ; et « Analysés », le nombre d'instances évaluées.
• Un tableau avec une ligne par candidate : « Instance » (nom et identifiant), « Type », prix On-Demand, prix de la RI, « Économies » en montant et en pourcentage, CPU moyen et « Confiance ».
• Un encadré « Comment ça fonctionne ? » qui résume les critères et les hypothèses de prix.

Étape 3 : comprendre les critères et la confiance

Savoir comment une candidate est choisie, c'est ce qui permet de se fier à la liste. Voici les critères exacts :

• EC2 : uniquement les instances en cours d'exécution, d'un type présent dans le catalogue de prix de la plateforme et coûtant au moins 10 US$ par mois à la demande. En plus, le CPU moyen des 30 derniers jours (ou des 7 derniers, s'il n'y a pas 30 jours de métriques) doit être d'au moins 15 %.
• Confiance EC2 : « Élevée » si le CPU moyen est d'au moins 30 % et que le p95 ne dépasse pas le double de la moyenne ; « Moyenne » si la moyenne est d'au moins 15 % et que le p95 ne dépasse pas le triple ; « Faible » sinon. Une instance avec de fortes pointes ne disparaît pas de la liste : elle apparaît avec une confiance « Faible », à lire comme un avertissement, pas comme une recommandation.
• RDS : instances d'une classe présente dans le catalogue, d'au moins 10 US$ par mois, avec une moyenne de connexions sur 7 jours supérieure à 0,5. La confiance est « Élevée » au-delà de 5 connexions en moyenne et « Moyenne » sinon. Il n'y a pas de colonne CPU pour RDS.

Étape 4 : les hypothèses de prix et le résultat d'ACME

Les montants proviennent d'un catalogue de prix approximatifs d'eu-west-1 pour Linux, avec des RI sans paiement initial (No Upfront) et, pour RDS, en Single-AZ. Le même catalogue s'applique quelle que soit la région de l'instance. Avec la durée sur « 1 an », la page d'ACME affiche « Économies 1 an » de 287,10 US$/mois, 9 « Candidats » et 11 « Analysés » (les 9 instances EC2 en cours d'exécution plus les 2 RDS). Sur « 3 ans », l'économie monte à 458,50 US$/mois. Voici le détail à 1 an :

Étape 5 : décider ce que l'on réserve vraiment

La liste est un point de départ, pas un bon de commande. ACME la passe en revue avec l'équipe et écarte deux candidates :

• La t3.medium des rapports, à cause de sa confiance « Faible » : avec des pointes proches de quatre fois la moyenne, l'équipe préfère étudier une autre taille avant de s'engager pour un an.
• La base de staging, parce qu'ils prévoient de l'éteindre la nuit. Une réservation sur une ressource éteinte la moitié du temps perd presque tout son intérêt.
• Résultat : ils réservent les 4 m5.large, les 2 c5.xlarge et la db.m5.large. Économie : 255,70 US$/mois, environ 3 068 US$ par an.
• Engagement : ils paieront 424,70 US$ par mois pendant 12 mois (5 096,40 US$ au total), qu'ils utilisent ou non ces machines. À la demande, elles leur coûtaient 680,40 US$/mois.

Étape 6 : valider dans le simulateur

Dans Optimisation → « Simulateur d'économies », ACME active le scénario « Instances Réservées (1 an) ». Le champ « Économies estimées (USD/mois) » est déjà pré-rempli avec le total à 1 an de la dernière analyse (287,10). Elle le remplace par 255,70 pour refléter sa décision et clique sur « Simuler les économies ». Le simulateur renvoie « Économies mensuelles » 255,70 US$, « Économies annuelles » 3 068,40 US$ et « Nouveau coût », c'est-à-dire la dépense mensuelle du compte lors de la dernière analyse moins cette économie : environ 2 144 US$.

• Vous pouvez combiner ce scénario avec « Rightsizing des instances » et les autres, mais attention : si une instance apparaît à la fois dans Rightsizing et dans Instances réservées, redimensionnez-la d'abord, puis réservez-la à sa nouvelle taille. Les deux économies ne s'additionnent pas telles quelles.
• Le scénario de réservation du simulateur fonctionne sur 1 an. Pour comparer avec 3 ans, utilisez le sélecteur de durée de la page Instances réservées.

Étape 7 : acheter la réservation sur AWS

AAA Sentinel recommande, mais n'achète pas : la réservation s'achète dans la console AWS (EC2 → Reserved Instances pour les instances, RDS → Reserved instances pour les bases). Choisissez les mêmes type, région, système d'exploitation et mode de paiement que ceux évalués. Après l'achat, les analyses suivantes verront toujours ces instances en cours d'exécution : ne soyez pas surpris qu'elles restent dans la liste, la plateforme ne lit pas encore les réservations que vous détenez déjà.

Ce qu'il ne fait pas encore

Pour que l'outil vous aide sans mauvaise surprise, mieux vaut connaître ses limites actuelles :

• Il ne recommande que des Reserved Instances AWS pour EC2 et RDS. Il ne recommande ni Savings Plans, ni réservations Azure, ni CUD Google Cloud.
• Il ne tient pas compte des réservations ni des Savings Plans déjà achetés : vérifiez votre couverture actuelle dans AWS Cost Explorer avant d'en acheter d'autres.
• Il utilise des prix de catalogue approximatifs d'eu-west-1 (Linux, No Upfront, RDS Single-AZ), pas votre prix exact.
• Les types d'instance absents du catalogue sont ignorés.
• Il n'achète ni ne gère les réservations à votre place.

Checklist avant de réserver

Avec ces points vérifiés, chaque euro engagé aura derrière lui une charge qui l'utilise vraiment :

• Compte AWS connecté et une analyse récente terminée.
• Liste des candidates revue dans Instances réservées, à 1 et à 3 ans.
• Candidates en confiance « Faible » étudiées une par une, pas réservées à l'aveugle.
• Retiré de la liste tout ce que vous allez éteindre, redimensionner ou migrer pendant la période.
• Couverture actuelle en RI et Savings Plans vérifiée dans AWS Cost Explorer.
• Scénario validé dans le Simulateur d'économies et prix confirmé dans la console AWS.
• Pour les Savings Plans, Azure ou Google Cloud : recommandations natives de chaque fournisseur.