Descubre los costos ocultos de CloudWatch Metrics

El monitoreo en la nube es clave para mantener y optimizar la infraestructura de AWS, y Amazon CloudWatch es una de las herramientas principales para hacer seguimiento de métricas, logs y alarmas. Sin embargo, a medida que crece tu uso de AWS, también lo hacen los costos de CloudWatch, y a veces resulta difícil rastrearlos.

Un reto común para los usuarios de AWS es identificar con precisión qué dispara los costos de CloudWatch en el Cost & Usage Report (CUR). Aunque el reporte ofrece un desglose general, le falta la atribución detallada que se necesita para detectar las fuentes específicas detrás de los costos elevados.

Este artículo presenta un caso real en el que se diagnostican costos inesperados de CloudWatch con DoiT Cloud Intelligence. Tras identificar las operaciones más costosas, mostraremos cómo aprovechar los data events de CloudTrail y Amazon Athena para descubrir el origen de esos cargos y obtener información accionable. Al final, tendrás una estrategia clara para entender y gestionar los costos ocultos de CloudWatch.

Amazon CloudWatch es una herramienta esencial de monitoreo para entornos AWS, ya que ofrece información detallada sobre métricas y logs. Sin embargo, su estructura de costos a veces resulta opaca, lo que dificulta identificar el origen de los picos inesperados en la factura.

Si bien el Cost & Usage Report (CUR) brinda un desglose granular de los costos de AWS, se queda corto cuando se trata de la visibilidad a nivel de recurso para cargos específicos. Un ejemplo claro es GetMetricData, una operación de API que se utiliza para recuperar datos de métricas de CloudWatch. A pesar de su impacto significativo en los costos, el CUR no ofrece el nivel de detalle suficiente para determinar qué servicios, aplicaciones o usuarios son responsables de esos cargos.

Esta falta de transparencia complica la optimización de costos, la prevención de excesos presupuestarios y la toma de decisiones informadas sobre las configuraciones de monitoreo.

Para ilustrar este reto, usamos los reportes de DoiT Cloud Analytics, que ayudan a visualizar e interpretar los datos de costos en la nube. La información se puede representar en distintos diagramas, además de filtrarse y agruparse para obtener mejores insights.

Por ejemplo, el siguiente análisis muestra un desglose detallado del costo de uso de CloudWatch durante 28 días, donde resaltan los costos consistentemente altos asociados a las operaciones GMD-Metrics (GetMetricData).

La tabla de costos a continuación clasifica los gastos de CloudWatch por SKU (Stock Keeping Unit), tipo de operación e información del recurso. Lo más relevante:

• GMD-Metrics (GetMetricData) es uno de los principales generadores de costos.
• Falta la información del recurso, lo que dificulta determinar el origen de las solicitudes.
• MetricMonitorUsage también suma a los costos, aunque en menor medida.

Dado que GetMetricData está disparando costos significativos y sin explicación clara, hace falta una investigación más detallada con los data events de CloudTrail y Amazon Athena para rastrear su origen.

De forma predeterminada, AWS CloudTrail registra eventos de gestión, como cambios de IAM, configuraciones de seguridad y aprovisionamiento de recursos. Sin embargo, los data events, que capturan llamadas de API específicas de cada servicio (como operaciones a nivel de objeto en S3 o ejecuciones de Lambda), no vienen habilitados por defecto.

Como necesitamos rastrear los eventos de CloudWatch Metrics, hay que habilitar de forma explícita los data events de CloudTrail. Esto se puede configurar en un trail existente o creando uno nuevo.

Configurar CloudTrail

1. Elegir un trail de CloudTrail

• Modifica un trail existente o crea uno nuevo.
• Define un bucket de S3 para almacenar los logs de CloudTrail.

2. Configurar funciones opcionales

• Cifrado con KMS (opcional) para mayor seguridad.
• Validación de logs y notificaciones de SNS (opcionales, para integridad y alertas).
• Almacenamiento en CloudWatch Logs (no aplica aquí, ya que usamos Athena para el análisis).

Definir el data event para CloudWatch Metrics

1. Selecciona CloudWatch metric como tipo de Data Event.

2. Especifica el Log Selector:

• Todos los eventos (nuestra elección por simplicidad).
• Eventos de solo lectura o de solo escritura.
• Usa selectores personalizados para tener mayor control.

Una vez habilitado, los logs de CloudTrail empezarán a capturar las solicitudesGetMetricDatade CloudWatch, pero hay que esperar a que se acumulen suficientes logs antes de analizarlos.

Crear una tabla de Athena para los logs de CloudTrail

Ahora que CloudTrail está registrando las solicitudesGetMetricDatade CloudWatch en un bucket de S3, podemos usar Amazon Athena para analizarlas.

Para analizar los logs de CloudTrail con Amazon Athena, debes crear una tabla que haga referencia a los datos de log almacenados en tu bucket de S3:

• Entra a la consola de CloudTrail y ve a Event history en el menú lateral izquierdo.
• Haz clic en Create Athena table y, en el menú desplegable de Storage location, selecciona el bucket de S3 donde se almacenan tus logs de CloudTrail.

Consultar los eventos GetMetricData

Ahora podemos consultar en Amazon Athena quién o qué está haciendo solicitudesGetMetricData. Esta consulta SQL es solo un ejemplo sobre un conjunto de datos pequeño. Con un dataset real, una consulta distinta podría arrojar resultados más precisos.

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;

Interpretar los resultados

Los resultados de la consulta (ejemplo a continuación) revelan las fuentes que originan las solicitudesGetMetricData.

• La fila superior muestra 18 solicitudes, lo que la convierte en el principal generador de costos.
• Las columnas principalId y arn ayudan a identificar si las solicitudes provienen de un servicio específico de AWS, un usuario o rol de IAM, o una aplicación.
• Si las solicitudes excesivas no son necesarias, considera reducir la frecuencia de polling, ajustar la configuración de monitoreo o restringir el acceso para bajar los costos.