Aller au contenu

AWS Mis à jour le 2026-07-04

Ce qu'un vrai audit de coûts AWS couvre (et ce qu'une « évaluation » gratuite saute)

Un vrai audit de coûts AWS examine les données d'usage, l'architecture, les engagements et la gouvernance — pas juste une capture de Cost Explorer. Voici la portée complète, et ce que les évaluations gratuites laissent de côté.

Un vrai audit de coûts AWS part de vos données d’usage réelles — le Cost and Usage Report, les métriques d’utilisation CloudWatch, la couverture d’engagements — et produit une liste classée de changements avec l’effort, le risque et l’économie attendue attachés à chacun. Une « évaluation » gratuite exécute typiquement un balayage automatisé, signale les six mêmes constats génériques pour tout le monde et facture le correctif comme un mandat. La différence n’est pas la rigueur pour elle-même : le balayage automatisé ne peut pas voir les constats qui portent le gros de l’argent, parce qu’ils vivent dans l’architecture et le contexte de la charge, pas dans une liste de ressources.

Ce que vous décidez

Vous décidez si vous payez pour de la profondeur. L’outillage automatisé (Trusted Advisor, Compute Optimizer, scanneurs tiers) trouve les ressources orphelines, les instances inactives et les engagements manquants — des constats réels, qui valent l’action, et largement gratuits à découvrir vous-même. Ce que l’outillage ne trouve pas : une NAT Gateway qui porte du trafic qui appartient à un point de terminaison VPC, un traitement par lots qui pourrait rouler sur Spot, un niveau de base de données dimensionné pour une pointe de lancement vieille de deux ans, des pipelines de journaux qui ingèrent du debug à volume de production, ou une structure de comptes qui rend la propriété des coûts impossible. Ces constats exigent une personne qui lit votre architecture contre votre facture, et c’est typiquement là que se trouve la majorité de la dépense récupérable.

Le cadrage honnête : si votre facture mensuelle est petite, servez-vous vous-même avec l’outillage gratuit et une liste de contrôle. Passé le point où une économie de 15 % paie l’attention professionnelle plusieurs fois, un audit qui couvre toute la portée ci-dessous mérite ses honoraires — et tout audit qui saute la moitié de la portée est un instrument de vente.

Quoi vérifier en premier

Avant de commander quoi que ce soit, établissez ce que vous voyez vous-même :

  • Un export de facturation détaillé est-il configuré? Sans historique CUR/Data Exports, tout auditeur commence partiellement aveugle.
  • Que dit déjà Trusted Advisor? Les vérifications de coûts au-delà de la base exigent un plan de soutien Business ou supérieur — si vous en avez un, récoltez d’abord les constats gratuits.
  • Quelle est votre couverture et utilisation d’engagements? Deux appels CLI, ci-dessous.
  • La dépense peut-elle être attribuée? Si rien n’est étiqueté, attendez-vous à ce que tout audit commence par du travail d’attribution.

Comment vérifier

# Un export détaillé (CUR 2.0 via Data Exports) est-il configuré?
aws bcm-data-exports list-exports

# Utilisation des Savings Plans — les engagements existants servent-ils?
aws ce get-savings-plans-utilization \
  --time-period Start=2026-06-01,End=2026-07-01

# Couverture des réservations — combien d'usage roule à découvert, à la demande
aws ce get-reservation-coverage \
  --time-period Start=2026-06-01,End=2026-07-01

Dans la console : Billing and Cost Management > Data Exports pour l’export, Cost Explorer > Savings Plans > Utilization report pour la santé des engagements. Une faible utilisation d’engagements existants est en soi un constat — vous avez acheté la mauvaise forme.

L’approche

Ce qu’un vrai audit couvre, dans l’ordre où le travail se fait :

  1. Une base tirée du CUR, pas de captures Cost Explorer. Données par poste sur au moins trois mois, vue amortie, séparées en calcul, stockage, transfert de données et frais par requête. C’est la carte sur laquelle tout le reste s’épingle.
  2. L’utilisation contre la capacité provisionnée. CPU CloudWatch, mémoire (là où l’agent la rapporte), IOPS et nombre de connexions contre ce qui est provisionné — la base de preuve du redimensionnement, avec les règles de validation couvertes dans le redimensionnement Compute Optimizer.
  3. La revue du portefeuille d’engagements. Couverture, utilisation, calendrier d’expiration, et si la forme de l’engagement (compute vs famille d’instances, durée, option de paiement) correspond à la stabilité réelle de la charge.
  4. L’analyse des chemins de données. Traitement NAT Gateway, transfert inter-AZ, sortie, patrons de requêtes S3. C’est là que les audits trouvent l’argent que les scanneurs manquent, parce que ça exige de lire les flux de trafic contre l’architecture.
  5. La vérification du cycle de vie du stockage. Chaînes d’instantanés, volumes détachés, versionnage S3 sans expiration, rétention des journaux, duplication des sauvegardes. Le dimensionnement des niveaux cache et données appartient ici aussi — le patron est celui décrit dans les leviers de coût ElastiCache.
  6. La gouvernance et l’attribution. Couverture d’étiquetage, structure de comptes, alertes de budget, détection d’anomalies. Un audit qui corrige le chiffre mais pas la gouvernance se dégrade en deux trimestres.
  7. Un plan de remédiation classé. Chaque constat avec économie estimée, effort, risque et propriétaire. Si le livrable est un jeu de diapositives sans ce tableau, vous avez acheté du marketing.

Ce qu’une évaluation gratuite saute typiquement : les points 4 à 7. Elle rapporte les orphelins et les engagements manquants — les constats qu’un script peut produire — et s’arrête là où le jugement commence.

Quand c’est la mauvaise approche

Sautez l’audit si vous connaissez déjà la réponse. Une équipe qui vient de lancer sait que la facture n’est pas optimisée; dépensez l’argent à livrer. Sautez-le en pleine migration — auditez l’architecture de destination, pas celle qu’on démolit. Et ne commandez pas un audit comme substitut à la propriété : un rapport que personne n’exécute est le document le plus cher de l’entreprise.

Erreurs courantes

  • Accepter des promesses de pourcentage d’économies avant que quiconque ait vu vos données. Un chiffre cité avant la lecture du CUR est un chiffre de vente.
  • Auditer seulement le compte de gestion. Dans une Organization, la dépense et le gaspillage vivent dans les comptes membres.
  • Traiter l’audit comme le correctif. L’audit est un diagnostic; les économies arrivent quand le plan de remédiation est exécuté et vérifié contre la facture suivante.
  • Laisser l’auditeur vendre les engagements. Celui qui recommande des achats de Savings Plans ne devrait avoir aucune marge sur la recommandation.

Garder le contrôle

  • Configurez Data Exports maintenant, même si l’audit est dans des mois — l’historique ne se reconstitue pas.
  • Relancez vous-même les requêtes de base de l’audit chaque mois; les écarts sont le système d’alerte précoce.
  • Suivez les constats de remédiation jusqu’à la fermeture, comme des actions d’incident, avec propriétaires et dates.
  • Ré-auditez légèrement tous les 12 mois ou après tout changement d’architecture majeur; la documentation AWS Cost Management couvre l’outillage qui garde la base à jour.

Un bon audit se paie tout seul avec les constats de chemins de données et de gouvernance — les parties que le balayage gratuit ne touche jamais. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.