La remise que vous ne touchiez pas : pourquoi Spot et Graviton coûtent si peu

La facture AWS a dépassé le budget deux mois de suite. Le budget mensuel a été dépassé d'un pourcentage à un chiffre - rien d'alarmant en valeur absolue, mais la tendance montait. En cherchant quoi couper ressource par ressource, la conclusion a surpris : il n'y avait presque plus rien à réduire. Le vrai levier n'était pas « combien on consomme » mais « comment on achète ». Ce qu'on en a retenu : chaque chiffre de la facture a une raison d'être, et c'est en comprenant cette raison qu'on décide ce qu'on éteint et ce qu'on garde.

Les ressources étaient déjà taillées au plus juste

On a d'abord regardé la consommation. Mais ce terrain avait déjà été largement travaillé. Pas de passerelle NAT, une architecture en sous-réseaux publics ; les logs conservés seulement 7 jours ; le tracing échantillonné à 1% ; le dashboard d'observabilité tassé dans les quotas gratuits. La base de données et Redis tournaient déjà sur des instances ARM moins chères, S3 était en tiering automatique, et le bastion ne se lançait qu'à la demande. Ressource par ressource, presque tout ce qu'on pouvait presser avait déjà été pressé.

La facture de juin, poste par poste : la base de données (RDS) représentait à elle seule environ 40% du total, suivie du compute (ECS Fargate) à environ 17%, puis le load balancer et le WAF à environ 10% chacun, et enfin l'IP publique, le cache (ElastiCache) et S3 en pourcentages à un chiffre. Réduire encore la taille des instances aurait été un pas en arrière : la base de données avait déjà été agrandie une fois faute de mémoire, et le WAF avait été laissé là volontairement pour valider ses règles avant tout déploiement en production. Le levier restant n'était pas la ressource, mais le mode de paiement : consommer exactement la même chose, mais l'acheter moins cher.

Pourquoi Spot est si peu cher

La première chose qui a sauté aux yeux, c'est qu'on achetait le compute uniquement au tarif à la demande, plein pot. Or AWS a un guichet où le même serveur coûte bien moins cher : Fargate Spot. Environ 70% de moins que le tarif à la demande.

Ce prix a une raison d'être. AWS bâtit ses data centers pour absorber les pics de demande. En temps normal, il reste des serveurs inoccupés. Laisser cette capacité dormir rapporte zéro, donc AWS la brade à condition de pouvoir la reprendre en 2 minutes dès qu'un client au tarif plein se présente. C'est le même principe qu'une compagnie aérienne qui liquide ses sièges vides juste avant le décollage : de toute façon, un siège vide au décollage ne rapporte rien, autant le vendre sous condition plutôt que pas du tout.

Tout l'enjeu, c'est de pouvoir assumer cette condition : « on te récupère la place si on te le demande ». En production, c'est délicat. Si des utilisateurs sont connectés et qu'une tâche est reprise 2 minutes plus tard, le service vacille, même brièvement. Mais le staging, c'est différent : pas d'utilisateurs réels, et quelques minutes d'indisponibilité ne gênent qu'un QA de passage. On a donc basculé l'API de staging sur Spot. La performance est strictement identique au tarif à la demande - même vCPU, même mémoire, sur le même matériel. La seule chose qui change, c'est la disponibilité, avec ce risque de reprise, et c'est une condition que le staging accepte volontiers. Une fois appliqué, les tâches de staging ont tourné normalement sur Spot.

Pourquoi Graviton est si peu cher

Le deuxième point concernait le chipset du compute. La base de données et Redis tournaient déjà sur des instances ARM, mais Fargate, qui fait tourner l'application elle-même, était resté sur x86. En passant sur Graviton, le chipset ARM conçu par AWS lui-même, on obtient la même performance environ 20% moins cher.

La raison de ce prix bas est différente de celle de Spot. Sur une instance classique, AWS achète ses processeurs à Intel ou AMD, et ce que l'on paie inclut la marge du fabricant de puces. Graviton est conçu directement par AWS, donc cette marge intermédiaire disparaît. De plus, l'architecture ARM consomme moins d'électricité et dégage moins de chaleur pour un même calcul, ce qui réduit aussi les coûts d'énergie et de refroidissement du data center. Pour AWS, le coût de revient est plus bas, donc vendre 20% moins cher reste rentable - et c'est aussi une stratégie pour attirer les clients dans son propre écosystème de puces.

La différence essentielle est là. La remise de Spot vient avec une condition : accepter la reprise. Celle de Graviton n'en a aucune : c'est simplement une puce moins chère. Spot ne peut donc s'appliquer qu'au staging, tandis que Graviton s'étend tel quel jusqu'en production. Côté performance, peu d'inquiétude à avoir : sur Node.js, la performance par vCPU est équivalente à x86 sur Graviton, voire meilleure. Le seul point à surveiller est le cold start : au premier démarrage de l'appli, sensible à la vitesse mono-cœur, Graviton peut être légèrement plus lent qu'un x86 récent, ce qui ajoute quelques secondes au lancement. On a d'abord déployé en staging pour mesurer ce temps de démarrage, avant de promouvoir en production. La seule vérification préalable à faire : s'assurer que les modules natifs sont bien compilés pour arm64.

Pour résumer la nature des deux remises : celle de Spot est le prix d'une contrainte qu'on accepte de subir, donc elle vient avec une condition (d'où le staging) ; celle de Graviton est le partage de l'avantage de coût propre à la puce AWS, donc sans condition (d'où la production). À performance égale, il n'y avait aucune raison de rester au tarif plein sur x86. En réalité, cette optimisation n'a rien économisé de nouveau : elle a surtout consisté à enfin toucher une remise qu'on laissait sur la table.

Certains coûts ne doivent pas être coupés

Mais en parcourant la facture, on tombe aussi sur le piège inverse : un poste qui ressemble à du gaspillage alors que c'est en réalité une assurance.

C'était le cas de RDS Proxy. Il représentait un coût fixe mensuel, et il est apparu au premier abord comme un candidat à la réduction. L'une des fonctions de Proxy est de gérer la rotation automatique des secrets sans interruption de service, et cette rotation était justement désactivée. Pourquoi garder le Proxy si on n'utilise pas la rotation ?

C'était une mauvaise lecture. Le rôle premier de Proxy n'est pas la rotation, mais la protection contre les pics de connexions. Lors d'un déploiement ou d'un scale-out, le nombre de tâches augmente brusquement, et les connexions vers la base de données grimpent avec elles - or une base de données a un plafond de connexions simultanées. Proxy regroupe et multiplexe les connexions en amont pour rester sous ce plafond. Et cette base de données précise avait déjà été agrandie une fois faute de mémoire ; chaque connexion consomme de la mémoire. Autrement dit, ce coût fixe n'était pas du gaspillage, mais la prime d'assurance qui empêche la base de données de s'effondrer sous l'afflux de connexions à chaque déploiement. L'éteindre n'aurait pas fait économiser - cela aurait retiré le bouclier.

L'origine de cette mauvaise lecture était un commentaire de code. Le commentaire décrivant ce Proxy était centré sur la rotation, ce qui poussait facilement à conclure : « la rotation est désactivée, donc le Proxy est inutile ». Plutôt que de retirer Proxy du plan d'économies, on a ajouté une ligne au commentaire : « rôle principal : limiter les pics de connexions, la rotation n'est qu'une fonction annexe ». Pour que la prochaine personne qui lit la facture ne tombe pas dans le même piège.

Chaque chiffre de la facture a une raison d'être

Quand on nous dit de réduire les coûts cloud, le réflexe est de se demander « qu'est-ce qu'on coupe ». On réduit les instances, on désactive des fonctions, on supprime des ressources. Mais ce qu'on retient de cette expérience, c'est l'inverse. Avant de réduire, la question à poser est : « pourquoi ce chiffre est-il là ? »

Certains chiffres sont des remises qu'on ne touchait pas. Comme Spot et Graviton : il existait un guichet pour acheter la même ressource moins cher, et on payait plein pot sans le savoir. Chacune de ces remises a sa propre raison d'être bon marché, et comprendre cette raison - assumer une reprise, ou profiter d'un avantage de coût sans condition - détermine où l'appliquer en toute sécurité. D'autres chiffres sont au contraire des assurances qu'il ne faut pas couper. Même s'ils ressemblent à du gaspillage, s'ils préviennent un incident précis, cette ligne budgétaire n'est pas une dépense : c'est une protection.

Au final, lire une facture, ce n'est pas la faire baisser, c'est comprendre la raison de chaque chiffre. Une fois cette raison connue, on garde les remises dont on peut assumer la condition, et on conserve les coûts qui évitent un incident. C'est tout ce qu'on a fait ici. Pas de nouvelle économie à proprement parler - juste la distinction entre la remise à saisir et l'assurance à préserver.