AWS Builder Center

Builder Center

Alarmas de Amazon CloudWatch con ventana de reloj: un día no es lo mismo que 24 horas

¿Se hizo el backup ayer? Es una pregunta sencilla y casi nunca la hace alguien de operaciones. La hace la persona dueña del proceso, y no quiere saber si hubo un backup exitoso en las últimas 24 horas contadas desde este minuto. Quiere saber si el martes quedó cubierto. Parece un matiz. Pero cuando la alarma y la persona que pregunta miden cosas distintas, aparecen alarmas que suenan sin que haya un problema real y reportes que no cuadran con lo que el negocio cree que se acordó.

vtjean

Este artículo va sobre el objetivo, la pieza de la serie que casi siempre se da por sentada. Una alarma tiene un inicio, sí, pero también tiene una ventana de evaluación, y esa ventana es la que define qué significa "cumplir". Cumplir durante un día calendario en tu zona horaria no es lo mismo que cumplir durante un intervalo móvil de 24 horas. Desde el 7 de agosto de 2026, Amazon CloudWatch permite elegir cuál de las dos cosas quieres medir.

Qué se anunció

Las alarmas de CloudWatch ahora aceptan una ventana de evaluación alineada al reloj, además de la ventana deslizante que ya existía. La función está disponible en todas las Regiones donde CloudWatch está disponible, excepto Medio Oriente (EAU) y Medio Oriente (Baréin).
El cambio no toca las alarmas que ya tienes. Si no indicas nada, la alarma sigue usando una ventana deslizante, igual que antes.

Longitud y posición de la ventana

Hay dos ideas que conviene separar porque es fácil mezclarlas.
La longitud de la ventana de evaluación es el período multiplicado por el número de períodos de evaluación. Una alarma con período de 1 hora y 3 períodos de evaluación mira 3 horas de datos. Eso no cambió.
Lo nuevo es dónde se ubica esa ventana en el tiempo. Eso lo controla el parámetro EvaluationWindow de la API PutMetricAlarm, que acepta dos valores:
  • SlidingWindow: es el valor predeterminado. La ventana es móvil y avanza con cada evaluación.
  • WallClockWindow: la ventana se alinea a los límites del reloj que corresponden al período, y opcionalmente a una zona horaria específica.
Con ventana deslizante, período de 1 hora y 1 período de evaluación, una evaluación puede cubrir de 13:07 a 14:07 y la siguiente de 13:08 a 14:08. La ventana se va corriendo. Con ventana de reloj y el mismo período, la alarma mira la hora de reloj completa: de 13:00 a 14:00, luego de 14:00 a 15:00.

El caso del backup diario

El ejemplo de la documentación es el que hace visible la diferencia sin mucha explicación.
Piensa en un job de backup que corre una vez al día y en un proceso que publica una métrica varias veces al día: 1 si terminó un backup desde la última publicación, 0 si no. Creas una alarma con período de 1 día, estadística Sum, 1 período de evaluación y la condición de que la suma sea al menos 1.
Con ventana deslizante, la alarma mira siempre las últimas 24 horas. Si dos backups consecutivos quedan separados por un poco más de 24 horas, por ejemplo porque uno terminó a las 01:10 y el siguiente a las 01:25 del día después, hay un tramo en el que las últimas 24 horas solo contienen ceros. La suma da 0 y la alarma entra en ALARM. Y sin embargo cada día calendario tuvo su backup. Para el negocio no pasó nada.
Con ventana de reloj, la alarma evalúa cada día calendario de forma independiente. Si el lunes hubo un backup y el martes hubo otro, las dos evaluaciones cumplen, sin importar cuántas horas separaron uno del otro.
Ahí está el punto: la ventana deslizante contesta "¿hubo actividad en las últimas N horas?" y la ventana de reloj contesta "¿hubo actividad en este día, en esta hora o en esta semana?". Las dos preguntas son válidas. El problema aparece cuando la alarma hace una y el acuerdo con el negocio está escrito en términos de la otra.

Dónde caen los límites

Los límites de la ventana de reloj dependen del período:
  • Período de 1 hora: el inicio de cada hora.
  • Período de 1 día: la medianoche.
  • Período de 1 semana: el lunes a las 00:00, que es el inicio de semana según ISO 8601.
Estos puntos de alineación son fijos y no se pueden cambiar. Si tu semana operativa empieza el domingo, o tu día de negocio arranca a las 06:00, la ventana de reloj no va a seguir esa convención. Lo que sí puedes ajustar es la zona horaria, que mueve dónde cae la medianoche o el lunes a las 00:00.
Los períodos soportados son 1 minuto, 5 minutos, 1 hora, 1 día y 1 semana. Si pides una ventana de reloj con otro período, la llamada devuelve un error de validación que lista los períodos soportados.

Zonas horarias

Por defecto, la ventana de reloj usa UTC. La zona se puede indicar de tres formas:
  • Identificadores IANA, como America/New_York.
  • Desplazamientos fijos respecto a UTC, como +05:30, -08:00 o Z.
  • Identificadores con prefijo de desplazamiento, como UTC+05:30 o GMT-08:00.
La zona tiene que resolverse a un desplazamiento que sea múltiplo de 5 minutos. Un valor como +01:03 se rechaza.
En la práctica, la diferencia que pesa es el horario de verano. Las zonas IANA lo manejan de forma automática. Los desplazamientos fijos y los identificadores con prefijo no lo observan. Si defines tu alarma diaria con -05:00 pensando en Nueva York, durante parte del año tu medianoche va a quedar una hora corrida respecto a la medianoche local.
Una nota corta para quienes operamos desde Puerto Rico: la isla no observa horario de verano, así que America/Puerto_Rico se comporta igual todo el año. La distinción entre IANA y desplazamiento fijo importa más cuando el mismo equipo opera cargas que siguen zonas del territorio continental de Estados Unidos. En ese caso conviene usar identificadores IANA para no enterarse del cambio de hora por una alarma.
Otro detalle: las zonas cuyo desplazamiento no es de horas completas, como Asia/Kolkata, mueven también los límites horarios y los de menos de una hora. Con Asia/Kolkata, una alarma horaria de reloj no coincide con el inicio de hora en UTC.

La frecuencia de evaluación no cambia

Algo que confunde al principio: una alarma de reloj con período de 1 hora no se evalúa una vez por hora. Se sigue evaluando cada minuto. Lo que cambia es qué mira. En cada evaluación, la alarma considera la hora de reloj completada más reciente.
De ahí sale el compromiso principal de la función. Con ventana de reloj, un punto de datos solo se refleja en la alarma cuando termina el período que lo contiene. Si algo falla a las 13:05 en una alarma horaria de reloj, la alarma lo va a tomar en cuenta cuando cierre la hora de 13:00 a 14:00, no antes.

Cuándo usarla y cuándo no

Por ese retraso, la documentación no recomienda la ventana de reloj para alarmas que disparan acciones de escalado automático. Para rendimiento en tiempo real, latencia o agotamiento de recursos, sigue con la ventana deslizante. Ahí lo que importa es reaccionar rápido.
La ventana de reloj encaja en cargas donde el objetivo ya está expresado en términos de calendario:
  • Jobs batch diarios que tienen que terminar antes de la medianoche en una zona horaria concreta.
  • Reportes semanales de cumplimiento o de negocio.
  • Backups.
  • Cargas programadas en general.
Una prueba útil al revisar alarmas: si al escribir el objetivo aparecen frases como "por día", "cada semana", "antes de medianoche" o "en horario de Nueva York", probablemente quieres una ventana de reloj. Si aparece "en los últimos 5 minutos" o "de forma sostenida", probablemente no.

Un día sin datos también define el objetivo

Falta el caso contrario: que no llegue ningún dato. Si el job o el proceso que publica la métrica dejan de correr, ese día la métrica no tiene ceros, tiene un hueco. CloudWatch no suma huecos. Los trata según la configuración de datos faltantes de la alarma, y el valor predeterminado es missing: si no hay ningún dato en el rango que se evalúa, la alarma pasa a INSUFFICIENT_DATA. Si solo configuraste la notificación para el estado ALARM, el día que el backup no corre nadie se entera.
Con ventana deslizante, cuando faltan datos, CloudWatch busca puntos más atrás del rango de evaluación y puede evaluar la alarma con un dato real anterior. La ventana de reloj no hace eso. Lee exactamente la ventana alineada, el período por los períodos de evaluación, y nada más. Si el martes no tiene datos, la alarma no va a buscar al lunes.
Por eso, con ventana de reloj, el tratamiento de datos faltantes forma parte de la definición del objetivo. Al crear la alarma hay que contestar qué significa un período sin datos:
  • Si la métrica confirma que algo salió bien, como un backup exitoso, un día sin datos es un incumplimiento. Corresponde breaching.
  • Si la métrica solo aparece cuando algo sale mal, como un fallo de cumplimiento, una semana sin datos es una buena semana. Corresponde notBreaching.
  • Si no lo decides, queda missing. La alarma del backup se va a INSUFFICIENT_DATA el día que falla, y la de cumplimiento se queda en INSUFFICIENT_DATA en las semanas en que todo salió bien.
Los ejemplos de la siguiente sección ya incluyen esa decisión.

Ejemplos con la AWS CLI

Estos ejemplos usan la AWS Command Line Interface (AWS CLI). Cada comando va en una sola línea.
Una alarma diaria de backup alineada a la medianoche de Puerto Rico:
1
aws cloudwatch put-metric-alarm --alarm-name DailyBackupCheck --metric-name SuccessfulBackups --namespace MyApplication --statistic Sum --period 86400 --evaluation-periods 1 --threshold 1 --comparison-operator LessThanThreshold --evaluation-window '{"WallClockWindow":{"Timezone":"America/Puerto_Rico"}}' --treat-missing-data breaching
El período de 86400 segundos es un día. La alarma suma los backups exitosos de cada día calendario y entra en ALARM si el total es menor que 1 o si el día no tiene datos, que es lo que pasa cuando el proceso que publica la métrica deja de correr. Si tu carga sigue el horario de la costa este, cambia la zona a America/New_York y deja que la zona IANA resuelva el horario de verano.
Una alarma semanal de cumplimiento en UTC:
1
aws cloudwatch put-metric-alarm --alarm-name WeeklyComplianceCheck --metric-name ComplianceFailures --namespace MyApplication --statistic Sum --period 604800 --evaluation-periods 1 --threshold 0 --comparison-operator GreaterThanThreshold --evaluation-window '{"WallClockWindow":{}}' --treat-missing-data notBreaching
Aquí el período es una semana y el objeto WallClockWindow va vacío, así que la zona es UTC. La semana arranca el lunes a las 00:00 UTC y cualquier fallo de cumplimiento dentro de esa semana pone la alarma en ALARM. Como una semana sin fallos no publica ningún dato, notBreaching hace que esa semana cuente como cumplida en lugar de dejar la alarma en INSUFFICIENT_DATA.
Para confirmar cómo quedó configurada una alarma:
1
aws cloudwatch describe-alarms --alarm-names DailyBackupCheck
Si la alarma usa ventana de reloj, la respuesta incluye el campo EvaluationWindow. Si el campo no aparece, la alarma usa ventana deslizante. Vale la pena meter esta verificación en cualquier revisión de alarmas, porque en una lista las dos variantes se ven iguales.
Si ya tienes una alarma y quieres pasarla de ventana deslizante a ventana de reloj, o al revés, puedes hacerlo en cualquier momento actualizando la alarma.

En la consola

En la consola de CloudWatch, al crear o editar la alarma, busca la sección Evaluation window y elige Wall clock window. Si la opción no aparece, el tipo de métrica o el período que elegiste no la soporta. Lo primero que conviene revisar es el período.

Metric math y Metrics Insights

Hay dos reglas adicionales cuando la alarma no es sobre una métrica simple.
En alarmas de metric math y de CloudWatch Metrics Insights, cada métrica del arreglo Metrics tiene que usar un período soportado por la ventana de reloj. No alcanza con que la expresión final lo cumpla.
Las alarmas de Metrics Insights pueden evaluar como máximo 3 horas, es decir, período por períodos de evaluación. Con ventana de reloj, CloudWatch reserva un período adicional, así que el límite efectivo es período por (períodos de evaluación + 1), menor o igual a 3 horas. Con período de 1 hora, la ventana deslizante admite hasta 3 períodos de evaluación y la ventana de reloj hasta 2. Si migras una alarma de Metrics Insights que ya usa 3 períodos de 1 hora, vas a tener que bajar a 2 antes de cambiar la ventana.

El runbook empieza con una pregunta ya contestada

Esto también cambia la primera página del runbook. Con ventana deslizante, cuando la alarma suena, la persona de guardia tiene que reconstruir qué intervalo exacto se evaluó y decidir si el problema es real o es un efecto de cómo cayó la ventana. Con ventana de reloj, la alarma ya dice qué día, qué hora o qué semana falló.
El primer paso del runbook puede ser directo: identificar el día calendario afectado y revisar la ejecución del job de ese día. La conversación con la persona dueña del proceso también se simplifica, porque las dos partes hablan del mismo "ayer". Cuando alguien pregunta si el backup del martes quedó hecho, la alarma ya evaluó el martes.

Limitaciones

  • No está disponible en Medio Oriente (EAU) ni en Medio Oriente (Baréin).
  • No aplica a alarmas de alta resolución (períodos de 10, 20 o 30 segundos), alarmas compuestas ni alarmas PromQL.
  • Solo soporta períodos de 1 minuto, 5 minutos, 1 hora, 1 día y 1 semana.
  • Los puntos de alineación son fijos. No puedes definir que el día empiece a las 06:00 ni que la semana empiece el domingo.
  • Un punto de datos se refleja solo cuando termina su período. En una alarma diaria, un fallo temprano en el día se refleja cuando cierra ese día.
  • La ventana de reloj no busca puntos de datos fuera de la ventana alineada. Si no configuras cómo tratar los datos faltantes, un período sin datos deja la alarma en INSUFFICIENT_DATA en lugar de ALARM.
  • No es buena opción para alarmas que disparan escalado automático ni para señales que necesitan reacción inmediata.
  • En Metrics Insights, la ventana de reloj reserva un período adicional dentro del límite de 3 horas, así que admite un período de evaluación menos que la ventana deslizante.
  • Los desplazamientos fijos y los identificadores con prefijo no observan horario de verano. Si eliges uno por comodidad, la alineación se corre durante parte del año.
  • La zona horaria tiene que resolverse a un desplazamiento múltiplo de 5 minutos.

Recursos

# amazon-cloudwatch# monitoring-observability# observability# sre# cloud-operations
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article