Les ressources cloud qui gaspillent le plus sur AWS, Azure et Google Cloud, et comment les trouver avec Résultats actifs

Le gaspillage dans le cloud est étonnamment répétitif. Quel que soit le fournisseur ou le montant de la facture, on retrouve presque toujours les mêmes ressources oubliées, qui facturent chaque heure sans que personne ne s'en serve. Les trouver à la main oblige à parcourir chaque console, région par région. Dans cet article, nous passons en revue ces schémas, nous indiquons quelle règle d'AAA Sentinel détecte chacun sur AWS, Azure et Google Cloud, et nous montrons comment traiter la liste des Résultats actifs jusqu'à la transformer en économies.

Pourquoi le gaspillage se répète

Presque toute la dépense inutile naît du même geste : on supprime ou on arrête la ressource principale et les accessoires survivent. Quand on supprime une machine virtuelle, son disque peut rester. Quand on retire un environnement, l'IP publique réservée, le load balancer ou le NAT tournent toujours. Et ce qui est utilisé est souvent dimensionné pour un pic qui n'est jamais venu. Aucune de ces ressources ne prévient : elles ne tombent pas en panne, ne créent pas d'incident et leur coût se dilue dans une ligne de la facture.

Ce que vous y gagnez

Détecter ces ressources de façon systématique change votre manière de travailler les économies :

• Une seule liste pour les trois clouds, triée par sévérité et par économie mensuelle estimée.
• Des critères fixes et connus : chaque résultat vient d'une règle avec un seuil précis, pas d'une opinion.
• Des décisions qui restent : ce que vous écartez ou marquez comme résolu le reste lors des analyses suivantes.
• Un chemin clair du résultat à l'action, à la main, par un ticket ou avec l'agent.

Comment AAA Sentinel le résout : analyses, règles et résultats

Chaque analyse lit les ressources et les métriques de vos comptes connectés avec des droits en lecture seule et leur applique les règles d'analyse. Il existe aujourd'hui 51 règles de coût : 19 pour AWS, 16 pour Azure et 16 pour Google Cloud. Chaque règle qui se vérifie produit un résultat avec une sévérité, une recommandation et une économie mensuelle estimée. Trois écrans couvrent le circuit :

• Règles d'analyse : le catalogue complet, avec le plan qui inclut chaque règle, l'étiquette « Automatisable » quand l'agent peut appliquer la correction et un interrupteur pour l'activer ou la désactiver.
• Historique des analyses : chaque analyse avec son coût, ses résultats et la comparaison avec la précédente (nouvelles, disparues, inchangées).
• Résultats actifs : la liste de travail avec tous les résultats de la dernière analyse de chaque compte.

Chaque schéma, sa règle

Voici les schémas de gaspillage et les règles qui les détectent, avec leurs seuils réels. Free inclut les règles de base ; Pro ajoute celles qui ont besoin de métriques d'usage plus détaillées.

• Disques non attachés (Free) : STORAGE_UNATTACHED_VOLUME sur AWS (volume EBS à l'état available), AZURE_DISK_UNATTACHED et GCP_DISK_UNATTACHED.
• IP publiques non associées (Free) : NETWORK_UNASSOCIATED_EIP sur AWS, AZURE_IP_UNASSOCIATED et GCP_STATIC_IP_UNUSED.
• Machines arrêtées qui paient encore leurs disques (Free) : COMPUTE_STOPPED_WITH_VOLUME sur AWS, AZURE_VM_STOPPED sur Azure et GCP_VM_STOPPED sur Google Cloud (arrêtée depuis au moins une semaine).
• Machines presque inactives (Free) : CPU moyen inférieur à 5 % sur 7 jours, avec COMPUTE_LOW_CPU, AZURE_COMPUTE_LOW_CPU et GCP_COMPUTE_LOW_CPU.
• Machines surdimensionnées (Pro) : avec un CPU moyen sur 7 jours inférieur à 20 %, AWS_COMPUTE_RIGHTSIZE, AZURE_COMPUTE_RIGHTSIZE et GCP_COMPUTE_RIGHTSIZE proposent de descendre d'exactement une taille.
• Load balancers sans trafic (Pro) : NETWORK_IDLE_LB sur AWS (ALB avec moins de 10 requêtes par jour en moyenne sur 7 jours, ou NLB et GWLB traitant moins de 1 Mio par jour) et AZURE_LB_IDLE (load balancer Standard sans trafic depuis 7 jours) et GCP_LB_IDLE (forwarding rule sans trafic depuis 7 jours, quand la supprimer réduit le forfait des forwarding rules).
• Bases de données sans connexions (Pro) : zéro connexion en 7 jours (dans Cloud SQL, tout au plus quelques connexions brèves et isolées), avec DATABASE_ZERO_CONN_RDS, AZURE_SQL_ZERO_CONN et GCP_SQL_ZERO_CONNECTIONS.
• NAT orphelins ou sous-utilisés (Pro) : NETWORK_ORPHAN_NAT, AZURE_NETWORK_ORPHAN_NAT et GCP_NETWORK_ORPHAN_NAT signalent le NAT qui traite moins de 1 Go par jour et dont aucune route ni sous-réseau ne dépend. Sur AWS, NETWORK_UNDERUSED_NAT signale en plus le NAT sous 1 Go par jour même s'il a encore des routes.
• Stockage dans une classe chère (Pro) : buckets de plus de 100 Go en classe Standard, avec STORAGE_S3_WRONG_CLASS et GCP_GCS_WRONG_CLASS, et sur Azure AZURE_STORAGE_WRONG_TIER, pour les comptes avec plus de 100 Go en Hot, sans stratégie de cycle de vie qui change de niveau tout le compte et avec peu de lectures en 30 jours.
• Snapshots orphelins (Free) : STORAGE_ORPHAN_SNAPSHOT sur AWS, pour les snapshots EBS dont le volume source n'existe plus, et AZURE_SNAPSHOT_ORPHAN et GCP_SNAPSHOT_ORPHAN, pour les snapshots de plus de 30 jours dont le disque source n'existe plus.
• Bases NoSQL avec de la capacité en trop (Pro) : DATABASE_DYNAMO_OVERPROV sur AWS et AZURE_COSMOS_OVERPROV sur Azure, quand elles utilisent moins de 20 % de ce qu'elles réservent sur 7 jours.
• Disques de génération précédente (Pro, AWS uniquement) : STORAGE_EBS_GP2_TO_GP3, pour les volumes gp2 en service qui coûteraient moins en gp3 avec les mêmes performances.
• Versions en support étendu payant (Pro) : COMPUTE_EKS_EXTENDED_SUPPORT et DATABASE_RDS_EXTENDED_SUPPORT sur AWS (EKS, RDS et Aurora), GCP_GKE_EXTENDED_SUPPORT et GCP_SQL_EXTENDED_SUPPORT sur Google Cloud (GKE sur le canal Extended et Cloud SQL) et AZURE_DB_EXTENDED_SUPPORT sur Azure (MySQL et PostgreSQL), aussi 60 jours avant que la facturation commence, et AZURE_AKS_LTS pour les clusters AKS au niveau Premium avec support à long terme.
• Endpoints de ML inutilisés (Pro) : COMPUTE_SAGEMAKER_ENDPOINT_IDLE, AZURE_ML_ENDPOINT_IDLE et GCP_VERTEX_ENDPOINT_IDLE, pour les endpoints SageMaker, Azure Machine Learning et Vertex AI avec des instances ou des réplicas actifs et aucune requête en 14 jours.
• En plus, sur AWS (Pro) : ressources sans activité depuis plus de 30 jours qui ne sont pas étiquetées comme production.

Cas pratique : ACME sur trois clouds

ACME est une entreprise fictive avec sa boutique sur AWS, sa plateforme de données sur Azure et son analytique sur Google Cloud, au plan Pro. Après la première analyse de ses trois comptes, voici les résultats qui nous intéressent, avec l'économie estimée par chaque règle et la décision de l'équipe :

Étape 1 : lancer une analyse

Dans Mes comptes cloud, chaque compte a un bouton « Scanner ». En Free, vous pouvez lancer jusqu'à 3 analyses par semaine ; en Pro et Business, les comptes sont analysés automatiquement chaque jour et vous pouvez toujours en lancer à la main. Une fois terminée, l'analyse apparaît dans Historique des analyses : « Voir » affiche le coût, l'économie potentielle et la comparaison avec l'analyse précédente, qui sépare les résultats nouveaux, disparus et inchangés.

Étape 2 : passer en revue les règles d'analyse

Avant de traiter la liste, jetez un œil aux Règles d'analyse. Vous pouvez filtrer par fournisseur et par catégorie, et chaque carte indique le plan qui l'inclut et si elle est « Automatisable ». Les règles hors de votre plan affichent un cadenas.

• Désactivez une règle avec son interrupteur si elle ne s'applique pas à votre cas. Le changement vaut à partir de l'analyse suivante.
• Désactiver une règle ne marque pas ses résultats comme résolus : la plateforme arrête de regarder, et elle distingue ce cas de la disparition du problème.
• Les seuils des règles ne sont pas configurables : les 5 % de CPU ou les 7 jours sont les mêmes pour tout le monde.

Étape 3 : filtrer les résultats actifs

Résultats actifs regroupe les résultats de la dernière analyse de chaque compte, triés par sévérité puis, à l'intérieur de chaque sévérité, par économie. Les filtres sont en haut :

• Onglets de sévérité : Tous, Critique, Haut, Moyen et Bas, chacun avec son compteur.
• Sélecteur de compte, avec « Tous les comptes » pour voir les trois clouds ensemble.
• « Automatisables uniquement », pour garder ce que l'agent peut corriger.
• « Voir les écartés », qui réaffiche ce que vous avez marqué comme écarté ou résolu.
• Le champ « Rechercher... », qui cherche dans le titre, le nom de la ressource et la description.

Étape 4 : ouvrir le détail

Un clic sur un résultat ouvre le panneau « Détail de l'alerte ». Vous y trouvez la sévérité, la description, la « Recommandation », la ressource, le compte, la région et les « Économies estimées » par mois. Le lien « Voir la ressource » mène à la fiche de la ressource. Si le résultat a une correction automatique, vous verrez aussi le bouton pour l'automatiser, présenté à l'étape 7.

Étape 5 : décider du statut

Dans le même panneau, le bloc « Statut » propose quatre boutons. La décision est enregistrée au niveau de l'organisation et conservée lors des analyses suivantes :

• Ouvert : aucune décision. C'est l'état de départ, et y revenir efface la décision précédente.
• Accepté : vous reconnaissez le problème et allez le corriger. Il compte toujours dans les KPI, car la dépense est toujours là.
• Écarté : vous avez décidé de ne pas agir (chez ACME, le load balancer de staging). Il ne compte plus dans les KPI ni dans les rapports.
• Résolu : vous l'avez déjà corrigé. Il ne compte pas non plus dans les KPI.

Étape 6 : l'envoyer dans Jira ou Linear

Si votre équipe travaille avec des tickets, connectez Jira Cloud (avec un jeton d'API) ou Linear dans Alertes → Intégrations (plan Pro). Dans chaque intégration, vous choisissez « Créer un ticket pour les alertes de sévérité », réglé par défaut sur haute. Ensuite :

• Quand une analyse détecte de nouveaux résultats de sévérité haute et que la notification « Nouvelles détections à priorité élevée » est activée dans Canaux d'alerte, un ticket est créé avec le résumé de cette alerte. C'est un ticket par alerte, qui regroupe les résultats de l'analyse, pas un par résultat.
• Pour un ticket sur un résultat précis, le bouton « Créer un ticket » apparaît sur les actions de l'Agent IA issues d'un résultat (plan Business).

Étape 7 : proposer la correction (Business)

En Business, les résultats qui ont une correction automatique affichent un bouton « Automatiser » dans la liste et dans le détail. Il ouvre une fenêtre avec « Ce qui va se passer », « Pourquoi », « Impact », « Avant de continuer », « Comment revenir en arrière » et une étiquette « Réversible » ou « Non réversible ». « Créer l'automatisation » laisse l'action proposée dans Agent IA → Tableau de bord, sous « En attente d'approbation ». Rien ne s'exécute tant qu'une personne autorisée à approuver ne l'a pas validée, et après l'approbation il y a une période de grâce avant l'exécution (48 heures pour supprimer un volume, par exemple) pendant laquelle vous pouvez l'annuler.

• L'agent a besoin d'un rôle d'écriture séparé, créé à l'étape « Activer l'agent autonome (optionnel) » lors de la connexion du compte.
• Sur AWS, arrêter, redimensionner ou terminer une instance EC2 exige qu'elle porte l'étiquette FinOpsSentinelManaged=true.
• Avant de supprimer un volume EBS, l'agent crée un snapshot de sauvegarde. Libérer une IP élastique, en revanche, la perd : vous pouvez en réserver une autre, mais pas la même adresse.
• Avec « Convertir en playbook », la même correction est proposée automatiquement après chaque analyse pour les résultats de cette règle, toujours en attente d'approbation.

Le résultat chez ACME

ACME agit sur tout sauf le load balancer de staging, qu'elle marque « Écarté ». La Lambda est supprimée par hygiène et n'ajoute rien. L'économie estimée s'établit à 70 + 50 + 45 + 38 + 33 + 10,80 + 7,30 = 254,10 US$ par mois, environ 3 050 US$ par an aux prix catalogue. À mesure que chaque ressource disparaît, ses résultats passent à « Disparu » dans les analyses suivantes. En Business, le tableau de bord de l'agent affiche à part les « Économies vérifiées », mesurées par rapport au coût réel du compte au moins 7 jours après chaque action.

Ce qu'il ne fait pas encore

Pour savoir à quoi vous attendre :

• Il n'y a pas de règles pour Kubernetes ni pour le coût à l'intérieur des clusters.
• Il n'y a pas de règle d'ancienneté des snapshots : les règles de snapshots orphelins cherchent les snapshots sans disque source, pas les snapshots anciens.
• Google Cloud n'a pas de règle de load balancer sans trafic, et Azure n'a pas de règle de classe de stockage chère.
• Les seuils des règles ne sont pas réglables : on peut seulement activer ou désactiver chaque règle.
• Résultats actifs n'a pas de bouton de ticket par résultat : les tickets viennent des alertes ou de l'Agent IA.
• L'économie estimée se calcule sur le coût que la règle attribue à la ressource, pas sur votre facture. Prenez-la comme un ordre de grandeur.

Checklist pour démarrer

Avec tout cela en place, le gaspillage cesse de s'accumuler en silence :

• Vos comptes AWS, Azure et Google Cloud connectés dans Mes comptes cloud.
• Une première analyse lancée et passée en revue dans Historique des analyses.
• Les règles qui ne s'appliquent pas désactivées dans Règles d'analyse.
• Chaque résultat de sévérité haute avec un statut : accepté, écarté ou résolu.
• Jira ou Linear connectés dans Alertes → Intégrations, si vous travaillez avec des tickets.
• En Business, le rôle de l'agent créé et les premières corrections proposées depuis le résultat.