SNS vs SQS vs Kinesis : arrêtez de deviner, commencez à choisir

SNS vs SQS vs Kinesis : arrêtez de deviner, commencez à choisir

Soyons honnêtes. La première fois que j’ai dû choisir entre SNS et SQS, je suis resté scotché devant la console AWS pendant 40 minutes, j’avais ouvert sept onglets, et je doutais encore. C’était il y a des années. Aujourd’hui, AWS propose six services de livraison d’événements. Oui, six. De quoi déstabiliser même les architects les plus confirmés.

Mais en vrai, c’est simple. Arrêtez de penser aux services et commencez à penser à la *forme* de vos données. Vous avez besoin d’un push ou d’un pull ? De rejouer des événements ? D’un fan-out ? D’un routage basé sur le contenu ? Voilà les vraies questions.

Je vous explique tout avec la méthode que j’aurais adoré avoir à l’époque.

Les candidats (un guide court et plein d’opinions)

SNS — Le mégaphone

SNS (Simple Notification Service, https://aws.amazon.com/sns/) est un service pub/sub de type push. Vous publiez un message, et SNS le pousse immédiatement à tous ses abonnés : fonctions Lambda, files SQS, endpoints HTTP, e-mails, push mobile. C’est du fire-and-forget par conception : SNS ne garde pas les messages et ne réessaie presque rien. Si personne n’écoute, le message est perdu.

**À utiliser quand :** un seul événement doit déclencher plusieurs actions en même temps.

SQS — La file fiable

SQS (https://aws.amazon.com/sqs/) est une file en mode pull. Les producteurs déposent des messages, les consommateurs viennent les chercher à leur rythme. Ce n’est pas du pub/sub, c’est du point-à-point. Les messages vivent jusqu’à 14 jours, et les files FIFO garantissent un ordre strict et un traitement exactly-once.

**À utiliser quand :** vous voulez découpler un producteur et un consommateur, avec de la fiabilité et sans routage compliqué.

Kinesis — La bande magnétique à remonter le temps

Kinesis (https://aws.amazon.com/kinesis/) est une plateforme de streaming de données. Contrairement à SQS, où un message est consommé puis supprimé, Kinesis permet à plusieurs consommateurs de lire le même flux indépendamment et de rejouer les données jusqu’à 365 jours. L’ordre est solide par shard, et le débit est énorme.

**À utiliser quand :** vous avez un gros volume de données en streaming et vous avez besoin de rejouer.

MSK — Kafka sans le mal de tête (enfin, moins)

MSK (Managed Streaming for Apache Kafka, https://aws.amazon.com/msk/) est du Kafka managé. Vous avez tout l’écosystème Kafka : topics, partitions, consumer groups, Kafka Connect, ksqlDB — sans construire le cluster vous-même. Mais vous restez responsable du dimensionnement des brokers, du tuning et des mises à jour des OS.

**À utiliser quand :** vous savez déjà utiliser Kafka, vous avez besoin de Kafka Connect, ou vous migrez une installation Kafka existante.

EventBridge — Le routeur intelligent

EventBridge (https://aws.amazon.com/eventbridge/) est le petit nouveau qui a vite grandi. C’est un bus d’événements avec un filtrage et un routage puissants basés sur le contenu. On ne se contente pas de publier et de prier : on peut filtrer, transformer et router des événements vers différentes cibles selon ce qu’ils contiennent. En bonus, il gère les événements planifiés (un cron intégré) et s’intègre nativement avec plus de 140 services AWS.

**À utiliser quand :** la logique de routage dépend du contenu de l’événement, ou si vous construisez une vraie architecture événementielle.

RabbitMQ — Le vétéran éprouvé

RabbitMQ (https://www.rabbitmq.com/) est le broker open-source qui a plus de dix ans. Il supporte plusieurs protocoles (AMQP, MQTT, STOMP), offre un routage flexible avec des exchanges et des bindings, et tourne n’importe où. Sur AWS, on le fait typiquement tourner sur EC2 (https://aws.amazon.com/ec2/) ou via un service managé tiers.

**À utiliser quand :** vous avez besoin de motifs de routage complexes comme des topic exchanges avec wildcards, ou du multi-protocole.

La matrice de décision (votre aide-mémoire)

Arrêtez de comparer les tableaux de fonctionnalités. Posez-vous plutôt ces six questions :

| Question | Meilleur choix |
|---|---|
| Découplage one-to-one ? | SQS |
| Fan-out one-to-many ? | SNS ou EventBridge |
| Plusieurs consommateurs indépendants ? | Kinesis |
| Déjà Kafka-literate ou besoin de l’écosystème Kafka ? | MSK |
| Routage basé sur le contenu du message ? | EventBridge |
| Routage complexe ou existant + plusieurs protocoles ? | RabbitMQ |

Ma philosophie : **par défaut, utilisez les services natifs AWS, sauf si vous avez une bonne raison de ne pas le faire.** Gérer son propre broker, c’est de la charge opérationnelle dont personne n’a besoin en 2026.

Scénarios concrets

Scénario 1 : pipeline de commandes e-commerce

Vous tenez une boutique en ligne. Quand une commande est passée, il faut envoyer un e-mail de confirmation, mettre à jour le stock, déclencher la livraison et notifier l’équipe anti-fraude.

Fan-out classique. Mon choix : **SNS ou EventBridge**. Publiez un événement « order.placed », et SNS le pousse en même temps vers une Lambda d’e-mail, une file SQS pour le stock et un service de livraison. Mais si vous voulez filtrer — par exemple ne notifier l’anti-fraude que pour les commandes de plus de 100 € —, les règles basées sur le contenu d’EventBridge sont imbattables. Vos consommateurs restent simples, ils ne reçoivent que ce qu’ils doivent recevoir.

Scénario 2 : analyse de flux de clics

Votre plateforme reçoit des millions de clics par heure. Trois équipes — analytics, ML et sécurité — doivent consommer ces données indépendamment. Et chaque équipe veut pouvoir rejouer au moins une semaine de données.

C’est du **Kinesis**. Avec SQS, si un consommateur lit un message, il disparaît pour tout le monde. Avec Kinesis Data Streams, trois consommateurs indépendants peuvent lire le même flux en parallèle, chacun à son rythme. Si votre équipe analytics parle déjà Kafka, MSK est une alternative crédible. Mais Kinesis demande moins de soins opérationnels.

Scénario 3 : système legacy avec routage complexe

Vous modernisez un vieux système de point de vente qui utilise RabbitMQ avec des topic exchanges du genre `order.created.retail` et `warehouse.stock.low`. Des centaines de routing keys sont branchées sur des services backend.

Porter cette logique sur SNS serait un carnage : SNS ne supporte que du filtrage basique, pas des motifs complexes. **RabbitMQ** ou **EventBridge** peuvent faire le travail. EventBridge offre une intégration native AWS et un schema registry, mais rebrancher toutes ces règles de routage prend du temps. Garder RabbitMQ demande moins d’effort de migration, mais vous laisse gérer des instances EC2 pendant des années. Moi, je choisirais EventBridge si l’équipe a la capacité ; sinon, je garde RabbitMQ et je concentre mon énergie sur des problèmes plus importants.

Conseils pratiques du terrain

1. **Commencez par SQS + Lambda.** C’est le motif asynchrone le plus simple sur AWS. Ça couvre 90 % des besoins de découplage backend. Ajoutez SNS quand vous avez besoin de fan-out, EventBridge quand vous avez besoin de routage intelligent.

2. **Pensez au replay dès le premier jour.** La vraie question n’est pas « est-ce que mon service peut gérer un message en échec ? » mais « est-ce que mon service peut relire deux fois le même message ? » Kinesis et MSK rendent le replay naturel. SQS FIFO donne du exactly-once mais limite le débit.

3. **Respectez les durées de rétention.** SNS ne garde rien. SQS plafonne à 14 jours. Kinesis peut aller jusqu’à 365 jours avec la rétention étendue. MSK est à 7 jours par défaut, avec possibilité d’augmenter. Si vous avez besoin de pistes d’audit ou de retraitement, choisissez en conséquence.

4. **Utilisez le long polling sur SQS.** Ça accumule jusqu’à 20 secondes de messages au lieu de poller sans cesse des files vides. Ce seul réglage peut réduire votre facture SQS de 90 %.

5. **Évitez l’usine à gaz.** J’ai déjà vu une Lambda déclencher un topic SNS, qui publie dans une file SQS, qui pousse vers une autre Lambda, qui envoie dans Kinesis — pour un simple upload de fichier. Chaque étape ajoute de la latence et un nouveau mode de panne. Ce n’est pas parce que vous *pouvez* tout chaîner que vous *devez* le faire.

FAQ

Peut-on utiliser SNS et SQS ensemble ?
Absolument — et c’est l’un des motifs les plus puissants sur AWS. SNS fait un fan-out vers plusieurs files SQS, et chaque file est traitée indépendamment par des services différents. On combine la force de diffusion de SNS avec la fiabilité, la rétention et les nouvelles tentatives de SQS. C’est le motif derrière la plupart des architectures événementielles sérieuses sur AWS.

Est-ce qu’EventBridge remplace SNS ?
Pas complètement, mais ça s’en rapproche. EventBridge fait tout ce que fait SNS — pub/sub, fan-out — plus le filtrage par contenu, la découverte de schémas et une intégration AWS profonde. Pour les nouveaux projets, je pars sur EventBridge par défaut. Mais si vous avez juste un besoin simple de push vers une Lambda, SNS reste plus simple à comprendre et à opérer.

Quand choisir MSK plutôt que Kinesis ?
Choisissez MSK si votre équipe connaît déjà Kafka, si vous avez besoin de Kafka Connect ou ksqlDB, ou si vous migrez une infrastructure Kafka existante. Kinesis gagne quand vous partez de zéro, que vous voulez moins de charge opérationnelle et que l’écosystème Kafka ne vous manque pas.

RabbitMQ est-il mort dans le monde AWS ?
Non, mais c’est devenu un produit de niche. Il brille pour les logiques de routage complexes et le support multi-protocoles. Beaucoup d’entreprises font encore tourner RabbitMQ en production. Mais si vous construisez du neuf sur AWS, je préférerais clairement EventBridge ou Kinesis. Faites la migration une fois, et remerciez-vous plus tard.

Dernières réflexions

Le « meilleur » service de messagerie n’est pas celui qui a le plus de fonctionnalités. C’est celui qui correspond à la forme de votre problème. SQS pour un simple découplage. SNS pour le fan-out. Kinesis pour le streaming avec replay. MSK pour du Kafka à grande échelle. EventBridge pour le routage intelligent. RabbitMQ pour la complexité à l’ancienne.

Vous avez maintenant une matrice de décision mentale qui m’aurait économisé 40 minutes et sept onglets à l’époque. Allez construire des trucs.