Quel montant d'engagement AWS Savings Plans choisir ? Le problème du dimensionnement — et comment arrêter de deviner

La réponse courte

Si vous ne retenez qu'une chose de cet article : engagez-vous sur votre base durable — le compute qui tourne réellement en continu — pas sur la semaine moyenne, ni sur le pic. Traduisez-la en une politique de couverture que vous pouvez défendre (la part de vos dépenses que vous voulez placer sous engagement, plus un plafond à ne pas franchir), puis ajoutez de l'engagement par petites étapes vers cette cible plutôt qu'en un seul gros achat.

Tout ce qui suit explique pourquoi c'est la bonne réponse, pourquoi le processus habituel la rend difficile à appliquer, et comment la mettre en œuvre en continu sans surveiller un tableur en permanence.

Pourquoi le combien est réellement difficile

Commençons par deux termes que l'on emploie indifféremment, à tort : couverture et utilisation.

• La couverture correspond à la part de vos dépenses à la demande éligibles placées sous engagement. Si vous consommez environ 80 $/heure de compute éligible aux Savings Plans et que 60 $/heure sont couverts, votre couverture est de 75 %.
• L'utilisation correspond à la part de l'engagement acheté effectivement consommée. Si vous vous engagez à 70 $/heure et que seuls 60 $/heure d'utilisation correspondante se matérialisent, vous êtes à ~86 % d'utilisation — et vous payez toujours le tarif engagé pour les 14 % restés inutilisés.

Voici la partie inconfortable : ces deux indicateurs évoluent en sens inverse dès qu'on agit dessus. Visez une couverture plus élevée et vous achetez plus d'engagement, ce qui expose l'utilisation au moindre creux d'activité. Protégez l'utilisation en achetant prudemment et votre couverture — et vos économies — restent faibles. Dimensionner un engagement, c'est précisément choisir où placer le curseur entre ces deux extrêmes. La plupart des équipes ne font jamais ce choix explicitement ; elles se contentent de réagir.

Viennent ensuite les leviers, dont chacun change l'équation :

Choix	Options	Le compromis
Durée	1 an vs 3 ans	La durée de 3 ans offre une remise plus importante, mais triple le verrouillage sur lequel vous pariez.
Paiement	Sans / Partiel / Tout d'avance	Payer davantage d'avance offre un tarif légèrement meilleur, mais immobilise de la trésorerie et augmente l'enjeu en cas d'erreur.
Type de plan	Compute SP vs EC2 Instance SP	Le Compute SP (jusqu'à ~66 % de remise) s'adapte à la famille d'instances, à la taille, à la région, à l'OS, à la tenancy, et même à Fargate/Lambda. L'EC2 Instance SP (jusqu'à ~72 % de remise) rapporte un peu plus mais vous verrouille sur une famille d'instances dans une région. Flexibilité contre remise, encore une fois.

Pour mesurer la valeur de ces choix, regardez leur effet sur le prix d'une seule instance — la même c6a.8xlarge, dans une seule région, tarifée selon les durées et options de paiement d'un Compute Savings Plan (plus le tarif à la demande) :

L'écart est énorme : la même machine passe d'environ 1,22 $/heure à la demande à ~0,54 $/heure avec un Compute Savings Plan de trois ans — une variation de ~56 % entièrement déterminée par la manière d'acheter. Et les écarts ne sont pas régulièrement répartis : passer d'une durée de 1 an à 3 ans divise presque le tarif par deux, tandis que le choix du paiement d'avance (Sans / Partiel / Total) ne le fait bouger que de quelques pour cent. Le levier qui ressemble à une note de bas de page — la durée — est celui qui déplace réellement l'argent.

Chacun de ces choix suppose que vous savez à quoi ressembleront vos workloads sur toute la durée de l'engagement. Avec un plan EC2 Instance de trois ans tout payé d'avance, vous ne dimensionnez pas un engagement : vous faites une prédiction sur votre architecture en 2028. C'est là la vraie difficulté. Le chiffre n'est pas difficile à calculer. C'est le futur dont il dépend qui est difficile à connaître.

Les cinq forces qui déplacent sans cesse la cible

Si votre utilisation était une ligne plate, ce serait un exercice de tableur. Elle ne l'est jamais. Cinq forces continuent de faire dériver le bon chiffre après votre engagement.

1. L'utilisation n'est pas plate. Les dépenses réelles de compute varient d'une semaine à l'autre : jobs batch, lancements, trafic saisonnier, onboarding d'un gros client. Un engagement dimensionné sur une bonne semaine devient un sur-engagement lors d'une semaine calme. Dimensionnez sur une semaine chargée à 70 $/heure alors que votre base durable est en réalité de 60 $/heure, et dès que l'activité retombe, ces 10 $/heure supplémentaires deviennent de l'engagement inutilisé — soit environ 87 600 $ par an payés pour une capacité que vous n'utilisez pas. La remise que vous cherchiez est plus petite que le gaspillage que vous avez créé.

2. Le right-sizing et les migrations réduisent la base. C'est la force qui immobilise le plus d'argent en silence. Vous vous engagez sur l'utilisation d'aujourd'hui, puis votre équipe fait son travail : elle redimensionne les instances surprovisionnées, migre un service vers Graviton, refactore un monolithe. Votre utilisation baisse, votre engagement, lui, ne bouge pas. Vous vous engagez sur votre base de 60 $/heure, puis votre équipe migre vers Graviton et la base se stabilise à 50 $/heure. Du jour au lendemain, ces ~10 $/heure d'engagement n'ont plus nulle part où atterrir — avec environ deux ans restants sur un plan de trois ans, soit à peu près 175 000 $ immobilisés. Vous avez pris la bonne décision d'ingénierie et vous en êtes puni. La bonne démarche suit l'ordre inverse : d'abord le right-sizing, ensuite l'engagement sur le régime de croisière allégé. Presque personne ne le fait, parce que l'engagement et le right-sizing vivent dans les backlogs d'équipes différentes.

3. Les engagements expirent — et les expirations arrivent par vagues. Un Savings Plan acheté il y a un an disparaît un jour précis. Si vous en avez acheté plusieurs d'un coup, ils expirent d'un coup, et votre couverture chute brutalement du jour au lendemain. Renouveler implique de refaire tout l'exercice de dimensionnement, précisément au moment où vous êtes le moins susceptible d'y prêter attention. Ratez ce moment et vous repassez au plein tarif à la demande sur la tranche expirée.

4. Une cible de couverture n'est pas un résultat d'utilisation. Vous pouvez viser 80 % de couverture et finir malgré tout avec une utilisation médiocre si la consommation faiblit après l'achat. Les cibles se fixent sur l'historique ; l'utilisation se réalise dans le futur. L'écart entre les deux est du pur gaspillage, et vous ne le voyez qu'à l'arrivée de la facture.

5. Le temps lui-même. Chaque jour passé à attendre assez de certitude pour vous engager est un jour au tarif à la demande. Des équipes repoussent leurs engagements pendant des mois en quête d'une confiance qui ne vient jamais — et la remise qu'elles reportent est perdue pour de bon. Comme nous l'écrivions dans l'article sur les erreurs d'engagement : même en pleine migration et en pleine incertitude, engager une partie vaut mieux que ne rien engager du tout.

Remarquez qu'aucune de ces forces n'est un échec de planification. C'est simplement la réalité. Votre infrastructure est censée changer. Le problème n'est pas que la cible bouge — c'est que la plupart des processus d'engagement sont conçus comme si elle ne bougeait pas.

Pourquoi l'approche manuelle s'effondre

Voici comment le dimensionnement se déroule généralement en pratique.

Une fois par trimestre, quelqu'un ouvre la recommandation d'achat de Savings Plans d'AWS. AWS analyse une fenêtre rétrospective — au choix 7, 30 ou jusqu'à 60 jours — et vous remet un seul engagement horaire suggéré, optimisé pour un maximum d'économies. Quelqu'un y jette un œil, le réduit peut-être par prudence, obtient une validation, et achète.

Trois problèmes sont inscrits dans ce déroulé.

Premièrement, il s'agit d'un chiffre unique issu d'une seule fenêtre rétrospective. Les recommandations à économies maximales supposent que votre passé récent est votre futur et poussent la couverture à la hausse. Parfait quand l'utilisation est stable ; coûteux dès qu'elle ne l'est plus.

Deuxièmement, c'est un achat massif en une fois. Vous prenez toute la décision d'engagement du trimestre et l'exécutez en une seule transaction, un seul jour. Si ce jour tombe au sommet d'un pic d'utilisation, vous venez d'ancrer un an d'engagement sur un pic.

Troisièmement, c'est déjà obsolète. Le temps que la recommandation soit examinée, approuvée et achetée, des jours ou des semaines ont passé et l'utilisation a bougé. Vous ne vous engagez pas sur votre réalité actuelle : vous vous engagez sur l'instantané d'une réalité déjà révolue.

Le problème de fond, c'est la cadence. L'utilisation change en continu ; le processus manuel se déclenche chaque trimestre. Vous échantillonnez un signal mouvant quatre fois par an et agissez sur chaque échantillon avec des semaines de retard. Aucune rigueur de tableur ne corrige un problème de fréquence d'échantillonnage.

Un meilleur modèle mental : dimensionner sur la base, puis y monter par paliers

La solution recouvre en réalité deux tâches distinctes, et il est utile de les nommer : le dimensionnement (choisir le bon chiffre) et l'échelonnement (l'atteindre en toute sécurité). Deux changements dans la façon d'aborder chacune.

Premier changement — le dimensionnement : ancrez-vous sur la base durable. C'est la tâche qui consiste à choisir le chiffre. Plutôt que de demander quel est le bon montant en dollars, décidez quelle part de vos dépenses éligibles vous voulez couvrir — en vous ancrant sur la base durable, la partie qui tourne en continu — et laissez le montant en découler. Cela transforme une estimation sans garde-fou en une politique sur laquelle on peut raisonner :

• Prudent (~65 % de couverture). Vous protégez l'utilisation et conservez de la flexibilité. Vous laissez volontairement quelques économies de côté. Adapté aux utilisations volatiles ou en évolution rapide.
• Équilibré (~80 % de couverture). Le choix par défaut pour la plupart des workloads de production stables : des économies significatives avec une marge confortable contre les creux.
• Agressif (~90 % de couverture). Économies maximales, marge minimale. Approprié uniquement lorsque votre base est réellement stable et prévisible.

Pourquoi ne pas toujours choisir agressif ? Parce que la couverture a des rendements décroissants, et que la dernière tranche est la plus dangereuse. Le socle de votre utilisation — la partie qui tourne 24 h/24, 365 jours par an — est le plus sûr à couvrir, et la remise y est pratiquement gagnée d'avance. À mesure que vous poussez la couverture, vous commencez à engager la partie variable, en haut de votre courbe d'utilisation : les heures qui n'existent que pendant les pics. Cette dépense marginale est précisément celle qui a le plus de chances de disparaître, ce qui signifie que la couverture ajoutée au-delà de ~80 % porte l'essentiel du risque de sur-engagement tout en apportant les économies les moins fiables. La bonne posture n'est pas de tout couvrir. C'est de couvrir la base stable de façon agressive et le sommet volatil avec prudence.

Deuxième changement — l'échelonnement : avancez par petites étapes. C'est une tâche différente : non pas quoi engager, mais comment y parvenir. Plutôt qu'un seul gros achat, découpez la distance vers votre cible en une série de petits engagements échelonnés dans le temps. L'échelonnement règle plusieurs des cinq forces d'un coup :

• Des étapes petites et fréquentes signifient qu'aucun achat ne s'ancre sur un pic. Vous lissez votre entrée dans l'engagement, comme on lisse une prise de position par des achats programmés.
• Des dates de départ décalées signifient des expirations décalées — pas d'effet falaise au renouvellement, puisque vos plans arrivent à échéance quelques-uns à la fois plutôt que tous en même temps.
• S'engager progressivement signifie pouvoir ralentir ou vous arrêter dès que l'utilisation faiblit, au lieu de découvrir le sur-engagement un an après la signature d'un contrat verrouillé.

Mais gardez les deux tâches séparées. L'échelonnement gère le timing — la concentration des achats et les effets falaise à l'expiration — pas le dimensionnement. Il ne peut pas sauver une cible trop agressive : échelonnez lentement vers le mauvais chiffre et vous finirez tout de même sur-engagé, juste quelques semaines plus tard. Fixez d'abord la bonne base ; échelonnez ensuite.

Le hic : dimensionner sur une base mouvante, revérifier la couverture chaque semaine, ajuster pour les expirations et marquer une pause lors des baisses d'activité constitue un travail réellement continu. Fait à la main, c'est un mi-temps que personne n'a. C'est exactement le vide que l'automatisation vient combler.