Monitoreá el estado de los servicios AWS con el Dashboard de Salud de AWS

Introducción

El AWS Health Dashboard es la consola centralizada donde Amazon Web Services publica el estado operativo de sus servicios globales, regiones y cuentas. No es un simple «status page»: combina información técnica detallada sobre eventos programados (mantenimientos, actualizaciones), incidentes activos (fallas regionales o globales) y recomendaciones personalizadas para tu cuenta (como actualizar versiones de AMIs o aplicar parches de seguridad).

Si tu equipo opera workloads en múltiples regiones o cuentas, ignorar esta herramienta equivale a operar sin radar meteorológico en medio de una tormenta. Un evento no advertido puede generar caídas de servicios, pérdida de rendimiento o costos inesperados por acciones automatizadas que dependen de APIs afectadas.

En esta guía, aprenderás a:

• Interpretar el estado global vs. el estado específico de tu cuenta.
• Configurar alertas proactivas usando AWS Health API y Amazon EventBridge.
• Automatizar respuestas mediante AWS Lambda para minimizar el tiempo de impacto.

Qué es y para qué sirve

El AWS Health Dashboard se divide en dos vistas principales:

1. Estado global de AWS (status.aws.amazon.com):

– Indica si un servicio está Operativo, en Degradación o Fuera de servicio.

– Incluye estimaciones de tiempo de recuperación (ETR) y enlaces a postmortems oficiales.

1. Estado de la cuenta de AWS (disponible en la consola de AWS):

– Recomendaciones: Alertas contextualizadas como «Actualizá la versión de tu AMI para resolver una vulnerabilidad».

– RSS y APIs: Acceso programático para integrar con herramientas de monitoreo externas.

• Equipos de DevOps/SRE: Detectar fallas antes de que impacten en pipelines (ej: un fallo en EBS que afecte a pods de EKS).
• Equipos de Seguridad: Recibir notificaciones sobre parches críticos (ej: vulnerabilidades en RDS que requieran reinicio).
• Equipos Financieros: Evitar costos por eventos prolongados (ej: instancias EC2 detenidas por mantenimiento no planificado).

Prerequisitos

Para seguir esta guía, necesitarás:

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::aws:policy/AWSHealthFullAccess \
  --action-names health:Get* health:Describe*

Si el comando devuelve Denied, revisá los permisos de tu rol o usuario.

Guía paso a paso

1. Verificá el estado global de AWS

1. Abrí el AWS Health Dashboard global.
2. Filtrá por servicio (ej: EC2, RDS) y región (ej: US East (N. Virginia)).
3. Buscá el estado en la columna Service Status:

– Performance Issues: Amarillo ⚠️.

– Service Disruption: Rojo ❌.

Si un servicio como EKS muestra ❌ en una región, pero tu workload está en otra sin afectación, podés descartar problemas en tu infraestructura.

2. Accedé al estado de tu cuenta (AWS Personal Health Dashboard)

1. Ingresá a la consola de AWS y buscá «Personal Health Dashboard» en la barra de búsqueda.
2. Seleccioná la región donde operas (ej: us-east-1).
3. Explorá las pestañas:

– Eventos pasados: Historial de los últimos 30 días.

– Recomendaciones: Alertas como «Actualizá tu versión de Node.js en Lambda».

aws health describe-events \
  --region us-east-1 \
  --filter regions=us-east-1,eventStatusCodes=open

{
  "events": [
    {
      "arn": "arn:aws:health:us-east-1::event/EC2/EC2_INSTANCE_RETIREMENT_SCHEDULED_12345",
      "service": "EC2",
      "eventTypeCode": "EC2_INSTANCE_RETIREMENT_SCHEDULED",
      "startTime": "2024-06-15T12:00:00Z",
      "eventDescription": [
        {
          "language": "en_US",
          "latestDescription": "Your instance i-1234567890abcdef0 will be retired on 2024-06-20..."
        }
      ]
    }
  ]
}

Si el comando devuelve AccessDeniedException, asegurate de que tu usuario/rol tenga asignado el policy AWSHealthFullAccess.

3. Configurá alertas proactivas con Amazon EventBridge

Paso 3.1: Creá un rule en EventBridge

1. En la consola de AWS, buscá «Amazon EventBridge» > «Rules» > «Create rule».
2. Configurá lo siguiente:

– Rule type: Rule with an event pattern.

– Event source: AWS events or EventBridge partner events.

– Event pattern:

     {
       "source": ["aws.health"],
       "detail-type": ["AWS Health Event"],
       "detail": {
         "service": ["EC2", "RDS", "EKS"],
         "eventStatusCodes": ["open"]
       }
     }
     

1. Seleccioná «Next» y elegí un destino:

– SNS Topic: Para enviar notificaciones por correo/Slack.

– Step Functions: Para orquestar workflows complejos.

La rule quedará activa y filtrará solo eventos relevantes para tu infraestructura.

Paso 3.2: Enviá alertas a Slack (opcional)

1. Creá un webhook en Slack:

– Configurá el canal (ej: #infra-alerts) y copiá la URL.

1. Creá un Lambda para procesar el evento:

   # lambda_function.py
   import json
   import requests

   def lambda_handler(event, context):
       webhook_url = "TU_WEBHOOK_SLACK"
       for record in event['detail']['eventDescription']:
           if record['language'] == 'en_US':
               message = {
                   "text": f"🚨 *AWS Health Alert*\n📌 *Servicio*: {event['detail']['service']}\n🔗 *Detalle*: {record['latestDescription']}\n🕒 *Fecha*: {event['detail']['startTime']}"
               }
               requests.post(webhook_url, json=message)
               break
   

1. Asigná permisos al Lambda:

   aws lambda add-permission \
     --function-name aws-health-slack-alerts \
     --action lambda:InvokeFunction \
     --principal events.amazonaws.com \
     --statement-id "EventBridgeInvokeLambda"
   

1. Actualizá la rule de EventBridge para que invoque al Lambda:

   aws events put-targets \
     --rule aws-health-alerts \
     --targets '[{
       "Id": "1",
       "Arn": "arn:aws:lambda:us-east-1:123456789012:function:aws-health-slack-alerts"
     }]'
   

Recibirás alertas en Slack como:

🚨 *AWS Health Alert*
📌 *Servicio*: EC2
🔗 *Detalle*: Your instance i-1234567890abcdef0 will be retired on 2024-06-20...
🕒 *Fecha*: 2024-06-15T12:00:00Z

4. Automatizá respuestas con AWS Lambda

1. Creá un nuevo Lambda (ej: aws-health-instance-stop) con el siguiente código:

   import boto3

   ec2 = boto3.client('ec2')

   def lambda_handler(event, context):
       instance_id = event['detail']['affectedEntities'][0]['entityValue']
       ec2.stop_instances(InstanceIds=[instance_id])
       print(f"Deteniendo instancia {instance_id} por evento de AWS Health: {event['detail']['eventTypeCode']}")
   

1. Asigná permisos al Lambda:

   aws iam create-policy \
     --policy-name AWSHealthEC2StopPolicy \
     --policy-document '{
       "Version": "2012-10-17",
       "Statement": [{
         "Effect": "Allow",
         "Action": ["ec2:StopInstances"],
         "Resource": ["arn:aws:ec2:*:*:instance/*"]
       }]
     }'
   aws iam attach-role-policy \
     --role-name lambda-execution-role \
     --policy-arn arn:aws:iam::123456789012:policy/AWSHealthEC2StopPolicy
   

1. Actualizá la rule de EventBridge para que invoque a este Lambda cuando el evento sea de tipo EC2_INSTANCE_RETIREMENT_SCHEDULED:

   aws events put-rule \
     --name aws-health-retirement-alerts \
     --event-pattern '{
       "source": ["aws.health"],
       "detail-type": ["AWS Health Event"],
       "detail": {
         "eventTypeCode": ["EC2_INSTANCE_RETIREMENT_SCHEDULED"]
       }
     }'
   

Si un evento de AWS Health indica que una instancia será retirada, el Lambda la detendrá automáticamente.

5. Usá la API de AWS Health para integraciones externas

1. Generá un access key para la API:

   aws iam create-access-key --user-name aws-health-integration
   

1. Consultá eventos recientes:

   curl -X GET "https://health.us-east-1.amazonaws.com/events?eventStatusCodes=open&maxResults=10" \
     -H "x-amz-security-token: TU_SESSION_TOKEN" \
     -H "Authorization: AWS4-HMAC-SHA256 Credential=TU_ACCESS_KEY/20240615/us-east-1/health/aws4_request..."
   

1. Parseá la respuesta con jq:

   aws health describe-events --region us-east-1 --query 'events[].{service:service, type:eventTypeCode, time:startTime}' --output json | jq -r '.[] | "\(.time) \(.service) \(.type)"'
   

2024-06-15T12:00:00Z EC2 EC2_INSTANCE_RETIREMENT_SCHEDULED

Consideraciones y buenas prácticas

Limitaciones conocidas

• Latencia: Los eventos pueden tardar 5-15 minutos en aparecer en tu cuenta después de ser publicados globalmente.
• Falsos positivos: Algunos eventos de mantenimiento (ej: parches de seguridad) no siempre requieren acción inmediata.
• Cobertura: No todos los servicios AWS publican eventos detallados (ej: AWS Organizations tiene menos granularidad).

Alternativas cuando AWS Health no es suficiente

1. Priorizá eventos por impacto:

– Filtrá eventos con severity = high en la API.

1. Documentá tus automatizaciones:

1. Probá con eventos de prueba:

     aws health create-event \
       --event-type-code CUSTOM_TEST_EVENT \
       --service EC2 \
       --event-description "Prueba de alerta - $(date)"
     

Conclusión

El AWS Health Dashboard es tu primera línea de defensa contra fallas en la nube. En esta guía aprendiste a:

1. Distinguir entre el estado global de AWS y los eventos específicos de tu cuenta.
2. Configurar alertas proactivas usando EventBridge y Lambda.
3. Automatizar respuestas como detener instancias o notificar equipos.

• Integrá AWS Health con tu sistema de incident management (Jira, OpsGenie).
• Creá dashboards en Amazon Managed Grafana para visualizar el estado histórico.
• Revisá el AWS Health API Reference para personalizar aún más las alertas.

Fuentes

• AWS Health Dashboard Global
• AWS Health API Reference
• AWS IAM Policy: AWSHealthFullAccess
• Ejemplo de integración con Slack (AWS Samples)