Trouver le gaspillage cloud que personne ne cherche

La plupart du gaspillage cloud n’est pas une mauvaise décision prise exprès par quelqu’un. C’est un disque que personne n’a détaché après le redimensionnement d’un serveur il y a huit mois, un répartiteur de charge pointé vers un service qui a été décommissionné, un instantané gardé « au cas où » auquel plus personne n’a pensé depuis. Rien de tout ça n’apparaît sur une facture comme une seule ligne évidente — c’est étalé assez finement pour qu’une lecture ligne par ligne d’une facture ne l’attrape presque jamais.

Ce qui est vraiment scanné

Railyard ne majore jamais le calcul — chaque serveur est facturé par le vrai fournisseur cloud, à son prix. La page Costs utilise les mêmes identifiants cloud déjà enregistrés pour créer des serveurs, et scanne directement les comptes DigitalOcean, Hetzner, Vultr et AWS : chaque compte à son tour, région par région pour AWS, avec une progression en direct pendant l’exécution. Les montants facturés viennent de la propre API de facturation de chaque fournisseur quand il en existe une (AWS Cost Explorer, factures DigitalOcean, frais en attente Vultr, crédits et remboursements inclus) — Hetzner n’a pas d’API de facturation, donc ses chiffres viennent plutôt de la propre liste de prix en direct de Hetzner.

Ça ne s’arrête pas aux serveurs que Railyard a créés : disques, adresses IP, instantanés, images machine, passerelles NAT, répartiteurs de charge et bases de données — tout ce qui est dans le compte, y compris des ressources que le scan n’a eu aucun rôle à provisionner.

Ce que ça trouve vraiment

Regroupé selon la facilité de la correction — corrections faciles, moyennes, changements plus importants, et choses qui méritent un second regard — chaque trouvaille expliquant pourquoi elle est signalée, ce que la corriger fait à l’application en marche, et comment :

Des disques non attachés, et des disques posés sur des serveurs arrêtés depuis longtemps
Des adresses IP inutilisées, des passerelles NAT inactives et des répartiteurs de charge sans trafic réel
De vieux instantanés et images machine que personne n’a utilisés depuis
Des serveurs qui tournent au ralenti, ou sans applications, ou seulement avec des applications arrêtées
Un serveur dimensionné bien au-dessus de ce que sa propre moyenne et son pic de CPU/mémoire sur 14 jours exigent vraiment
Des types d’instances AWS de génération précédente, et où ARM (Graviton) coûterait moins cher pour le même travail
Des disques AWS et du stockage de base de données qui pourraient passer en gp3

La partie qui compte plus que la liste : la plupart tient en un clic

Là où une correction est sûre à automatiser, la trouvaille a un vrai bouton — supprimer le disque, libérer l’IP, supprimer l’instantané, terminer, convertir en gp3, arrêter, redimensionner — chacun demandant une confirmation et énonçant l’impact clairement d’abord (« supprime le disque et ses données — faites un instantané d’abord »). Un redimensionnement prend automatiquement un instantané du serveur avant d’y toucher. Les changements plus importants, comme déplacer tout un serveur vers ARM, viennent avec les vraies étapes plutôt qu’un bouton en un clic, parce que ce n’est pas une décision sûre à automatiser complètement.

Des garde-fous, pas juste un rapport

Définissez un budget mensuel et des règles de notification se déclenchent à 50 %, 80 % et 100 % de la prévision de fin de mois — plus chaque fois que les dépenses font un pic ou qu’un nouveau gaspillage apparaît. Cochez Hard cap et Railyard l’applique plutôt que de simplement alerter : à 100 % du budget, chaque application non-production se met en veille et créer de nouveaux serveurs devient impossible jusqu’à revenir sous la limite ou relever le budget. C’est la différence entre un tableau de bord de coûts et quelque chose qui empêche vraiment la facture de s’emballer pendant une longue fin de semaine que personne ne surveille.

Ce qu’elle est honnête de ne pas savoir

Les chiffres d’économies utilisent le prix de liste public de chaque fournisseur pour la région — un rabais d’entreprise négocié n’est pas visible pour le scan. Les répartitions de coûts par environnement sur le canvas sont la part de chaque service dans le prix de son serveur, calculée à partir de l’usage mémoire — une vraie estimation, présentée comme telle, pas comme une facture exacte.

Référence complète, incluant la politique IAM AWS exacte nécessaire : Coûts et économies.