Fundamentos de EventBridge

Una alarma de CloudWatch puede reiniciar la única instancia a la que apuntan sus dimensiones. Esto no lo puede hacer: cuando cualquier instancia etiquetada Environment=prod entra en estado stopped, abrir un OpsItem de Systems Manager, iniciar un runbook que capture la salida de consola y avisarle al equipo dueño. Acá no hay ningún número al que ponerle un umbral. Nada sube ni baja. Simplemente pasó algo, una vez, sobre un recurso, y por eso tienen que ocurrir varias cosas.

Ese es el hueco que llena EventBridge. Es el router que se sienta entre las cosas que pasan en tu cuenta y las cosas que deberían ejecutarse como respuesta.

Los eventos son hechos; las métricas son números

Conviene fijar esta frontera antes que nada, porque de ella dependen la mitad de las preguntas de diagnóstico de este dominio.

Una métrica es una serie temporal de números. CPUUtilization de una instancia vale 4% a las 09:00 y 71% a las 09:01. Las alarmas existen para vigilar esa serie y decidir cuándo los números estuvieron mal durante el tiempo suficiente como para importar.

Un evento es un documento JSON que describe algo que ocurrió, entregado una vez, cerca del momento en que ocurrió. Una instancia cambió de estado. Un snapshot de EBS terminó. Alguien llamó a AuthorizeSecurityGroupIngress. Se abrió una notificación de AWS Health para una región. Ninguno de esos es un número, así que ninguna alarma puede vigilarlos.

Ponte a prueba con una regla rápida: si una persona describiría la situación con un verbo en pasado, es un evento. Si la describiría con un número y una comparación, es una métrica.

Las dos cosas se conectan, y al examen le gusta esa conexión. El cambio de estado de una alarma de CloudWatch es en sí mismo un evento en el bus default (aws.cloudwatch, detail-type CloudWatch Alarm State Change). Así que la respuesta a "mi alarma necesita disparar una reparación de cinco pasos" casi siempre es: deja la alarma donde está, y que EventBridge matchee su evento de cambio de estado e inicie el flujo.

El sobre del evento

Todos los eventos tienen la misma estructura exterior, con la carga específica del servicio anidada dentro de detail. Este es un cambio de estado real de EC2:

{
  "version": "0",
  "id": "6a7e8feb-b491-4cf7-a9f1-bf3703467718",
  "detail-type": "EC2 Instance State-change Notification",
  "source": "aws.ec2",
  "account": "111122223333",
  "time": "2017-12-22T18:43:48Z",
  "region": "us-west-1",
  "resources": [
    "arn:aws:ec2:us-west-1:123456789012:instance/i-1234567890abcdef0"
  ],
  "detail": {
    "instance-id": "i-1234567890abcdef0",
    "state": "terminated"
  }
}

Los dos campos contra los que vas a escribir patrones todo el tiempo son source (qué servicio o aplicación emitió esto, aws.* para servicios de AWS) y detail-type (qué tipo de evento es dentro de ese source). Todo lo específico del evento vive bajo detail, y su forma la define el servicio que lo emite.

Dos detalles de resources agarran desprevenida a mucha gente. Los eventos de llamadas a la API que vienen de CloudTrail muchas veces traen resources vacío, así que un patrón que filtre por ese campo nunca va a matchear. Y los servicios globales como IAM y Route 53 existen solo en US East (N. Virginia), así que sus eventos de llamadas a la API están disponibles solo en esa región. Una regla en eu-west-1 esperando un cambio de política de IAM va a esperar para siempre.

Buses de eventos: default, personalizado y de partner

Un bus de eventos es un router que recibe eventos y se los ofrece a las reglas conectadas a él. Hay tres tipos, y la distinción no es cosmética.

El bus de eventos default existe en cada cuenta y región, y es donde los servicios de AWS entregan sus eventos. Eso no es configurable. Cuando una instancia EC2 cambia de estado, ese evento va al bus default de esa cuenta, punto.

Un bus de eventos personalizado es uno que creas tú. Tus propias aplicaciones publican en él con PutEvents, y puedes reenviar eventos de un bus a otro (incluso entre cuentas y regiones) haciendo que un bus sea target de una regla. Los buses personalizados existen para que los eventos de tus aplicaciones no compartan espacio de reglas con el tráfico de los servicios de AWS, y para que puedas adjuntar una política basada en recursos que deje publicar a otras cuentas específicas.

Un bus de partner recibe eventos de un proveedor SaaS a través de un partner event source que asocias con él.

La confusión que conviene matar ahora: crear un bus personalizado no mueve los eventos de los servicios de AWS hacia él. Si un escenario dice "aísla los eventos de nuestra aplicación del ruido de los servicios de AWS", el bus personalizado es correcto. Si un escenario dice "recibir los eventos de S3 en nuestro bus personalizado", la respuesta honesta es que llegan al bus default y tú los reenvías.

Cuotas que vale la pena recordar: 100 buses de eventos por cuenta y región, 300 reglas por bus en la mayoría de las regiones, y 5 targets por regla (esa última no es ajustable).

Reglas: el patrón es el filtro

Una regla tiene un filtro y una lista de targets. El filtro es un patrón de evento (matchear eventos por contenido) o una expresión de schedule (dispararse con una expresión cron o rate). Es uno u otro.

El patrón tiene la misma forma que el evento que matchea, y esa decisión de diseño es lo que hace que los patrones se lean bien. Este patrón selecciona terminaciones de instancias EC2:

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["terminated"]
  }
}

Tres requisitos separados, y los tres tienen que cumplirse.

Cómo funciona realmente el matching de patrones

Cuatro reglas gobiernan cada patrón que vas a escribir o depurar. Apréndelas acá y la mayoría de los problemas de "mi regla no se dispara" pasan a ser un diagnóstico de 30 segundos.

El matching es una prueba de subconjunto. Cada campo que nombras tiene que coincidir. Cada campo que omites se ignora. Así que {"source": ["aws.ecs"]} matchea todos los eventos de ECS del bus. Ese es el mecanismo detrás de las reglas que resultan dispararse cientos de veces por día: el patrón quedó poco específico, no equivocado.

Un array significa OR. "state": ["stopped", "terminated"] matchea cualquiera de los dos valores. Para exigir dos condiciones, nombras dos campos, que es un AND implícito. Hay una trampa relacionada: si escribes la misma clave dos veces en un patrón, EventBridge usa solo la última referencia e ignora la primera en silencio.

El matching es exacto, carácter por carácter. La mayoría de los servicios de AWS tratan : y / de un ARN como intercambiables. EventBridge no. Si el evento trae instance/i-0abc y tu patrón dice instance:i-0abc, no matchea nada, y nada te dice por qué.

Los operadores de comparación funcionan solo sobre nodos hoja. $or y anything-but son las dos excepciones.

Esos operadores son la otra mitad de la fluidez con patrones:

Dos restricciones sobre los dos últimos. wildcard es compatible con las reglas de bus pero no con los filtros de pipes, y cada bus admite solo 30 reglas que contengan wildcards, una cuota que no puedes subir. Y un $or que se expande a más de 1.000 combinaciones de reglas se rechaza con InvalidEventPatternException; la cuenta de combinaciones es el producto de la cantidad de argumentos de cada array $or del patrón.

Un patrón de evento está limitado a 2.048 caracteres de forma predeterminada.

El hábito de depuración más útil acá es el EventBridge Sandbox de la consola (o la API TestEventPattern). Pegas un evento real, pegas tu patrón, obtienes un sí o un no. No cuesta nada y resuelve discusiones que si no te llevan una tarde.

Targets y los dos modelos de permisos

Hasta 5 targets por regla. La lista es larga, y los que importan para remediación son Lambda, SNS, SQS, Step Functions, Systems Manager Automation, Systems Manager Run Command, OpsItem de Systems Manager, response plans de Incident Manager, tareas de ECS, API destinations y otros buses de eventos. Algunos targets ni siquiera reciben el evento: RebootInstances, StopInstances y TerminateInstances de EC2 tratan el evento solo como disparador de esa llamada a la API.

Los permisos funcionan de dos maneras, y saber cuál aplica a cuál target es material de examen.

Un rol de ejecución de IAM. Configuras RoleArn en el target, la trust policy del rol permite que events.amazonaws.com lo asuma, y su política de permisos otorga la acción que el target necesita. Así funcionan la mayoría de los targets, y es la única opción para targets como Systems Manager Automation y ECS.

Una política basada en recursos en el target. Para Lambda, SNS y SQS, si no hay rol de ejecución configurado, EventBridge cae en una política sobre el propio recurso target que le da a events.amazonaws.com permiso para invocar o publicar.

La consecuencia práctica es un escenario favorito. Creas la regla en la consola y funciona, porque la consola adjunta la política basada en recursos por ti. Creas la misma regla con PutTargets y el target nunca se invoca, porque nadie adjuntó esa política. La métrica TriggeredRules muestra que la regla se disparó; Invocations muestra que no llegó nada. Dos variantes más de la misma forma: una cola SQS o un topic SNS cifrados necesitan que la key policy le otorgue kms:Decrypt y kms:GenerateDataKey a events.amazonaws.com, y EventBridge directamente no puede usar una cola SQS cifrada con una AWS owned key.

Input transformation: darle otra forma al evento

Algunos targets necesitan el evento tal cual. Otros necesitan una estructura específica, o una línea legible por una persona. El input transformer resuelve esto en dos partes.

El input path define variables a partir del evento con JSON path:

{
  "timestamp": "$.time",
  "instance": "$.detail.instance-id",
  "state": "$.detail.state"
}

El input template es lo que el target recibe de verdad:

{
  "instance": <instance>,
  "state": <state>,
  "note": "la instancia \"<instance>\" está en <state>"
}

Tienes hasta 100 variables, más las reservadas que no necesitas definir: aws.events.rule-arn, aws.events.rule-name, aws.events.event.ingestion-time y aws.events.event.json para la carga original completa.

El modo de falla que debes esperar: EventBridge no valida los input paths cuando guardas la regla. Una ruta que no matchea nada no produce variable, y ese campo desaparece de la salida. Sin error, sin advertencia, solo un target que recibe menos de lo que querías.

Reglas programadas y EventBridge Scheduler

Una regla puede dispararse por schedule en vez de por patrón, usando rate(...) o cron(...). Dos datos sobre las reglas programadas de los que dependen varias preguntas: la expresión se evalúa en UTC, y la resolución más fina es de un minuto, con la invocación cayendo en algún punto dentro de ese minuto y no en el segundo exacto.

EventBridge Scheduler es el servicio aparte, construido específicamente para programación, y es la respuesta correcta cada vez que un escenario enfatiza escala o flexibilidad por schedule. Maneja millones de schedules, admite invocaciones únicas además de recurrentes, entiende zonas horarias, ofrece ventanas de tiempo flexibles para repartir la carga y alcanza más de 270 servicios con su universal target parameter. Las reglas programadas están limitadas por la cuota de reglas por bus y por el límite de 5 targets por regla; Scheduler no.

Pista de palabras clave: "miles de schedules por cliente", "una sola vez" o "en la zona horaria local del cliente" apuntan a Scheduler. "Reaccionar cuando este servicio de AWS haga algo" apunta a una regla.

Consejos para el examen

• Busca un verbo en pasado en el enunciado. "Cuando una instancia se termina", "cuando un snapshot completa", "cuando alguien cambia una política" son todos EventBridge. "Cuando la CPU supera el 80% durante 10 minutos" es una alarma.
• Una regla que se dispara mucho más de lo esperado tiene un patrón poco específico. Una regla que nunca se dispara suele ser una de tres cosas: un patrón con la puntuación equivocada en un ARN, un evento de servicio global esperado fuera de us-east-1, o un filtro sobre un campo resources que los eventos de CloudTrail dejan vacío.
• TriggeredRules mayor a cero con Invocations en cero significa que el enrutamiento funcionó y los permisos no. Esa es la pregunta de la política basada en recursos expresada en métricas.
• Las alarmas compuestas no pueden ejecutar acciones de EC2 ni de Auto Scaling. Cuando un escenario necesita que una condición compuesta dispare una reparación de varios pasos, la compuesta notifica y una regla de EventBridge matchea el evento de cambio de estado de la alarma.
• Los buses personalizados nunca reciben eventos de servicios de AWS de forma directa. Si una opción afirma lo contrario, descártala.
• Recuerda los tres números duros: 5 targets por regla (no ajustable), 300 reglas por bus de eventos, 100 buses por cuenta y región.

El modelo mental que te llevas: el bus no elige destino. Cada regla conectada a un bus ve cada evento que llega, decide por su cuenta si matchea y entrega a sus propios targets. Agregar una regla es agregar un consumidor sin tocar nada de lo que ya está corriendo, y eso es lo que significa "débilmente acoplado" en la práctica. Lo siguiente es Pipes, que cubre el caso para el que un bus está mal: un stream específico cuyos registros hay que filtrar, enriquecer con una consulta y entregar a exactamente un destino.