La plupart des équipes comprennent qu'un Compute Savings Plan permet d'économiser sur le compute cloud. Beaucoup moins comprennent le mécanisme précis. Et ce détail compte, car mal dimensionner l'engagement coûte de l'argent réel dans les deux directions : trop haut signifie payer pour des heures engagées non utilisées ; trop bas signifie rater des économies disponibles.
Le mécanisme en une phrase
Vous vous engagez à dépenser un montant horaire minimum en compute. En échange, AWS applique automatiquement des réductions (jusqu'à 66% vs on-demand) sur votre usage éligible. L'engagement est mesuré en dollars par heure, pas en instances spécifiques.
C'est cette abstraction qui distingue les Compute Savings Plans des Reserved Instances classiques. Vous n'achetez pas "3 instances m5.xlarge pendant un an". Vous achetez "12$/heure de compute AWS pendant un an, utilisables sur n'importe quelle combinaison d'instances EC2, Fargate, ou Lambda".
Comment le calcul fonctionne concrètement
Prenons un exemple. Votre workload actuel :
- 4x m5.xlarge EC2 (0.192$/h on-demand chacune = 0.768$/h total)
- 2x c5.2xlarge EC2 (0.34$/h on-demand chacune = 0.68$/h total)
- Usage Fargate équivalent à 0.25$/h
Total on-demand : 1.698$/h, soit environ 1,230$/mois (730 heures).
Avec un Compute Savings Plan de 1$/h sur 1 an, vous payez :
- Engagement : 1$/h × 730h = 730$/mois (garanti, que vous utilisiez ou non)
- Usage couvert : 1$/h de compute bénéficie d'une réduction d'environ 40%
- Usage excédentaire : 0.698$/h reste en on-demand
Le calcul devient : 730$ (engagement) + 0.698 × 730 × 1.0 (on-demand) = 730 + 509 = 1,239$/mois.
Économie vs full on-demand : environ 0$ dans ce cas mal calibré.
Le problème ici : l'engagement de 1$/h est trop bas pour couvrir l'essentiel du workload, mais consomme quand même du budget.
Le piège du sous-engagement
Beaucoup d'équipes, par prudence, s'engagent trop bas. "On ne sait pas si on va scaler, mettons 50% de notre usage actuel."
Le problème : vous payez toujours l'engagement minimum, même si votre usage baisse. Si vous vous engagez à 1$/h et n'utilisez que 0.5$/h de compute pendant un mois, vous payez quand même 730$ d'engagement.
Mais le vrai coût caché est l'économie ratée. Sur les 0.698$/h non couverts, vous payez plein tarif alors qu'un engagement plus élevé aurait appliqué la réduction.
Le piège du sur-engagement
À l'inverse, s'engager trop haut par optimisme crée du gaspillage direct.
Imaginons un engagement de 2$/h pour le même workload de 1.698$/h :
- Engagement : 2$/h × 730h = 1,460$/mois
- Usage réel couvert : 1.698$/h (tout votre compute bénéficie de la réduction)
- Gaspillage : 0.302$/h × 730h = 220$/mois d'engagement payé mais non utilisé
Vous économisez sur le compute utilisé, mais perdez 220$/mois sur l'engagement excédentaire. Le net peut être négatif vs un engagement correctement dimensionné.
La méthode de dimensionnement
Dans notre travail avec des équipes engineering, notamment lors de nos audits d'infrastructure cloud, nous utilisons cette approche en trois étapes :
Étape 1 : Établir la baseline
Analysez 3-6 mois d'historique de compute. Identifiez :
- Le minimum horaire (votre baseline incompressible)
- La moyenne horaire
- Le 90e percentile horaire
AWS Cost Explorer fournit ces données dans la vue "Savings Plans recommendations".
Étape 2 : Choisir le percentile d'engagement
La règle de base : engagez-vous au niveau de votre minimum stable, pas de votre moyenne.
Si votre minimum est 0.8$/h, votre moyenne 1.2$/h, et votre pic 2$/h, un engagement à 0.8$/h est conservateur mais sûr. Vous couvrez 100% de votre baseline, le reste passe en on-demand.
Pour des workloads très prévisibles (batch processing quotidien, applications internes), vous pouvez engager plus proche de la moyenne. Pour des workloads variables (SaaS avec usage client imprévisible), restez proche du minimum.
Étape 3 : Valider avec les projections business
L'engagement est sur 1 ou 3 ans. Vos plans business changent-ils cette équation ?
- Migration cloud en cours ? L'usage va augmenter, engagez sur la projection post-migration
- Consolidation prévue ? L'usage peut baisser, restez conservateur
- Lancement de nouveau produit ? Attendez les données réelles avant d'ajuster
Compute Savings Plans vs Reserved Instances
Les Reserved Instances (RI) offrent des réductions légèrement supérieures (jusqu'à 72% vs 66%), mais avec des contraintes :
| Aspect | Compute Savings Plan | Reserved Instance | |--------|---------------------|-------------------| | Flexibilité instance | Toutes instances EC2/Fargate/Lambda | Instance type et AZ spécifiques | | Réduction max | 66% | 72% | | Facilité de gestion | Une seule décision : montant horaire | Gestion par type d'instance | | Revente | Non | Oui (RI marketplace) |
Pour la majorité des workloads modernes (conteneurisés, serverless-first), les Compute Savings Plans sont le meilleur choix. La flexibilité compense largement les 6% de réduction en moins.
Les RI restent pertinentes pour des workloads très stables sur des types d'instances spécifiques (bases de données on-premise, applications legacy non conteneurisées).
Le cas particulier de l'IA/ML
Les workloads d'entraînement et d'inférence IA ont des patterns spécifiques :
Entraînement (bursty, GPU-intensif)
L'entraînement de modèles est souvent sporadique : 2 semaines intensives par mois, puis maintenance. Les Savings Plans sont mal adaptés à ce pattern. Préférez les Spot Instances pour l'entraînement (jusqu'à 90% de réduction, avec risque d'interruption).
Inférence (continu, prévisible)
Si vous servez des modèles en production 24/7, l'inférence est une baseline stable. Idéal pour les Savings Plans. Engagez-vous au niveau de votre usage d'inférence minimum.
Pattern mixte
Beaucoup d'équipes ont les deux. Séparez les workloads logiquement :
- Inférence : Savings Plan
- Entraînement : Spot Instances + on-demand pour les jobs critiques
Outils de monitoring recommandés
Le dimensionnement n'est pas une décision unique. Révisez trimestriellement.
AWS Cost Explorer
Gratuit, intégré. La section "Savings Plans recommendations" analyse votre historique et suggère des engagements. Prenez ces recommandations comme point de départ, pas comme vérité absolue.
CloudHealth / Spot.io
Outils tiers avec des analyses plus fines : prédiction de coverage, alertes sur sous/sur-utilisation, recommandations cross-cloud.
Kubecost (pour Kubernetes)
Si vos workloads tournent sur EKS, Kubecost attribue les coûts par namespace/deployment. Vous voyez quels services consomment votre engagement Savings Plan.
Erreurs courantes à éviter
Erreur 1 : Ignorer les engagements existants
Avant d'acheter un nouveau Savings Plan, vérifiez vos engagements actuels (RI, anciens Savings Plans). AWS n'empêche pas l'over-commitment.
Erreur 2 : Engagement 3 ans par défaut
L'engagement 3 ans offre une réduction supérieure (environ 10% de plus que 1 an). Mais 3 ans est une éternité en cloud. Si votre roadmap inclut des migrations (vers un autre cloud, vers du serverless), l'engagement 1 an est plus prudent.
Erreur 3 : Oublier les régions
Les Compute Savings Plans sont globaux (toutes régions), mais les EC2 Savings Plans sont régionaux. Vérifiez quel type vous achetez.
Erreur 4 : Ne pas réviser
Un engagement correct en janvier peut être inadapté en juillet. Intégrez la révision des Savings Plans dans votre cycle FinOps trimestriel. Si vous n'avez pas de cycle FinOps établi, un audit de maturité digitale peut vous aider à mettre en place les bonnes pratiques.
Cas particulier : startups et scale-ups
Les recommandations ci-dessus supposent un workload relativement stable. Les startups en croissance rapide ont un défi différent : leur usage évolue trop vite pour des projections fiables.
Pour les entreprises en phase de scaling, nous recommandons :
- Engagez uniquement sur la baseline incompressible (instances de production core)
- Gardez la capacité de burst en on-demand ou Spot
- Révisez mensuellement, pas trimestriellement
- Privilégiez No Upfront pour maximiser la flexibilité
Le coût supplémentaire de cette prudence (environ 10% vs un engagement optimisé) est une assurance contre le sur-engagement si la croissance ralentit.
Checklist avant engagement
Avant de valider un achat de Savings Plan, cochez ces points :
- [ ] J'ai analysé au moins 3 mois d'historique de compute
- [ ] J'ai identifié mon minimum horaire stable
- [ ] J'ai vérifié mes engagements existants (RI, anciens SP)
- [ ] J'ai consulté la roadmap produit/infra pour les 12 prochains mois
- [ ] J'ai configuré des alertes de coverage dans Cost Explorer
- [ ] J'ai planifié une révision dans 3 mois
Pour une analyse complète de vos coûts cloud et des recommandations d'optimisation adaptées à votre contexte, explorez notre Discovery Sprint ou consultez notre méthodologie Hermes pour structurer votre approche FinOps.
FAQ
Puis-je annuler un Compute Savings Plan après l'achat ?
Non. L'engagement est ferme sur la durée choisie (1 ou 3 ans). C'est pourquoi le dimensionnement correct est crucial. AWS propose parfois des ajustements pour des cas exceptionnels, mais ne comptez pas dessus.
Les Savings Plans s'appliquent-ils à tous les services AWS ?
Les Compute Savings Plans couvrent EC2, Fargate, et Lambda. Les EC2 Savings Plans ne couvrent que EC2. D'autres services (RDS, Redshift) ont leurs propres programmes de Reserved Instances.
Comment les Savings Plans interagissent-ils avec les Spot Instances ?
Les Spot Instances ne sont pas éligibles aux Savings Plans. Vous payez le prix Spot (généralement 60-90% moins cher que on-demand) sans que cela consomme votre engagement. Votre engagement s'applique d'abord aux instances on-demand.
Quelle est la différence entre "All Upfront", "Partial Upfront", et "No Upfront" ?
Ce sont les options de paiement. All Upfront : vous payez tout au début, réduction maximale. Partial : 50% au début, 50% mensualisé, réduction intermédiaire. No Upfront : tout mensualisé, réduction minimale. Pour la plupart des entreprises, No Upfront offre le meilleur équilibre entre flexibilité et économies.
Est-il possible de combiner plusieurs Savings Plans ?
Oui. Vous pouvez avoir plusieurs plans actifs simultanément. AWS applique automatiquement les réductions dans l'ordre le plus avantageux. Cela peut être utile pour ajuster progressivement votre engagement à mesure que votre usage évolue.