Messaging parity

1. The names, and the one-to-many problem

Google Cloud	AWS	Azure
Pub/Sub	SNS + SQS; Kinesis Data Streams; Amazon MQ	Service Bus, Event Grid, and Event Hubs — Microsoft's table gives all three
Pub/Sub BigQuery / Bigtable / Cloud Storage subscriptions	Kinesis Data Firehose	Event Hubs Capture, Stream Analytics
Cloud Tasks	SQS + Lambda event-source mapping; EventBridge Scheduler	Storage queues, Service Bus scheduled enqueue
Eventarc	EventBridge	Event Grid
Cloud Scheduler	EventBridge Scheduler	Azure Logic Apps, Functions timer triggers
Workflows	Step Functions	Logic Apps, Durable Functions

Microsoft maps Pub/Sub to three different Azure services in three separate rows. That is not sloppiness; it is the shape of the difference. Pub/Sub is one product covering durable queuing, publish/subscribe fan-out and high-volume ingestion, where Azure splits those across Service Bus, Event Grid and Event Hubs and AWS splits them across SNS, SQS and Kinesis.

Estimate consequence, both directions:

to Google Cloud: two or three messaging products collapse into one. One IAM surface, one client library,

one set of operational dashboards. Count the removed products as a line.

from Google Cloud: one Pub/Sub estate fans out, and the split is per topic, decided by whether that

topic is really a queue, a fan-out or an ingestion firehose. Do that triage during the estimate, because the target product determines the client rewrite.

2. There is no partition count to size — and that cuts both ways

	Google Cloud	AWS Kinesis	Azure Event Hubs
throughput unit	none to configure; per-message parallelism	shards	partitions + throughput units
ordering	ordering keys, opt-in, per key	per shard, inherent	per partition, inherent
consumer parallelism ceiling	per message	one per shard (per consumer group)	one per partition

Two readings.

Moving a Kafka, Kinesis or Event Hubs workload onto Pub/Sub deletes a capacity-planning exercise. No

shard count, no partition count, no rebalancing. That is real saved design time and real saved operational surface.

But ordering changes shape. On a partition-based system ordering is free and parallelism is capped by

partition count. On Pub/Sub parallelism is free and ordering costs you serialisation per key. So:

if the source used partitions only for throughput → the migration simplifies;
if it used partitions for ordering → you need a high-cardinality ordering key, and a low-cardinality

one recreates a single-partition topic (reference/messaging/errors.md §4).

Going the other way, every Pub/Sub topic needs a partition or shard count invented for it, and that number has to come from measured throughput.

3. Three subscription types delete a consumer service

Pub/Sub's BigQuery, Bigtable and Cloud Storage subscriptions write messages into those services with no code. The nearest counterparts are Kinesis Data Firehose on AWS and Event Hubs Capture or Stream Analytics on Azure — and those are separate services with their own configuration, their own IAM and, in two cases, their own bill.

Estimate consequence. Look through the source architecture for a consumer whose only job is "read from the queue, write to the warehouse / the lake / the table". On Google Cloud that is a subscription property. Each one found is a service deleted — code, deployment, monitoring and on-call — and it is the most commonly missed saving in a messaging migration.

4. Cloud Tasks bundles what the other clouds separate

A Cloud Tasks queue is "a managed set of tasks with the same target type and configuration", carrying rate limits, retry parameters and scheduled delivery times.

Requirement	Google Cloud	AWS	Azure
per-item HTTP dispatch with a rate limit	one queue	SQS + a Lambda event-source mapping with concurrency controls, or a worker	Storage queue or Service Bus + a worker
"run this at 14:30 tomorrow"	a task's scheduled delivery time	EventBridge Scheduler, or a delayed SQS message (bounded)	Service Bus scheduled enqueue
dispatch to an on-premises endpoint	an HTTP/S target — documented	possible, via a worker	possible, via a worker

The estimate line: one Google Cloud queue often replaces a queue plus a scheduler plus a worker. And the documented on-premises HTTP target is useful in a partial migration — the queue can move before the thing it dispatches to does.

5. Eventarc against EventBridge and Event Grid

All three route platform events as a managed service, and Eventarc uses the open CloudEvents format, which helps a consumer port.

The row worth carrying: Eventarc's Cloud Audit Logs source makes nearly anything audited into a trigger — the compute family records "90+ event sources through Cloud Audit Logs". Where a source-cloud design has a hand-written watcher per service, the Google Cloud equivalent may be a trigger. And Eventarc Advanced's transformation, filtering and schema conversion can replace a function whose only job is reshaping an event between two systems.

Both are component removals rather than cost moves, which is exactly the kind of row a like-for-like estimate misses.

6. Pricing dimension (never a price)

	Google Cloud	AWS	Azure
messaging	data volume published and delivered, plus storage for retained messages	SNS/SQS: per request; Kinesis: shard-hours plus payload units	Service Bus: per operation by tier; Event Hubs: throughput units plus ingress events
task queues	operations	SQS requests	operations
event routing	per event	per event published	per operation

The structural trap: Google Cloud meters Pub/Sub largely on bytes, where SQS and Event Grid meter on requests and Kinesis and Event Hubs on provisioned capacity. A messaging estimate converted by message count alone will be wrong in a direction that depends on message size — small messages are relatively cheaper on Pub/Sub, large ones relatively dearer than a per-request model. You need the average message size, and guides/parity-and-migration-method.md lists it as a required input.

7. What this guide cannot tell you

Whether a given consumer is idempotent. Pub/Sub's default is at-least-once, so that question has to be answered per consumer before a migration, and no table answers it.