Cuando una arquitectura en AWS deja de ser un solo bloque y se divide en servicios que deben comunicarse, aparece la pregunta: ¿los conecto con Amazon SQS, con Amazon SNS o con Amazon EventBridge? Los tres desacoplan componentes y los tres son totalmente administrados —sin servidores que parchar ni operar—, pero resuelven problemas distintos. Elegir sin criterio se paga después en latencia, en eventos perdidos o en una integración que se vuelve difícil de mantener.
Esta guía compara los tres con criterios de decisión para gerentes y arquitectos de tecnología, no solo para desarrolladores.
Qué es cada uno, en una frase
- Amazon SQS (Simple Queue Service) es una cola de mensajes: un componente deja un mensaje y otro lo recoge cuando está listo. La comunicación es punto a punto y el consumidor sondea la cola (modelo pull). Sirve para desacoplar y amortiguar carga entre partes de un sistema.
- Amazon SNS (Simple Notification Service) es un servicio de publicación/suscripción: un mensaje publicado en un tema se empuja al instante a todos sus suscriptores (modelo push). Sirve para difundir un mismo hecho a varios destinos a la vez.
- Amazon EventBridge es un bus de eventos serverless: recibe eventos de servicios de AWS, aplicaciones propias y SaaS de terceros, y los enruta a los destinos correctos según reglas basadas en el contenido del evento. Sirve para construir arquitecturas orientadas a eventos e integraciones amplias.
La confusión es comprensible: los tres mueven mensajes de un lado a otro. Pero el modelo de comunicación de cada uno es distinto, y esa diferencia es la que decide.
Los criterios que realmente deciden
1. ¿Un consumidor o muchos? (acoplamiento)
Este criterio filtra primero. Si cada mensaje debe procesarlo un único consumidor —una orden que se factura una sola vez, un trabajo que se ejecuta una vez—, SQS es la elección natural: la cola entrega el mensaje, el consumidor lo procesa y lo elimina.
Si un mismo hecho debe llegar a varios destinos en paralelo —notificar a inventario, a facturación y a analítica al mismo tiempo—, necesitas difusión: SNS o EventBridge. SNS empuja la misma copia a todos los suscriptores; EventBridge enruta según reglas. Aquí aparece el patrón fan-out: publicar una vez y reaccionar en varios frentes.
2. Pull vs push: quién controla el ritmo
SQS funciona por sondeo: el consumidor pregunta por mensajes cuando tiene capacidad. Eso lo vuelve ideal como amortiguador: si llega un pico, los mensajes se acumulan en la cola y el consumidor los procesa a su ritmo sin caerse. Es backpressure gratis.
SNS y EventBridge empujan el mensaje al destino apenas ocurre. Ganan en latencia y en simplicidad de reacción inmediata, pero el destino tiene que estar listo para recibir —por eso muchas veces se coloca una cola SQS delante del consumidor final, incluso cuando la difusión la hace SNS o EventBridge.
3. Filtrado: ¿cada destino recibe todo o solo lo suyo?
Con SQS cada cola es un flujo propio: no hay filtrado, el consumidor recibe lo que se puso en su cola.
SNS permite políticas de filtrado por suscripción: cada suscriptor puede recibir solo los mensajes cuyos atributos le interesan, en lugar de todo el tema.
EventBridge lleva el filtrado más lejos: sus reglas evalúan patrones sobre el contenido completo del evento, no solo atributos sueltos. Si tu enrutamiento depende de “qué dice el evento por dentro” —tipo, origen, valores del payload—, EventBridge es el más expresivo de los tres.
4. Persistencia y reintentos
SQS almacena los mensajes de forma duradera hasta que se procesan, con una retención configurable de hasta 14 días, y ofrece colas de mensajes muertos (DLQ) para aislar lo que falla repetidamente. Es la opción más robusta cuando no puedes perder un mensaje.
SNS no retiene el mensaje más allá de sus reintentos de entrega; para no perder eventos, se combina con una cola SQS que sí los guarda. EventBridge puede archivar y reproducir eventos, útil para reprocesar historia o depurar.
5. Integraciones con SaaS de terceros
Aquí EventBridge es único: recibe eventos directamente de fuentes de socios (aplicaciones SaaS) y los mete en tu arquitectura sin código de pegamento. SQS y SNS no tienen ese ecosistema de conectores SaaS. Si tu integración cruza los límites de AWS hacia herramientas externas, EventBridge es el punto de entrada pensado para eso.
Comparación lado a lado
| Dimensión | Amazon SQS | Amazon SNS | Amazon EventBridge |
|---|---|---|---|
| Modelo | Cola (punto a punto) | Pub/sub (notificaciones) | Bus de eventos (enrutamiento) |
| Entrega | Pull: el consumidor sondea | Push: a los suscriptores | Push: a los targets por reglas |
| Relación | 1 mensaje → 1 consumidor | 1 mensaje → N suscriptores | N orígenes → N destinos |
| Filtrado | No (cada cola, su flujo) | Políticas de filtrado | Patrones sobre el evento |
| Persistencia | Sí, hasta 14 días | No (reintentos + DLQ) | Archivo y reproducción |
| Ordenamiento | FIFO disponible | FIFO disponible | Sin garantía de orden |
| SaaS de terceros | No | No | Sí (fuentes de socios) |
| Uso típico | Desacoplar y amortiguar | Fan-out y notificaciones | Arquitectura event-driven |
Los tres juntos: el caso más común
En arquitecturas reales rara vez se elige “uno de los tres”. Se combinan según lo que cada tramo necesita:
- SNS + SQS (fan-out clásico): un evento se publica una vez en SNS y llega a varias colas SQS; cada consumidor procesa su copia a su ritmo, con DLQ para lo que falla. Es el patrón de difusión más usado en AWS.
- EventBridge como enrutador de negocio: EventBridge recibe eventos de varios orígenes —incluidos SaaS— y, según reglas de contenido, los manda a Lambda, a Step Functions, a una cola SQS o a un tema SNS.
- SQS como buffer delante de todo: cuando el consumidor final es sensible a picos, se coloca una cola SQS antes para absorber la ráfaga.
Si tu arquitectura además debe orquestar una secuencia de pasos (no solo mover mensajes), la pieza que se suma es un orquestador como AWS Step Functions para coordinar el flujo, un servicio serverless más. Y si estás decidiendo el modelo de cómputo que consumirá estos eventos, lo vemos en EKS vs ECS vs Lambda.
Cómo elegimos en Caleidos
La mensajería y los eventos son los tendones de una arquitectura desacoplada: mal elegidos, acoplan lo que debían separar. En Caleidos partimos de la pregunta de negocio —¿qué debe pasar cuando ocurre este hecho, y cuántos sistemas reaccionan?— antes de nombrar un servicio. A partir de ahí diseñamos el patrón: cola para desacoplar, pub/sub para difundir, bus de eventos para enrutar e integrar. Es parte de cómo construimos aplicaciones nativas de la nube sobre AWS, junto con microservicios y arquitecturas serverless que escalan sin que tu equipo administre servidores.
En resumen
No hay un ganador absoluto entre SQS, SNS y EventBridge: hay un encaje según el problema. SQS desacopla y amortigua carga con durabilidad; SNS difunde el mismo hecho a varios destinos con baja latencia; EventBridge enruta por contenido e integra con el mundo SaaS. La arquitectura sólida casi siempre usa más de uno, cada uno en el tramo donde rinde mejor. Si estás definiendo cómo se comunican tus servicios en AWS, conversemos: la decisión correcta se toma sobre tu carga real, no sobre una tabla genérica.
