Choisissez selon la forme du besoin, pas selon le nom du service : SQS pour une commande point à point qui exige tampon et contre-pression, SNS pour la diffusion push en fan-out, EventBridge pour des événements métier routés sur leur contenu avec archive et rejeu, Kinesis pour des flux ordonnés à fort débit lus par plusieurs consommateurs, chacun à sa position. Aucun des quatre ne remplace les trois autres. Les combiner est normal : une règle EventBridge alimentant une file SQS consommée par Lambda est le motif que nous retenons par défaut.
À quoi servent SQS, SNS, EventBridge et Kinesis ?
SQS est une file : un producteur confie du travail à un consommateur logique unique, avec réessais, visibility timeout et contre-pression via la profondeur de la file. SNS est un diffuseur : un message poussé à tous les abonnés en même temps. EventBridge est un routeur : il confronte le contenu des événements à des règles et le transmet aux cibles choisies. Kinesis est un journal : un flux ordonné et rejouable, découpé en shards.
Poser le choix ainsi clôt la plupart des débats avant qu'ils ne commencent. Une commande à exécuter une seule fois n'est pas un événement à diffuser, et un flux de clics n'est pas une file de travail. Les documentations SNS et EventBridge parlent toutes deux de pub/sub, ce qui explique précisément pourquoi les équipes les confondent.
SQS ou SNS : mettre une commande en file ou annoncer un fait ?
Choisissez SQS quand exactement un consommateur doit traiter chaque message et que la file doit absorber les pics : les consommateurs l'interrogent à leur rythme, les échecs sont réessayés, les messages toxiques finissent en dead-letter queue. Choisissez SNS quand plusieurs abonnés indépendants doivent recevoir le même message immédiatement, en push, sans tampon sur le topic.
Les deux existent en variante FIFO : les files SQS FIFO ordonnent les messages par groupe et les dédupliquent, avec un plafond de débit inférieur aux files standard, et les topics SNS FIFO livrent dans l'ordre vers des files SQS FIFO. En pratique, les deux se combinent : SNS diffuse vers une file par abonné, chaque service garde ainsi son tampon et sa politique de réessai. Le versant file est détaillé dans quand utiliser AWS SQS.
SNS ou EventBridge : quand le routage bat-il le simple fan-out ?
Choisissez EventBridge quand les abonnés s'intéressent à des tranches différentes d'un événement métier : les règles filtrent sur n'importe quel champ du payload, les événements s'archivent et se rejouent, un registre de schémas documente les contrats. Choisissez SNS pour un fan-out à très haut débit ou du push vers des canaux qu'EventBridge n'atteint pas directement, comme le SMS et le push mobile.
Les filter policies SNS portent sur les attributs et, dans certaines limites, sur le corps du message ; les patterns EventBridge portent nativement sur tout l'événement et routent vers un large éventail de cibles AWS et de partenaires SaaS. SNS conserve en général l'avantage en latence et en plafond de débit, la télémétrie y reste donc. Pour les événements métier entre services, une règle EventBridge alimentant SQS puis Lambda combine routage, tampon et réessais dans un seul motif composable.
Quelle combinaison pour vos flux d'événements ? Décrivez votre système : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →Kinesis ou SQS : flux ou file ?
Choisissez Kinesis quand l'ordre par clé compte, quand plusieurs consommateurs doivent lire les mêmes enregistrements indépendamment, ou quand il faut pouvoir rembobiner : les enregistrements restent sur le flux pendant une rétention configurable, jusqu'à un an, et chaque lecteur suit sa propre position. Choisissez SQS quand chaque message est une unité de travail à traiter une fois puis supprimer.
Les modèles de consommation n'ont rien en commun. Les consommateurs SQS se disputent les messages et la suppression est globale : une fois traité, le message disparaît, avec une rétention plafonnée à 14 jours. Les lecteurs Kinesis Data Streams parcourent les shards par itérateurs (ou reçoivent les enregistrements en push via l'enhanced fan-out) : ajouter un consommateur analytique le mois prochain, rejeu de la veille compris, n'exige aucune coordination avec les lecteurs existants.
Ordre, rétention, rejeu : quelles différences réelles ?
Ordre : SQS FIFO et SNS FIFO garantissent l'ordre par groupe de messages, Kinesis le garantit par clé de partition au sein d'un shard, SQS standard, SNS standard et EventBridge ne garantissent aucun ordre. Rejeu : Kinesis nativement par position, EventBridge via ses archives, SQS et SNS jamais, une fois le message livré et supprimé.
La rétention suit la même ligne de partage. SQS conserve les messages non consommés jusqu'à 14 jours, SNS ne conserve rien après les tentatives de livraison, les archives EventBridge retiennent les événements aussi longtemps que configuré, et Kinesis retient de 24 heures à 365 jours. Si un auditeur ou un job de retraitement demande un jour « que s'est-il passé mardi dernier », seuls les archives EventBridge et la rétention Kinesis répondent à peu de frais.
Quels modèles de consommation et quelles formes de coût ?
Les consommateurs SQS interrogent la file, SNS et EventBridge poussent vers leurs cibles, les consommateurs Kinesis tirent via des itérateurs de shard ou s'abonnent au push de l'enhanced fan-out. Le coût suit les mêmes lignes : SQS et SNS facturent à la requête, EventBridge à l'événement publié sur le bus, Kinesis au shard-heure plus données en mode provisionné, ou au gigaoctet à la demande.
Conséquence pratique : une file, un topic ou un bus inactifs ne coûtent presque rien, tandis qu'un flux provisionné inactif continue de facturer à l'heure. Un volume soutenu inverse le tableau : la facturation à la requête croît linéairement avec le nombre de messages, pas la facturation au shard. Vérifiez les formes actuelles sur la page de tarification Kinesis avant d'y engager un gros volume, dans un sens ou dans l'autre.
Le comparatif en sept dimensions
Une question suffit souvent à trancher : qui consomme le message, l'ordre compte-t-il, quelqu'un le rejouera-t-il un jour. Le tableau condense les quatre services selon les sept axes que nous vérifions en premier lors d'une revue de messaging. Lisez d'abord la dernière ligne, puis confirmez que le reste la soutient.
| Dimension | SQS | SNS | EventBridge | Kinesis Data Streams |
|---|---|---|---|---|
| Modèle de livraison | File point à point | Fan-out push (pub/sub) | Routage par règles (bus) | Journal partagé en shards |
| Ordre | FIFO : par groupe de messages | Topics FIFO : par groupe | Aucun | Par clé de partition, par shard |
| Rejeu | Non | Non | Oui, via archive | Oui, par position |
| Filtrage | Aucun (côté consommateur) | Filter policies | Patterns sur tout le contenu | Aucun (côté consommateur) |
| Forme de débit | Quasi illimité (standard) | Fan-out très haut débit | Modéré, borné par quotas | Croît avec le nombre de shards |
| Type de consommateur | Workers en polling | Abonnés en push | Cibles en push | Itérateurs de shard ou push fan-out |
| Quand il gagne | Commandes avec contre-pression et réessais | Diffusion vers de nombreux canaux push | Événements métier routés, archive, cibles SaaS | Flux ordonnés, lecteurs multiples, rejeu |
Check-list de décision
Déroulez ces questions dans l'ordre et arrêtez-vous au premier oui :
- Plusieurs lecteurs des mêmes enregistrements, ordre par clé ou rejeu par position ? Kinesis.
- Événements métier filtrés sur leur contenu, besoin d'archive et de rejeu ? EventBridge.
- Même message poussé vers de nombreux canaux, SMS ou mobile compris ? SNS.
- Un seul consommateur, un travail qui doit survivre aux pics et aux pannes ? SQS.
- Encore un doute ? Partez d'EventBridge routant vers SQS : toutes les options ultérieures restent ouvertes.