Updated March 20, 2017
Compare the services that Amazon and Google provide to help facilitate communication between various parts of your application. This article focuses on the messaging services available on each platform.
Service model comparison
For message queueing, Amazon provides Amazon Simple Queue Service (SQS) and Google provides Google Cloud Pub/Sub. The features of Amazon SQS map to those of Cloud Pub/Sub as follows:
|Feature||Amazon SQS||Google Cloud Pub/Sub|
|Message retention||Up to 14 days||Up to 7 days|
|Maximum number of in-flight messages per queue||120,000 for standard & 20,000 for FIFO||Unlimited for pull (subject to quota), and 1,000 for push|
|Maximum payload size||256 KB||10 MB|
|Fan-out||With Amazon SNS||Natively supported|
|Dead letter queue||Yes||No|
|Billing||Queue owner pays||Subscribers pay|
Amazon Simple Queue Service (SQS) and Amazon Simple Notification Service (SNS)
In Amazon Simple Queue Service (SQS), operations center around a message queue that you create. You send messages to the queue, and client applications pull these messages from the queue. To implement a fan-out system, in which multiple subscribers can consume a single message, you can combine Amazon SQS with Amazon Simple Notification Service (SNS), which delivers push notifications to a variety of devices and endpoints. You subscribe an Amazon SQS queue to an Amazon SNS topic, and when a message is published to the topic, Amazon SNS sends an Amazon SQS message to the subscribed queue.
Amazon SQS offers two message queue types: standard queues and FIFO queues. Standard queues offer high throughput, but do not guarantee strict message ordering or exactly-once delivery. Conversely, FIFO queues make these guarantees, but have lower throughput than standard queues.
Cloud Pub/Sub combines message queuing, push-based message delivery, and high-volume streaming message delivery into one global service. It uses a publish/subscribe model: a publisher application creates and sends messages to a topic, and subscriber applications create a subscription to receive messages from the topic. As a publish/subscribe-based service, Cloud Pub/Sub natively supports both fan-in, in which multiple message sources can target a single topic, and fan-out.
In contrast to Amazon SQS, which supports pull-based message delivery, Cloud Pub/Sub supports both push- and pull-based message delivery. In push-based delivery, Cloud Pub/Sub initiates requests to your subscriber application to deliver messages. In pull-based delivery, your subscriber application initiates requests to the Cloud Pub/Sub server to retrieve messages, similar to Amazon SQS.
Like Amazon SQS standard queues, Cloud Pub/Sub does not guarantee message ordering. If you need strict message ordering, however, you can mitigate this limitation in various ways. As with Amazon SQS standard queues, Cloud Pub/Sub also does not guarantee exactly-once delivery. To handle duplicate messages, your code should deal with messages in an idempotent manner.
Unlike Amazon SNS, Cloud Pub/Sub is intended for application and system integrations rather than direct communication with end-user interfaces such as mobile phones or web pages. For this type of client-server communication, you can use Firebase Cloud Messaging, Cloud Platform's solution for sending push notifications to multiple mobile devices.
Amazon SQS and Cloud Pub/Sub both require you to acknowledge messages to remove them from a queue or subscription.
Amazon SQS features visibility timeout. When a process acquires a message for processing, the message becomes invisible to other processes that are processing the queue. The diagram below illustrates how the visibility timeout works when processing messages.
Figure 1: Amazon SQS visibility timeout
When the message is acquired, the visibility timeout starts counting down. During this countdown period, the consuming application processes the message. If processing is successful and within the visibility timeout window, the consuming application can then make a call to delete the message. If the application does not make this call before the visibility timeout expires, the message becomes visible to other processes again.
Similarly, Cloud Pub/Sub has an acknowledgement deadline. By default, this deadline is 10 seconds, but it can be extended up to 10 minutes. For a pull subscription, subscribers can also modify the deadline on the fly on a per-message basis to allow for shorter or longer time to process a given message.
Figure 2: Cloud Pub/Sub acknowledgement deadline
Message delivery guarantees
Amazon SQS has two types of queues available: standard queues and first-in-first-out (FIFO) queues. Amazon SQS standard queues and Cloud Pub/Sub both guarantee that each message will be delivered at least once. Similarly, the two services have comparable limitations: each may have occasional message duplication, and neither make guarantees about message delivery order.
Amazon SQS FIFO queues mitigate both problems by supporting exactly-once, ordered delivery of messages. The FIFO queues have a limit of 300 transactions per second.
Though Cloud Pub/Sub does not provide FIFO-style deduplication and message order guarantees, it's possible to achieve this functionality at the application level. For guidance, see Message Ordering.
Amazon SQS and Amazon SNS
Amazon SQS is priced based on data transfer out of Amazon SQS and number of requests. All Amazon SQS API calls count as requests. A single request can have from 1 to 10 messages, with a maximum total payload of 256 KB. Each 64 KB chunk of the payload is billed as a single request.
Amazon SNS is priced based on the number of notifications you publish, the number of notifications you deliver, and any additional API calls for managing topics and subscriptions. Delivery pricing varies by endpoint type.
Cloud Pub/Sub is priced based on the amount of data volume used for message delivery. Volume is calculated based on the message and attribute data for publish, pull, and push operations. For more details, see Cloud Pub/Sub pricing.
Check out the other Google Cloud Platform for AWS Professionals articles: