CloudWatch factura por cinco ejes y casi todos los equipos miran uno

Un equipo que investiga una subida inesperada en AWS mira CloudWatch, ve la ingesta de registros, pone una retención más corta en el grupo más grande y sigue adelante. La factura apenas cambia, porque la retención nunca fue la parte cara.

CloudWatch cobra por separado la ingesta de registros, el almacenamiento de registros, las métricas personalizadas, las llamadas a la API de métricas, los paneles, las alarmas y las consultas de análisis de registros. Cada uno tiene su unidad y su modo de fallo, y los dos que generan casi toda la sorpresa son las métricas personalizadas y el registro de aplicación dejado en nivel de depuración.

Averigua por qué eje estás pagando

Antes de cambiar nada, desglosa la línea de CloudWatch por tipo de uso en el explorador de costes. Los tipos de uso nombran el eje directamente, distinguiendo datos ingeridos, almacenamiento por tiempo, métricas y peticiones a la API.

Después saca el desglose por grupo de registro, porque el reparto siempre es desigual. La métrica de bytes entrantes por grupo de registro en los últimos treinta días te dice adónde va la ingesta, y tres o cuatro grupos se llevarán casi todo.

Haz las dos cosas antes de tocar nada. Los equipos optimizan con regularidad la tercera línea más grande porque era la que entendían.

Métricas personalizadas y la explosión de dimensiones

Esta es la que produce números genuinamente escandalosos, y es aritmética, no mala suerte.

Una métrica personalizada se factura por cada combinación única de nombre de métrica y valores de dimensión. Publica una métrica con una dimensión de servicio de diez valores y una de extremo de veinte, y tienes doscientas métricas. Añade una dimensión con el identificador de cliente y cinco mil valores y tienes un millón, cada una facturada al mes.

La regla es la misma que para las etiquetas de Prometheus: el valor de una dimensión tiene que venir de un conjunto pequeño y acotado. Nunca uses identificador de cliente, de petición o de usuario, una ruta de URL completa, un identificador de instancia en una flota que rota, ni una cadena de versión que cambia en cada despliegue. La plantilla de la ruta, no la ruta resuelta, exactamente como en Prometheus a escala.

Dos detalles que conviene conocer. El formato de métricas embebidas te permite escribir métricas dentro de un evento de registro estructurado, y CloudWatch las extrae, lo que cambia la forma del coste y te deja conservar los campos de alta cardinalidad como propiedades del registro mientras solo los de baja cardinalidad se convierten en métricas. Esa suele ser la arquitectura correcta. Y los filtros de métricas sobre grupos de registro crean métricas a partir del contenido, lo cual es cómodo y crea cardinalidad en silencio si el filtro captura un valor variable.

Revisa también las métricas que no consume nadie. Una métrica publicada desde 2022 que ningún panel ni alarma referencia es un cargo mensual puro, y enumerar métricas contra las alarmas y paneles que las usan es una tarde que con frecuencia se paga sola.

La ingesta y el nivel de registro que nadie revirtió

La ingesta se cobra por gigabyte y es donde el comportamiento de una aplicación se ve directamente.

Las causas habituales, en el orden en que las encontramos:

• Registro de depuración activado en producción. Encendido durante un incidente, nunca apagado. Es la causa individual más común de un escalón en la línea de CloudWatch.
• Funciones que registran cada invocación. Con muchas invocaciones, la salida de registro de la propia función puede costar más que su cómputo.
• Registros de flujo de red a máxima verbosidad en interfaces con tráfico, que son un volumen enorme que casi nunca se consulta en crudo.
• Registros de acceso del balanceador incluidas las comprobaciones de salud, que son una fracción grande de las peticiones y no se leen nunca.
• Trazas de pila multilínea contadas como muchos eventos salvo que el agente las una.

Los arreglos estructurales son los de los logs son la línea que crece: eventos estructurados, niveles usados como se diseñaron, y un nivel de registro dinámico para que un ingeniero pueda subir la verbosidad de una función sin desplegar y sin que se vuelva permanente.

Donde el dato hace falta pero no a precio de análisis, los filtros de suscripción pueden encaminar los registros a otro sitio, y la clase de acceso infrecuente cuesta menos de ingerir a cambio de funciones de consulta reducidas. Comprueba qué pierdes antes de mover un grupo, en particular filtros de métricas y alarmas.

Almacenamiento, retención y el valor por defecto que más cuesta

Los grupos de registro no caducan por defecto. Ese valor por defecto es la razón de que la mayoría de las cuentas guarden años de registros de aplicación que nadie ha consultado desde la semana en que se escribieron.

Pon retención por grupo y por clase en vez de un número para todo: registros de auditoría y seguridad, lo que diga el requisito de cumplimiento; registros de aplicación, entre uno y tres meses; registros de depuración y de acceso, días. Hazlo cumplir con una política para que los grupos nuevos no hereden el valor infinito, porque una limpieza manual la deshace el siguiente despliegue.

Para lo que de verdad necesite retención larga, exporta a almacenamiento de objetos y aplica reglas de ciclo de vida ahí. El precio de almacenamiento es mucho menor, y el camino de consulta es más lento de una forma que encaja con lo poco que vas a usarlo, que es el mismo razonamiento de S3 y la transferencia de datos.

Consultas, paneles y alarmas

El análisis de registros se factura por gigabyte escaneado. Una consulta sobre un grupo grande con un rango temporal amplio escanea todo lo que hay dentro, y un elemento de panel respaldado por una consulta se relanza en cada refresco, para cada persona que lo mira. Eso es un gasto programado disfrazado de comodidad. Estrecha el rango temporal, filtra pronto en la consulta y ten cuidado con poner consultas de análisis en un panel que está abierto en una pantalla de pared todo el día.

Los paneles se facturan por encima de una franquicia, lo cual es menor salvo que el entorno haya acumulado decenas que nadie abre. Las alarmas se facturan por alarma, con las compuestas y las de alta resolución a precios distintos, y las de alta resolución son apreciablemente más caras. Usa resolución estándar salvo que necesites de verdad detección por debajo del minuto.

La API se cobra por petición, y una herramienta de observabilidad de terceros consultando miles de métricas cada minuto es una línea real. Si ejecutas una plataforma de monitorización externa, comprueba qué está tirando y con qué frecuencia. Los flujos de métricas suelen salir más baratos que el sondeo a escala.

Lo que se olvida

• Las métricas de contenedores y la monitorización mejorada son métricas personalizadas. Activarlas en un clúster grande crea muchas métricas por nodo y por pod. Útiles, y no gratis.
• Todos los servicios de AWS escriben registros en algún sitio. Aparecen grupos de registro sin que nadie los cree a propósito, y nada los borra.
• Los destinos de registro entre cuentas siguen facturando la ingesta, en la cuenta que recibe.
• Cambiar la retención no es retroactivo como la gente supone. Reducirla borra los datos antiguos, que es la idea, pero verifica antes que no hay nada relevante para cumplimiento en el grupo.
• Alarmas sobre métricas ausentes. Configura a conciencia el tratamiento de los datos que faltan, o una alarma no se disparará jamás en silencio.

Qué hacer esta semana

Lanza una consulta que liste tus grupos de registro ordenados por bytes ingeridos en los últimos treinta días, y al lado lista los grupos sin retención configurada. La intersección de esas dos listas es donde está el dinero, y poner retención en los cinco primeros es un cambio de diez minutos con efecto inmediato en la siguiente factura. Es la misma primera pasada que hacemos en la fase de costes de un proyecto cloud, junto a las capas de dónde se esconde la factura de AWS.