EventBridge

Modelo mental

SNS y EventBridge resuelven el mismo problema —un productor, varios consumidores que no se conocen— y lo resuelven al revés el uno del otro.

En SNS el productor elige el canal: publica en el topic pedidos y quien esté suscrito a pedidos lo recibe todo. El acoplamiento no ha desaparecido, se ha movido: ahora está en el nombre del topic, y por eso los sistemas con SNS acaban con veinte topics y una convención de nombres que nadie recuerda.

En EventBridge el productor publica en un bus y ya está. Es el consumidor quien declara qué le interesa, con una regla que contiene un patrón sobre el JSON del evento:

{
  "detail-type": ["PedidoCreado"],
  "detail": {
    "pais": ["ES"],
    "importe": [{ "numeric": [">", 500] }]
  }
}

Nadie tuvo que crear un topic pedidos-españa-grandes. El productor no sabe que esa regla existe y no se entera si mañana desaparece.

Ese cambio de dirección es el que hace que EventBridge escale organizativamente: añadir un consumidor no toca nada de lo que ya existe, ni siquiera la configuración del productor. Es la razón por la que aparece en cuanto hay varios equipos publicando en el mismo sitio.

Lo que se paga a cambio

Tres cosas, y conviene tenerlas claras antes de elegirlo por moda:

• Menos throughput. Fuera de Virginia, Oregón e Irlanda, PutEvents cae a 2 400, a 1 200, a 600 o a 400 por segundo. SNS, en las mismas regiones pequeñas, da 300 — son órdenes parecidos, pero si estabas en us-east-1 mirando 10 000, el salto al desplegar en otra región es brusco.
• Más latencia. Evaluar patrones cuesta más que copiar un mensaje a una cola.
• Cinco destinos por regla, y es un muro.

El archivo es lo que suele decidir

EventBridge puede archivar todo lo que pasa por un bus y reproducirlo después. Eso es lo que SNS estándar no tiene y no va a tener: en SNS, un consumidor que estuvo tres días con un bug perdió tres días de eventos y no hay manera de recuperarlos.

Si alguna vez has tenido que pedir a otro equipo que te reenvíe eventos a mano, ya sabes cuánto vale esa casilla.

Cómo te factura

Por evento publicado, y con una asimetría que conviene conocer:

Comparado con SNS —del orden de 0,50 USD por millón de publicaciones, con las entregas a SQS y Lambda gratis— EventBridge sale claramente más caro por evento. La diferencia se paga por el enrutado por contenido, el archivo y el replay. Si no vas a usar ninguna de las tres, estás pagando de más.

Detalle útil: los eventos que generan los propios servicios de AWS hacia el bus por defecto no se facturan. Reaccionar a un cambio de estado de EC2 o a un Object Created de S3 es gratis; publicar tus propios eventos de dominio, no.

Cuándo NO usarlo

• Fan-out simple sin reglas. Si todos los consumidores quieren todos los eventos, SNS es más rápido, más barato y aguanta más. Las reglas de EventBridge no aportan nada cuando no filtras.
• Throughput alto fuera de las tres regiones grandes. 400 PutEvents por segundo se alcanza antes de lo que parece.
• Necesitas orden. No hay ordenación de ningún tipo.
• Necesitas latencia mínima. Entre el PutEvents y el destino hay evaluación de patrones. Para un camino crítico y corto, una cola directa.
• Un evento tiene que llegar a más de cinco sitios y no quieres varias reglas. El límite es duro; el diseño tiene que contar con él.

Errores comunes

Chocar contra los cinco destinos. Es el límite que más sorprende porque no se puede ampliar. La salida habitual es partir en varias reglas con el mismo patrón, o poner una cola en medio y hacer el fan-out ahí.

Suponer el throughput de us-east-1. Es el mismo error que con SNS y con API Gateway, y se repite porque todos los tutoriales están escritos en Virginia. Si despliegas en São Paulo, tu PutEvents va a 600 y tus invocaciones a 750.

Patrones que no caben. El patrón de evento tiene un techo de 2 048 caracteres. Una lista larga de valores permitidos lo agota rápido, y entonces toca dividir la regla.

Abusar de los comodines. Solo 30 reglas por bus pueden llevar wildcards en su patrón, y ese límite no se ajusta. Es un recurso escaso: gástalo donde haga falta de verdad.

Meter todo en el bus por defecto. El bus por defecto recibe además los eventos de todos los servicios de AWS de tu cuenta. Mezclar ahí tus eventos de dominio complica los patrones y complica los permisos. Crea un bus propio.

No poner DLQ en el destino. Si el destino falla, EventBridge reintenta y luego descarta. Cada target admite su propia cola de mensajes fallidos, y sin ella los eventos se pierden en silencio.

Olvidar el techo de la política del bus. Son 10 240 caracteres y crece cada vez que das acceso a otra cuenta. En una organización con muchas cuentas es un límite real, no teórico.

Fuentes

Todas las cuotas —destinos por regla, reglas con comodines, PutEvents e invocaciones por región, reglas y buses, tamaño de patrón y de política, API destinations y plano de control—, y qué se puede ampliar y qué no: Amazon EventBridge quotas. Cuotas de SNS usadas en la comparación: Amazon SNS endpoints and quotas. Los importes proceden de las páginas de precios de AWS, que se renderizan dinámicamente y no pudieron citarse literalmente: trátalos como orden de magnitud.