AWS Builder Center

Builder Center

Canaries multiubicación en Amazon CloudWatch Synthetics: ¿cuántas ubicaciones tienen que fallar para despertar a alguien?

Un canary que falla desde una sola Región deja una pregunta abierta. Puede que la aplicación esté caída para todos los usuarios. También puede ser un problema de red entre esa Región y el endpoint, o una dependencia que responde mal solo desde ahí. Con un solo punto de medición, quien está de guardia no tiene cómo distinguir un caso del otro, y la alarma suena igual en los dos.

vtjean

En esta serie, la señal y el objetivo han ido por separado: primero qué medir, después contra qué compararlo. Esta entrada los junta en una sola decisión. Desde el 18 de junio de 2026, Amazon CloudWatch Synthetics permite ejecutar el mismo canary desde varias Regiones a la vez y administrarlo desde un solo lugar. Eso cambia la señal, porque ahora hay varios puntos de vista, y obliga a definir el objetivo con más cuidado: cuántas ubicaciones tienen que fallar para que valga la pena despertar a alguien.

Cómo se medía antes

Antes, medir desde varias Regiones significaba crear y mantener un canary independiente en cada una. El anuncio lo describe como trabajo operativo adicional, con el riesgo de que las configuraciones se desalinearan con el tiempo: un canary se actualizaba y otro no, y las mediciones dejaban de ser comparables.
Un blog de AWS de 2023 proponía agrupar canaries de varias Regiones para tener una vista agregada. Ese enfoque y el nuevo no se combinan. Un canary multiubicación no puede pertenecer a un grupo, y si ya pertenece a uno hay que quitarlo de todos los grupos antes de agregarle réplicas.

Primaria y réplicas

El modelo tiene una Región primaria y réplicas. El canary se crea y se administra en la primaria, que es la fuente de verdad de la configuración, y CloudWatch Synthetics crea réplicas en las Regiones que se elijan, hasta 50. Cada réplica corre de forma independiente con el mismo script, el mismo horario y las mismas variables de entorno.
Todas las operaciones que cambian algo, como crear, actualizar, iniciar, detener o borrar, se hacen desde la primaria y se propagan a las réplicas de forma asíncrona. Desde una réplica no se puede editar, iniciar, detener ni borrar el canary. Un canary existente de una sola Región se puede convertir en multiubicación agregándole réplicas, sin recrearlo.
La propagación asíncrona tiene consecuencias prácticas. Cada réplica tiene un estado de replicación, visible en la pestaña Configuration del canary:
  • InProgress: la réplica se está creando o actualizando.
  • InSync: la réplica está sincronizada con la configuración de la primaria.
  • Inconsistent: la réplica quedó desalineada, por ejemplo porque falló una propagación. Se reintenta actualizando el canary otra vez.
Mientras alguna réplica está en InProgress, el canary no se puede modificar, iniciar ni detener. Si una réplica falla al crearse, el canary primario se crea igual y esa réplica queda en Inconsistent. El estado general que muestra la primaria resume todo: si alguna réplica está en InProgress, el estado general es InProgress, y si alguna está en Inconsistent, el general es Inconsistent. Conviene revisar ese estado después de cada cambio, porque un canary que parece desplegado en cinco Regiones puede estar corriendo en cuatro.

La señal: SuccessPercent por ubicación y agregado

En la Región primaria, el canary publica SuccessPercent con una dimensión Location para cada Región donde corre. Además publica un SuccessPercent agregado, sin esa dimensión, que representa la tasa de éxito combinada de todas las ubicaciones. Duration también se publica con la dimensión Location, igual que SuccessPercentWithRetries, que mide las ejecuciones que terminan bien después de todos los reintentos.
La documentación recomienda crear la alarma sobre el SuccessPercent agregado para vigilar la salud general del canary.
Las ejecuciones de todas las ubicaciones aparecen en una sola tabla en la primaria, con una columna Location que permite filtrar por Región. Los artefactos, como capturas de pantalla, archivos HAR y reportes, se guardan en el bucket de Amazon S3 del canary, con un prefijo de Región para las ejecuciones de las réplicas. Cada réplica también publica sus métricas en su propia Región, así que si la primaria no está disponible, los datos, las métricas y los logs de cada ubicación se pueden consultar directamente en la Región de la réplica.

El objetivo: cuántas ubicaciones cuentan como problema

El anuncio dice que se pueden configurar alarmas que se activen solo cuando el problema se detecta desde varias ubicaciones, para evitar notificaciones por fallas de red aisladas y transitorias. La documentación no explica cómo se construye exactamente esa alarma. Lo que documenta son las dos métricas, la agregada y la de cada ubicación. A partir de ahí hay dos caminos.

Umbral sobre el agregado

Lo que sigue es un razonamiento a partir de la definición de la métrica. La documentación no lo describe ni publica la fórmula exacta con la que se calcula el agregado.
Si el agregado se comporta como un promedio y cada ubicación aporta el mismo número de ejecuciones, con cinco ubicaciones una sola que falle por completo bajaría la tasa combinada a aproximadamente 80 %. Dos ubicaciones caídas la bajarían a aproximadamente 60 %. Bajo ese supuesto, el umbral de la alarma responde la pregunta del título: un umbral de 90 % dispara con una ubicación caída, y uno de 70 % espera a que caigan dos.
Antes de fijar ese umbral en producción, conviene comprobar el comportamiento real, por ejemplo comparando en un mismo período el agregado con el SuccessPercent de cada ubicación cuando alguna tuvo fallas. Detener una sola réplica para probar no es posible: iniciar o detener un canary multiubicación aplica a la primaria y a todas las réplicas a la vez. También hay que tener en cuenta que una ubicación que falla la mitad de las veces mueve el agregado mucho menos que una caída completa, así que una degradación parcial en una Región puede pasar por debajo del umbral.

Alarmas por ubicación en una alarma compuesta

La otra opción es una práctica general de Amazon CloudWatch, y la documentación de esta función no la menciona. Consiste en crear una alarma sobre el SuccessPercent de cada ubicación y combinarlas en una alarma compuesta. La regla de una alarma compuesta usa las funciones ALARM, OK e INSUFFICIENT_DATA sobre otras alarmas, unidas con AND, OR y NOT, y acepta paréntesis para agrupar.
Por ejemplo, con tres Regiones, esta regla dispara cuando fallan al menos dos. Los nombres de las alarmas son ilustrativos:
1
(ALARM("canary-us-east-1") AND ALARM("canary-us-west-2")) OR (ALARM("canary-us-east-1") AND ALARM("canary-eu-west-1")) OR (ALARM("canary-us-west-2") AND ALARM("canary-eu-west-1"))
La sintaxis no tiene una función del tipo "al menos N de M", así que la regla crece rápido con el número de ubicaciones. Con cinco Regiones y un mínimo de dos en falla, son diez combinaciones. Por eso la alarma compuesta encaja mejor con pocas ubicaciones críticas, y el agregado con muchas réplicas.
La ventaja de la compuesta es que la decisión queda escrita: la regla dice qué ubicaciones y cuántas, sin depender de cómo se calcula el agregado.

Un cuidado con los datos faltantes

Si una ubicación deja de publicar datos, su SuccessPercent se queda sin datos. Un caso documentado que lleva a esto es una réplica que falla al crearse: el canary primario se crea igual y esa réplica queda en Inconsistent. En CloudWatch, una alarma sin datos pasa por defecto a INSUFFICIENT_DATA, que es un estado distinto de ALARM. En una alarma compuesta que solo evalúa ALARM, esa ubicación deja de contar y nadie se entera. Conviene decidir cómo trata cada alarma por ubicación los datos faltantes, o incluir INSUFFICIENT_DATA en la regla, según lo que el equipo quiera que signifique una ubicación que dejó de reportar.

El runbook: regional o global

Cuando la alarma suena, la primera pregunta útil es desde dónde falla. Filtrar la tabla de ejecuciones por Location, o mirar SuccessPercent por ubicación, la responde rápido, y la respuesta divide el runbook en dos ramas:
  • Si falla desde todas las ubicaciones, el problema probablemente está en la aplicación o en algo que todos los usuarios comparten. El runbook sigue por el servicio.
  • Si falla desde una o dos, el problema probablemente está en el camino entre esas Regiones y el endpoint, o en una dependencia que se comporta distinto según el origen. El runbook sigue por la red o por esa dependencia.
La documentación de alarmas compuestas trae un detalle útil para este paso: la descripción de la alarma acepta Markdown, que se muestra en la pestaña de detalles en la consola, y la propia documentación sugiere usarla para enlazar runbooks. Una alarma que ya lleva el enlace al procedimiento correcto ahorra el primer minuto de búsqueda.
Para revisar logs, hay que saber que cada ejecución los genera en su propia Región. La documentación propone una regla de centralización de Amazon CloudWatch Logs con las Regiones de las réplicas como origen, la misma cuenta y la Región primaria como destino, y un filtro por el prefijo de los grupos de logs de los canaries. Con esa configuración, los logs de las réplicas quedan en el mismo grupo de logs que los de la primaria. Un efecto secundario: la regla también trae los logs de los otros canaries que corran en esas Regiones, aunque no sean multiubicación.
Una vez centralizados, CloudWatch Logs Insights permite filtrar por Región. El ejemplo de la documentación busca errores de us-west-2:
1
2
3
fields @timestamp, @message, @logStream
| filter @aws.region like /us-west-2/
| filter @message like /ERROR/

Permisos y control de Regiones

Además de los permisos habituales de CloudWatch Synthetics, crear y administrar canaries multiubicación requiere la acción synthetics:ReplicateCanary, que permite al servicio crear, actualizar y borrar las réplicas. Una política que ya otorga todas las acciones de synthetics la incluye.
Hay dos claves de condición, synthetics:AddReplicaLocations y synthetics:RemoveReplicaLocations, para controlar en qué Regiones se pueden agregar o quitar réplicas. La documentación trae ejemplos que permiten réplicas solo en ciertas Regiones o las niegan en otras. Para un equipo que opera desde el Caribe y atiende usuarios en varios países, esto permite ampliar la cobertura sin perder control sobre dónde corre cada réplica.

Limitaciones

  • Requiere el runtime syn-nodejs-puppeteer-16.0 o posterior, o syn-nodejs-playwright-7.0 o posterior.
  • Está disponible en las Regiones comerciales de AWS con CloudWatch Synthetics. No está en AWS GovCloud (US) ni en las Regiones de China.
  • Admite hasta 50 réplicas, y el archivo .zip del script no puede pasar de 50 MB.
  • El nombre del canary no puede existir ya en ninguna de las Regiones de réplica.
  • Las etiquetas no se replican. Hay que agregarlas en cada Región de réplica.
  • La configuración de VPC no se hereda. Cada réplica que necesite conectividad de VPC requiere su propia configuración.
  • Todas las ubicaciones usan el mismo script, el mismo horario y las mismas variables de entorno.
  • Un canary multiubicación no puede pertenecer a un grupo.
  • El costo crece en proporción al número de réplicas: cada una cuesta lo mismo que un canary independiente.
  • Mientras hay replicación en curso no se puede modificar, iniciar ni detener el canary, y para borrarlo primero hay que quitar todas las réplicas.
  • La documentación no publica la fórmula del SuccessPercent agregado ni explica cómo construir una alarma que dispare solo cuando fallan varias ubicaciones.
  • Las alarmas compuestas no tienen una función "al menos N de M", así que la regla crece con el número de ubicaciones.

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