Amazon SNS Deep Dive: Una guía práctica de diseño “Pub/Sub” comparada con Cloud Pub/Sub y Azure Event Grid / Service Bus

Introducción (Puntos clave)

• Este artículo se centra en Amazon Simple Notification Service (Amazon SNS) y,
  en comparación con Google Cloud Pub/Sub, Azure Event Grid y Azure Service Bus Topics,
  organiza cómo diseñar mensajería event-driven al estilo Pub/Sub.
• Amazon SNS es un servicio Pub/Sub completamente gestionado que admite tanto mensajería A2A (aplicación-a-aplicación) como A2P (aplicación-a-persona).
  Los mensajes publicados en un topic pueden distribuirse (fan-out) a múltiples colas SQS, funciones Lambda, endpoints HTTPS, email, SMS y notificaciones push móviles.
• En GCP, Cloud Pub/Sub se usa ampliamente como columna vertebral de mensajería asíncrona de alto rendimiento para microservicios y data pipelines.
• En Azure:
  • Event Grid: un broker serverless orientado al enrutamiento de eventos
  • Service Bus Topics: un message broker empresarial con funciones avanzadas (colas + topics)
    se corresponden en intención con SNS.
• Este artículo está dirigido a:
  • Ingenieros backend que quieren adoptar una arquitectura event-driven en microservicios o serverless
  • SREs y arquitectos que conocen colas como SQS pero quieren ordenar las diferencias entre SNS / Pub/Sub / Event Grid / Service Bus Topics
  • Desarrolladores de producto que quieren enviar notificaciones al usuario (email / SMS / push) de manera inteligente
• Al final podrás explicar decisiones como:
  • “Este evento va por un SNS topic → fan-out a SQS”
  • “Para flujos de logs y analítica usaremos Pub/Sub / Event Grid / Service Bus Topics”
  • “Las alertas user-facing se envían por SNS (email / SMS / push)”

1. ¿Qué es Amazon SNS? El hub Pub/Sub de AWS que conecta A2A y A2P

1.1 Rol y características de SNS

Amazon SNS es un servicio de mensajería Pub/Sub completamente gestionado.

En términos menos formales:

“Publicas eventos o notificaciones en un topic,
y SNS actúa como un centro logístico que los difunde a múltiples destinos (servicios o personas) suscritos.”

Características principales:

• Mensajería A2A
  • Compartir eventos entre microservicios
  • Fan-out desde SNS a SQS / Lambda / Kinesis / HTTP(S), etc.
• Notificaciones A2P
  • Email, SMS y notificaciones push móviles
• Escalado automático y alta disponibilidad gestionados por AWS
• Integración profunda
  • Muchos servicios de AWS pueden enviar eventos directamente a SNS (CloudWatch Alarms, Auto Scaling, S3, Lambda, EventBridge, etc.)

1.2 Tipos de endpoints soportados

• Amazon SQS
• AWS Lambda
• HTTP / HTTPS
• Email (SMTP / JSON)
• SMS
• Push móvil (APNs / FCM / ADM, etc.)

En GCP y Azure, la parte A2P se ofrece mediante servicios separados; por lo tanto,
SNS destaca como “un solo servicio que cubre A2A y A2P.”

2. Posicionamiento de SNS frente a servicios equivalentes en otras nubes

2.1 Google Cloud Pub/Sub

• Es la columna vertebral Pub/Sub de GCP.
• Conceptos clave:
  • Topics y subscriptions (push/pull)
  • Alto rendimiento
  • Integración fuerte con BigQuery, Dataflow, Cloud Functions, Cloud Run

En intención, SNS (+SQS) y Pub/Sub cumplen roles muy similares:
“desacoplar aplicaciones mediante eventos.”

2.2 Azure Event Grid & Service Bus Topics

• Event Grid: broker de eventos centrado en enrutamiento serverless
• Service Bus Topics: Pub/Sub empresarial con filtros avanzados

Mapeo aproximado:

• SNS topics → Service Bus Topics / Pub/Sub topics
• EventBridge → Event Grid (y parte de Pub/Sub)

3. Conceptos clave en SNS: Topics, Subscriptions y Message Attributes

3.1 Topics

Son unidades centrales del modelo SNS.
Su organización habitual es por tipo de evento o dominio.

3.2 Subscriptions

Definen a qué destino se enviarán los mensajes.
Un topic puede tener múltiples suscriptores (SQS, Lambda, webhooks, email…).

3.3 Message Attributes y filtrado

Permiten etiquetar mensajes (event_type, priority, region) y filtrar por suscripción.
Esto habilita enrutamiento fino, equivalente a filtros en Azure Service Bus Topics.

4. Casos de uso representativos

4.1 Distribución A2A (fan-out)

Ejemplo: evento orders.

• Facturación → SQS
• Envíos → SQS
• Analítica → SQS
• Confirmación por email → Lambda

4.2 Alertas y monitorización

CloudWatch Alarms → SNS → email / Slack / SMS.

4.3 Notificaciones al usuario (A2P)

Email, SMS, push móvil.
Ventaja frente a otras nubes: todo centralizado.

4.4 IoT, logs y hubs de eventos

SNS como hub central → SQS / Lambda / Kinesis.

5. Patrones arquitectónicos

5.1 SNS + SQS: fan-out + buffering

Patrón clásico:

• SNS distribuye
• SQS desacopla, almacena y reintenta

5.2 SNS + Lambda: procesamiento serverless

Ejecución inmediata con bajo mantenimiento.

5.3 SNS + EventBridge

División de roles:

• SNS = Pub/Sub simple (+A2P)
• EventBridge = enrutamiento complejo

6. Consideraciones de diseño: modelado, reintentos y seguridad

6.1 Estructura y esquema del mensaje

Uso recomendado de event_id, event_type, schema_version.
Payload pesado → mejor enviar referencias.

6.2 Idempotencia y reintentos

SNS es at-least-once →
Diseñar siempre para procesar duplicados sin efectos adversos.

6.3 Seguridad

IAM policies, resource policies, encriptación KMS, acceso privado con VPC endpoints.

7. Comparación de alto nivel: “personalidades” de los servicios

• SNS: Pub/Sub sencillo + A2P
• SQS: cola 1-a-1
• Cloud Pub/Sub: backbone de alta capacidad
• Event Grid: event bus serverless
• Service Bus Topics: message broker robusto

Patrones estándar:

• AWS: SNS + SQS + Lambda
• GCP: Pub/Sub + Cloud Run / Functions
• Azure: Event Grid + Functions / Service Bus

8. Errores comunes

8.1 Un solo topic para todo

8.2 Multiplicar topics en exceso

8.3 Ignorar la idempotencia

8.4 No monitorear métricas ni DLQs

9. ¿Quién se beneficia?

9.1 Backend

Desacoplamiento y extensibilidad.

9.2 SRE / Platform

Trazabilidad de eventos y estandarización entre nubes.

9.3 Product Managers / Tech Leads

Reducción del acoplamiento entre servicios.

9.4 CTOs de startups

Arquitectura simple ahora, escalable después.

10. Tres pasos prácticos

1. Listar eventos potenciales.
2. Crear un topic SNS + SQS/Lambda de prueba.
3. Mentalmente portar el diseño a GCP/Azure.

11. Resumen

SNS es:

• Un backbone Pub/Sub para desacoplar microservicios
• Un hub de notificaciones hacia usuarios

Adoptar una mentalidad event-driven —
pasar de “servicios llamándose directamente” a
“eventos al centro y servicios suscribiéndose” —
conduce a arquitecturas más resilientes, extensibles y observables.

No hace falta empezar por algo perfecto.
Con convierte un solo flujo en event-driven y construye desde ahí.

Referencias

• https://aws.amazon.com/sns/
• https://docs.aws.amazon.com/ja_jp/sns/latest/dg/welcome.html
• https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-phone-number-as-subscriber.html
• https://zenn.dev/issy/articles/zenn-sns-overview
• https://cloud.google.com/pubsub/docs/overview
• https://learn.microsoft.com/ja-jp/azure/event-grid/overview
• https://learn.microsoft.com/ja-jp/azure/service-bus-messaging/service-bus-queues-topics-subscriptions