Multi-cloud10 octobre 2026 10 min de lecture

Gérer les coûts multi-cloud avec AAA Sentinel : AWS, Azure et Google Cloud dans une seule vue

Quand chaque cloud est suivi dans sa propre console, personne ne connaît la dépense totale ni l'endroit où se cache le gaspillage. Nous montrons comment connecter AWS, Azure et Google Cloud à AAA Sentinel, lire la dépense unifiée, appliquer les mêmes règles aux trois et répartir le coût par équipe, avec un exemple complet.

Cet article est aussi disponible en:esenpt

Peu d'entreprises choisissent d'avoir trois clouds. En général, cela arrive tout seul : l'application est née sur AWS, l'ERP est arrivé avec un contrat Microsoft et l'équipe data a eu un coup de cœur pour BigQuery. Chaque cloud a sa console, sa facture et ses noms pour la même chose, et la question la plus simple, combien avons-nous dépensé dans le cloud ce mois-ci, finit par se régler en additionnant des tableurs. Cet article montre comment réunir les trois clouds dans AAA Sentinel et en tirer parti étape par étape, avec un exemple complet.

Le problème : trois consoles, trois vérités

Gérer chaque cloud séparément n'est pas seulement inconfortable. Cela a des conséquences concrètes :

  • Personne ne voit le total. Chaque équipe connaît sa part, mais la dépense globale n'apparaît qu'à la clôture, quand il est trop tard pour corriger.
  • Le gaspillage se cache dans le cloud secondaire. Celui que « personne ne regarde » accumule des disques orphelins et des machines oubliées pendant des mois.
  • Les critères ne sont pas comparables. Ce qu'AWS appelle une instance EC2 est une machine virtuelle dans Azure et une instance Compute Engine dans Google Cloud, et chaque console les mesure à sa manière.
  • La répartition par équipe devient impossible, car les étiquettes ne s'écrivent pas de la même façon d'un cloud à l'autre.

Ce que vous apporte une vue unifiée

Avec les trois clouds au même endroit, la discussion change :

  • Une seule dépense totale, mise à jour à chaque analyse, au lieu de trois chiffres à additionner à la main.
  • Les mêmes règles de détection partout : un disque non attaché est un résultat, qu'il soit sur AWS, Azure ou Google Cloud.
  • Une comparaison de la dépense par fournisseur et par type de charge de travail.
  • Une répartition du coût par étiquettes de gouvernance, avec le même critère pour tous les clouds.

Comment AAA Sentinel s'y prend

La prise en charge multi-cloud repose sur cinq briques, chacune avec son plan :

  • La connexion des comptes, depuis Mes comptes cloud → « Connecter un compte », avec un assistant différent pour chaque fournisseur. Pro inclut cinq comptes, y compris pendant l'essai de 30 jours, et Business vingt : trois clouds tiennent dès le premier jour.
  • Le « Tableau de bord », avec la dépense totale de tous les clouds. Disponible dans tous les plans.
  • Les « Règles d'analyse », qui appliquent les mêmes familles de détection aux trois fournisseurs.
  • La « Comparaison multi-cloud », dans Rapports → Multi-cloud, avec la dépense par fournisseur, la comparaison des workloads et des recommandations de migration à titre informatif. Plan Pro.
  • La répartition par étiquettes : « Par étiquettes » (Pro), compte par compte, et « Chargeback » (Business), avec tous les comptes ensemble.

Cas pratique : ACME sur trois clouds

ACME, une entreprise fictive, a sa boutique en ligne sur AWS, son ERP et sa base SQL sur Azure, et son analytique sur Google Cloud. Jusqu'ici, chaque équipe consultait sa console une fois par mois. Voici sa dépense mensuelle approximative :

ACME · dépense mensuelle par cloud

AWS (boutique en ligne)
6 200 US$
Azure (ERP et SQL)
2 900 US$
Google Cloud (analytique et quelques VM)
1 400 US$
Total
10 500 US$

Étape 1 : connecter les trois clouds

Dans Mes comptes cloud → « Connecter un compte », l'assistant demande d'abord « Quel fournisseur cloud ? » puis suit un chemin différent pour chacun. Dans les trois cas, l'accès est en lecture seule :

  • AWS : « Étape 1 — Créer le rôle IAM » ouvre CloudFormation avec une pile prête à l'emploi qui crée un rôle en lecture seule protégé par un ExternalId. À « Étape 2 — Copier l'ARN du rôle », vous copiez l'ARN renvoyé par la pile, et à « Étape 3 — Connecter le compte », vous le collez et lui donnez un nom. Les coûts proviennent de Cost Explorer.
  • Azure : « Étape 1 — Créer le principal de service » vous donne les commandes Azure CLI (ou Cloud Shell) pour créer un principal de service avec le rôle Reader, pour l'inventaire et la posture, et Cost Management Reader, pour les coûts. À « Étape 2 — Identifiants du principal de service », vous saisissez l'ID du locataire (Tenant ID), l'ID de l'application (appId), le secret client (password) et l'ID d'abonnement, puis à « Étape 3 — Nom et connexion », vous le nommez.
  • Google Cloud : « Étape 1 — Créer un compte de service » dans IAM & Admin → Service Accounts, avec roles/viewer et les rôles de lecture Compute, SQL et Functions, et les API correspondantes activées dans le projet. À « Étape 2 — Uploader le compte de service », vous envoyez le fichier JSON. « Étape 3 — Coûts réels (optionnel) » vous demande la table BigQuery Billing Export.

Sur Google Cloud, sans BigQuery Billing Export, la plateforme estime le coût à partir des prix publics. Pour que le total d'ACME soit comparable avec AWS et Azure, qui fournissent un coût réel, l'équipe data configure l'export avant de connecter le compte.

Étape 2 : lire le Tableau de bord

Après la première analyse de chaque compte, le « Tableau de bord » affiche le « Coût total » de « tous les clouds · 30 jours » : pour ACME, environ 10 500 US$. En dessous se trouvent l'« Évolution des coûts », avec la prévision du mois en cours en Pro, le bloc « Requiert votre attention », le résumé « Économies » et la liste « Vos comptes cloud », avec la dépense, l'économie possible et la dernière analyse de chaque compte. Pour la première fois, la direction d'ACME voit un seul chiffre pour tout le cloud.

En Free, vous pouvez lancer trois analyses par semaine ; en Pro, elles sont quotidiennes et automatiques. Avec trois clouds, c'est l'analyse quotidienne qui garde le total à jour sans que personne ait à y penser.

Étape 3 : les mêmes règles sur les trois clouds

Les « Règles d'analyse » appliquent des familles équivalentes chez chaque fournisseur. Dans tous les plans : CPU faible, disques non attachés, IP publiques inutilisées et ressources sans étiquettes de gouvernance, ainsi que les machines arrêtées qui continuent de coûter sur AWS et Azure. Pro ajoute, selon le fournisseur, les équilibreurs de charge sans trafic, les bases sans connexions, les fonctions sans invocations, le stockage dans une classe chère, le rightsizing et les passerelles NAT orphelines. Dans « Résultats actifs », avec le filtre « Tous les comptes », ACME voit ensemble les résultats de ses trois clouds :

ACME · quelques résultats de la première analyse

AWS · volume EBS de 500 Go non attaché
environ 40 US$/mois
Azure · VM Standard_D4s_v5 arrêtée mais non désallouée
le calcul reste facturé : environ 140 US$/mois
Google Cloud · IP statique réservée inutilisée
environ 7 US$/mois
Les trois · ressources avec moins de deux étiquettes de gouvernance
aucune économie directe, mais empêche de répartir le coût

La VM Azure est un classique du cloud secondaire : l'éteindre depuis le système d'exploitation l'arrête, mais Azure continue de facturer le calcul tant qu'elle n'est pas désallouée. Personne ne l'avait vu, parce que personne ne regardait là.

Étape 4 : la Comparaison multi-cloud

Dans Rapports → Multi-cloud (/reports/multicloud) se trouve la « Comparaison multi-cloud ». Elle est construite à partir de la dernière analyse terminée de chaque compte et comprend ces parties :

  • Des indicateurs en haut : « Dépense totale », le fournisseur qui dépense le plus et les économies totales des recommandations de migration.
  • Une carte par fournisseur avec sa dépense mensuelle et son nombre de ressources.
  • « Distribution des dépenses par fournisseur », ventilée par catégorie (calcul, bases de données, stockage, réseau, serverless). Chez ACME : AWS 59 %, Azure 28 % et Google Cloud 13 %.
  • « Comparaison des workloads par fournisseur » : le coût du même type de charge dans chaque cloud, y compris des estimations pour les fournisseurs où vous n'avez pas de ressources, avec l'option la moins chère marquée « Moins cher » et un niveau de confiance.
  • « Recommandations de migration », avec « Coût actuel », « Coût estimé », « Économies », « Complexité » et « Confiance ».

Les recommandations de migration sont purement informatives

Une recommandation apparaît lorsqu'un autre cloud reviendrait au moins 15 % et 10 US$ par mois moins cher pour une catégorie. La complexité dépend du type de charge : faible pour le stockage, moyenne pour le calcul et élevée pour les bases de données ou le réseau. Chez ACME, une recommandation apparaît pour le calcul Azure. L'équipe l'écarte : l'ERP a des licences liées à Azure, et déplacer des données entre clouds entraîne un coût de sortie que l'estimation n'inclut pas.

Le rapport l'indique lui-même, « Informatif uniquement » : les estimations reposent sur les tarifs publics de chaque fournisseur (EU West) et n'incluent ni remises, ni engagements, ni trafic réseau, ni egress, ni licences. De plus, quand vous comparez une catégorie présente sur deux clouds, c'est ce que vous dépensez sur chacun qui est comparé, et ce n'est pas forcément la même charge. Servez-vous-en pour vous poser des questions, pas pour décider d'une migration.

Étape 5 : répartir le coût avec Chargeback et Par étiquettes

AAA Sentinel mesure la couverture de cinq étiquettes de gouvernance sur les trois clouds : Environment, Project, Owner, CostCenter et Team. Il accepte aussi la clé en minuscules, ce qui compte sur Google Cloud, où les libellés (labels) n'acceptent que des minuscules : environment, project, owner, costcenter et team. À partir de cette mesure, il y a deux rapports :

ACME · Chargeback sur la clé Team

AWS · 80 % des ressources avec Team
6 200 × 0,80 = 4 960 US$ étiqueté
Azure · 50 % avec Team
2 900 × 0,50 = 1 450 US$ étiqueté
Google Cloud · 30 % avec team
1 400 × 0,30 = 420 US$ étiqueté
Résultat
6 830 US$ étiqueté · 3 670 US$ non attribué
  • « Par étiquettes » (Pro), compte par compte : « Couverture de balisage » par clé, « Décomposition par service », « Résultats par région » et « Résultats par type de ressource ».
  • « Chargeback » (Business), avec tous les comptes ensemble : vous choisissez une clé et voyez la dépense divisée entre « Étiqueté » et « Non attribué », plus la « Décomposition par compte », avec son fournisseur, et le « Top services par coût ».
  • La répartition est proportionnelle à la couverture : la dépense de chaque compte est divisée selon le pourcentage de ses ressources qui portent cette étiquette.

Les 3 670 US$ non attribués sont la liste de tâches d'ACME. La « Stratégie de tagging » (Pro) indique quelles ressources non étiquetées pèsent le plus et permet d'appliquer les étiquettes manquantes.

Dans quelle devise s'affichent les montants

Dans ces rapports, tout le coût est stocké en dollars. Si un compte renvoie son coût réel dans une autre devise, la plateforme ne le mélange pas avec le reste et se rabat sur des estimations à prix publics, qui sont en dollars. Sur Google Cloud, l'export contient le taux de change appliqué par Google, et la conversion est annulée ligne par ligne. Si vous préférez voir des euros ou des livres, changez-le dans Configuration → Préférences → « Devise d'affichage » : chaque montant est converti avec le taux de la Banque centrale européenne de sa propre date, l'historique ne bouge donc jamais.

Quand il faut répartir par équipe précise

Le Chargeback vous dit quelle part de la dépense est étiquetée et quelle part ne l'est pas, mais il ne répartit pas entre les valeurs d'une étiquette : il ne sépare pas l'équipe paiements de l'équipe catalogue. Pour cela, il existe la répartition par centre de coût sur la facture détaillée au format FOCUS, également en Business, que nous expliquons dans l'article « De la facture cloud au coût par commande : répartition par centre de coût et coût unitaire sur AWS, Azure et Google Cloud ». Vous y verrez aussi que, dans ce rapport, chaque devise a sa propre carte et n'est jamais convertie.

Ce qu'il ne fait pas encore

Pour utiliser la vue multi-cloud avec discernement, mieux vaut connaître ses limites :

  • Chargeback et Par étiquettes répartissent selon la couverture des étiquettes (étiqueté ou non attribué), pas selon la valeur de chaque étiquette.
  • La comparaison des workloads et les recommandations de migration sont des approximations : une partie de l'inventaire est reconstituée à partir des résultats et de la ventilation des coûts par service.
  • Les recommandations de migration n'incluent ni egress, ni licences, ni remises, ni engagements, et la plateforme n'exécute pas de migration.
  • Sur Google Cloud, sans BigQuery Billing Export, le coût est une estimation à prix publics.
  • Les cinq clés de gouvernance sont fixes : le Chargeback n'accepte pas de clés personnalisées.

Checklist pour démarrer

Une fois tout cela en place, la prochaine fois qu'on vous demandera combien coûte le cloud, vous aurez une seule réponse pour les trois :

  • Plan Pro ou supérieur pour connecter plus d'un compte (Business pour le Chargeback).
  • AWS, Azure et Google Cloud connectés en lecture seule.
  • BigQuery Billing Export configuré sur Google Cloud pour obtenir le coût réel.
  • « Tableau de bord » consulté et « Résultats actifs » filtrés sur « Tous les comptes ».
  • Comparaison multi-cloud lue, avec les migrations prises comme des pistes, pas comme des ordres.
  • Les cinq étiquettes de gouvernance convenues et écrites de la même façon sur les trois clouds, en minuscules sur Google Cloud.
  • Devise d'affichage choisie dans Configuration → Préférences.