Insights — Cloud et coûts
Votre facture AWS n'est pas chère : elle est mal pilotée.
Un compte créé un vendredi après-midi, une passerelle NAT oubliée, trois environnements de test qui tournent toute la nuit : la dérive des coûts cloud vient rarement du prix des serveurs, presque toujours des décisions qui n'ont pas été prises. Voici comment nous lisons une facture, poste par poste.
01 — Le constat
Un an plus tard, la facture a augmenté de 35 % sans qu'aucune application n'ait été ajoutée.
Chez nos clients, la facture augmente presque toujours pour les mêmes raisons : des environnements de recette qui ne s'éteignent jamais, des instances choisies une fois pour toutes et jamais réévaluées, du stockage qui s'accumule sans règle de cycle de vie, et des flux qui traversent l'internet public alors qu'une liaison privée suffirait.
Aucune de ces causes n'est spectaculaire. Toutes sont invisibles dans la console, parce que la console montre l'état présent — jamais ce qui a changé, ni ce qui ne sert plus à rien.
01Les cinq postes qui dérapent en silence
Le calcul arrive en tête, mais il est rarement coupable seul : une instance surdimensionnée coûte cher parce qu'elle est trop grosse, pas parce qu'Amazon est cher. Viennent ensuite les bases de données, dont le stockage et les sauvegardes croissent sans jamais être purgés.
Le stockage objet est le troisième poste, et le plus souvent le plus mal rangé : des gigaoctets conservés dans la classe la plus chère, pour des fichiers que personne n'ouvre depuis deux ans. Le réseau est le quatrième — et le plus surprenant pour les directions financières, parce qu'il ne contient aucune ressource visible. Enfin l'observabilité : journaux et métriques conservés indéfiniment, à un coût qui finit par dépasser celui de l'application surveillée.
- Calcul : familles d'instances figées, environnements de test allumés en permanence
- Bases : sauvegardes et journaux conservés sans durée de vie
- Stockage : classes inadaptées, versions orphelines, volumes détachés
- Réseau : passerelles NAT et transferts inter-zones non mesurés
- Observabilité : journaux conservés sans filtre ni rétention définie
02Lire une facture en trois passes
La première passe est factuelle : nous classons chaque ligne par application, par équipe et par environnement. Sans cette étape, aucune décision n'est possible, car personne ne peut arbitrer un poste qui n'a pas de propriétaire.
La deuxième passe est comparative : nous regardons la courbe sur douze mois, pas le mois en cours. Une facture stable qui double en trois mois raconte une histoire précise — un déploiement, un import, une réplication mal filtrée.
La troisième passe est prospective : nous reconstruisons la facture cible, avec les engagements de capacité adaptés à la charge réellement stable, et un budget par application avec alertes à 60 %, 80 % et 100 %.
03Les six leviers qui font vraiment baisser la facture
Sur une plateforme de taille moyenne, six actions suffisent en général à retirer plus de la moitié de la dépense inutile, sans toucher à la disponibilité.
Le redimensionnement arrive en premier, parce qu'il ne demande aucune négociation et produit un effet immédiat. Les engagements de capacité viennent ensuite, mais uniquement sur la charge stable : payer d'avance pour une charge incertaine, c'est transformer une variable en risque.
- Redimensionnement des instances surdimensionnées
- Bascule vers des processeurs Graviton quand la charge le permet
- Engagements de capacité sur la seule charge prévisible
- Cycle de vie automatique vers les classes de stockage froides
- Remplacement des passages publics par des points de terminaison privés
- Arrêt programmé des environnements hors production
04Ce que nous ne coupons jamais
Une seule économie est interdite : réduire la redondance. Supprimer une zone de disponibilité ou désactiver la copie de sauvegarde fait baisser la facture du mois et augmente le coût de l'incident qui viendra.
Nous refusons également d'optimiser sans mesure. Chaque recommandation est chiffrée, datée, et vérifiable dans la facture du mois suivant : si le gain annoncé n'apparaît pas, la méthode est en cause, pas la comptabilité.
Un exemple réel de lecture : 3 200 € par mois ramenés à 1 420 €, soit 21 400 € par an, à périmètre et à niveau de service constants.
02 — Questions courantes
Les trois questions que l'on nous pose sur ce sujet
Combien de temps faut-il pour voir un effet sur la facture ?
Le premier effet apparaît dès le mois suivant pour les postes visibles : environnements inutilisés éteints, instances redimensionnées, stockage orphelin supprimé. Les engagements de capacité se voient sur le deuxième ou le troisième mois, parce qu'il faut d'abord mesurer la charge qui est réellement stable.
Peut-on optimiser sans dégrader la performance ?
Oui, à condition d'avoir des mesures avant de décider. Nous ne redimensionnons une instance qu'après avoir regardé son usage réel sur trente jours, et nous ne changeons de famille de processeurs qu'après une comparaison en recette. Toute optimisation est réversible.
Faut-il un outil payant pour suivre tout cela ?
Non. Les fonctions natives d'AWS suffisent : étiquetage obligatoire, budgets par application, rapports de coûts par service et alarmes de dérive. Les outils spécialisés apportent du confort quand la plateforme grossit, jamais les décisions à votre place.
Vous voulez savoir ce que votre plateforme devrait coûter ?
Audit AWS de cinq jours : cartographie des comptes et du réseau, analyse de la facture sur douze mois, plan d'optimisation chiffré et priorisé.