AWS Outposts: monitoreo de LAGs con métricas LagStatus en CloudWatch

Introducción

Hasta ahora, los equipos de infraestructura híbrida que operaban racks físicos de AWS Outposts dependían de métricas dispersas y herramientas externas para diagnosticar problemas en los Link Aggregation Groups (LAGs). Si un LAG caía, el equipo debía cruzar datos de BGP con interfaces virtuales (VIFs) o recurrir a comandos en switches on-premises para confirmar el estado. Esto generaba demoras en la detección y en la resolución de incidentes, especialmente cuando la falla no estaba en la capa de red AWS, sino en el lado del cliente.

Con la introducción de la métrica LagStatus en CloudWatch, AWS cierra ese hueco. Ahora, los administradores pueden ver el estado operativo de un LAG —up o down— directamente en la consola de CloudWatch, sin salir de AWS y sin coordinar con otros equipos. Este cambio es especialmente relevante para entornos donde la resiliencia de la conectividad híbrida es crítica, como en arquitecturas de disaster recovery o migraciones a la nube.

Qué ocurrió

A partir de abril de 2026, AWS habilitó la métrica LagStatus en CloudWatch para todos los racks de Outposts en:

• Regiones comerciales de AWS (ej: us-east-1, eu-west-1)
• AWS GovCloud (US-East) y AWS GovCloud (US-West)

Esta métrica complementa a las existentes VifConnectionStatus y VifBgpSessionState, pero con un enfoque específico: informar si el LAG está listo para forwardpear tráfico. La novedad no es solo su existencia, sino su integración nativa con CloudWatch, lo que permite:

1. Configurar alarmas automáticas cuando un LAG cae.
2. Correlacionar el estado del LAG con métricas de BGP y VIFs en un mismo panel.
3. Reducir el mean time to detect (MTTD) de fallas en la conectividad híbrida.

Según el anuncio oficial, la métrica se activa para todos los LAGs de Outposts, independientemente de si son de primera o segunda generación. Esto incluye configuraciones con:

• 802.3ad (LACP)
• Estáticos (sin negociación dinámica)

Impacto para DevOps / Infraestructura / Cloud / Seguridad

DevOps y Site Reliability Engineering (SRE)

Para equipos SRE que gestionan entornos híbridos, la métrica LagStatus reduce la dependencia de:

• Herramientas de monitoreo externas (ej: Zabbix, Nagios) para verificar el estado del LAG.
• Acceso SSH a switches on-premises para revisar el estado del bundle en el lado del cliente.

1. Revise el estado de los VIFs asociados (usando las métricas VifConnectionStatus y VifBgpSessionState).
2. Verifique si el problema es en AWS o en el lado del cliente (ej: falla en el switch local).
3. Notifique al equipo de red on-premises solo si la causa es externa.

Esto alinea el monitoreo de Outposts con las prácticas de Observability modernas, donde los datos de red, cómputo y almacenamiento deben converger en un mismo sistema.

Infraestructura y Cloud

Para los equipos de infraestructura, la métrica LagStatus simplifica la validación de SLAs híbridos. Por ejemplo:

• Si un cliente contrata un SLA de 99.99% de disponibilidad en la conectividad Outposts, ahora puede monitorear ese KPI directamente desde CloudWatch, sin depender de scripts personalizados o herramientas de terceros.
• En arquitecturas de multi-Region failover, la métrica permite detectar rápidamente si un LAG en una región de respaldo está operativo antes de redirigir tráfico.

Seguridad

Desde la perspectiva de seguridad, la métrica LagStatus aporta visibilidad sin precedentes sobre posibles ataques o configuraciones erróneas:

• Un LAG que pasa de up a down y vuelve a up en segundos podría indicar un ataque de flapping (ej: un atacante intentando saturar el enlace).
• Si el LAG está en down pero los VIFs muestran BGP activo, podría señalar un error en la configuración de seguridad (ej: políticas de firewall bloqueando el tráfico LACP).

Los equipos de seguridad pueden usar esta métrica para:

1. Correlacionar eventos de LagStatus con logs de AWS GuardDuty o CloudTrail.
2. Crear reglas personalizadas en AWS Security Hub para alertar sobre patrones sospechosos (ej: múltiples cambios de estado en menos de 5 minutos).

Detalles técnicos

Métricas disponibles

La métrica LagStatus se publica en CloudWatch con las siguientes características:

{
  "MetricData": [
    {
      "MetricName": "LagStatus",
      "Dimensions": [
        { "Name": "OutpostId", "Value": "op-1234567890abcdef0" },
        { "Name": "LagId", "Value": "lag-9876543210fedcba" }
      ],
      "Value": 0,
      "Unit": "None",
      "Timestamp": "2026-04-15T14:30:00Z"
    }
  ]
}

Requisitos previos

Para que la métrica funcione, el rack de Outposts debe cumplir con:

1. Firmware actualizado: Versión mínima de firmware para racks de segunda generación es 1.10.0 (lanzado en marzo de 2026).

1. Configuración de LAG: El LAG debe estar creado y asociado a una interfaz virtual (VIF).
2. Permisos en IAM: El rol de IAM que consume la métrica debe tener el permiso:

   {
     "Effect": "Allow",
     "Action": "cloudwatch:GetMetricData",
     "Resource": "*"
   }
   

Limitaciones conocidas

AWS documenta las siguientes restricciones:

• La métrica no detecta problemas de latencia en el LAG (solo su estado operativo).
• No cubre LAGs en Outposts con conectividad de tercera parte (ej: enlaces proporcionados por un ISP externo).
• El valor de LagStatus puede tardar hasta 2 minutos en reflejarse en CloudWatch tras un cambio de estado (debido a la propagación en la capa de control de Outposts).

Qué deberían hacer los administradores y equipos técnicos

Paso 1: Verificar compatibilidad del rack

Antes de usar la métrica, confirmá que tu rack de Outposts tenga el firmware actualizado:

aws outposts list-outposts \
  --query 'Outposts[?contains(OutpostArn, `op-`)].{OutpostId:OutpostId,Status:Status,FirmwareVersion:FirmwareVersion}' \
  --output table

Si el firmware es menor a 1.10.0, actualizalo con:

aws outposts update-outpost \
  --outpost-id op-1234567890abcdef0 \
  --firmware-version 1.10.0

> ⚠️ Nota: La actualización puede tardar hasta 30 minutos y requiere reiniciar el rack.

Paso 2: Configurar alarmas en CloudWatch

Creá una alarma para notificar cuando un LAG pase a down:

1. Abrí la consola de CloudWatch > Alarms > Create alarm.
2. En Metric, seleccioná:

– Metric name: LagStatus

– Dimensions: LagId (o OutpostId si querés monitorear todos los LAGs de un rack).

1. Configurá la alarma con:

– Alarm condition: Less than threshold = 1

– Threshold value: 1

– Datapoints to alarm: 1 out of 1

1. Asociá la alarma a un SNS topic para notificaciones (ej: Slack, PagerDuty, o email).

resource "aws_cloudwatch_metric_alarm" "outposts_lag_down" {
  alarm_name          = "outposts-lag-down-op-1234567890abcdef0"
  comparison_operator = "LessThanThreshold"
  evaluation_periods  = "1"
  metric_name         = "LagStatus"
  namespace           = "AWS/Outposts"
  period              = "60"
  statistic           = "Minimum"
  threshold           = "1"
  alarm_description   = "Alarma para LAG down en Outpost ${var.outpost_id}"
  alarm_actions       = [aws_sns_topic.outposts_alerts.arn]

  dimensions = {
    OutpostId = var.outpost_id
    LagId     = var.lag_id
  }
}

Paso 3: Correlacionar LagStatus con otras métricas

Para diagnosticar fallas, combiná LagStatus con:

• VifConnectionStatus: Si está en 0, el problema es en la capa de red AWS.
• VifBgpSessionState: Si está en DOWN, el problema es en el túnel BGP.
• NetworkInterfaceStatus: Para verificar si la interfaz virtual está attached.

METRICS AWS/Outposts LagStatus, VifConnectionStatus, VifBgpSessionState
| STATS avg(LagStatus) AS AvgLagStatus, avg(VifConnectionStatus) AS AvgVifConn, avg(VifBgpSessionState) AS AvgBgpState BY OutpostId, LagId
| WHERE OutpostId = 'op-1234567890abcdef0'
| SORT @timestamp DESC
| LIMIT 20

Paso 4: Documentar procedimientos de remediación

Actualizá tus runbooks con los siguientes pasos:

1. Si LagStatus = 0 y VifConnectionStatus = 1:

– Verificá que el puerto esté up y que el bundle esté configurado correctamente.

1. Si LagStatus = 0 y VifBgpSessionState = DOWN:

– Verificá que el ASN (Autonomous System Number) esté correctamente configurado en ambos extremos.

1. Si LagStatus = 0 y NetworkInterfaceStatus = 2 (error):

– Contactá al soporte de AWS si el problema persiste.

Conclusión

La incorporación de la métrica LagStatus en CloudWatch para AWS Outposts marca un avance significativo en la observabilidad de entornos híbridos. Para los equipos de DevOps y SRE, esto significa:

• Menor tiempo de detección de fallas en la conectividad LAG.
• Menor dependencia de herramientas externas y coordinación con otros equipos.
• Mayor alineación con prácticas de Observability (datos de red, cómputo y almacenamiento en un solo lugar).

Para los equipos de infraestructura, la métrica facilita la validación de SLAs y la gestión de arquitecturas resilientes. Y para seguridad, aporta visibilidad crítica para detectar patrones anómalos en la conectividad.

Fuentes

• AWS What’s New: AWS Outposts racks now support LagStatus CloudWatch metric
• Documentación de métricas de CloudWatch para Outposts (segunda generación)
• Documentación de métricas de CloudWatch para Outposts (primera generación)
• AWS Service Health Dashboard (estadísticas de incidentes en LAGs)