CloudCostCompare

Guides

Event streaming costs: Azure Event Hubs vs Amazon Kinesis vs Google Pub/Sub

Updated 27 Oct 2026

An event stream is the buffer that takes device messages from the IoT gateway and hands them to the services that need them: the database, stream processing, the archive. It lets each of those read at its own pace and replay data if something fails.

All three clouds offer one, but they count usage in completely different ways.

Azure Event Hubs: throughput units plus events

Event Hubs (Standard tier) is sold by throughput unit (TU), charged per hour. One TU allows roughly:

  • 1 MB/s or 1,000 events per second in, whichever comes first;
  • 2 MB/s out.

On top of the hourly TU charge you pay per million ingress events, where each event is counted in 64 KB blocks. Small events count as one block each.

What this means:

  • You size for your peak rate, not your average. A stream that bursts to 1,500 events per second for a few minutes needs two TUs for that hour (auto-inflate can add TUs automatically, but it doesn’t remove them by itself).
  • Many tiny messages can hit the 1,000 events/s limit long before the 1 MB/s one. Batching several readings into one event cuts both the TU count and the event charge.

Amazon Kinesis Data Streams (on-demand): per stream plus per GB

In on-demand mode, Kinesis has no capacity to choose. You pay:

  • Per stream-hour, a fixed charge for each stream that exists;
  • Per GB written into the stream;
  • Per GB read out of it.

This suits traffic you can’t predict, because capacity follows the load automatically. Two things to watch:

  • Every consumer reads the data again, and reads are charged per GB. A stream read by the database, the archive and stream processing is read three times.
  • For a steady, high-volume stream, provisioned mode (paying per shard) can work out cheaper than on-demand. It needs more management.

Google Cloud Pub/Sub: pay by volume

Pub/Sub charges by data volume: once for what you publish, and again for each subscription that delivers it. There are no units, shards or streams to size.

  • It scales from nothing to very large volumes with no configuration.
  • Like Kinesis reads, each subscription is billed separately, so three consumers means paying for delivery three times.
  • Pub/Sub bills a minimum size per request, so publishing many tiny messages one at a time costs more than their bytes suggest. Batching fixes this.

Pub/Sub is also what replaces the retired Cloud IoT Core gateway on Google Cloud: devices usually reach it through a partner MQTT broker. See what to use instead of IoT Core.

Which model suits which traffic

Your traffic Tends to favour
Steady, predictable rate, many consumers Capacity pricing (Event Hubs TUs, or Kinesis provisioned shards)
Unpredictable or spiky, or just starting out Volume pricing (Pub/Sub, Kinesis on-demand)
Many very small messages Whichever you choose, batch them first
Only one or two consumers Volume pricing, since you pay for few re-reads

Compare current prices