RI, Savings Plans, Spot et on-demand — la matrice de décision par forme de charge

Une revue FinOps sur une facture AWS de 50 k$/mois (compute seul) trouve 100 % en on-demand. L’équipe plateforme ne s’est pas engagée parce que la feuille de route bouge vite et personne ne veut verrouiller de la capacité qui s’avère être la mauvaise famille d’instance dans six mois. Les économies sur la table sont réelles — la ligne on-demand est 30 % au-dessus de ce que le même compute coûterait sous un engagement raisonnable. La question n’est pas de s’engager ou non ; c’est quel engagement correspond à quelle charge, et quelle part du parc laisser en on-demand pour la flexibilité. La matrice de décision ci-dessous a quatre colonnes — RI, Savings Plans (Compute et EC2 Instance), Spot, on-demand — et un petit ensemble de formes de charge qui correspondent proprement à chacune.

Ce qui se passe

Les quatre modèles de prix et leurs différences structurelles :

La distinction haut niveau entre Compute Savings Plans et EC2 Instance Savings Plans : Compute est plus large (couvre aussi Fargate et Lambda, famille d’instance flexible) mais le taux de remise est plus bas. EC2 Instance est plus étroit (une famille dans une région) et le taux de remise est plus élevé. Pour une charge tournant 24/7 sur m6i dans us-east-1, EC2 Instance est la meilleure affaire ; pour une charge qui bascule entre EC2 et Fargate au gré de l’évolution architecturale, Compute est l’engagement plus sûr.

Les deux cas où les Reserved Instances gagnent encore en 2026 : les réservations RDS (les Savings Plans ne couvrent pas RDS) et les charges où la fonctionnalité d’échange des Convertible RI fournit une flexibilité spécifique non disponible dans les Savings Plans. Pour tout le reste, les Savings Plans ont largement remplacé les RIs parce que la flexibilité de famille les rend moins risqués.

Spot est sa propre catégorie. Les instances Spot sont de la capacité EC2 qu’AWS vend en remise profonde mais peut récupérer avec un avertissement de 2 minutes. L’ajustement, ce sont les charges qui peuvent absorber l’interruption — traitement par lot, runners de CI build, dev/test, workers web sans état derrière un autoscaling group avec stratégie capacity-optimized. L’ajustement, ce ne sont pas les bases de données, les caches avec état, les services à instance unique. Le patron malheureux, ce sont les équipes qui lisent la remise de 90 %, mettent la production en Spot sans concevoir pour l’interruption, et perdent l’état quand une récupération Spot survient.

Comment vérifier

Les recommandations Cost Explorer et la couverture courante :

# couverture courante
aws ce get-savings-plans-coverage \
  --time-period Start=$(date -u -v-30d +%Y-%m-%d),End=$(date -u +%Y-%m-%d) \
  --granularity MONTHLY \
  --query 'SavingsPlansCoverages[].[TimePeriod.Start,Coverage.CoveragePercentage]' \
  --output table

# recommandations
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 \
  --query 'SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationDetails[].[InstanceFamily,EstimatedSavingsPercentage,UpfrontCost,HourlyCommitmentToPurchase]' \
  --output table

La fenêtre de lookback de 60 jours est la fenêtre de calibration qu’AWS utilise pour projeter l’engagement. Si la fenêtre de lookback inclut une période inhabituelle (un pic de campagne, un mois avec un environnement périmé depuis supprimé), la recommandation sera décalée. Relancer la recommandation après que la charge se soit stabilisée pendant au moins 30 jours.

Pour la vérification d’éligibilité Spot, lister les charges :

aws ec2 describe-instances \
  --query 'Reservations[].Instances[?InstanceLifecycle==`null`].[InstanceId,InstanceType,Tags[?Key==`workload-type`].Value|[0]]' \
  --output table

Tout ce qui est tagué batch, ci, dev, stateless-worker est candidat à Spot. Tout ce qui est tagué database, stateful, singleton ne l’est pas.

La correction

La matrice de décision par forme de charge, avec l’engagement correspondant :

Production en état stable (24/7, prévisible) :

• Les 80 % de baseline qui tournent en continu reviennent aux Savings Plans.
• Si la charge est verrouillée sur une famille d’instance pour le futur prévisible, EC2 Instance Savings Plans pour la remise plus profonde.
• Si l’architecture peut basculer entre EC2 et Fargate, Compute Savings Plans pour la flexibilité.
• Durée : 1 an. Les durées de 3 ans donnent une remise plus profonde mais verrouillent la capacité à travers des cycles architecturaux qui invalident souvent l’engagement. La remise marginale sur l’année 3 vaut rarement le lock-in.
• Paiement : no-upfront dans la plupart des cas. Les options de paiement à l’avance donnent quelques pourcents en plus mais immobilisent de la trésorerie. Prendre la remise opérationnelle, garder la trésorerie qui circule.

Production bursty (baseline prévisible + pic variable) :

• Couvrir la baseline (le p10 de la taille du parc, ou ce qu’est le plancher toujours-allumé) avec des Savings Plans.
• Laisser la couche bursty supérieure en on-demand.
• L’erreur est de s’engager sur la moyenne. Un engagement au-dessus du plancher toujours-allumé gaspille la remise pendant le creux ; un engagement sous le plancher laisse des économies sur la table pendant le pic.

Batch tolérant à l’interruption (CI, ETL, entraînement, workers sans état) :

• Spot, avec ASG mixed-instance et stratégie d’allocation capacity-optimized.
• La stratégie capacity-optimized biaise vers les types d’instance avec le taux d’interruption le plus bas au moment de la demande. La variante price-capacity-optimized ajoute un poids prix.
• Toujours avoir un fallback on-demand : un ASG avec OnDemandPercentageAboveBaseCapacity réglé pour que la charge survive à une rupture Spot. Un mélange typique est 30 % de baseline on-demand + 70 % de Spot pour le sommet variable.

Imprévisible, courte durée (proof-of-concept, charges irrégulières) :

• On-demand. L’engagement demande de la prévisibilité. Une charge qui pourrait être supprimée dans trois mois ne devrait pas être sur un engagement de 12 mois.
• La prime de 30 % pour on-demand est le coût de l’option, et l’option vaut de l’argent réel quand la feuille de route est incertaine.

Bases de données et caches avec état :

• RDS Reserved Instances pour la tier base (les Savings Plans ne couvrent pas RDS).
• ElastiCache et Redshift ont leurs propres options RI.
• Jamais de Spot.

Le calcul de break-even est direct une fois la charge classifiée. Un Savings Plan 1 an en option no-upfront break-even au mois 6 — si la charge tourne en continu pendant au moins six mois, l’engagement paie par rapport à on-demand. Après six mois, chaque mois supplémentaire est pure économie.

Pour les durées de 3 ans, le break-even pousse à environ la marque des 12 mois quand on intègre la valeur-temps de l’argent plus la probabilité plus élevée que la charge change de forme sur trois ans. L’engagement de 3 ans n’est correct que lorsque la charge est assez stable pour que l’équipe projette confiamment l’usage à trois ans (un service plateforme de longue durée, une charge réglementée qui ne peut bouger de cloud, une ligne produit établie). Pour la plupart des SaaS, 1 an est le bon appel.

Le choix Compute contre EC2 Instance dans les Savings Plans :

• Si 80 % du parc tourne sur une famille dans une région pour le futur prévisible : EC2 Instance, prendre la remise plus profonde.
• Si le parc utilise trois ou quatre familles sur deux régions : Compute, prendre la flexibilité.
• Si la charge mélange EC2 et Fargate : Compute, parce qu’EC2 Instance ne couvre pas Fargate.
• Si la charge est purement Lambda : les Compute Savings Plans couvrent Lambda (la seule option d’engagement qui le fait).

L’arbitrage du lock-in est réel. Une équipe qui s’engage à 100 % en Savings Plans ne laisse aucune place à la charge pour rétrécir — si le parc baisse de 30 % après un refactor, l’engagement inutilisé est quand même facturé. La règle des 80 % est le compromis pratique : s’engager sur les 80 % planchers d’usage, laisser le haut variable en on-demand. Réévaluer tous les six mois.

Trois règles sur chaque mission de stratégie d’engagement :

Classifier avant de s’engager. Un tableur listant chaque charge, sa forme (stable/bursty/batch/imprévisible), sa cible d’engagement, son modèle de prix courant. L’engagement est mécanique une fois la matrice remplie.

S’engager sur la baseline, pas sur la moyenne. Le plancher toujours-allumé est l’engagement sûr. Tout au-dessus est on-demand ou Spot, selon la tolérance à l’interruption.

Durées 1 an par défaut. La remise 3 ans est réelle mais le lock-in se compose à travers les cycles architecturaux. Les engagements de 3 ans n’appartiennent qu’aux charges avec une stabilité pluriannuelle prouvée.

La classification initiale sur une facture de 50 k$/mois tient en deux jours concentrés. Le premier tour d’engagements capture typiquement 25 à 30 % de la facture dans le premier mois. Le rythme continu est une revue trimestrielle liée à la cadence d’audit de coûts du playbook Stack Harbor plus large.

Stack Harbor opère le nettoyage IAM, la baseline CloudWatch, AWS Backup et le rythme de contrôle des coûts dans le cadre de Gestion AWS et des Environnements infogérés en continu. Si la facture est à 100 % en on-demand sur une charge stable, commencez par une consultation d’infrastructure.