Comparing Key Features Across Amazon’s SNS, Azure Service Bus, and Google Cloud Platform

Cloud computing, once obscure since its emergence in the mid-2000s, has evolved into a thriving sector that ignites fierce rivalry among both financial titans and tech behemoths. Today, nearly every facet of commerce appears to hinge on cloud computing, which offers readily essential resources such as data storage and computing power on demand, all without the need for direct, hands-on management by a user.

As more business leaders begin to adopt cloud computing services into their operations, it becomes imperative to understand the unique features cloud computing providers offer, identify the consistency among them, and outline their respective support for event-driven architecture mechanisms.

Below, we do just that by investigating the leading cloud computing market leaders: Amazon’s Simple Notification Service (SNS) and Simple Queue Service (SQS), Microsoft’s Azure Service Bus, and Google Cloud Platform (GCP). 

Understanding Cloud Event-Driven Architectures 

While GCP, SNS, and SQS all serve a similar purpose or function, they do so by a different means of “architecture” or method:

 

AWS SNS and AWS SQS: Amazon SNS, a fully managed publish-subscribe messaging service, facilitates seamless communication by enabling applications to send messages or notifications to a distributed subscriber base via protocols like HTTP and Amazon SQS. The ‘Topic’ acts as a central hub for message publication, while SQS subscriptions serve as efficient endpoints for receiving messages published to a specific topic.

GCP Pub/Sub (Google Cloud Pub/Sub): Pub/Sub, a robust messaging service, facilitates communication between independent applications through scalable and resilient models like publish-subscribe and point-to-point. Analogous to AWS SNS and SQS, a ‘Topic’ serves as the message hub, while a ‘Subscription’ acts as the receiving endpoint.

Azure Service Bus: Azure Service Bus, a versatile messaging service, supports queuing and publish-subscribe models, ensuring reliable message delivery between applications. In similarity to AWS SNS and SQS, the ‘Topic’ acts as the central messaging hub, while a ‘Subscription’ serves as an endpoint for message reception.

Feature Breakdown of AWS vs. GCP vs Azure

Multi-Topic Subscription: AWS enables a single subscription to connect with multiple topics —GCP and Azure lack this feature. If your application requires a single subscription for multiple topics, create two separate subscriptions, each individually subscribed, in GCP and Azure.

Message Body Filtering: Message body-based filtering is essential for refining message handling in cloud-based systems. While AWS offers this feature at the subscription level, GCP and Azure simply do not support it. For users transitioning to GCP or Azure from AWS, awareness of this distinction is key for cloud-integration success. To maintain efficient filtering, GCP and Azure users can update filters using message attributes or handle filtering at the application level for a seamless experience.

Message Attributes: AWS, GCP, and Azure vary in their handling of message attributes, especially concerning support for arrays. In AWS, message attributes can be represented as string arrays, whereas GCP and Azure lack this capability. AWS provides regex-based pattern matching capabilities for message attribute values in Amazon Simple Notification Service (SNS) filtering, while Azure employs SQL-like expressions that evaluate against message properties. GCP strictly supports only “equals” and “not equals” for comparison purposes.

Large Payload Support: To send large Amazon SNS messages exceeding the 256 KB limit, you can utilize the Amazon SNS Extended Client Library, which supports data in an Amazon S3 bucket and publishes only the reference to the S3 object to the Amazon SNS topic. Subscribed Amazon SQS queues can then use the Amazon SQS Extended Client Library to retrieve the payloads from S3. Azure and GCP lack this capability and need a custom implementation to support this feature.

Direct Message Publication to Subscriber: In AWS SQS, messages can be published to SQS. In Azure, messages can be published directly to a subscription whereas in GCP, messages cannot be directly published to a subscription. Instead, it’s mandatory to push messages to a subscription subscribed to a topic.

FIFO Support: Amazon Simple Queue Service (SQS) and Azure Service Bus and GCP Pub Sub support FIFO (First-In-First-Out) message processing, but there are some differences in their implementations. 

Here’s how FIFO in AWS, Azure Service Bus, and GCP compare:

Message Ordering

AWS SQS: In SQS, FIFO queues guarantee that messages are processed in the order they are received. Messages with the same message group ID are also processed in order, allowing you to group related messages together.

Azure Service Bus: Like AWS SQS, Azure Service Bus FIFO queues guarantee that messages are processed in the order they were sent. Messages are processed in a strict FIFO manner, ensuring the first message sent is the first to be received and processed.

GCP Pub/Sub: If messages have the same ordering key and are published to the same region, you can enable message ordering and receive the messages in the order that the Pub/Sub service receives them. 

Message Deduplication

AWS SQS: SQS FIFO queues have built-in message deduplication based on a combination of the message group ID and the message deduplication ID. This prevents identical messages from being delivered more than once.

Azure Service Bus: Azure Service Bus FIFO queues do not have built-in message deduplication features. If you need to prevent duplicates, you would need to handle it at the application level.

GCP Pub/Sub: Pub/Sub provides automatic deduplication of published messages on a best-effort basis. If you publish a message with the same ordering key and message ID as a previously published message, and the previous message has not yet been acknowledged, then Pub/Sub understands that this is a duplicate message and does not deliver it to subscribers.

Support for Message Groups

• AWS SQS: SQS FIFO queues support message groups, which allow you to group related messages together using the same message group ID. This ensures that messages with the same message group ID are processed in the order they are received.
• Azure Service Bus: Azure Service Bus does not have a concept of message groups. However, you can achieve similar functionality by using sessions, where messages with the same session ID are processed in order.
• GCP Pub Sub: The equivalent concept in Google Cloud Pub/Sub for message groups in Amazon SQS FIFO queues is using ordering keys. While Pub/Sub doesn’t have a direct concept of message groups, ordering keys allow you to group related messages together and ensure they are processed in order.

Visibility Timeout

• AWS SQS: In SQS FIFO queues, the visibility timeout specifies the time period during which the message is invisible to other consumers after it has been dequeued by a consumer.
• Azure Service Bus: Azure Service Bus FIFO queues have a similar concept called “lock duration,” which specifies the time period during which a message is locked (invisible) after being dequeued by a consumer.
• One way to handle redelivery is to adjust the acknowledgement deadline. If your subscriber application needs more time to process a message, you can modify the acknowledgement deadline for a specific message. This prevents the message from being redelivered during this extended deadline.

Message Retention Period

• AWS SQS: SQS FIFO queues have a default message retention period of 4 days, which means messages will be kept in the queue for up to 4 days before they are deleted.
• Azure Service Bus: Azure Service Bus FIFO queues have a default message retention period of 7 days, which means messages will be kept in the queue for up to 7 days before they are automatically removed.
• GCP PubSub: The default message retention duration is 7 days, and the default expiration period is 31 days. 

Essentially, these cloud providers support strict message ordering. Further considerations, such as message size limits and retention periods, are relatively similar between these services. 

Staying Ahead of the Industry and Competition

Still spending too much time searching for critical information and building competitive and market landscapes? Missing out on potential growth opportunities within your space? Never miss out on information again with real-time alerts, dashboards, and personalized insights. 

Watch this demo video to see how our proprietary AI search technology helps you get smart on industries, competitors, and key accounts—faster and all in one place.

Start your free trial with AlphaSense today.

 

This article has contributions by two authors:

Author: Pooja Dhannawat – Staff Engineer in AlphaSense

Pooja Dhannawat, a seasoned Staff Engineer, brings over a decade of extensive IT experience. Proficient in Java, Spring Boot, and AWS, she specializes in crafting intricate system architectures, particularly in microservices and Event-Driven Architecture. Leveraging AWS SQS/SNS, GCP Pub/Sub, and Azure Service Bus, she excels in building robust solutions. Pooja is renowned for her ability to design and deploy scalable, resilient systems, optimizing efficiency and responsiveness through event-driven paradigms.

Co Author: Sandesh Deshmane Enterprise Architect in AlphaSense

With over 16 years of expertise in Software Development across diverse programming languages, Sandesh Deshmane is an accomplished Enterprise Architect. His specialization lies in crafting intricate data pipelines and complex systems. His hands-on experience spans a broad spectrum of Big Data and Distributed Systems, including technologies such as Hadoop, Apache Spark, Apache Storm, AWS EMR, Apache Cassandra, AWS Redshift, Elastic Search, Apache Kafka, SQS/SNS, Google pubsub and Apache Zookeeper. Sandesh’s comprehensive skill set and deep knowledge in these domains make him a valuable asset in architecting and implementing robust solutions for complex technological landscapes.