AWS vous accorde jusqu'à 72 % de remise sur le calcul si vous promettez de continuer à payer pendant trois ans. Le chiffre est réel et il figure dans toutes les checklists d'optimisation des coûts. Ce que la checklist ne dit pas, c'est à quelle fraction de votre facture la promesse peut s'appliquer, et pour l'architecture que font tourner la plupart des petites équipes en 2026, la réponse honnête est : presque aucune.
Nous avons publié notre facture et dit que nous payons tout à la demande. Voici le raisonnement derrière cette phrase, les quatre instruments, ce que chacun peut et ne peut pas couvrir, et la règle que nous utilisons pour savoir quand arrêter de dire non.
Les quatre instruments
| Instrument | Couvre | Ne couvre pas | Remise typique 1 an, sans acompte |
|---|---|---|---|
| Compute Savings Plan | EC2, Fargate, Lambda, toute région, toute famille d'instances | App Runner, tout ce qui n'est pas du calcul | ~20–30 % (Lambda ~17 %) |
| EC2 Instance Savings Plan | EC2 dans une famille dans une région | Tout le reste | ~30–40 % |
| RDS / Aurora Reserved Instances | Instances RDS et Aurora provisionnées, par classe | Aurora Serverless v2 | ~30–40 % |
| Capacité réservée DynamoDB | Unités de capacité lecture/écriture provisionnées | Mode à la demande | ~50 % |
Trois choses à remarquer avant tout calcul. Les Savings Plans sont des engagements de dépense, en dollars par heure, pas sur des ressources précises, ce qui les rend flexibles dans ce qu'ils couvrent. Les Reserved Instances sont des engagements sur des classes d'instances précises, ce qui les rend moins chères et plus fragiles. Et la liste de ce qu'ils ne couvrent pas est là où vit une architecture orientée serverless.
Ce que notre facture peut réellement couvrir
Prenez la facture ligne par ligne et demandez quel instrument s'applique :
| Ligne | Mensuel | Couvrable par | Remise disponible |
|---|---|---|---|
| App Runner | 190 $ | rien | 0 |
| Aurora Serverless v2 | 130 $ | rien (pas de réservation pour Serverless v2) | 0 |
| NAT Gateway | 100 $ → 66 $ | rien | 0 |
| CloudWatch | 95 $ | rien | 0 |
| CloudFront + S3 | 55 $ | bundle sécurité CloudFront, engagement minimum bien au-dessus de nous | 0 |
| DynamoDB à la demande | 35 $ | seulement si passé en provisionné, puis réservé | 0 tel que configuré |
| Secrets Manager, KMS | 66 $ | rien | 0 |
| Lambda | 15 $ | Compute Savings Plan | 17 % → 2,50 $ |
| CodeBuild | 15 $ | rien | 0 |
| Tout le reste | 50 $ | rien | 0 |
| Total | ~750 $ | 15 $ couvrables | ~2,50 $ / mois |
Deux dollars cinquante. Pour un engagement de douze mois. Les instruments qui promettent 72 % s'appliquent à 2 % de la facture, parce que les quatre plus grosses lignes sont App Runner, Aurora Serverless, NAT et CloudWatch, et qu'aucune n'est réservable. L'architecture qui a rendu la plateforme peu coûteuse à exploiter l'a aussi rendue impossible à remiser.
L'autre coût d'un engagement
Même là où une remise s'applique, un engagement a un prix qui n'est pas sur la facture : c'est un pari que l'architecture ne changera pas pendant un an. La nôtre change. App Runner pourrait devenir Fargate pour le service qui bute sans cesse sur la limite de 120 secondes. Aurora Serverless v2 pourrait devenir une instance provisionnée si la charge s'aplatit. L'une des Lambdas deviendra probablement un conteneur. Chacun de ces mouvements rendrait sans valeur une réservation sur l'ancienne chose, et une réservation sur la nouvelle chose serait celle que nous aurions voulue.
Un Compute Savings Plan est l'exception ici, et c'est pourquoi c'est le seul que nous envisagerions en premier : il suit la dépense à travers EC2, Fargate et Lambda, donc « la Lambda est devenue un conteneur » ne le laisse pas en plan. Les Reserved Instances n'ont pas cette propriété. Une RI Aurora pour db.r6g.large est une r6g.large pendant un an, et si vous redimensionnez, vous payez pour les deux.
La règle que nous utilisons
Nous nous engageons quand trois choses sont vraies en même temps :
- La dépense couvrable atteint au moins 500 $ par mois. En dessous, l'économie est inférieure à 100 $ par mois et la conversation annuelle ne vaut pas un après-midi. Pour nous, cela signifie soit que le calcul est passé sur Fargate ou EC2, soit que la base est devenue provisionnée.
- La forme est stable depuis six mois. Pas la facture, la forme : les mêmes services, les mêmes classes d'instances, aucune migration à la feuille de route. Six mois de stabilité sont la preuve que douze de plus sont plus probables qu'improbables.
- Nous couvrons la base, pas le pic. Un engagement de Savings Plan, ce sont des dollars par heure, chaque heure. Fixez-le à 60–70 % de la dépense horaire stable la plus basse, pour que la nuit la plus calme de l'année l'engagement soit encore entièrement utilisé. Tout ce qui est au-dessus reste à la demande. Sous-s'engager gaspille un peu de remise ; sur-s'engager paie de la capacité qui n'existe pas.
Et toujours un an, sans acompte, d'abord. La remise sur trois ans est plus grande, et le pari sur trois ans porte sur une architecture qui, pour une équipe de notre taille, n'existera plus dans trois ans.
Ce que nous dirions à une équipe à 3 000 $ par mois
Le tableau change avec l'échelle, et il change avec l'architecture plus qu'avec l'échelle. Une équipe qui dépense 3 000 $ par mois sur Fargate et un cluster Aurora provisionné peut en couvrir peut-être 2 000 et économiser 600 $ par mois avec deux engagements pris en un après-midi ; c'est un chiffre réel et elle devrait le faire. Une équipe qui dépense 3 000 $ par mois sur App Runner, Serverless v2, CloudWatch et NAT peut en couvrir quelques centaines, et son après-midi est mieux employé sur la ligne CloudWatch ou le nombre de NAT, où les économies sont plus grandes et n'exigent aucune promesse.
Regardez ce que vous payez réellement avant de regarder la table des remises. Si les plus grosses lignes n'y figurent pas, la réponse est rien, pour l'instant, et c'est très bien.
Si vous voulez la vérification ligne par ligne de la réservabilité de votre propre facture, nous la faisons en une heure.