Google Cloud for AWS Professionals: Application Services

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 Pub/Sub. The features of Amazon SQS map to those of Pub/Sub as follows:

Feature Amazon SQS Google Pub/Sub
Data source Topic Topic
Data destination Queue Subscriber
Deployment locality Regional Global
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 Yes
Delay queues 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.


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, 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, Pub/Sub supports both push- and pull-based message delivery. In push-based delivery, Pub/Sub initiates requests to your subscriber application to deliver messages. In pull-based delivery, your subscriber application initiates requests to the Pub/Sub server to retrieve messages, similar to Amazon SQS.

Like Amazon SQS standard queues, 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, 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, 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's solution for sending push notifications to multiple mobile devices.

Message lifecycle

Amazon SQS and Pub/Sub both require you to acknowledge messages to remove them from a queue or subscription.

Amazon SQS

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.

Amazon SQS visibility timeout

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, 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.

Pub/Sub acknowledgement deadline

Figure 2: 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 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 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.


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 Pub/Sub pricing.

What's next?

Check out the other Google Cloud for AWS Professionals articles:

For guidance on passing data between Google Cloud and AWS using their respective messaging services, see Connect Google Cloud Pub/Sub to AWS SNS Topics Through Cloud Functions.