Servicio de mensajería pub/sub de AWS que distribuye mensajes a múltiples suscriptores simultáneamente, habilitando patrones de fan-out y notificaciones a escala.
Amazon SNS (Simple Notification Service) es un servicio de mensajería pub/sub completamente gestionado que permite el envío de mensajes desde publicadores hacia múltiples suscriptores de forma simultánea. A diferencia de los sistemas de colas tradicionales, SNS implementa el patrón fan-out donde un mensaje se distribuye a todos los endpoints suscritos al topic.
El servicio opera con topics como puntos de comunicación lógicos. Los publicadores envían mensajes a un topic, y SNS se encarga de entregar copias del mensaje a todos los suscriptores configurados. Esta arquitectura desacopla completamente a los productores de los consumidores, permitiendo escalabilidad independiente y evolución de sistemas sin afectar otros componentes.
SNS soporta tanto topics estándar como FIFO (First-In-First-Out). Los topics estándar ofrecen throughput prácticamente ilimitado con entrega at-least-once, mientras que los FIFO garantizan orden estricto y entrega exactly-once con un límite de 300 mensajes por segundo por grupo de mensajes (hasta 3,000 msg/s por topic).
SNS puede entregar mensajes a múltiples tipos de endpoints:
Servicios AWS nativos:
Endpoints externos:
SNS permite filtrado granular de mensajes usando message attributes y filter policies. Cada suscriptor puede definir una política JSON que especifica qué mensajes debe recibir:
{
"event_type": ["order_created", "order_updated"],
"region": ["us-east-1", "eu-west-1"],
"amount": [{"numeric": [">", 100]}],
"customer_tier": ["premium", "enterprise"]
}Esta funcionalidad elimina la necesidad de procesar y descartar mensajes irrelevantes en el consumidor, reduciendo costos y latencia. Los filtros soportan coincidencias exactas, rangos numéricos, prefijos de strings y listas de valores permitidos.
# Topic SNS principal
resource "aws_sns_topic" "order_events" {
name = "order-events"
display_name = "Order Processing Events"
# Configuración de entrega
delivery_policy = jsonencode({
"http" = {
"defaultHealthyRetryPolicy" = {
"minDelayTarget" = 20
"maxDelayTarget" = 20
"numRetries" = 3
"numMaxDelayRetries" = 0
"numMinDelayRetries" = 0
"numNoDelayRetries" = 0
"backoffFunction" = "linear"
}
}
})
}
# SQS para procesamiento de inventario
resource "aws_sqs_queue" "inventory_processing" {
name = "inventory-processing"
visibility_timeout_seconds = 300
message_retention_seconds = 1209600
# Dead letter queue para mensajes fallidos
redrive_policy = jsonencode({
deadLetterTargetArn = aws_sqs_queue.inventory_dlq.arn
maxReceiveCount = 3
})
}
resource "aws_sqs_queue" "inventory_dlq" {
name = "inventory-processing-dlq"
}
# SQS para notificaciones de usuario
resource "aws_sqs_queue" "user_notifications" {
name = "user-notifications"
visibility_timeout_seconds = 60
redrive_policy = jsonencode({
deadLetterTargetArn = aws_sqs_queue.notifications_dlq.arn
maxReceiveCount = 5
})
}
resource "aws_sqs_queue" "notifications_dlq" {
name = "user-notifications-dlq"
}
# Suscripción para inventario con filtrado
resource "aws_sns_topic_subscription" "inventory_subscription" {
topic_arn = aws_sns_topic.order_events.arn
protocol = "sqs"
endpoint = aws_sqs_queue.inventory_processing.arn
# Solo eventos de creación y cancelación de órdenes
filter_policy = jsonencode({
event_type = ["order_created", "order_cancelled"]
product_category = ["electronics", "books"]
})
}
# Suscripción para notificaciones con filtrado diferente
resource "aws_sns_topic_subscription" "notifications_subscription" {
topic_arn = aws_sns_topic.order_events.arn
protocol = "sqs"
endpoint = aws_sqs_queue.user_notifications.arn
# Solo eventos que requieren notificación al usuario
filter_policy = jsonencode({
event_type = ["order_created", "order_shipped", "order_delivered"]
notification_required = ["true"]
})
}
# Permisos para que SNS escriba a SQS
resource "aws_sqs_queue_policy" "inventory_policy" {
queue_url = aws_sqs_queue.inventory_processing.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = {
Service = "sns.amazonaws.com"
}
Action = "sqs:SendMessage"
Resource = aws_sqs_queue.inventory_processing.arn
Condition = {
ArnEquals = {
"aws:SourceArn" = aws_sns_topic.order_events.arn
}
}
}]
})
}
resource "aws_sqs_queue_policy" "notifications_policy" {
queue_url = aws_sqs_queue.user_notifications.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = {
Service = "sns.amazonaws.com"
}
Action = "sqs:SendMessage"
Resource = aws_sqs_queue.user_notifications.arn
Condition = {
ArnEquals = {
"aws:SourceArn" = aws_sns_topic.order_events.arn
}
}
}]
})
}Los topics FIFO de SNS garantizan orden estricto y entrega exactly-once usando message group IDs y deduplication IDs:
import boto3
import json
from datetime import datetime
sns = boto3.client('sns')
# Publicar mensaje FIFO con agrupación
response = sns.publish(
TopicArn='arn:aws:sns:us-east-1:123456789012:order-events.fifo',
Message=json.dumps({
'order_id': 'ord_12345',
'event_type': 'order_created',
'timestamp': datetime.utcnow().isoformat(),
'customer_id': 'cust_67890'
}),
MessageGroupId='customer_67890', # Agrupa por cliente
MessageDeduplicationId='ord_12345_created', # Previene duplicados
MessageAttributes={
'event_type': {
'DataType': 'String',
'StringValue': 'order_created'
},
'customer_tier': {
'DataType': 'String',
'StringValue': 'premium'
}
}
)SNS implementa políticas de reintento configurables por tipo de endpoint:
| Endpoint | Reintentos totales | Duración | Configuración |
|---|---|---|---|
| Lambda/SQS | 100,015 | ~23 días | Automático (backoff exponencial) |
| HTTP/HTTPS | 3 (por defecto) | Personalizable | Política de entrega configurable |
| Email/SMS/Push | 50 | ~6 horas | Fijo (backoff exponencial) |
Para endpoints HTTP, se puede configurar una política de entrega personalizada que define el comportamiento de reintentos, incluyendo delays mínimos y máximos, función de backoff y número de intentos. Los endpoints AWS gestionados (Lambda, SQS) tienen reintentos agresivos con backoff exponencial que pueden extenderse por semanas.
SNS permite suscripciones entre cuentas AWS diferentes, habilitando arquitecturas multi-tenant y organizacionales:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ACCOUNT-B:root"
},
"Action": "sns:Subscribe",
"Resource": "arn:aws:sns:us-east-1:ACCOUNT-A:shared-events",
"Condition": {
"StringEquals": {
"sns:Protocol": ["sqs", "lambda"]
}
}
}]
}SNS se integra nativamente con CloudWatch para observabilidad:
Métricas clave:
NumberOfMessagesPublished: Mensajes publicados al topicNumberOfNotificationsDelivered: Entregas exitosas por endpointNumberOfNotificationsFailed: Fallos de entregaPublishSize: Tamaño promedio de mensajesAlarmas sugeridas (ajustar según el caso de uso):
SNS es fundamental en arquitecturas event-driven modernas porque resuelve el problema de acoplamiento entre servicios. En sistemas distribuidos, el acoplamiento directo entre componentes crea dependencias frágiles que limitan la escalabilidad y aumentan la complejidad operacional.
Con SNS, un servicio de órdenes puede publicar eventos sin conocer qué sistemas los consumen. Inventario, facturación, notificaciones y analytics pueden suscribirse independientemente. Esto permite evolución independiente de servicios, deployment desacoplado y tolerancia a fallos mejorada.
La combinación SNS + SQS es especialmente poderosa porque combina la distribución inmediata de SNS con la durabilidad y procesamiento controlado de SQS. Los equipos pueden procesar eventos a su propio ritmo sin perder mensajes, implementar backpressure y manejar picos de tráfico de forma resiliente.
Para arquitectos de sistemas, SNS representa la diferencia entre sistemas monolíticos acoplados y arquitecturas distribuidas que escalan. Es la infraestructura que permite patrones como Event Sourcing, CQRS y microservicios verdaderamente desacoplados.
Modelo de computación en la nube donde el proveedor gestiona la infraestructura automáticamente, permitiendo ejecutar código sin aprovisionar ni administrar servidores, pagando solo por el uso real.
Servicio de colas de mensajes completamente administrado de AWS que desacopla componentes de aplicaciones distribuidas, garantizando la entrega de mensajes con escalabilidad ilimitada.
Patrón arquitectónico donde los componentes se comunican mediante eventos asíncronos, permitiendo sistemas desacoplados, escalables y reactivos.
Servicio de cómputo serverless de AWS que ejecuta código en respuesta a eventos sin necesidad de aprovisionar ni administrar servidores, escalando automáticamente desde cero hasta miles de ejecuciones concurrentes.
Capacidad de entender el estado interno de un sistema a partir de sus outputs externos: logs, métricas y traces, permitiendo diagnosticar problemas sin acceso directo al sistema.
Diseño de arquitectura para escalar un segundo cerebro personal a un sistema de producción con AWS serverless — desde el prototipo actual hasta casos de uso especializados en legal, investigación y comunidad.
Colección de 13 módulos Terraform publicados en el Terraform Registry para desplegar arquitecturas serverless en AWS, con 12 ejemplos que cubren desde ECS básico hasta CRUD full-stack con DynamoDB y AgentCore con MCP.
Backend serverless de producción para un grafo de conocimiento personal — DynamoDB, Lambda, Bedrock, MCP, Step Functions. La implementación de la arquitectura descrita en el ensayo «Del prototipo a producción».