AWS Builder Center

Builder Center

Ver la métrica no es lo mismo que poseerla: centralización de métricas entre cuentas en Amazon CloudWatch

Amazon CloudWatch sumo la centralizacion de metricas entre cuentas. A diferencia de la observabilidad entre cuentas con AWS Observability Access Manager, que consulta el dato donde vive sin copiarlo, la centralizacion replica las metricas a la cuenta de destino, que pasa a poseerlas. Con esa propiedad se ejecutan alarmas locales, metric math y deteccion de anomalias desde una sola cuenta, a cambio de coste de ingesta en el destino.

vtjean

Hay una pregunta que separa dos arquitecturas de observabilidad que a primera vista parecen iguales: cuando ves una métrica de otra cuenta en tu panel central, ¿esa métrica es tuya, o solo la estás mirando prestada? La respuesta cambia por completo lo que puedes hacer con ella. En esta serie venimos insistiendo en que responder bien a un incidente empieza mucho antes de la alerta: por elegir la señal, fijar el objetivo y tener el runbook listo. La centralización de métricas entre cuentas, disponible de forma general desde el 15 de junio de 2026 en Amazon CloudWatch, toca esas tres decisiones a la vez, pero solo si primero se entiende la distinción que casi todo el mundo pasa por alto.
Esa distinción es la propiedad del dato. Y confundirla lleva a diseños que fallan justo cuando más se necesitan.

Dos caminos que se confunden

Amazon CloudWatch ofrece dos maneras de trabajar con métricas de varias cuentas, y no son lo mismo. Se parecen en la superficie (ambas te dan visibilidad desde una cuenta central) pero difieren en algo fundamental: dónde vive el dato y quién lo posee.
El primer camino es la observabilidad entre cuentas mediante AWS Observability Access Manager, disponible desde 2022. El segundo es la centralización de métricas entre cuentas, la capacidad nueva de junio de 2026. El primero consulta el dato donde está. El segundo copia el dato a donde lo necesitas. Esa frase resume toda la diferencia, y el resto del artículo la desarrolla.

AWS Observability Access Manager: consultar sin copiar

La observabilidad entre cuentas a través de AWS Observability Access Manager funciona por enlace. Se designa una cuenta de monitorización y se enlazan las cuentas origen. A partir de ese momento, desde la cuenta central se ven las métricas, los logs y las trazas de las cuentas enlazadas sin copiar los datos. Es un modelo de consulta en el sitio: el dato sigue viviendo en la cuenta origen, y la cuenta central lo lee a través del enlace.
Este modelo tiene dos ventajas claras. La primera es el alcance: una cuenta de monitorización admite un número muy alto de cuentas origen (hasta cien mil), lo que lo hace adecuado para dar visibilidad amplia a una organización entera. La segunda es el coste: como no se copia el dato, no hay coste de ingesta en el destino. Ves todo, desde un solo lugar, sin duplicar nada.
El límite aparece cuando quieres hacer algo más que mirar. Como el dato vive en la cuenta origen, la cuenta de monitorización no puede construir una alarma local sobre esa métrica, ni ejecutar detección de anomalías sobre ella, ni tratarla como si fuera nativa. Puede consultarla, graficarla, incluirla en un panel. Pero el procesamiento local que asume propiedad del dato no está disponible, porque la cuenta central no es dueña de ese dato.

Centralización de métricas: copiar y poseer

La centralización de métricas entre cuentas resuelve exactamente ese límite, y lo hace por una vía distinta: la replicación. En lugar de consultar el dato donde está, lo copia a la cuenta de destino. Esa copia cambia todo, porque el destino pasa a tener la propiedad completa del dato.
La configuración se hace mediante reglas de centralización definidas por origen (por cuenta y por Región). Cada regla determina qué métricas se copian y desde dónde. El resultado es que la cuenta de destino recibe esas métricas como si fueran propias, y sobre datos propios se puede hacer todo lo que antes estaba vedado:
  • Alarmas locales sobre las métricas centralizadas.
  • Metric math combinando métricas de varias cuentas en una misma expresión.
  • Detección de anomalías ejecutándose en la cuenta de destino.
  • Consultas PromQL sobre las métricas centralizadas, tratadas como cualquier otra métrica local.
Aquí está el precio a cambio de la propiedad: como el dato se copia, se aplica coste de ingesta en el destino. La replicación no es gratis. Pero a cambio se obtiene capacidad de procesamiento local que la consulta en el sitio no puede dar.

Por qué la propiedad cambia el runbook

Traslademos esto a un incidente real, que es donde la distinción deja de ser teórica. Imagina un territorio de varias cuentas: producción en una, servicios compartidos en otra, cargas de datos en una tercera. A las dos de la madrugada salta un problema que cruza esas fronteras.
Con solo consulta en el sitio, quien responde ve las métricas de las tres cuentas desde el panel central, lo cual ya es útil. Pero para alarmar sobre una combinación de métricas de dos cuentas, o para que la detección de anomalías señale la desviación, tiene que ir a cada cuenta origen y montar allí el procesamiento. En plena guardia, saltar entre cuentas es fricción, y la fricción cuesta minutos que no sobran.
Con centralización, esas métricas ya viven en la cuenta de monitorización. La alarma que combina la latencia de producción con la tasa de errores de servicios compartidos se define una vez, en un solo lugar, y se dispara sin depender de las cuentas origen. La detección de anomalías corre sobre los datos centralizados. El runbook se ejecuta desde una única cuenta que posee el dato, no desde un recorrido entre cuentas.
Este es el mapeo con la serie. La métrica centralizada es la señal unificada del territorio multi-cuenta: un solo lugar, propiedad completa. El objetivo es poder alarmar y ejecutar cálculos de nivel de servicio sobre métricas de varias cuentas de forma local, sin salto entre cuentas. Y el runbook responde desde esa cuenta central que es dueña del dato, en lugar de reconstruir el contexto brincando entre orígenes durante el incidente.

El patrón que usan los equipos maduros: los dos, no uno

La conclusión práctica no es elegir un camino y descartar el otro. Los dos se complementan, y los equipos con experiencia usan ambos a la vez.
AWS Observability Access Manager da la visibilidad amplia: consulta en el sitio sobre toda la organización, con su alcance de muchas cuentas y sin coste de ingesta en el destino. Es la vista de conjunto. La centralización de métricas se reserva para el subconjunto concreto de métricas que necesitan procesamiento local en la cuenta de monitorización: aquellas sobre las que se quiere alarmar, hacer metric math o correr detección de anomalías desde el centro.
Dicho de otro modo: se consulta en el sitio para ver casi todo, y se replica solo lo que hay que poseer. Esa combinación mantiene el coste bajo control (no se copia lo que solo hace falta mirar) y a la vez habilita el procesamiento local donde de verdad importa. Ver la métrica no es lo mismo que poseerla, y una arquitectura bien pensada decide, métrica por métrica, cuál de las dos cosas necesita.

Dónde encaja la centralización de logs

Para situar las fechas y evitar confusiones, conviene ordenar la línea de tiempo. La centralización de logs, configurada por nombre y tipo de fuente de datos, llegó a disponibilidad general antes, el 30 de marzo de 2026. La centralización de métricas, tanto entre cuentas como entre Regiones, es la incorporación del 15 de junio de 2026. Son piezas de la misma idea (llevar telemetría de varias cuentas a un punto de propiedad central) aplicadas a tipos de señal distintos, y llegaron en momentos distintos.

Cómo pensar la configuración

Antes de escribir la primera regla de centralización, conviene un inventario honesto de qué métricas justifican la copia. La pregunta guía es sencilla: ¿necesito alarmar, hacer metric math o correr detección de anomalías sobre esta métrica desde la cuenta central? Si la respuesta es sí, es candidata a centralizar. Si solo necesito verla en un panel, la consulta en el sitio basta y evita el coste de ingesta.
Un esbozo de ese razonamiento, escrito como criterio en un bloque indentado:
1
2
3
4
5
6
Metrica de latencia de checkout (produccion)
necesita alarma local en cuenta central -> centralizar
Metrica de uso de CPU de un lote nocturno
solo visualizacion ocasional -> consulta en el sitio (OAM)
Errores 5xx del gateway compartido
metric math + deteccion de anomalias -> centralizar
La regla de centralización se define por origen, indicando cuenta y Región de procedencia. Empezar por un subconjunto pequeño y medir el coste de ingesta real antes de ampliar es más prudente que centralizar todo de golpe.

Limitaciones

  • La replicación genera coste de ingesta en la cuenta de destino. Centralizar de forma indiscriminada puede encarecer la factura sin aportar valor si la métrica solo se visualiza.
  • Copiar el dato implica que existe en dos sitios. Hay que tener claro el modelo de retención en cada lado y qué cuenta es la fuente de verdad.
  • La configuración por reglas de origen requiere gobernanza. En organizaciones grandes conviene un proceso para decidir qué se centraliza y quién lo aprueba, o las reglas se multiplican sin control.
  • La consulta en el sitio mediante AWS Observability Access Manager y la centralización cubren necesidades distintas. Usar solo una de las dos deja huecos: sin consulta en el sitio falta la vista amplia, sin centralización falta el procesamiento local.
  • Conviene confirmar en la documentación la disponibilidad por Región, las cuotas y las combinaciones de origen y destino admitidas, ya que son capacidades recientes y estos detalles evolucionan.
  • La centralización entre Regiones añade consideraciones de latencia y de residencia de datos que hay que evaluar según el caso.

Recursos

# multi-account# governance# monitoring-observability# observability# amazon-cloudwatch
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