¿Tu factura de CloudWatch es cada vez más cara? Guía práctica de reducción de costos para Logs y Metrics

CloudWatch puede pasar fácilmente de ser la “herramienta de observabilidad por defecto” a convertirse en un agujero negro en tu factura. Especialmente después de integrar contenedores, microservicios, Lambda, API Gateway y VPC Flow Logs, conceptos como Logs ingest, retención de logs, Custom Metrics, Alarms y Dashboards crecen en conjunto. Para reducir costos, el primer paso no es eliminar el monitoreo, sino desglosar con claridad en qué se está gastando el dinero.

Los siguientes precios se basan en tarifas públicas comunes de us-east-1 como referencia; los costos reales dependerán de la región de AWS que utilices: la ingesta estándar de CloudWatch Logs suele rondar los $0.50/GB, el archivo de logs aproximadamente $0.03/GB-month; las consultas de Logs Insights suelen costar $0.005/GB scanned; los primeros 10,000 Custom Metrics cuestan unos $0.30/metric-month; las alarmas de resolución estándar rondan los $0.10/alarm metric-month; y los dashboards personalizados tienen un costo aproximado de $3/dashboard-month.

Primero localiza: ¿El gasto viene de Logs o de Metrics?

En Cost Explorer, selecciona CloudWatch en Service y luego desglosa por Usage type. Los elementos de alto costo más comunes incluyen:

• DataProcessing-Bytes: Ingesta de logs.
• TimedStorage-ByteHrs: Almacenamiento/retención de logs.
• MetricMonitorUsage: Métricas personalizadas.
• AlarmMonitorUsage: Alarmas.
• GMD-Metrics o solicitudes de API: Consultas de GetMetricData.

Muchos equipos asumen que los dashboards son la parte costosa, cuando en realidad el problema suele ser la ingesta de logs o las custom metrics de alta cardinalidad.

Logs - Táctica 1: Configurar el período de retención

Por defecto, los Log Groups de CloudWatch pueden retener los datos indefinidamente. Para los logs de aplicaciones, muchos equipos solo necesitan retención en línea de 7, 14, 30 o 90 días.

Visualización en lote:

aws logs describe-log-groups \
  --query 'logGroups[*].[logGroupName,retentionInDays,storedBytes]' \
  --output table

Configurar la retención:

aws logs put-retention-policy \
  --log-group-name /aws/ecs/prod-api \
  --retention-in-days 30

Se recomienda organizar la retención por capas según el tipo de log: 90 días para logs de errores de producción, entre 14 y 30 días para logs generales de la aplicación, de 3 a 7 días para logs de depuración (debug), y exportar los logs de auditoría y cumplimiento a S3 para almacenamiento a largo plazo.

Logs - Táctica 2: Filtrar antes de la ingesta, no al consultar

La parte más costosa de CloudWatch Logs suele ser la ingesta. Filtrar mediante subscription filters o Logs Insights una vez que los logs ya están en CloudWatch no te ahorrará la tarifa de ingesta.

Debes filtrar los logs en la aplicación, en el sidecar, o en herramientas como Fluent Bit u OpenTelemetry Collector:

[FILTER]
    Name   grep
    Match  app.*
    Exclude log ^.*healthcheck.*$

Prioriza descartar logs de alta frecuencia y bajo valor, como health checks, peticiones 200 de recursos estáticos, depuraciones (debug) repetitivas o payloads excesivamente largos. Mantener por defecto el nivel INFO en producción y cambiar temporalmente a DEBUG solo para solucionar problemas es mucho más económico que recopilar de forma continua todo el debug.

Logs - Táctica 3: Limpiar Log Groups sin uso

Cuando se eliminan o retiran servicios de Lambda, ECS, API Gateway o Step Functions, no siempre se eliminan automáticamente sus log groups. Puedes identificar aquellos grupos que llevan mucho tiempo sin registrar actividad:

aws logs describe-log-groups \
  --query 'logGroups[?storedBytes>`0`].[logGroupName,storedBytes,retentionInDays]' \
  --output table

Luego, combínalo con lastEventTimestamp para verificar si todavía están en uso. Se recomienda exportar los datos a S3 antes de borrarlos para evitar la pérdida accidental de datos de cumplimiento.

Logs - Táctica 4: Cuidado con la integración de logs de proveedores con alto tráfico

Los logs de VPC Flow Logs, ALB Access Logs, WAF Logs y CloudFront Logs pueden ser inmensos. No los envíes todos a CloudWatch por defecto.

La práctica más común es:

• Enviar logs a CloudWatch para la resolución de problemas a corto plazo.
• Enviar logs de acceso a S3 para el almacenamiento a largo plazo.
• Utilizar Athena para consultar datos históricos.
• Muestrear únicamente los campos necesarios en VPC Flow Logs, o habilitarlos solo para subredes o interfaces de red (ENI) críticas.

La experiencia interactiva de S3 + Athena no es tan inmediata como la de CloudWatch Logs, pero el costo de retención a largo plazo suele ser mucho menor, ideal para consultas de auditoría de baja frecuencia.

Logs - Táctica 5: Evaluar alternativas como opción complementaria

Si el problema principal radica en el costo de ingesta y almacenamiento de CloudWatch Logs, puedes evaluar opciones alternativas. Por ejemplo, S4 Logs es un producto alternativo optimizado para reducir los costos de CloudWatch Logs, ideal para escenarios con gran volumen de logs, períodos largos de retención y donde la capacidad de consulta nativa de CloudWatch no es el único requisito indispensable.

No debe considerarse como un “reemplazo a ciegas de CloudWatch”. Si tu equipo depende en gran medida de Logs Insights, CloudWatch Alarms y de tus flujos de operaciones actuales, debes calcular el costo de la migración. Un enfoque más práctico es elegir un log group de alto tráfico y bajo riesgo para realizar un piloto, y luego utilizar la calculadora de costos para estimar el rango de ahorro.

Metrics - Táctica 1: Controlar la cardinalidad

El riesgo principal de las Custom Metrics es la alta cardinalidad. CloudWatch factura según la combinación de namespace, metric name y dimension. Un diseño de dimensiones como el siguiente es peligroso:

MetricName=Latency
Dimensions=service, endpoint, customer_id, pod_id, request_id

Si hay 10,000 valores para customer_id y 50 para endpoint, la combinación teórica se expandirá rápidamente. Lo más seguro es conservar únicamente las dimensiones estrictamente necesarias para la resolución de problemas y alarmas:

MetricName=LatencyP95
Dimensions=service, endpoint, environment

Los campos de alta cardinalidad como pod_id o request_id son más adecuados para incluirse en logs o traces, no como dimensiones de CloudWatch custom metrics.

Metrics - Táctica 2: Agregar antes de reportar

Evita ejecutar PutMetricData directamente desde cada instancia, inquilino o endpoint. Puedes agregar las métricas en la aplicación o en la capa del collector, por ejemplo, reportando p50/p95/p99, count y error_count una vez cada 60 segundos.

La API de PutMetricData también genera costos por solicitudes, con una tarifa común de unos $0.01/1,000 requests. Cambiar la frecuencia de reporte de 10 a 60 segundos por lo general no afecta a la mayoría de las alertas de negocio, pero reduce drásticamente las solicitudes de API y la cantidad de métricas.

Metrics - Táctica 3: Utilizar EMF correctamente

El formato Embedded Metric Format permite extraer métricas a partir de logs estructurados, lo cual es excelente para conectar logs con métricas. Sin embargo, EMF no genera “métricas gratuitas”. Sigue generando costos por ingesta de logs y puede generar cobros por custom metrics.

Al usar EMF, ten en cuenta lo siguiente:

• Evita incluir user_id, order_id o container_id en las dimensiones.
• Controla el número de namespaces.
• Agrega los eventos de alta frecuencia antes de generar la salida EMF.
• Revisa periódicamente cuántas unique metrics reales se están generando.

Metrics - Táctica 4: Gestionar también las alarmas y Dashboards

Un problema común con las alarmas es crear una para cada combinación de dimensiones, lo que resulta en miles de alarmas. Es más recomendable:

• Crear un número reducido de alarmas agregadas para los SLO críticos.
• Investigar los detalles específicos a través de dashboards o logs.
• Utilizar composite alarms para reducir el ruido de las alarmas relacionadas.
• Eliminar los dashboards que nadie consulta.

Aunque el precio unitario de un dashboard no sea muy alto, la actualización automática frecuente genera costos de la API GetMetricData, especialmente en pantallas de monitoreo y sistemas que realizan consultas cíclicas (polling).

¿Cuándo considerar S4 Metrics?

Si el problema principal con CloudWatch Custom Metrics son los costos derivados de la alta cardinalidad, pero tu negocio realmente necesita conservar métricas detalladas, puedes evaluar alternativas como S4 Metrics. Su propósito es reducir el costo de cardinalidad de las métricas personalizadas de CloudWatch, no reemplazar todo el sistema de observabilidad. Se recomienda comenzar con un piloto A/B utilizando namespaces no críticos o la familia de métricas con el costo más elevado.

Un plan de 7 días listo para ejecutar

Día 1: Identifica en Cost Explorer el usage type principal de CloudWatch. Día 2: Enumera el tamaño y la retención de todos los log groups. Día 3: Cambia la retención predeterminada indefinida a un esquema por niveles de 7, 14, 30 o 90 días. Día 4: Configura filtros previos en Fluent Bit u OTel Collector para descartar logs de bajo valor. Día 5: Redirige los logs de largo plazo hacia S3 + Athena. Día 6: Exporta la lista de custom metrics y elimina las dimensiones con alta cardinalidad. Día 7: Evalúa si vale la pena realizar un piloto con alternativas como S4 Logs o S4 Metrics.

El principio para reducir costos en CloudWatch es simple: conserva las señales de alto valor y evita la ingesta de ruido de bajo valor; los datos que necesiten retención a largo plazo deben trasladarse a sistemas diseñados específicamente para ese propósito.

Nota: El autor de este artículo pertenece a abyo software (desarrolladores de S4, un producto de optimización de costos disponible en AWS Marketplace).