Sooner or later, every team building on AWS hits the same fork in the road: two services need to talk asynchronously, and you have to choose between Amazon SQS and Apache Kafka.

The usual framing is "SQS is simple, Kafka is powerful." That's true, but it hides the difference that actually matters:

SQS is a queue. A consumer takes a message, processes it, deletes it.
Kafka is a log. Messages stay for as long as you configure, and every consumer keeps its own bookmark.

Once you see it that way, the choice gets a lot easier.

SQS in 30 seconds

SQS is fully managed: no brokers, no partitions, no disks to size. Producers send, consumers poll, and a received message stays hidden for the visibility timeout. Delete it in time and it's gone for good; crash, and it reappears for another worker.

aws sqs send-message --queue-url $QUEUE_URL \ --message-body '{"orderId": 4821, "total": 59.90}' aws sqs receive-message --queue-url $QUEUE_URL \ --max-number-of-messages 10 --wait-time-seconds 20 # delete only after the work really succeeded aws sqs delete-message --queue-url $QUEUE_URL --receipt-handle $HANDLE
  • Standard queues: at-least-once delivery, best-effort ordering, practically unlimited throughput.
  • FIFO queues: strict ordering per message group plus 5-minute deduplication, at lower throughput.
  • Retention: 1 minute to 14 days, then SQS drops the message.

Kafka in 30 seconds

Kafka writes messages to topics split into partitions, which are append-only files. Reading doesn't delete anything; consumers just move an offset.

# billing and analytics read the same topic with independent offsets kafka-console-consumer.sh --bootstrap-server localhost:9092 \ --topic orders --group billing kafka-console-consumer.sh --bootstrap-server localhost:9092 \ --topic orders --group analytics --from-beginning

That last part is the superpower SQS doesn't have. Add a fraud-detection service six months from now and it can read every order still in retention, without the producer changing a line.

Quick comparison

Amazon SQS Apache Kafka
Model Queue, deleted after processing Log, retained with offsets
Operations Fully run by AWS You, or MSK / Confluent Cloud
Many consumers, same message Needs SNS fan-out to several queues Built in via consumer groups
Replay No Yes, reset offsets
Ordering None (Standard) / per group (FIFO) Per partition
Pricing Per request, 1M free/month Per broker or cluster hour + storage

Pick SQS when...

  • Each message is a job: resize an image, send an email, generate a PDF. Once it's done, nobody needs it again.
  • You want zero ops. Wire it to Lambda and AWS handles polling, batching and scaling. Failures go to a dead-letter queue with one redrive policy.
  • Traffic is low or spiky. An idle queue costs close to nothing (just turn on long polling so empty receives don't add up).

Pick Kafka when...

  • The same event matters to many systems: billing, inventory, search, the data warehouse. Each is just another consumer group.
  • You need replay. A buggy consumer wrote bad data for two days? Fix it and rewind only that group: 
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \ --group analytics --topic orders \ --reset-offsets --to-datetime 2026-10-01T00:00:00.000 --execute
  • You're doing event sourcing, CDC with Debezium, or stream processing with Kafka Streams / Flink.

The cost nobody puts in the table

Self-hosted Kafka is real work: sizing brokers, picking partition counts up front, watching consumer lag, handling upgrades. Amazon MSK removes the servers, but you still pay for brokers running 24/7, and a small multi-AZ cluster lands in the hundreds of dollars a month before storage. For a three-person team shipping a SaaS app, that gap versus an idle SQS queue is significant.

If you want a replayable log but prefer to stay AWS-native, Kinesis Data Streams sits in the middle: multiple consumers, up to 365 days of retention, no brokers, but without Kafka's ecosystem.

The one-question rule

After a message is processed, does anything ever need to read it again?

  • No → start with SQS.
  • Yes, or several independent systems consume the same events → Kafka.

And plenty of teams run both: Kafka carries core business events between services, while SQS queues at the edges handle the jobs those events trigger.

📖 Want the full breakdown? The complete guide covers FIFO vs Standard queues, MSK pricing, Kinesis, and a detailed FAQ: Kafka vs Amazon SQS: Which Messaging Service Is Better? on Online ToolKit Hub.

Working with message payloads? Check out the free tools at onlinetoolkithub.com to format and validate JSON right in your browser.

Which one does your team use, and why? Let me know in the comments 👇