Alla scoperta dei costi nascosti delle metriche CloudWatch

Il monitoraggio del cloud è fondamentale per mantenere e ottimizzare l'infrastruttura AWS, e Amazon CloudWatch è uno degli strumenti di riferimento per tenere sotto controllo metriche, log e allarmi. Tuttavia, con il crescere dell'utilizzo di AWS aumentano anche i costi di CloudWatch, che a volte diventano difficili da ricostruire.

Una difficoltà ricorrente per chi usa AWS è individuare con precisione le voci che pesano sui costi di CloudWatch all'interno del Cost & Usage Report (CUR). Il report offre una panoramica di alto livello, ma non scende nel dettaglio necessario per identificare le fonti specifiche delle spese più elevate.

In questo articolo presentiamo un caso reale di diagnosi di costi CloudWatch inattesi tramite DoiT Cloud Intelligence. Dopo aver individuato le operazioni più onerose, vedremo come sfruttare gli eventi dati di CloudTrail e Amazon Athena per risalire all'origine di queste spese e ricavarne indicazioni operative. Al termine, avrà a disposizione una strategia chiara per comprendere e gestire i costi nascosti di CloudWatch.

Amazon CloudWatch è uno strumento di monitoraggio indispensabile negli ambienti AWS e fornisce visibilità dettagliata su metriche e log. La sua struttura dei costi, però, può risultare poco trasparente e rende difficile capire da dove arrivino picchi di fatturazione inattesi.

Il Cost & Usage Report (CUR) offre una suddivisione granulare dei costi AWS, ma si rivela insufficiente quando serve visibilità a livello di risorsa su voci di spesa specifiche. Un esempio significativo è GetMetricData, l'operazione API utilizzata per recuperare i dati delle metriche di CloudWatch. Nonostante il suo impatto rilevante sui costi, il CUR non fornisce dettagli sufficienti a stabilire quali servizi, applicazioni o utenti generino questi addebiti.

Questa scarsa trasparenza rende complicato ottimizzare i costi, evitare di sforare il budget e prendere decisioni informate sulle configurazioni di monitoraggio.

Per illustrare il problema abbiamo utilizzato i report di DoiT Cloud Analytics, che permettono di visualizzare e interpretare i dati sui costi del cloud. I dati possono essere rappresentati con diversi tipi di diagrammi, oltre che filtrati e raggruppati per ottenere indicazioni più puntuali.

L'analisi seguente, ad esempio, propone una suddivisione dettagliata dei costi di CloudWatch su un arco di 28 giorni e mette in evidenza i costi costantemente elevati legati alle operazioni GMD-Metrics (GetMetricData).

La tabella qui sotto suddivide ulteriormente le spese di CloudWatch per SKU (Stock Keeping Unit), tipo di operazione e informazioni sulla risorsa. In particolare:

• GMD-Metrics (GetMetricData) è tra le principali voci di costo.
• Mancano le informazioni sulla risorsa, e questo rende difficile risalire all'origine delle richieste.
• Anche MetricMonitorUsage incide sui costi, ma in misura minore.

Poiché GetMetricData genera costi consistenti e non spiegati, serve un'indagine più approfondita con gli eventi dati di CloudTrail e Amazon Athena per risalire alla loro origine.

Per impostazione predefinita, AWS CloudTrail registra gli eventi di gestione, come modifiche IAM, configurazioni di sicurezza e provisioning delle risorse. Gli eventi dati, invece, che intercettano chiamate API specifiche di un servizio (per esempio le operazioni a livello di oggetto su S3 o le esecuzioni di Lambda), non sono attivi di default.

Per tracciare gli eventi delle metriche di CloudWatch è quindi necessario abilitare esplicitamente gli eventi dati di CloudTrail. La configurazione può avvenire su un trail esistente oppure creandone uno nuovo.

Configurare CloudTrail

1. Scegliere un trail di CloudTrail

• Modificare un trail esistente o crearne uno nuovo.
• Indicare un bucket S3 in cui archiviare i log di CloudTrail.

2. Configurare le funzionalità opzionali

• Crittografia KMS (opzionale) per maggiore sicurezza.
• Convalida dei log e notifiche SNS (opzionali, per integrità e avvisi).
• Archiviazione su CloudWatch Logs (non rilevante in questo caso, dato che usiamo Athena per l'analisi).

Definire l'evento dati per le metriche CloudWatch

1. Selezionare CloudWatch metric come tipo di evento dati.

2. Specificare il Log Selector:

• All events (la nostra scelta, per semplicità).
• Read-only events oppure Write-only events.
• Custom selectors, per un controllo più granulare.

Una volta abilitato, CloudTrail inizierà a registrare le richieste GetMetricData di CloudWatch, ma occorrerà attendere che si accumulino log a sufficienza prima di poterli analizzare.

Creare una tabella Athena per i log di CloudTrail

Ora che CloudTrail registra le richieste GetMetricData di CloudWatch in un bucket S3, possiamo usare Amazon Athena per analizzarle.

Per analizzare i log di CloudTrail con Amazon Athena occorre creare una tabella che faccia riferimento ai dati di log archiviati nel bucket S3:

• Aprire la console di CloudTrail e selezionare Event history nel menu di sinistra.
• Cliccare su Create Athena table e, nel menu a discesa Storage location, scegliere il bucket S3 in cui sono archiviati i log di CloudTrail.

Interrogare gli eventi GetMetricData

A questo punto possiamo interrogare Amazon Athena per capire chi o cosa stia generando le richieste GetMetricData. La query SQL che segue è solo un esempio basato su un piccolo set di dati di prova: su un dataset reale, una query diversa potrebbe restituire risultati più accurati.

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;

Interpretare i risultati

I risultati della query (esempio riportato di seguito) mostrano le fonti che generano le richieste GetMetricData.

• La prima riga registra 18 richieste, risultando il principale fattore di costo.
• Le colonne principalId e arn aiutano a capire se le richieste provengano da uno specifico servizio AWS, da un utente o ruolo IAM oppure da un'applicazione.
• Se le richieste in eccesso non sono necessarie, valuti di ridurre la frequenza di polling, ottimizzare le impostazioni di monitoraggio o limitare gli accessi per contenere i costi.