SQS, SNS, EVENT BRIDGE, KINESIS

SQS

  • Pull service — message stays in the queue until it gets pulled
  • Standard Queues — Ordering is not guaranteed
  • FIFO Queues — get a message in the right order but might not be a good fit for high throughput

SNS

  • Push service — 1:M
  • Pub/Sub service
  • SMS — but not support two-way messages and MMS
  • HTTP
  • SMTP
  • Mobile push
  • Time-sensitive update
  • Only support integration with Standard Queue NOT FIFO
  • Support CloudTrail, CloudWatch
  • Common use case: Autoscaling sends another SNS to another application layer or another consumer
  • Notification monitoring
  • Workflow system
  • Publishing many consumers
  • Support high throughput

EVENT BRIDGE

  • M:M — sending messages to different providers to many different consumers
  • Great throughput for decoupling architecture
  • Push service
  • If the event can’t reach the receiver then it will retry so it makes it better than SQS that overload their receivers if there is not enough capability to the message
  • Support third party providers
  • Support sending event to another AWS account

KINESIS

  • Very high throughput
  • Collect streaming data in real-time
  • Support varies option for storing event to s3 or trigger lambda function or ec2
  • Storing events up to 7 days and allow replay
  • Analytic realtime
  • Gaming, IoT

Founder of Nadtakan.com & Serverless Cloud developer. Follow me on Twitter https://twitter.com/NadtakanF