Distribuir notificaciones con SNS y SQS

Introducción

El equipo de preparación de pedidos necesita todas las notificaciones de pedidos, mientras el de análisis solo necesita los pedidos nuevos. Publicarás una vez para dos colas, configurarás sus permisos de entrega y filtrarás las notificaciones de análisis.

Completa primero Enviar y consumir trabajos con SQS y Proteger un bucket con una política de recursos. Esta VM independiente proporciona una CLI configurada y datos de referencia ajenos al trabajo. Las colas son destinos de notificaciones; esta unidad no necesita un consumidor Lambda.

Relación con las certificaciones

Este laboratorio ofrece práctica para los siguientes temas de examen.

Cloud Practitioner (CLF-C02) · Tarea 3.8: Distribución SNS, filtros de suscripción y permisos de entrega.
Solutions Architect – Associate (SAA-C03) · Tarea 2.1: Distribución SNS, filtros de suscripción y permisos de entrega.
Developer – Associate (DVA-C02) · Tarea 1.1: Distribución SNS, filtros de suscripción y permisos de entrega.
DevOps Engineer – Professional (DOP-C02) · Tarea 5.1: Práctica de fundamentos: Distribución SNS, filtros de suscripción y permisos de entrega.
Solutions Architect – Professional (SAP-C02) · Tarea 2.4: Práctica de fundamentos: Distribución SNS, filtros de suscripción y permisos de entrega.

Crear el tema y conceder la entrega a las colas

En este paso, crea un tema y dos colas vacías con permiso para que solo ese tema entregue mensajes.

Amazon Simple Notification Service (SNS) distribuye una publicación a través de las suscripciones de un tema. Usa AWS View junto a Terminal para comparar las conexiones del tema, los cuerpos de cola y los filtros; conserva los datos de referencia.

cd /home/labex/project

Crea el tema SNS del productor. La sustitución de comandos, $(...), guarda el ARN devuelto en una variable de shell para los siguientes comandos:

TOPIC_ARN=$(aws sns create-topic --name labex-q04-orders --query TopicArn --output text)

Crea destinos independientes y guarda sus URL de cola:

FULFILLMENT_URL=$(aws sqs create-queue --queue-name labex-q04-fulfillment --query QueueUrl --output text)
ANALYTICS_URL=$(aws sqs create-queue --queue-name labex-q04-analytics --query QueueUrl --output text)

Las suscripciones usan los ARN de cola como destinos. Selecciona ambos identificadores:

FULFILLMENT_ARN=$(aws sqs get-queue-attributes --queue-url "$FULFILLMENT_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
ANALYTICS_ARN=$(aws sqs get-queue-attributes --queue-url "$ANALYTICS_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)

Una política de cola concede al servicio SNS sqs:SendMessage sobre esta cola exacta, con aws:SourceArn limitado a tu tema. La configuración de una suscripción por sí sola no concede permiso de entrega. Escribe una política JSON ordinaria por cola; el shell inserta las variables de ARN:

cat > fulfillment-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "sns.amazonaws.com"},
    "Action": "sqs:SendMessage",
    "Resource": "$FULFILLMENT_ARN",
    "Condition": {"ArnEquals": {"aws:SourceArn": "$TOPIC_ARN"}}
  }]
}
EOF
cat > analytics-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "sns.amazonaws.com"},
    "Action": "sqs:SendMessage",
    "Resource": "$ANALYTICS_ARN",
    "Condition": {"ArnEquals": {"aws:SourceArn": "$TOPIC_ARN"}}
  }]
}
EOF

El atributo SQS Policy contiene una cadena JSON. --rawfile lee un archivo de política en esa cadena y después CLI aplica el archivo ordinario de atributos:

jq -n --rawfile policy fulfillment-policy.json '{Policy:$policy}' > fulfillment-attributes.json
jq -n --rawfile policy analytics-policy.json '{Policy:$policy}' > analytics-attributes.json
aws sqs set-queue-attributes --queue-url "$FULFILLMENT_URL" --attributes file://fulfillment-attributes.json
aws sqs set-queue-attributes --queue-url "$ANALYTICS_URL" --attributes file://analytics-attributes.json

Lee los permisos configurados:

aws sqs get-queue-attributes --queue-url "$FULFILLMENT_URL" --attribute-names QueueArn Policy
aws sqs get-queue-attributes --queue-url "$ANALYTICS_URL" --attribute-names QueueArn Policy

Ambas políticas indican su propia cola y el mismo tema de pedidos. AWS View muestra un tema, dos colas vacías y ninguna suscripción todavía.

Suscribir ambas colas y filtrar las notificaciones de análisis

En este paso, conecta cada cola al tema y elige qué notificaciones recibe el equipo de análisis.

distribución SNS y filtro de suscripción

La suscripción de análisis selecciona el atributo de mensaje kind=created; cada cola recibe su propia copia.

Una suscripción conecta un protocolo y un endpoint a un tema SNS. Para sqs, el endpoint es el ARN de la cola. Guarda los ARN de suscripción para poder configurar y después eliminar cada conexión:

FULFILLMENT_SUB=$(aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$FULFILLMENT_ARN" --query SubscriptionArn --output text)
ANALYTICS_SUB=$(aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$ANALYTICS_ARN" --query SubscriptionArn --output text)

Una política de filtro selecciona notificaciones para una suscripción. El alcance de filtro predeterminado son los atributos de mensaje. La suscripción de análisis solo acepta un atributo String kind con el valor created; la de preparación de pedidos no tiene filtro:

aws sns set-subscription-attributes --subscription-arn "$ANALYTICS_SUB" --attribute-name FilterPolicy --attribute-value '{"kind":["created"]}'

Inspecciona ambas suscripciones y los atributos de análisis:

aws sns list-subscriptions-by-topic --topic-arn "$TOPIC_ARN"
aws sns get-subscription-attributes --subscription-arn "$ANALYTICS_SUB"

Espera dos endpoints SQS y el filtro de análisis. La entrega de mensajes sin procesar está desactivada de forma predeterminada, por lo que los cuerpos de cola contendrán un envoltorio de notificación SNS con el tema, el ID de mensaje, la cadena del mensaje original y los atributos. Las colas permanecen vacías hasta la publicación.

Demostrar la distribución, el filtrado y el límite de entrega

En este paso, publica dos notificaciones e inspecciona las entregas independientes reales.

Publica un evento de creación. El mensaje JSON es la carga útil de negocio; el atributo String separado es lo que evalúa este filtro de suscripción:

aws sns publish --topic-arn "$TOPIC_ARN" --message '{"id":"fanout-order","kind":"created"}' --message-attributes '{"kind":{"DataType":"String","StringValue":"created"}}'

Publica un evento de actualización con el mismo ID de pedido:

aws sns publish --topic-arn "$TOPIC_ARN" --message '{"id":"fanout-order","kind":"updated"}' --message-attributes '{"kind":{"DataType":"String","StringValue":"updated"}}'

Observa AWS View: la cola de preparación de pedidos tiene dos notificaciones y la de análisis solo la notificación de creación. Comprueba los recuentos:

aws sqs get-queue-attributes --queue-url "$FULFILLMENT_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
aws sqs get-queue-attributes --queue-url "$ANALYTICS_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

Recibe los mensajes para inspeccionarlos con visibilidad cero. Esto libera inmediatamente estos mensajes sintéticos para la limpieza posterior en lugar de mantenerlos en curso. El ejemplo demuestra copias independientes, no procesamiento ni confirmación. fromjson lee cada cadena de envoltorio y la selección final de campos muestra los campos de notificación usados aquí:

aws sqs receive-message \
  --queue-url "$FULFILLMENT_URL" \
  --max-number-of-messages 10 \
  --visibility-timeout 0 \
  --output json | jq '[.Messages[].Body | fromjson | {Type, TopicArn, MessageId, Message, MessageAttributes}]'
aws sqs receive-message \
  --queue-url "$ANALYTICS_URL" \
  --max-number-of-messages 10 \
  --visibility-timeout 0 \
  --output json | jq '[.Messages[].Body | fromjson | {Type, TopicArn, MessageId, Message, MessageAttributes}]'

El cuerpo es un envoltorio SNS: Type es Notification, TopicArn es tu tema y Message contiene la cadena JSON original. La notificación de creación tiene el mismo MessageId SNS en ambas colas; cada cola contiene su propio mensaje SQS. La cola de preparación de pedidos también contiene el evento de actualización, que la de análisis excluyó con el filtro. Los consumidores independientes pueden confirmar sus copias por separado.

Ahora comprueba por qué importa el permiso del tema. Establece temporalmente el aws:SourceArn de la cola de preparación de pedidos en el ARN de un tema sintético ajeno al trabajo:

jq --arg wrong 'arn:aws:sns:us-east-1:123456789012:labex-q04-unrelated' '.Statement[0].Condition.ArnEquals["aws:SourceArn"]=$wrong' fulfillment-policy.json > wrong-source-policy.json
jq -n --rawfile policy wrong-source-policy.json '{Policy:$policy}' > wrong-source-attributes.json
aws sqs set-queue-attributes --queue-url "$FULFILLMENT_URL" --attributes file://wrong-source-attributes.json

Publica una notificación de actualización para otro pedido sintético. SNS acepta la publicación, pero la cola de preparación de pedidos ya no está autorizada para este tema; la de análisis filtra el atributo de actualización:

aws sns publish --topic-arn "$TOPIC_ARN" --message '{"id":"blocked-order","kind":"updated"}' --message-attributes '{"kind":{"DataType":"String","StringValue":"updated"}}'

Comprueba que los recuentos de cola siguen siendo dos y uno, sin ningún envoltorio de blocked-order en AWS View:

aws sqs get-queue-attributes --queue-url "$FULFILLMENT_URL" --attribute-names ApproximateNumberOfMessages
aws sqs get-queue-attributes --queue-url "$ANALYTICS_URL" --attribute-names ApproximateNumberOfMessages

Una respuesta de publicación correcta demuestra que SNS aceptó la notificación; la entrega al destino necesita su propia evidencia. Restablece la política original exacta antes de la comprobación del paso:

aws sqs set-queue-attributes --queue-url "$FULFILLMENT_URL" --attributes file://fulfillment-attributes.json

Este entorno de trabajo comprueba la entrega inmediata a colas de la misma cuenta y los filtros de atributos String. Los cambios de filtros SNS en producción pueden tardar hasta 15 minutos en propagarse y las entregas fallidas tienen un comportamiento de reintento del servicio; este breve experimento de permisos no es un modelo de reintentos de producción.

Ejemplo de AWS View: la cola de preparación de pedidos contiene notificaciones de creación y actualización; la de análisis solo contiene la notificación de creación con el mismo ID de mensaje SNS.

Eliminar conexiones y notificaciones desechables

En este paso, elimina ambas suscripciones, el tema y las colas, conservando los datos de referencia ajenos al trabajo.

Cancela primero la suscripción de ambos endpoints:

aws sns unsubscribe --subscription-arn "$FULFILLMENT_SUB"
aws sns unsubscribe --subscription-arn "$ANALYTICS_SUB"

Elimina el tema y las colas. La eliminación de las colas descarta las notificaciones sintéticas; no se afirmó que se hubiera realizado procesamiento de negocio con ellas:

aws sns delete-topic --topic-arn "$TOPIC_ARN"
aws sqs delete-queue --queue-url "$FULFILLMENT_URL"
aws sqs delete-queue --queue-url "$ANALYTICS_URL"

Demuestra la limpieza mediante consultas nativas correctas:

aws sns list-topics
aws sns list-subscriptions
aws sqs list-queues
aws dynamodb scan --table-name labex-q04-reference --query Items

Las listas de temas y suscripciones están vacías, las URL de cola están ausentes y el elemento de referencia todavía indica keep unchanged. Los fallos de autenticación o de red no demuestran la eliminación. AWS View muestra los mismos recursos vacíos.

Elimina tus archivos ordinarios de configuración:

rm -f fulfillment-policy.json analytics-policy.json fulfillment-attributes.json analytics-attributes.json wrong-source-policy.json wrong-source-attributes.json

Ejecuta la comprobación de limpieza antes de finalizar el entorno.

Resumen

Conectaste un tema SNS a dos colas SQS independientes, limitaste la entrega a un tema de origen exacto y filtraste las notificaciones de análisis usando un atributo de mensaje. Los envoltorios reales de notificación demostraron el evento publicado compartido y las copias separadas en las colas. También diferenciaste la aceptación de una publicación por SNS de su entrega a los destinos y después eliminaste tus recursos, conservando los datos de referencia.

Los consumidores de cola todavía necesitan gestionar entregas repetidas. La siguiente unidad aplica una condición atómica de DynamoDB para evitar que los trabajos repetidos produzcan efectos de negocio duplicados.