AWS vs Azure vs GCP

Streaming Services Compared: Kinesis vs Event Hubs vs Pub/Sub

Building a resilient, low-latency streaming pipeline requires selecting an ingestion layer that balances throughput, ordering guarantees, operational overhead, and cost. While open-source frameworks l

Published 10/24/2026 · Izan Technologies

Want this built for your team?

Senior engineers, your cloud, your IP.

Building a resilient, low-latency streaming pipeline requires selecting an ingestion layer that balances throughput, ordering guarantees, operational overhead, and cost. While open-source frameworks like Apache Kafka remain ubiquitous, fully managed cloud-native ingestion engines reduce management toil and integrate natively with downstream analytical platforms like Snowflake and Databricks. When evaluating the primary hyperscalers—AWS, Azure, and GCP—engineers must evaluate Amazon Kinesis Data Streams, Azure Event Hubs, and Google Cloud Pub/Sub against concrete architectural constraints.

In this deep dive, we have these core streaming services compared across their operational models, scaling mechanics, protocol compatibility, and performance trade-offs. Whether your pipeline powers real-time fraud detection, IoT telemetry, or dynamic ML inference, understanding the low-level mechanics of these platforms will keep your architecture robust and cost-effective.

Architectural Paradigms: Partition-Based vs. Global Topic

Before analyzing throughput limits or pricing formulas, it is critical to understand the foundational architectural difference dividing these three platforms: partitioned commit logs versus distributed message bus architectures.

[Partitioned Log: Kinesis / Event Hubs]
Producer ---> [ Shard / Partition 1 ] ===> Fixed consumer instances
         ---> [ Shard / Partition 2 ] ===> (Ordered strictly per shard)

[Distributed Message Bus: GCP Pub/Sub]
Producer ---> [ Global Topic ] ===> Distributed auto-scaling subscribers
                                    (Ordering via explicit Ordering Keys)

Amazon Kinesis and Azure Event Hubs use an append-only, partitioned log model heavily inspired by Apache Kafka. Data is routed to explicit shards or partitions based on a hash of a partition key. Consumers maintain their own cursors (offsets), reading data sequentially. This guarantees strict message ordering within a single partition and allows multiple distinct applications to replay events independently over the retention window.

Google Cloud Pub/Sub, by contrast, operates fundamentally as a serverless, horizontally distributed pub/sub messaging system. Instead of exposing individual partitions to the operator, Pub/Sub abstracts scaling entirely behind a global topic. Consumers create subscriptions (pull or push) and receive messages without managing partition assignments. While Pub/Sub supports message ordering via message attributes (ordering keys), its baseline architecture favors dynamic concurrency and stateless fan-out over append-only log replay.

Amazon Kinesis Data Streams (AWS)

Amazon Kinesis Data Streams is the bedrock of real-time event streaming within the AWS ecosystem. It offers two capacity modes: Provisioned and On-Demand.

Scaling and Throughput Mechanics

In Provisioned mode, Kinesis capacity is metered strictly by shards:

  • Ingress: 1 MB/second or 1,000 records/second per shard.
  • Egress: 2 MB/second per shard (shared across standard consumers) or 2 MB/second per consumer shard via Enhanced Fan-Out (EFO).
  • Latency: Typically 70ms–200ms with standard consumers; sub-70ms using HTTP/2-based EFO.

Kinesis On-Demand automates capacity by dynamically scaling up to previous peak throughput (default ceiling up to 200 MiB/s write and 400 MiB/s read per stream), eliminating manual resharding operations for workloads with spiky or unpredictable patterns.

Developer and Consumer Ecosystem

Consuming from Kinesis typically relies on the Kinesis Client Library (KCL), an orchestration layer that handles worker instance coordination, shard lease tracking via Amazon DynamoDB, and fault tolerance. For managed stream processing, AWS integrates Kinesis natively with Managed Service for Apache Flink, AWS Lambda, and Amazon Kinesis Data Firehose (for automated micro-batching into Amazon S3, Redshift, or Snowflake).

However, Kinesis lacks native Kafka protocol compatibility. Migrating an existing Kafka-based microservices fleet to Kinesis requires refactoring producers and consumers to use AWS SDKs.

Azure Event Hubs (Azure)

Azure Event Hubs is Microsoft’s enterprise-tier streaming engine, designed as an event-ingestion alternative to Apache Kafka that bridges seamlessly into Azure Data Lake Storage (ADLS Gen2), Microsoft Fabric, and Azure Databricks.

Scaling and Throughput Mechanics

Event Hubs meters scale through Throughput Units (TUs) on Standard tiers or Processing Units (PUs) on Premium/Dedicated tiers:

  • Standard TU: 1 MB/second or 1,000 events/second ingress; 2 MB/second or 4,096 events/second egress.
  • Auto-Inflate: Automatically scales TUs up to an administrator-defined threshold to avoid throttling during traffic bursts.
  • Partitions: Unlike Kinesis, where adding capacity requires splitting shards, Event Hubs decouples partition count (configured at creation, typically 2–32) from throughput scale (TUs/PUs). Throughput can be adjusted dynamically without modifying the stream's physical partition count.

Native Kafka Compatibility and Capture

A standout architectural feature of Azure Event Hubs is its native Apache Kafka API endpoint (Kafka 1.0+). Applications configured to talk to Kafka can point their connection strings directly to Event Hubs namespaces without rewriting producer or consumer codebases.

Additionally, Event Hubs Capture provides fully managed zero-code data offloading directly to Azure Blob or ADLS Gen2 in Avro or Parquet formats. This provides a resilient, low-maintenance pathway for landing raw events into delta lakehouse architectures.

Google Cloud Pub/Sub (GCP)

Google Cloud Pub/Sub is engineered for extreme scale with minimal operational maintenance, abstracting infrastructure components like shards, nodes, and capacity units entirely.

Scaling and Throughput Mechanics

Pub/Sub does not force teams to provision capacity upfront:

  • Ingress/Egress: Scales automatically to handle gigabytes per second of throughput out of the box, subject only to regional project quotas (which can be increased on demand).
  • Global Architecture: Topics are global resources. A publisher in Tokyo and a publisher in Frankfurt can send events to the same topic; subscribers read messages from local Google Cloud regions without cross-region routing pipelines.
  • Ordering: Message ordering is disabled by default to maximize horizontal scale. When enabled via ordering keys, messages sharing a key are delivered in publication sequence, though this introduces concurrency constraints similar to traditional partition keys.

Integrations and Push Subscriptions

Pub/Sub excels in serverless, event-driven compute patterns. In addition to standard streaming pull APIs, it supports Push subscriptions that invoke HTTPS endpoints, Cloud Run services, or Cloud Functions directly. For analytical workflows, Google Cloud Dataflow (Apache Beam) provides turnkey stream-to-batch processing, windowing, and schema validation. Furthermore, Pub/Sub BigQuery subscriptions write messages directly into Google BigQuery tables without compute intermediaries.

For teams needing append-only logs, Google also offers Pub/Sub Lite, a lower-cost, partition-based alternative with explicit shard management closer to Kinesis or Kafka.

Feature Breakdown: Streaming Services Compared

Evaluating aws vs azure vs gcp for real-time streaming requires weighing features against operational trade-offs. Here is how the three native services compared side by side:

CapabilityAmazon Kinesis Data StreamsAzure Event HubsGoogle Cloud Pub/Sub
Architectural ModelPartitioned commit log (Shards)Partitioned commit log (Partitions)Distributed message bus (Topics/Subs)
Capacity ManagementProvisioned (manual/auto shard) or On-DemandProvisioned (TUs/PUs) with Auto-Inflate100% Serverless, auto-scaling
Max Ingress (Per Unit)1 MB/s / 1,000 rec/s per shard1 MB/s / 1,000 evt/s per TUElastic (Regional quotas: 100MB/s+ default)
Ordering GuaranteeStrict per partition keyStrict per partition keyOut-of-order baseline; strict via Ordering Keys
Kafka API SupportNo (requires AWS SDK / KPL / KCL)Yes (Wire-compatible Kafka 1.0+ endpoint)No (requires Cloud Pub/Sub client libraries)
Data Retention24 hours to 365 days1 to 90 days (Dedicated: up to 90 days)10 minutes to 7 days
Native Storage SinkKinesis Firehose -> S3, Redshift, SnowflakeEvent Hubs Capture -> ADLS Gen2 / BlobDirect Pub/Sub to BigQuery / Cloud Storage
Primary Sweet SpotDeep AWS architectures, Flink/LambdaAzure, multi-cloud Kafka migration, FabricServerless microservices, Dataflow, BigQuery

Architectural Trade-Offs in Production

When architecting a production streaming fabric, theoretical limits matter less than edge cases under load.

1. Consumer Group State and Backpressure

With Kinesis and Event Hubs, reading state is deterministic. If your downstream consumer (e.g., a Spark Structured Streaming application on Databricks) crashes, it restarts from its last committed checkpoint offset in DynamoDB or Blob storage. Backpressure is managed naturally: the consumer pulls only what it can process, leaving the remaining data in the immutable log buffer.

With GCP Pub/Sub, consumers acknowledge individual messages or batches. If a consumer falls behind, unacknowledged messages trigger redelivery, which can induce "redelivery storms" under heavy load if client acknowledgment deadlines are tuned incorrectly.

2. Migration and Lock-In

If vendor-agnostic architecture is a requirement, Azure Event Hubs provides the clearest advantage through native Kafka client compatibility. Switching your consumer fleet between on-premise Kafka, Confluent Cloud, and Event Hubs requires modifying configuration files rather than codebases.

Kinesis and Pub/Sub require proprietary SDK wrappers. To avoid lock-in when using AWS or GCP, engineering teams should decouple transport layers by adopting abstraction frameworks like Apache Beam, Apache Flink, or Spark Structured Streaming. At Izan Technologies, our data engineering teams routinely implement abstracted consumer frameworks on Databricks and Snowflake, ensuring infrastructure changes do not destabilize core data processing logic.

3. Cost Vectors: Idle Streams vs. Massive Scale

  • Kinesis On-Demand simplifies capacity management, but costs roughly 50% more per ingested gigabyte than a well-tuned provisioned stream.
  • Azure Event Hubs charges flat hourly rates per active TU/PU regardless of whether data is flowing, which can prove inefficient for low-volume, sporadic pipelines.
  • Pub/Sub charges purely per volume of data processed (ingestion, delivery, and cross-region egress). A topic handling zero traffic incurs zero base cost, making it exceptionally cost-effective for dynamic workloads.

How Izan Technologies Helps

Designing an enterprise streaming pipeline requires balancing high throughput, low latency, schema validation, and predictable cloud spending. At Izan Technologies, we architect end-to-end data engineering, AI, and analytics solutions on AWS, Azure, Databricks, and Snowflake. Whether you are transitioning to an event-driven architecture, building sub-second feature stores for real-time ML inference, or eliminating streaming ingestion bottlenecks, our team builds production-ready systems tailored to your technical requirements. Most importantly, our clients retain 100% ownership of all IP and code delivered throughout the engagement.

Accelerate your real-time analytics journey: Try our Smart AI DataStudio to explore intelligent data transformation, or talk to an expert to design your enterprise streaming architecture.

Want this built for your team?

Senior engineers, your cloud, your IP.