Alertas por Email con SNS: Por qué No Recibes los Mensajes y Cómo Solucionarlo

Configuraste un tema SNS, añadiste tu dirección de correo como suscriptor, y publicaste un mensaje de prueba — pero tu bandeja de entrada sigue vacía. Antes de revisar políticas de acceso o configuraciones de red, la causa más frecuente es la más simple: el enlace de confirmación de suscripción nunca fue cliqueado. SNS no entrega ningún mensaje a una suscripción de email que permanezca en estado PendingConfirmation.

TL;DR: Diagnóstico Rápido de Alertas SNS por Email

SíntomaCausa más probableAcción inmediata
No llega ningún email tras publicarSuscripción sin confirmarVerificar estado con aws sns list-subscriptions-by-topic
El email de confirmación no llegóFiltro de spam o dirección incorrectaRevisar spam; re-suscribir con dirección correcta
Suscripción confirmada pero sin mensajesPolítica de acceso al tema restrictivaRevisar política del tema con aws sns get-topic-attributes
Mensajes publicados pero no entregadosFiltro de suscripción activoVerificar FilterPolicy en los atributos de suscripción

Cómo Funciona la Suscripción de Email en SNS

SNS utiliza un modelo de publicación/suscripción donde los mensajes publicados en un tema se entregan a todos los suscriptores confirmados. Para el protocolo email, el flujo tiene una etapa de confirmación obligatoria que muchos omiten al configurar alertas por primera vez.

graph TD A["aws sns subscribe"] --> B["Suscripción creada
Estado: PendingConfirmation"] B --> C["SNS envía email
con enlace de confirmación"] C --> D{"¿Usuario hizo clic
en el enlace?"} D -- No --> E["Estado permanece:
PendingConfirmation"] D -- Sí --> F["Estado: Confirmed"] E --> G["SNS NO entrega mensajes"] F --> H["SNS entrega mensajes
al publicar en el tema"] style E fill:#ff6b6b,color:#fff style G fill:#ff6b6b,color:#fff style F fill:#51cf66,color:#fff style H fill:#51cf66,color:#fff
  1. Creación de suscripción: Al ejecutar aws sns subscribe, SNS registra la suscripción en estado PendingConfirmation y envía un email con un enlace único de confirmación.
  2. Ventana de confirmación: El enlace de confirmación tiene una validez limitada. Si no se confirma a tiempo, la suscripción expira y debe recrearse.
  3. Estado Confirmed: Solo tras hacer clic en el enlace, la suscripción pasa a Confirmed y SNS comienza a entregar mensajes.
  4. Entrega de mensajes: Cada publicación al tema genera un intento de entrega a todos los suscriptores confirmados. SNS reintenta en caso de fallo transitorio según su política de reintentos para email.

Paso 1: Verificar el Estado de la Suscripción de Email en SNS

El primer diagnóstico siempre es confirmar el estado real de la suscripción. Una suscripción en PendingConfirmation es funcionalmente invisible para el sistema de entrega — SNS no le enviará nada hasta que esté confirmada. Este paso descarta el 80% de los casos antes de ir más lejos.

aws sns list-subscriptions-by-topic \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MisAlertas \
  --query 'Subscriptions[?Protocol==`email`].{Endpoint:Endpoint,Estado:SubscriptionArn}' \
  --output table

Si el campo SubscriptionArn muestra PendingConfirmation en lugar de un ARN real, la suscripción no está activa. Revisa la bandeja de spam del correo destino. Si el email de confirmación no aparece, elimina la suscripción pendiente y vuelve a crearla.

Paso 2: Re-suscribir y Confirmar Correctamente

Si la suscripción está pendiente o el enlace expiró, el camino más limpio es eliminarla y crearla de nuevo. No hay forma de reenviar el email de confirmación original desde la CLI — hay que generar una nueva suscripción.

# Eliminar la suscripción pendiente (requiere el ARN completo si ya fue asignado,
# o simplemente crear una nueva si aún muestra PendingConfirmation)
aws sns unsubscribe \
  --subscription-arn arn:aws:sns:us-east-1:123456789012:MisAlertas:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

# Crear nueva suscripción
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MisAlertas \
  --protocol email \
  --notification-endpoint tu-email@ejemplo.com

Tras ejecutar el segundo comando, revisa el correo destino en los próximos minutos. El asunto del email de confirmación es 'AWS Notification - Subscription Confirmation'. Haz clic en el enlace 'Confirm subscription' dentro del mensaje.

Paso 3: Confirmar que la Suscripción Quedó Activa

Después de hacer clic en el enlace, verifica que el estado cambió a Confirmed. Este paso cierra el ciclo — si el estado sigue en PendingConfirmation después de haber cliqueado el enlace, puede indicar que el enlace ya había expirado y necesitas repetir el paso anterior.

aws sns list-subscriptions-by-topic \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MisAlertas \
  --query 'Subscriptions[?Protocol==`email`]' \
  --output json

Una suscripción activa mostrará un ARN completo en el campo SubscriptionArn, con el formato arn:aws:sns:us-east-1:123456789012:MisAlertas:xxxxxxxx-....

Paso 4: Revisar la Política de Acceso del Tema SNS

Con la suscripción confirmada, si los mensajes aún no llegan, el siguiente sospechoso es la política de acceso del tema. Una política restrictiva puede bloquear silenciosamente las publicaciones de ciertos servicios o cuentas — no hay error visible en el publicador, simplemente el mensaje no se entrega.

aws sns get-topic-attributes \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MisAlertas \
  --query 'Attributes.Policy' \
  --output text

Examina el campo Policy resultante. Verifica que el principal que publica mensajes (tu cuenta, un servicio como CloudWatch Alarms, u otro servicio AWS) tenga permiso explícito para la acción sns:Publish. Si el tema fue creado con una política por defecto y solo publicas desde la misma cuenta, esto generalmente no es el problema — pero si CloudWatch u otro servicio dispara las alertas, la política debe permitirlo explícitamente.

Ejemplo de política mínima para permitir que CloudWatch publique en el tema:

🔽 Ver política IAM de ejemplo para CloudWatch → SNS 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudWatchPublish",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudwatch.amazonaws.com"
      },
      "Action": "sns:Publish",
      "Resource": "arn:aws:sns:us-east-1:123456789012:MisAlertas"
    }
  ]
}

Paso 5: Verificar el Filtro de Suscripción (FilterPolicy)

Un detalle que pasa desapercibido: si la suscripción tiene un FilterPolicy configurado, SNS solo entregará mensajes cuyo atributo coincida con el filtro. Mensajes publicados sin los atributos correctos son descartados silenciosamente — la suscripción está activa, el mensaje fue publicado, pero el email nunca llega.

aws sns get-subscription-attributes \
  --subscription-arn arn:aws:sns:us-east-1:123456789012:MisAlertas:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Busca el campo FilterPolicy en la respuesta. Si está presente y contiene condiciones, tus mensajes de prueba deben incluir los atributos de mensaje correspondientes para ser entregados. Si no necesitas filtrado, elimina la política de filtro actualizando el atributo a una cadena vacía.

Paso 6: Monitorear Entregas Fallidas con CloudWatch

Una vez que la configuración parece correcta pero todavía hay dudas sobre si los mensajes están siendo entregados, las métricas de SNS en CloudWatch son la fuente de verdad. SNS publica métricas como NumberOfNotificationsDelivered y NumberOfNotificationsFailed bajo el namespace AWS/SNS.

Estas métricas no están disponibles a través de aws sns — deben consultarse desde CloudWatch. La forma más directa desde la CLI es con aws cloudwatch get-metric-statistics:

aws cloudwatch get-metric-statistics \
  --namespace AWS/SNS \
  --metric-name NumberOfNotificationsFailed \
  --dimensions Name=TopicName,Value=MisAlertas \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 3600 \
  --statistics Sum \
  --region us-east-1

Ajusta --start-time y --end-time al intervalo donde publicaste mensajes de prueba. Si NumberOfNotificationsFailed muestra valores mayores a cero, SNS intentó entregar pero falló — en ese punto, habilitar el registro de entrega en CloudWatch Logs para el tema te dará el detalle del error.

Pensar en SNS como un cartero ayuda: el cartero solo entrega cartas a direcciones confirmadas. Si la dirección nunca fue verificada (PendingConfirmation), la carta va a la papelera interna antes de salir del edificio. Las métricas de CloudWatch son el registro del edificio — te dicen cuántas cartas salieron y cuántas rebotaron.

Caso Real: La Suscripción Estaba Confirmada, Pero las Alertas No Llegaban

La suscripción mostraba estado Confirmed, el tema existía, y los mensajes de prueba publicados manualmente desde la consola llegaban sin problema. Pero las alertas de CloudWatch Alarms nunca aparecían en el correo.

El diagnóstico inicial apuntó a un problema de entrega intermitente o a un filtro de suscripción. Ambas hipótesis eran incorrectas.

La causa real: la política del tema SNS había sido modificada para restringir el acceso solo a la cuenta principal, sin incluir el principal de servicio cloudwatch.amazonaws.com. CloudWatch intentaba publicar en el tema, pero la política lo rechazaba silenciosamente — sin error visible en la alarma de CloudWatch, sin métrica de fallo inmediata, sin log.

La verificación llegó al consultar NumberOfNotificationsFailed en CloudWatch para el período de las alarmas disparadas: el contador mostraba exactamente tantos fallos como alarmas habían cambiado de estado. Añadir el permiso sns:Publish para cloudwatch.amazonaws.com en la política del tema resolvió el problema de inmediato.

La lección operacional: cuando la suscripción está confirmada y los mensajes manuales llegan pero las alertas automatizadas no, el problema casi siempre está en los permisos del publicador — no en la suscripción.

Flujo Completo de Diagnóstico de Alertas SNS por Email

graph TD Start["No llegan emails de SNS"] --> S1["Paso 1: Verificar estado
list-subscriptions-by-topic"] S1 --> D1{"¿Estado es
PendingConfirmation?"} D1 -- Sí --> Fix1["Re-suscribir y confirmar
enlace del email"] Fix1 --> S1 D1 -- No --> S2["Paso 2: Verificar política
get-topic-attributes"] S2 --> D2{"¿Publicador tiene
permiso sns:Publish?"} D2 -- No --> Fix2["Añadir permiso en
política del tema"] Fix2 --> S2 D2 -- Sí --> S3["Paso 3: Verificar
FilterPolicy"] S3 --> D3{"¿FilterPolicy
activo?"} D3 -- Sí --> Fix3["Ajustar atributos
del mensaje o eliminar filtro"] Fix3 --> S3 D3 -- No --> S4["Paso 4: Consultar métricas
CloudWatch AWS/SNS"] S4 --> D4{"¿NotificationsFailed
> 0?"} D4 -- Sí --> Fix4["Habilitar delivery logs
en CloudWatch Logs"] D4 -- No --> End["Publicar mensaje de prueba
y re-verificar"] style Fix1 fill:#74c0fc,color:#000 style Fix2 fill:#74c0fc,color:#000 style Fix3 fill:#74c0fc,color:#000 style Fix4 fill:#74c0fc,color:#000
  1. Inicio: No se reciben emails tras publicar en el tema SNS.
  2. Verificar estado de suscripción: Si es PendingConfirmation, re-suscribir y confirmar el enlace del email.
  3. Verificar política del tema: Si el publicador es un servicio AWS (CloudWatch, etc.), asegurar que tiene permiso sns:Publish.
  4. Verificar FilterPolicy: Si existe, los mensajes deben incluir los atributos de mensaje correspondientes.
  5. Consultar métricas en CloudWatch: NumberOfNotificationsFailed confirma si SNS intentó entregar y falló.

Permisos IAM Necesarios para Diagnosticar SNS

Para ejecutar todos los comandos de diagnóstico de este artículo, el usuario o rol necesita al menos los siguientes permisos:

🔽 Ver política IAM mínima para diagnóstico SNS 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DiagnosticoSNS",
      "Effect": "Allow",
      "Action": [
        "sns:ListSubscriptionsByTopic",
        "sns:GetTopicAttributes",
        "sns:GetSubscriptionAttributes",
        "sns:Subscribe",
        "sns:Unsubscribe",
        "sns:Publish"
      ],
      "Resource": "arn:aws:sns:us-east-1:123456789012:MisAlertas"
    },
    {
      "Sid": "MetricasCloudWatch",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics"
      ],
      "Resource": "*"
    }
  ]
}

Nota: cloudwatch:GetMetricStatistics requiere "Resource": "*" — no admite restricción a nivel de recurso específico según la Service Authorization Reference de AWS.

Próximos Pasos y Recursos para Alertas SNS por Email

Si después de seguir estos pasos los emails siguen sin llegar, el siguiente nivel de diagnóstico es habilitar el registro de estado de entrega de SNS hacia CloudWatch Logs — esto captura el detalle de cada intento de entrega fallido con el código de error específico. La documentación oficial de AWS sobre atributos de temas SNS y la guía de notificaciones por email cubren la configuración de logging de entrega en detalle.

Glosario de Términos Clave

TérminoDefinición
PendingConfirmationEstado de una suscripción SNS que aún no ha sido confirmada mediante el enlace enviado al endpoint. SNS no entrega mensajes a suscripciones en este estado.
FilterPolicyAtributo de suscripción SNS que define condiciones sobre los atributos de mensaje. Solo los mensajes que coincidan con el filtro son entregados al suscriptor.
Política de acceso del temaPolítica basada en recursos adjunta al tema SNS que controla qué principales (usuarios, roles, servicios) pueden publicar o suscribirse.
NumberOfNotificationsFailedMétrica de CloudWatch bajo el namespace AWS/SNS que cuenta los intentos de entrega fallidos para un tema.
Principal de servicioIdentificador de un servicio AWS (ej: cloudwatch.amazonaws.com) usado en políticas IAM para otorgar permisos a servicios que actúan de forma autónoma.

Related Posts

Comentarios

Publicar un comentario

Entradas populares de este blog

EC2 sin acceso a Internet en VPC personalizada: Internet Gateway y Route Table

Creaste una VPC personalizada, lanzaste una instancia EC2 en una subred pública y no puedes hacer ping a google.com — ni SSH funciona desde fuera. Este es uno de los problemas más frecuentes al trabajar con redes en AWS, y casi siempre se reduce a tres capas que deben estar alineadas: el Internet Gateway, la Route Table y la configuración de IP pública. Si falla cualquiera de las tres, el tráfico no sale. TL;DR — Acceso a Internet en EC2 dentro de VPC personalizada Capa Qué debe estar configurado Error típico Internet Gateway Creado y adjunto a la VPC IGW existe pero no está adjunto Route Table Ruta 0.0.0.0/0 apuntando al IGW Route Table sin ruta de salida Subred pública Asociada a la Route Table correcta Subred usa la Route Table principal sin IGW IP pública Auto-assign habilitado o EIP asignado Instancia sin IP pública Security Group Regla de salida 0.0.0.0/0 permitida Egress bloqueado por SG restr...
Leer más

Actualizar Contenido en CloudFront: Cómo Crear una Invalidación para Limpiar el Caché del Edge

Reemplazaste un archivo en S3, recargaste el navegador, y CloudFront sigue sirviendo la versión antigua. Es uno de esos momentos donde sabes exactamente qué pasó, pero necesitas la solución correcta ahora mismo — sin esperar que el TTL expire solo. Este artículo explica cómo funciona el caché de CloudFront y cómo crear una invalidación de CloudFront para forzar la purga inmediata del edge. TL;DR — Invalidación de CloudFront en 30 Segundos Situación Acción Archivo actualizado en S3, CloudFront sirve versión vieja Crear invalidación con la ruta del archivo Múltiples archivos actualizados Usar wildcard /* o listar rutas específicas Quieres evitar invalidaciones frecuentes Usar versionado de archivos en el nombre (cache busting) Herramienta Consola AWS, CLI ( aws cloudfront create-invalidation ), o SDK Cómo Funciona el Caché de CloudFront CloudFront opera como una red de puntos de presencia distribui...
Leer más

Aumentar el Timeout de Lambda: Configuración, Límites y Diagnóstico en Producción

Tu función Lambda se detiene a los 3 segundos, pero el proceso que ejecuta necesita 10. No es un bug en tu código — es el timeout por defecto de Lambda actuando exactamente como fue diseñado. El problema es que ese valor predeterminado de 3 segundos sorprende a casi todos la primera vez, especialmente cuando la función funciona perfectamente en local pero falla en producción con un error Task timed out after 3.00 seconds . TL;DR — Aumentar el Timeout de Lambda Aspecto Detalle Timeout por defecto 3 segundos Timeout máximo 15 minutos (900 segundos) Dónde configurarlo Consola AWS, CLI, CloudFormation, SAM, Terraform Error observable Task timed out after X.XX seconds Coste asociado Mayor timeout = mayor ventana de facturación potencial Alternativa para tareas largas AWS Step Functions o procesamiento asíncrono Cómo Funciona el Timeout en AWS Lambda Lambda ejecuta tu función dentro de un entor...
Leer más