Démasquer les coûts cachés des métriques CloudWatch

La supervision cloud est essentielle pour maintenir et optimiser une infrastructure AWS, et Amazon CloudWatch reste l'outil de référence pour suivre les métriques, les logs et les alarmes. Mais à mesure que votre usage AWS s'intensifie, les coûts CloudWatch grimpent — et ils peuvent parfois s'avérer difficiles à tracer.

L'un des défis récurrents pour les utilisateurs AWS consiste à identifier précisément les postes de dépense CloudWatch dans le Cost & Usage Report (CUR). Si ce rapport offre une vue d'ensemble, il manque la granularité nécessaire pour rattacher les coûts élevés à des sources précises.

Cet article s'appuie sur un cas concret de diagnostic de coûts CloudWatch inattendus avec DoiT Cloud Intelligence. Après avoir identifié les opérations les plus coûteuses, nous verrons comment exploiter les data events CloudTrail et Amazon Athena pour remonter à l'origine de ces frais et en tirer des enseignements concrets. À la clé : une stratégie claire pour comprendre et maîtriser les coûts CloudWatch dissimulés.

Amazon CloudWatch est un outil de monitoring incontournable dans les environnements AWS, avec une vision détaillée des métriques et des logs. Sa structure de coûts peut toutefois sembler opaque, ce qui rend délicate l'identification des pics de facturation inattendus.

Si le Cost & Usage Report (CUR) détaille finement les coûts AWS, il pèche par un manque de visibilité au niveau des ressources sur certaines charges spécifiques. Prenons l'exemple de GetMetricData, une opération API utilisée pour récupérer des données de métriques CloudWatch. Malgré son impact significatif sur la facture, le CUR ne fournit pas suffisamment d'éléments pour déterminer quels services, applications ou utilisateurs sont à l'origine de ces dépenses.

Ce manque de transparence complique l'optimisation des coûts, la prévention des dépassements budgétaires et les arbitrages sur la configuration de la supervision.

Pour illustrer ce défi, nous nous sommes appuyés sur les rapports DoiT Cloud Analytics, qui permettent de visualiser et d'interpréter les données de coûts cloud. Ces données peuvent être présentées sous différents diagrammes, filtrées et regroupées pour en tirer davantage d'enseignements.

L'analyse ci-dessous présente une décomposition détaillée des coûts d'utilisation de CloudWatch sur 28 jours, mettant en évidence les coûts élevés et constants associés aux opérations GMD-Metrics (GetMetricData).

Le tableau de coûts ci-dessous classe les dépenses CloudWatch par SKU (Stock Keeping Unit), type d'opération et information de ressource. À retenir :

• GMD-Metrics (GetMetricData) figure parmi les principaux postes de dépense.
• Les informations sur les ressources sont absentes, ce qui complique l'identification de la source des requêtes.
• MetricMonitorUsage contribue également aux coûts, mais dans une moindre mesure.

Puisque GetMetricData génère des coûts importants et inexpliqués, une investigation plus poussée s'impose à l'aide des data events CloudTrail et d'Amazon Athena pour en retracer l'origine.

Par défaut, AWS CloudTrail enregistre les management events : modifications IAM, configurations de sécurité, provisionnement de ressources, etc. En revanche, les data events, qui capturent les appels d'API spécifiques à un service (opérations au niveau des objets S3, exécutions Lambda, etc.), ne sont pas activés par défaut.

Comme nous devons suivre les événements CloudWatch Metrics, il faut activer explicitement les data events CloudTrail. Cela peut se faire dans un trail existant ou via la création d'un nouveau trail.

Configurer CloudTrail

1. Choisir un trail CloudTrail

• Modifier un trail existant ou en créer un nouveau.
• Définir un bucket S3 pour stocker les logs CloudTrail.

2. Configurer les options facultatives

• Chiffrement KMS (facultatif) pour renforcer la sécurité.
• Validation des logs et notifications SNS (facultatif, pour l'intégrité et les alertes).
• Stockage CloudWatch Logs (sans objet ici, puisque nous utilisons Athena pour l'analyse).

Définir le data event pour CloudWatch Metrics

1. Sélectionnez CloudWatch metric comme Data Event Type.

2. Spécifiez le Log Selector :

• All events (notre choix, par souci de simplicité).
• Read-only events ou Write-only events.
• Custom selectors pour un contrôle plus fin.

Une fois activés, les logs CloudTrail commencent à capturer les requêtes CloudWatch GetMetricData, mais il faut laisser le temps aux logs de s'accumuler avant de les analyser.

Créer une table Athena pour les logs CloudTrail

Maintenant que CloudTrail enregistre les requêtes CloudWatch GetMetricData dans un bucket S3, nous pouvons les analyser avec Amazon Athena.

Pour analyser les logs CloudTrail avec Amazon Athena, vous devez créer une table qui pointe vers les données de logs stockées dans votre bucket S3 :

• Ouvrez la console CloudTrail et rendez-vous dans Event history via le menu de gauche.
• Cliquez sur Create Athena table, puis dans la liste déroulante Storage location, sélectionnez le bucket S3 où sont stockés vos logs CloudTrail.

Interroger les événements GetMetricData

Nous pouvons à présent identifier qui ou quoi émet des requêtes GetMetricData dans Amazon Athena. La requête SQL ci-dessous n'est qu'un exemple, sur un petit jeu de données. Sur un jeu de données réel, une requête différente pourra donner des résultats plus précis.

SELECT
    COUNT(*) as count,
    eventname,
    useridentity.principalId,
    useridentity.arn
FROM cloudtrail_logs_aws_cloudtrail_logs_cw_metrics
WHERE eventname = 'GetMetricData'
GROUP BY eventname, useridentity.principalId, useridentity.arn
ORDER BY count DESC
LIMIT 100;

Interpréter les résultats

Les résultats de la requête (exemple ci-dessous) révèlent les sources qui génèrent les requêtes GetMetricData.

• La première ligne affiche 18 requêtes, ce qui en fait le principal poste de coût.
• Les colonnes principalId et arn permettent de déterminer si les requêtes proviennent d'un service AWS spécifique, d'un utilisateur/rôle IAM ou d'une application.
• Si certaines requêtes s'avèrent superflues, pensez à réduire la fréquence de polling, à affiner les paramètres de supervision ou à restreindre les accès pour faire baisser la facture.