Comment fonctionnent les engagements
Le principe est simple : vous vous engagez sur un volume de consommation pendant 1 ou 3 ans, et le cloud provider vous accorde une remise importante. Deux grandes familles existent :
- Reserved Instance : engagement sur une ressource précise (SKU, région). La remise est la plus forte, la flexibilité la plus faible.
- Savings plan : engagement sur un montant horaire de consommation, flexible entre SKU, régions et parfois services. Un peu moins de remise, beaucoup plus de souplesse.
| Reserved Instance | Savings plan | |
|---|---|---|
| Remise | La plus forte | Légèrement inférieure |
| Flexibilité | Faible (SKU, région) | Forte (familles, régions) |
| Services couverts | VM, bases de données, storage, capacités data selon le provider | Compute principalement |
| Idéal pour | Charge stable et connue | Parc qui évolue, migrations en cours |
Notre méthode en 4 étapes
- Nettoyer avant de réserver. Rightsizing, cleaning et Stop/Start d'abord. Réserver une VM oversized, c'est payer trois ans pour du gaspillage.
- Mesurer la baseline. Historique d'usage par famille de VM (SKU), région et service, pour réserver uniquement ce qui tourne en permanence.
- Choisir le bon engagement. Reserved Instance ou savings plan, 1 ou 3 ans, scope shared ou single. Au-delà des VM : storage, bases de données, Synapse, Fabric, et engagement global avec le cloud provider (MACC sur Azure, accord de remise sur AWS).
- Piloter dans la durée. Coverage et utilization suivis chaque jour, exchanges et refunds quand l'architecture évolue, renouvellements préparés en amont.
Coverage et utilization : les deux indicateurs à suivre
- Coverage : la part de la consommation éligible couverte par un engagement. Une cible de 80 % et plus sur la baseline est un bon objectif.
- Utilization : la part de l'engagement réellement consommée. Une réservation utilisée à 60 % fait perdre une partie de la remise.
Ces deux indicateurs sont suivis dans notre dashboard, avec des alertes quand l'utilization baisse ou qu'une échéance approche.
Les erreurs les plus fréquentes
- Réserver avant d'avoir redimensionné le parc.
- Réserver de la non-prod qui devrait plutôt être arrêtée la nuit : une VM réservée qui est arrêtée continue de payer sa réservation.
- Sur-réserver juste avant une migration ou un décommissionnement.
- Laisser expirer des réservations sans les renouveler, et repasser au tarif pay-as-you-go sans s'en rendre compte.
- Oublier les engagements hors VM : stockage, bases de données, capacités data.
Réservations et Stop/Start ne se cumulent pas
Sur une VM non-prod, un Stop/Start à heures fixes fait gagner 50 à 60 %, presque autant qu'une réservation. Mais les deux ne se cumulent pas. En prod, la VM tourne en continu : c'est la réservation qui s'applique. En non-prod, le meilleur levier est le Stop automatique chaque soir avec un Start on demand, à environ 90 % d'économie.
Ce qu'une réservation ne fait pas
Une réservation baisse la facture, mais elle ne change rien à la consommation physique, donc rien à l'empreinte carbone réelle. Nous séparons toujours les économies financières des réductions d'empreinte. Voir notre page GreenOps.