AWS recently released a new feature to its venerable SQS service named "Fair Queues." In conversations with engineers about its behaviors, I found some general confusion regarding the various messaging systems in AWS, their functions, and how they differ from one another. In this article, I aim to provide an overview of the different types of AWS messaging services, including some examples you can use to teach others.
For people new to AWS architectures, the myriad of options (SQS, SNS, EventBridge, Kinesis, MSK) for data movement can be overwhelming. I've found it helpful to categorize these in broad terms and then tie them to specific examples of real-world use cases.
The thing all these services have in common is that they move data. They differ in rate, capacity, and destination. They also differ along another axis: how "managed" the service is. I'll indicate this as we go along.
I use the broad classifications "Queues," "Buses," and "Streams." Let's examine each and see where these services fall.
Queues
The term "queue" in computer science is a collection of entities that "can be modified by the addition of entities at one end of the sequence and removal of entities at the other end of the sequence." The term comes from the real-world phenomenon of people lining up for something. Imagine a grocery store and people lining up (or queuing) at a checkout counter. New carts line up at the back, and the cashier processes the carts at the front.
A queue can also be considered a buffer. It can absorb excess capacity (shoppers) that would otherwise overwhelm the limited resource (cashiers). The more cashiers (or the faster each works), the faster we can process the people in the queue. The queue helps to smooth out irregular or bursty workloads.
One of the first managed services offered by AWS was its Simple Queuing Service (SQS) back in 2006. SQS is fully managed and scales transparently as usage changes. Consumers use a pull-based model to access messages and only consume when they have the capacity to do so. Put another way, consumers have to ask, "Do you have any messages for me?" to receive anything.
In 2025, AWS added "fairness" to SQS. Out of the box, the queue processes messages (roughly) in the order ingested. With SQS fair queues, you specify how SQS groups the messages to more evenly distribute processing resources. This can help mitigate noisy-neighbor impacts in multi-tenant queues.
I group a queue with its consumer; it is part of the receiver's architecture, not the sender's.
Consider a queue if you need to slow things down. If you find yourself saying, "I cannot process this event just yet, but I don't want to lose it," reach for a queue.
Buses
There are many types of message buses, and they can include features typically found in queues or streams. Still, I want to focus on what I consider the fundamental characteristics of a message bus: fan-out and receiver agnosticism.
Fan-out refers to the situation where a single input message generates multiple output messages. For example, when I place an OrderReceived message on the bus, many independent listeners will each receive a copy of that message. This is often referred to as "pub-sub," which is short for "Publish/Subscribe." In pub-sub, the publisher should be unaware of the subscriber. It is receiver agnostic.
Receiver agnosticism is a fancy way of saying, "I do not know who may consume this message." In other words, the producer isn't saying, "Send this message to Frank." The producer says, "Send this message to anyone who happens to be listening." I've heard this compared to a radio, where anyone who is tuned in to the broadcast will listen to the show, but if you miss it, it's gone.
AWS unveiled its Simple Notification Service (SNS) in 2010. At the time, it was the only fully managed pub-sub service in the cloud world. As such, it was a pioneer in the space and set the bar (along with SQS) for what a fully managed service should do.
SNS is a push-based model. Subscribers receive messages in real time as they are published. They don't need to ask, "Do you have any messages for me?" Since messages are not persisted (remember the radio analogy?), you often see architectures that wire up an SQS queue as a subscriber to an SNS topic. Then, the consuming service pulls its messages from the SQS queue for processing.
In 2016, AWS released "CloudWatch Events" to enable users to receive notifications about the systems they run on AWS. It included EC2 shutdown and autoscale events, new service creation or deletion events, and many others. AWS chief evangelist Jeff Barr said, "You can think of CloudWatch Events as the central nervous system for your AWS environment. It is wired to every nook and cranny of the supported services, and becomes aware of operational changes as they happen."
By 2019, AWS realized that the system underpinning CloudWatch Events could become a first-class product of its own, and EventBridge was born. Since then, it has received a steady stream of enhancements, making it my preferred service for event-driven architectures.
I group a bus with its producer; it is part of the sender's architecture, not the receiver's.
Streams
At first glance, you may have a difficult time discerning a stream from a queue, and this is understandable. They share many of the same traits, such as ordering and persistence, but they differ primarily in how they are used.
A stream is concerned with data flows, a zoomed-out view of how data moves through a system. The relationships between the data elements are essential to stream analysis. In contrast, a queue is interested in each discrete data message as its own unit, apart from the others.
Think about a highway system in a city. Its operators are interested in things like: "How many cars come by each hour?", "What are the times with the highest rates of traffic?", and "What is the ratio of cars to big-rig trucks per hour?" In this case, we are less concerned with each vehicle (message) and more concerned with traffic (the stream). This stream, if recorded, could be "replayed" to answer new questions at a later time.
AWS launched its managed real-time streaming service, Kinesis, in 2013. It could capture and process gigabytes of data per second from multiple sources. Since then, AWS has offered different variations of Kinesis to focus on different streaming concerns:
- Kinesis Data Streams (the original)
- Kinesis Data Firehose (for moving large volumes of data to a destination)
- Kinesis Data Analytics (for Flink-like analysis of streams)
- Kinesis Video Streams (for capturing/processing video)
Another AWS stream I often encounter is the DynamoDB Stream. Introduced in 2014, it provides a time-ordered sequence of item-level modifications to a DynamoDB table as a stream. I regularly use this as a source to emit events to other services (DynamoDB Stream -> EventBridge). This stream is less configurable (more managed) than Kinesis.
AWS also supports a service named MSK, which stands for Managed Streaming for Apache Kafka. It simplifies the operation of an Apache Kafka cluster, although you are still responsible for instance sizes and EBS storage configuration. They have a more-managed, "serverless" version of MSK that removes some of the configuration, but does not scale to zero (thus, in my opinion, it does not qualify for the title "serverless"). Consider MSK if you are already using Apache Kafka and are seeking a quick operational win.
Architecturally grouping streams is not as clear-cut as in queues and buses. I have seen examples where the stream is part of the consumer. We have examples of streams as part of the producer (Hi, DynamoDB streams!). And I have worked on applications that were built around the stream itself, like event-processors for stock analysis.
Kafka confusion
Apache Kafka can act like a queue, a bus, or a stream depending upon its use. In fact, the original conversations that prompted this article were with engineers who had experience with Kafka but limited exposure to the more targeted AWS components. Under the hood, Kafka is combining buses, queues, and streams.
You can build similar behaviors by combining AWS components to compose more complicated message handlers. For example, back when I was a kid, if I didn't want to miss a radio broadcast of King Biscuit Flour Hour (look it up), I would take a tape recorder, press the record button, and place it next to the radio's speaker. This is analogous to wiring a queue to a bus. We've come a long way, baby.
Summary
Queues, buses, and streams share some common functionality; they all move messages. The differences emerge when we look at how each treats those messages, and how we group them architecturally.
If you are asked to explain the differences between buses, queues, and streams (or any other set of related concepts), have examples on hand to help you illustrate the similarities and differences. By moving away from the hand-wavy talk of software architecture and toward real-world examples, such as grocery stores, radios, and highways, you can help your engineers ground their thinking.
Happy building!
References
AWS Documentation: SQS, SNS, or EventBridge?
AWS: Original SNS Press Release
AWS: Original CloudWatch Events (EventBridge) Press Release
AWS: Original EventBridge Press Release
Yan Cui: Understanding push vs. poll in event-driven architectures
Svix: Event Streaming vs Message Queue
Wikipedia: Queue (abstract data type)
Top comments (0)