Agence cloud FinOps
Comment repenser ses engagements Azure avant février 2027
Microsoft a annoncé une évolution importante de sa politique d’échange des réservations Azure. À compter du 1er février 2027, les nouvelles réservations portant sur des services également couverts par les Savings Plans ne pourront plus être échangées contre d’autres réservations. Les réservations prises avant cette date conserveront, quant à elles, la possibilité d’un dernier échange après l’entrée en vigueur de la nouvelle politique.
Cette évolution concerne plusieurs types de réservations Azure, mais elle modifie notamment un arbitrage central des stratégies FinOps autour du compute : celui entre Reserved Instances (RIs) et Savings Plans. Elle pourrait être interprétée comme une incitation à délaisser progressivement les RIs au profit des Savings Plans, plus flexibles par nature. Ce serait pourtant une lecture trop rapide.
Les RIs restent l’un des mécanismes les plus intéressants pour optimiser le coût des workloads les plus stables et prévisibles. Les Savings Plans répondent à une problématique différente : accepter une remise moins importante en contrepartie d’une plus grande liberté dans la manière dont l’engagement est consommé. Microsoft continue d’ailleurs de recommander les RIs pour les workloads stables et les Savings Plans pour les plus dynamiques.
La véritable conséquence du changement annoncé pour 2027 est ailleurs : il devient plus coûteux de se tromper dans ses engagements.
Pour les organisations disposant d’un parc Azure important, les prochains mois constituent donc une période stratégique. Il ne s’agit pas simplement d’acheter davantage de réservations avant l’échéance ni de basculer mécaniquement vers les Savings Plans, mais de revoir la manière dont sont arbitrés RIs, Savings Plans et consommation à la demande.
Ce qui va réellement changer au 1er février 2027
La fin des échanges pour les nouvelles réservations éligibles
Aujourd’hui, une réservation Azure ne constitue pas nécessairement un engagement totalement figé. Sous certaines conditions, une organisation peut échanger une réservation devenue inadaptée contre une autre réservation.
Cette possibilité apporte une flexibilité importante. Une entreprise peut par exemple avoir réservé une certaine famille de machines virtuelles dans une région donnée, puis voir son architecture évoluer au cours de la période d’engagement. L’échange permet alors de réorienter tout ou partie de l’engagement.
À compter du 1er février 2027, cette possibilité disparaîtra pour les nouvelles réservations portant sur des services également pris en charge par les Savings Plans. Microsoft cite notamment Azure Virtual Machines, Azure App Service et Azure SQL Database. Les produits qui deviendraient ultérieurement éligibles aux Savings Plans entreront également dans le périmètre de cette nouvelle politique.
Le changement est important : une réservation achetée après cette date devra être considérée comme un engagement strictement associé à un besoin déterminé.
Une transition plus progressive pour les réservations existantes
Le 1er février 2027 ne constitue toutefois pas une suppression brutale de toute possibilité d’échange.
Une réservation achetée avant cette date pourra continuer à être échangée autant de fois que nécessaire jusqu’à l’entrée en vigueur de la nouvelle politique. Après cette date, elle conservera le droit à un dernier échange. La réservation issue de cet échange ne pourra ensuite plus être échangée à son tour.
Microsoft donne également l’exemple d’une réservation échangée partiellement : si seule une partie est échangée après la date limite, la quantité restante conserve son droit à un dernier échange.
Cette subtilité est importante pour les grandes organisations, qui pourront donc continuer à ajuster progressivement certains portefeuilles de réservations après février 2027.
Les RIs ne disparaissent pas
La nouvelle politique ne signifie surtout pas la disparition des RIs. Elles pourront toujours être achetées et renouvelées.
Le mécanisme d’Instance Size Flexibility reste également disponible : une même réservation peut continuer à couvrir différentes tailles de VMs appartenant à un même groupe de flexibilité. Par exemple, des D2s v5, D4s v5 ou D8s v5 peuvent être couvertes par une même réservation sur la série Dsv5.
Microsoft maintient également la possibilité de convertir certaines réservations en Savings Plans pour les workloads devenus plus dynamiques ou évolutifs.
Les règles d’annulation ne sont pas non plus modifiées.
C’est un point essentiel pour comprendre la stratégie de Microsoft : l’éditeur ne supprime pas les réservations. Il redéfinit plus nettement la place des réservations et des Savings Plans en fonction du niveau de prévisibilité de la consommation.
RIs et Savings Plans répondent à deux besoins différents
RIs : maximiser la remise sur le socle stable
Pour la suite de cette analyse, nous nous concentrerons principalement sur les RIs, qui constituent le cas d’usage historique des réservations sur le compute Azure.
Une RI consiste à s’engager sur une capacité de VMs définie, dans une région donnée, pour une période d’un ou trois ans. Pour les workloads stables, cette contrainte permet en contrepartie d’obtenir des remises importantes par rapport à la tarification Pay-As-You-Go.
Dans notre stratégie FinOps, nous avons privilégié les RIs pour les ressources dont la pérennité peut être anticipée. L’objectif n’est pas de réserver tout ce qui fonctionne aujourd’hui, mais d’identifier le socle de consommation dont l’organisation a de fortes chances d’avoir encore besoin pendant toute la durée de l’engagement.
Cette distinction est fondamentale. Une VM présente depuis douze mois n’est pas nécessairement une bonne candidate à une réservation de trois ans. Son application peut être décommissionnée, migrée vers un autre service, déplacée vers une autre région ou faire l’objet d’une transformation architecturale. La stabilité passée constitue un indicateur, elle ne remplace pas la connaissance de la roadmap.
C’est pourquoi Microsoft continue de positionner les RIs comme la solution privilégiée lorsque les workloads fonctionnent continuellement et qu’aucune évolution de type d’instance, de famille ou de région n’est anticipée.
Savings Plans : accepter moins de rigidité
Le Savings Plan repose sur une logique différente. L’entreprise ne s’engage plus sur une configuration précise, mais sur un montant de consommation horaire pendant une durée déterminée.
Cet engagement peut être consommé automatiquement par différents usages éligibles, apportant davantage de flexibilité lorsque les workloads changent de famille, de service ou de région. Une organisation peut ainsi savoir qu’elle conservera durablement un volume important de compute Azure sans pouvoir prédire quelles ressources consommeront précisément ce budget dans deux ans.
Le Savings Plan permet ainsi de s’engager sur la dépense plutôt que sur l’architecture.
Cette flexibilité a cependant une contrepartie : les RIs offrent généralement des remises plus importantes lorsqu’elles sont correctement utilisées. Microsoft applique d’ailleurs leurs avantages en priorité lorsqu’une consommation est simultanément éligible à une RI et à un Savings Plan.
La bonne stratégie n'est pas de choisir entre RIs et Savings Plans
L’erreur serait de considérer ces deux mécanismes d’engagements comme des solutions concurrentes entre lesquelles une organisation devrait choisir. Dans un environnement Azure mature, ils constituent au contraire deux couches d’une même stratégie d’engagement.
Les RIs couvrent la partie la plus stable et la mieux connue de la consommation. Les Savings Plans absorbent ensuite une partie de la consommation restante, celle dont la dépense est prévisible mais dont la répartition technique l’est moins. Enfin, la consommation réellement volatile ou incertaine reste volontairement facturée en Pay-As-You-Go.
L’enjeu n’est donc pas de choisir un mécanisme, mais de trouver le mix permettant simultanément d’optimiser les coûts, de conserver la flexibilité nécessaire au métier et de maintenir une stratégie FinOps exploitable dans la durée.
Standardiser avant de s'engager
La diversité technologique a également un coût économique
L’un des enseignements les plus intéressants de nos travaux sur les engagements Azure concerne le lien entre architecture et capacité à réserver.
Dans l’environnement étudié, nous avions observé que les entités présentant les niveaux de RIs les plus élevés étaient celles dont la consommation était concentrée sur un nombre limité de familles de VMs. À l’inverse, une forte dispersion entre différentes générations, familles et configurations réduisait mécaniquement le potentiel de couverture par les RIs.
Une organisation utilisant de nombreuses familles de VMs proches fonctionnellement, plusieurs générations d’une même série et un grand nombre de régions se retrouve avec une consommation fragmentée. Chaque fragment devient individuellement plus difficile à prévoir et donc plus difficile à engager via une RI.
La standardisation de l’architecture peut ainsi devenir un levier FinOps à part entière.
Réduire la fragmentation avant d'acheter des RIs
Notre approche consiste donc à travailler d’abord sur la standardisation des familles, générations et régions, lorsque cela est techniquement pertinent, avant de chercher à augmenter la couverture par les RIs.
Il ne s’agit évidemment pas de modifier une architecture uniquement pour obtenir une remise Azure. Les contraintes de performance, de résilience, de souveraineté, de latence ou de disponibilité restent prioritaires.
En revanche, lorsque plusieurs configurations répondent au même besoin, la standardisation permet de concentrer la consommation pour faire apparaître un socle durable beaucoup plus facilement réservable.
La suppression des échanges renforce cette logique. Plus un engagement devient difficile à modifier, plus il est important que l’architecture sur laquelle il repose soit elle-même cohérente et durable.
Le FinOps intervient alors en amont de l’achat : il contribue aux décisions d’architecture qui détermineront ensuite la capacité de l’entreprise à s’engager efficacement.
Identifier le véritable socle de consommation
Une fois les familles de VMs standardisées, il devient possible d’identifier les configurations de VMs et les régions qui concentrent réellement la consommation, puis d’isoler celles dont l’usage est suffisamment stable et durable pour justifier un engagement.
Dans notre approche, nous utilisions une logique de Pareto pour isoler les quelques combinaisons de séries et de régions représentant la majorité des usages de production. L’un des exemples étudiés permettait ainsi de ramener l’analyse à cinq séries couvrant 81 % de l’usage et quatre régions couvrant 90 % de la consommation. Les chiffres n’ont évidemment pas vocation à devenir une règle générale, mais le principe, lui, reste valable.
Il faut ensuite confronter cette analyse quantitative à la connaissance des équipes techniques : durée de vie prévue de l’application, migrations programmées, changements de régions, évolution des architectures, renouvellement des générations de VMs ou encore transformation vers des services managés.
Cette confrontation entre données historiques et roadmap technique permet de distinguer ce qui est simplement régulier aujourd’hui de ce qui est réellement durable.
Notre recommandation : RIs d'abord, Savings Plans ensuite
Réserver ce qui est stable et durable
Une fois ce socle identifié, notre recommandation reste de privilégier les RIs lorsqu’une organisation dispose d’un niveau de confiance suffisant sur la pérennité du workload.
Cette stratégie permet de conserver les remises les plus importantes là où la flexibilité supplémentaire d’un Savings Plan apporte peu de valeur.
Dans notre modèle, les RIs sont achetées en priorité sur les combinaisons de séries et de régions présentant une consommation durable. Les Savings Plans interviennent ensuite pour couvrir une partie du compute restant : familles de VMs plus rares, workloads moins stables, environnements hors production ou ressources éligibles dont la consommation est régulière sans être suffisamment prévisible pour une réservation précise.
Le raisonnement reste particulièrement pertinent aujourd’hui : il évite de payer pour de la flexibilité sur une consommation qui n’en a pas réellement besoin.
Utiliser les Savings Plans comme seconde couche
Une fois le socle stable couvert par les RIs, l’analyse peut porter sur la consommation éligible restante.
Si cette dépense reste suffisamment constante à l’échelle horaire mais se déplace entre différentes ressources, familles ou régions, elle constitue une bonne candidate à un Savings Plan.
Le dimensionnement doit néanmoins rester prudent. Un Savings Plan fonctionne sur un engagement horaire et la capacité inutilisée au cours d’une heure n’est pas reportée sur la suivante. Un workload consommant beaucoup pendant certaines périodes et très peu pendant d’autres peut donc afficher une dépense mensuelle importante tout en constituant un mauvais candidat à un engagement horaire trop élevé.
C’est précisément pour cette raison qu’un Savings Plan ne devrait pas être dimensionné uniquement à partir d’une moyenne mensuelle.
Accepter de conserver une part de Pay-As-You-Go
Enfin, vouloir atteindre 100 % de couverture par des engagements n’est généralement pas un objectif FinOps pertinent. La flexibilité a une valeur.
Une consommation volatile, un nouveau projet, une architecture en transformation ou un workload dont la durée de vie reste incertaine peuvent parfaitement justifier de rester temporairement en Pay-As-You-Go.
Le surcoût apparent du tarif à la demande peut alors être considéré comme le prix payé pour ne pas prendre un engagement dont l’organisation n’est pas certaine d’avoir besoin.
L’objectif n’est donc pas de maximiser le taux de couverture. Il est de maximiser la valeur économique du portefeuille d’engagements.
Février 2027 : une échéance à préparer dès maintenant
Auditer les RIs existantes
Les entreprises disposent encore de plusieurs mois pour préparer le changement.
La première étape consiste à dresser un état des lieux des RIs existantes et à déterminer quelles RIs correspondent à la trajectoire technique de l’entreprise.
Une RI parfaitement utilisée aujourd’hui peut devenir problématique demain si l’application concernée doit migrer, changer de région ou abandonner la famille de VM correspondante.
L’analyse de l’utilisation doit donc être complétée par une analyse de la durée de vie des applications avec les équipes engineering et produit.
Profiter intelligemment de la fenêtre d'échange
Les réservations achetées avant le 1er février 2027 pourront être échangées librement jusqu’à cette date et conserveront ensuite une dernière possibilité d’échange. Les entreprises disposent donc encore de plusieurs mois pour analyser leurs RIs et préparer les ajustements nécessaires.
L’idée n’est évidemment pas d’échanger toutes les RIs avant la deadline. Il s’agit plutôt d’identifier celles devenues incohérentes et, lorsque cela est pertinent, de les réorienter vers des consommations réellement durables.
Pour les workloads devenus trop mouvants pour justifier une réservation précise, le trade-in vers un Savings Plan reste également possible. Microsoft indique que cette possibilité n’est pas remise en cause par le changement de politique.
Cette recommandation reste finalement proche de celle que nous formulions déjà lors de la précédente annonce de changement de politique : standardiser les familles de VMs, déterminer les RIs à conserver ou à faire évoluer, puis arbitrer entre échange vers d’autres RIs et conversion vers un Savings Plan.
La différence est qu’en 2027, la possibilité de corriger ultérieurement une mauvaise décision sera nettement plus limitée.
Notre analyse : Microsoft redéfinit le prix de la flexibilité
La principale conséquence de cette évolution n’est pas la disparition des RIs. Elle est la séparation plus nette entre deux logiques d’engagement.
D’un côté, les RIs récompensent la capacité d’une organisation à prévoir précisément sa consommation. De l’autre, les Savings Plans permettent de s’engager tout en conservant davantage de liberté sur la manière dont cette consommation évoluera.
Actuellement, une entreprise peut bénéficier de remises importantes grâce aux RIs tout en conservant la possibilité de réorienter son engagement si son architecture évolue. La suppression des échanges réduit cette option.
Cela ne signifie pas qu’il faut basculer massivement vers les Savings Plans. Au contraire, une telle réaction risquerait de faire perdre une partie des économies accessibles sur les workloads les plus prévisibles.
La bonne réaction consiste plutôt à améliorer la qualité des décisions prises avant l’engagement.
À mesure que la possibilité de réorienter les RIs se réduit, la connaissance de la roadmap, la standardisation des architectures, la qualité des prévisions et la collaboration entre équipes FinOps, engineering et finance prennent davantage d’importance.
Une stratégie d’engagement consiste finalement à attribuer un prix à différents niveaux d’incertitude : réserver fortement ce que l’entreprise connaît, acheter de la flexibilité là où elle en a réellement besoin et ne pas s’engager sur ce qu’elle ne sait pas encore prévoir.
C’est probablement le principal enseignement à tirer de l’évolution annoncée par Microsoft.
Conclusion
La restriction des possibilités d’échange ne remet pas en cause la pertinence des RIs. Elle rend simplement leur utilisation plus exigeante.
À mesure que Microsoft réduit leur flexibilité, la qualité des décisions prises en amont devient plus importante : standardiser lorsque cela est pertinent, identifier le véritable socle de consommation, intégrer la roadmap technique et réserver uniquement ce que l’organisation est réellement capable de prévoir.
L’enjeu des prochains mois n’est donc pas de remplacer les RIs par des Savings Plans, mais de construire le bon équilibre entre engagement, optimisation et flexibilité.
Chez Sudo, nous accompagnons les organisations dans la définition et la mise en œuvre de leurs stratégies FinOps, depuis l’analyse des consommations et la gestion des engagements jusqu’à la construction d’un mix adapté entre RIs, Savings Plans et PAYG.
Si vous souhaitez anticiper l’évolution de la politique Azure et revoir votre portefeuille d’engagements avant février 2027, échangeons sur votre stratégie FinOps.