SNS et SQS : pub/sub et files

À la fin de ce tutoriel, vous créerez un topic SNS, une file SQS, une souscription SNS→SQS, publierez un message et le consommerez — pattern de découplage classique en ca-central-1.

Niveau : Intermédiaire · Temps estimé : 50–60 min · Versions testées : SNS/SQS 2026, AWS CLI v2 · Dernière vérification : 2026-09-10 · Region : ca-central-1

← Précédent : DynamoDB · → Suivant : CloudWatch · Hub : Démarrer avec AWS

Prérequis

• Profil lab
• Notions IAM (policies de souscription)

Coût estimé : négligeable à bas volume. Supprimez topic et files immédiatement après le lab pour éviter tout bruit de facturation et de messages orphelins.

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

Ce que nous allons construire

Publisher ──publish──► SNS topic lab-events
                           │ subscribe
                           ▼
                      SQS queue lab-events-q
                           │ receive/delete
                           ▼
                      Consumer (CLI)

(Schéma — alt : « SNS fan-out vers SQS ».)

Étape 1 — SNS vs SQS (examen)

	SNS	SQS
Modèle	Pub/Sub (push)	File (pull)
Destinataires	Multi (email, Lambda, SQS, HTTP…)	Un consumer à la fois par message (approx.)
Rétention	Non (délivre ou échoue)	Jusqu’à 14 jours
Fan-out	Native	Via SNS→plusieurs queues

Combo gagnant : SNS pour diffuser, SQS pour bufferiser chaque worker.

Étape 2 — Créer la file SQS

QUEUE_URL=$(aws sqs create-queue --queue-name lab-events-q 
  --attributes VisibilityTimeout=30,MessageRetentionPeriod=86400 
  --query QueueUrl --output text)

QUEUE_ARN=$(aws sqs get-queue-attributes --queue-url "$QUEUE_URL" 
  --attribute-names QueueArn --query 'Attributes.QueueArn' --output text)

echo "$QUEUE_URL"
echo "$QUEUE_ARN"

Visibility timeout : pendant ce délai, un message reçu est invisible aux autres consumers — le temps de le traiter avant DeleteMessage.

Règle pratique : visibility ≥ durée max de traitement (souvent timeout Lambda + marge). Trop court = doublons ; trop long = latence de retry après crash. Vous pouvez aussi changer le timeout par message (ChangeMessageVisibility) pendant un traitement long.

Étape 3 — Créer le topic SNS

TOPIC_ARN=$(aws sns create-topic --name lab-events 
  --query TopicArn --output text)
echo "$TOPIC_ARN"

Étape 4 — Autoriser SNS à écrire dans SQS

Policy queue (raw) :

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

aws sqs set-queue-attributes --queue-url "$QUEUE_URL" 
  --attributes file:///tmp/sqs-attrs.json

Astuce CLI : Attributes attend un JSON stringifié de la policy. Variante simple :

POLICY=$(jq -c . /tmp/sqs-policy.json)
aws sqs set-queue-attributes --queue-url "$QUEUE_URL" 
  --attributes "{"Policy":"$(echo $POLICY | sed 's/"/\"/g')"}"

Sous PowerShell, construisez le JSON Policy avec échappement adapté, ou utilisez la console pour la 1ʳᵉ fois puis exportez.

Étape 5 — Souscrire SQS au topic

aws sns subscribe 
  --topic-arn "$TOPIC_ARN" 
  --protocol sqs 
  --notification-endpoint "$QUEUE_ARN" 
  --query SubscriptionArn

Option Raw message delivery : évite l’enveloppe SNS JSON (attribut sur la souscription). Pour le lab, le format wrappé suffit.

Étape 6 — Publier et consommer

aws sns publish --topic-arn "$TOPIC_ARN" 
  --subject "lab" 
  --message '{"event":"order_created","id":"1001"}'

aws sqs receive-message --queue-url "$QUEUE_URL" --max-number-of-messages 1 
  --wait-time-seconds 10

Notez ReceiptHandle, puis :

aws sqs delete-message --queue-url "$QUEUE_URL" 
  --receipt-handle "REPLACE"

Sans delete, le message réapparaît après le visibility timeout (retry naturel).

Étape 7 — FIFO vs Standard

	Standard	FIFO (*.fifo)
Ordre	Best effort	Par MessageGroupId
Dédup	Best effort	Exact (id / content)
Throughput	Très élevé	Plus limité (sauf high throughput FIFO)

Noms FIFO : topic et queue doivent finir par .fifo.

Étape 8 — DLQ (dead-letter)

Après N réceptions échouées (maxReceiveCount), SQS peut rediriger vers une DLQ pour analyse. Pattern prod obligatoire pour les consumers Lambda/ASG.

# create lab-events-dlq + redrive policy sur lab-events-q (aperçu)

Lab concret (Standard) — créez la DLQ puis attachez la redrive policy :

DLQ_URL=$(aws sqs create-queue --queue-name lab-events-dlq   --attributes MessageRetentionPeriod=1209600   --query QueueUrl --output text)
DLQ_ARN=$(aws sqs get-queue-attributes --queue-url "$DLQ_URL"   --attribute-names QueueArn --query 'Attributes.QueueArn' --output text)

aws sqs set-queue-attributes --queue-url "$QUEUE_URL"   --attributes "{"RedrivePolicy":"{"deadLetterTargetArn":"$DLQ_ARN","maxReceiveCount":"3"}"}"

Alarmez ApproximateNumberOfMessagesVisible sur la DLQ : un message qui arrive là = bug consumer ou poison pill, pas un succès silencieux.

Étape 9 — Vérification

aws sns list-subscriptions-by-topic --topic-arn "$TOPIC_ARN"
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names All

Checklist : topic + queue · policy SourceArn · subscribe · publish · receive · delete.

Nettoyage

# unsubscribe si besoin
aws sns delete-topic --topic-arn "$TOPIC_ARN"
aws sqs delete-queue --queue-url "$QUEUE_URL"
# si créés en bonus / DLQ :
# aws sqs delete-queue --queue-url "$DLQ_URL"
# aws sqs delete-queue --queue-url "$Q2_URL"

Checklist prod courte

1. SSE (KMS) sur SQS + SNS.
2. DLQ + alarme CloudWatch ApproximateNumberOfMessagesVisible sur DLQ.
3. Idempotence consumer (DynamoDB conditional / dedup store).
4. Least privilege IAM séparée publisher / consumer.
5. Pas de secrets dans le body du message (référence Secrets Manager).

Erreurs fréquentes

Symptôme	Cause	Correction
Subscribe OK mais queue vide	Policy SQS refuse SNS	Condition SourceArn + sqs:SendMessage
Messages en double	At-least-once	Idempotence consumer
ReceiptHandle invalid	Timeout / déjà deleted	Receive à nouveau

Long polling

WaitTimeSeconds > 0 (long polling) réduit les réponses vides et le coût ReceiveMessage. Préférez 10–20 s en lab/prod plutôt que short polling agressif.

Filtrage SNS

Les subscription filter policies laissent chaque queue ne recevoir que certains attributs/payloads (event_type=order). Moins de bruit, moins de coût SQS.

Sécurité

Chiffrement SSE sur SQS (KMS), topics SNS chiffrés, least privilege sns:Publish / sqs:ReceiveMessage. Cross-account subscribe = policies des deux côtés.

Fan-out multi-queues

Un seul topic SNS peut alimenter lab-events-billing-q, lab-events-email-q, etc. Chaque équipe scale son consumer indépendamment — cœur des architectures event-driven AWS (avec EventBridge pour bus plus riches).

EventBridge vs SNS

EventBridge (bus) ajoute schemas, archive/replay, filtrages riches et intégrations SaaS. SNS reste excellent pour fan-out simple mobile/email/SQS. Pour une archi moderne « events » complexe, EventBridge + SQS est fréquent ; ce lab SNS→SQS reste le socle d’examen Associate.

Exactly-once ?

SQS Standard = at-least-once (doublons possibles). FIFO + dédup rapproche l’exactly-once côté file, mais votre consumer doit rester idempotent (clé métier). Ne concevez jamais un débit bancaire « +1 » non idempotent sur Standard.

Remise HTTP/S et Lambda

SNS peut pousser vers HTTPS (retry + DLQ SNS) ou Lambda. Avec SQS, Lambda poll la file (event source mapping) et gère partiellement les batch failures — pattern serverless très demandé.

Delay queue et timer

DelaySeconds (0–900) sur la queue ou à l’envoi diffère la visibilité initiale — utile pour « retry dans 5 min » sans EventBridge. Ne confondez pas avec visibility timeout (post-receive).

Attributs de message et filtrage

Publiez avec --message-attributes (String/Number/Binary). Une filter policy sur la souscription SQS ne laisse passer que event_type=order par ex. : moins de bruit, moins de coût receive. Le body peut rester opaque ; le routage se fait sur les attributs.

Lab bonus (8–10 min) — fan-out 2 queues + filtre

# 2e queue (billing) + policy SourceArn (même topic) + subscribe
Q2_URL=$(aws sqs create-queue --queue-name lab-events-billing-q --query QueueUrl --output text)
Q2_ARN=$(aws sqs get-queue-attributes --queue-url "$Q2_URL"   --attribute-names QueueArn --query 'Attributes.QueueArn' --output text)

# Réappliquez le même modèle de policy SQS (Principal sns, Condition SourceArn)
aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol sqs   --notification-endpoint "$Q2_ARN"

aws sns publish --topic-arn "$TOPIC_ARN"   --message '{"event":"order_created","id":"1002"}'   --message-attributes 'event_type={DataType=String,StringValue=order}'

# receive sur les deux files, puis delete + cleanup Q2 / DLQ
aws sqs receive-message --queue-url "$QUEUE_URL" --wait-time-seconds 5
aws sqs receive-message --queue-url "$Q2_URL" --wait-time-seconds 5

Objectif : voir le même event arriver dans deux buffers indépendants — cœur du fan-out SNS→SQS. En prod, chaque équipe scale son consumer ; une panne billing n’arrête pas l’email.

Scénario examen classique

« Une marketplace publie OrderPlaced ; facturation, email et anti-fraude doivent réagir indépendamment, avec retry et analyse des poison messages. » → SNS topic + 3 queues SQS (une par domaine) + DLQ par queue + consumers idempotents. Pas de chaînage synchrone EC2→EC2. EventBridge si vous avez besoin d’archive/replay et de bus multi-comptes ; SNS→SQS reste le pattern Associate le plus cité pour fan-out + buffer.

Checklist lab anti-facture SNS/SQS

1. Region ca-central-1 partout (profil lab) ; pas de topic orphelin dans une autre Region.
2. Policy SQS avec Condition aws:SourceArn = ARN du topic (évite que n’importe quel SNS du compte écrive).
3. Long polling (WaitTimeSeconds 10–20) ; pas de boucle short poll agressive.
4. DLQ + (idéalement) alarme CloudWatch sur messages visibles DLQ.
5. delete-topic + delete-queue (y compris DLQ / queues bonus) dès la fin — messages restants ne justifient pas de garder la file.

Coût et quotas en une minute

SNS facture surtout les publications et les notifications livrées ; SQS facture les requêtes API (Receive/Delete/…). À bas volume lab = cents. Attention FIFO high-throughput et KMS (appels GenerateDataKey). Surveillez NumberOfMessagesSent vs NumberOfMessagesReceived si un consumer est down : la rétention (ici 1 jour) masque le problème jusqu’à expiration.

Quiz (5 questions)

1. SNS sert surtout à : – A. Stocker 14 jours de messages
– B. Publier vers plusieurs abonnés
– C. Remplacer IAM

2. Après ReceiveMessage, il faut souvent : – A. Rien
– B. DeleteMessage avec le receipt handle
– C. Recréer la queue

3. SNS→SQS permet surtout de : – A. Éviter TCP
– B. Fan-out + buffer durable
– C. Chiffrer EBS

4. Une DLQ SQS sert surtout à : – A. Remplacer CloudTrail
– B. Isoler les messages qui échouent après N receives
– C. Accélérer FIFO

5. SQS Standard garantit : – A. Exactly-once sans effort
– B. At-least-once (idempotence consumer requise)
– C. Ordre strict global

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

Mobile push et SMS

SNS gère aussi push mobile (FCM/APNs) et SMS selon Region — hors scope lab compute, mais utile de le citer pour l’examen « notification utilisateurs ».

Pour aller plus loin

• SNS
• SQS
• Fanout
• DLQ
• Subscription filter policies
• Long polling

Maillage série AWS (P1)

← Précédent	DynamoDB
→ Suivant	CloudWatch alarmes
Aussi	Lambda · EventBridge