Choosing your plan
Gen 2
Event Streams is available as Lite plan, Standard plan, and Enterprise plan depending on your requirements.
The following page covers all IBM® Event Streams for IBM Cloud® plans including Classic (Gen 1) and VPC (Gen 2).
For information about Event Streams plan pricing, see the catalog. Search for Event Streams, then click the Event Streams tile to go to the provisioning
page.
Lite plan (Gen 1)
The Lite plan is free for users who want to try out Event Streams or build a proof-of-concept. Do not use the Lite plan for production use. It offers shared access to a multi-tenant Event Streams cluster. The Lite plan is only available on Gen 1 (Classic).
Standard plan (Gen 1)
The Standard plan is appropriate if you require event ingest and distribution capabilities but do not require any additional benefits of the Enterprise plan. The Standard plan offers shared access to a multi-tenant Event Streams cluster that seamlessly autoscales as you increase the number of partitions you are using for your workload.
The architecture is highly available by default. The service is distributed across three availability zones, which means that the cluster is resilient to the failure of a single zone or any component within that zone. The Standard plan is only available on Gen 1 Event Streams (Classic).
Enterprise plan (Gen 1)
The Enterprise plan is appropriate if data isolation, performance, and increased retention are important considerations. The Enterprise plan includes the following features:
- Exclusive access to a single-tenant Event Streams service instance deployed in a highly available multi zone region (MZR).
- Option to provision a single-tenant Event Streams service instance in a geographically local but single zone location (SZR).
- Scaling options to customize throughput, storage capacity, or both.
- The broadest possible set of compliance certifications, regions and features including public endpoint connectivity, Managed Schema Registry and Mirroring capabilities.
The architecture is highly available when you choose to deploy into a multi-zone region. The service is distributed across three availability zones, which means that the cluster is resilient to the failure of a single zone or any component within that zone.
Enterprise plan (Gen2)
The Enterprise Gen2 plan is appropriate if data isolation, performance, and increased retention are important considerations.
Built on IBM®’s latest platform, using highly secure software-defined networking and ideal for modern cloud-native applications. The Enterprise Gen2 plan includes the following features:
- Modern VPC-based software defined networking with private-only connectivity via VPE
- Hypervisor-level isolation with dedicated storage bandwidth
- Latest Kafka 4.1 features
Currently only available in select regions with support for private endpoints and Isolated Compute hosting. The Isolated Compute hosting model provides a Kafka cluster per service instance which runs on single-tenant virtual machines and storage, providing hypervisor-level isolation and dedicated storage bandwidth. This model is ideal for workloads that demand consistent performance and security.
What is supported by the Lite, Standard, Enterprise and Enterprise Gen2 plans
The following table summarizes what is supported by the plans:
| Lite plan | Standard plan | Enterprise plan | Enterprise Gen2 plan | |
|---|---|---|---|---|
| Tenancy | Multi-tenant | Multi-tenant | Single-tenant | Single-tenant |
| Availability zones | 3 | 3 | 3 (1 in single zone locations) |
3 |
| Availability | 99.99 % [1] | 99.99 % | 99.99 % (99.9 % in single zone locations) [2] | 99.99 % |
| Kafka version on cluster | Kafka 3.8 | Kafka 3.8 | Kafka 3.8 | Kafka 4.1 |
| Kafka Connect and Kafka Streams supported | No | Yes | Yes | Yes |
| Managed Schema Registry supported | No | No | Yes | Future release |
| Customer-managed encryption | No | No | Yes [3] | Yes |
| Fine-grained access control | Yes | Yes | Yes | Yes |
| Activity tracker events | No | Yes | Yes | Yes |
| Monitoring Event Streams metrics by using IBM Cloud Monitoring | Yes | Yes | Yes | Yes |
| Private/Public Networking | Public | Public | Both | Private (VPE) |
| Scale plan capacity | No | No | Yes | Future release |
| Maximum number of partitions | 1 [4] | 100 | 3000 - 9000 scales with throughput [5] | 3000 |
| Maximum retention limits | 100 MB for the partition | 1 GB per partition | 2 TB - 12 TB of scalable usable storage [6] | 2 TB of usable storage |
| Maximum throughput | 100 KB per second per partition | 1 MB per second per partition (20 MB per service instance) | 150 MB/s - 450 MB/s of scalable throughput [7] | 100 MB/s (50 MB/s Produce 50MB/s Consume) [8] |
| Maximum message size | 1 MB | 1 MB | 1 MB | 1 MB |
| Maximum number of connected clients | 5 | 500 | 10 000 | 1000 |
| Location (region) availability | Dallas (us-south) | Multizone location (MZR) Dallas (us-south) Sao Paulo (br-sao) Toronto (ca-tor) Washington (us-east) Frankfurt (eu-de) London (eu-gb) Madrid (eu-es) Osaka (jp-osa) Sydney (au-syd) Tokyo (jp-tok) |
Multizone location (MZR) Dallas (us-south) Sao Paulo (br-sao) Toronto (ca-tor) Washington (us-east) Frankfurt (eu-de) London (eu-gb) Madrid (eu-es) Osaka (jp-osa) Sydney (au-syd) Tokyo (jp-tok) Single zone location (SZR) |
Single-campus MZR (SC-MZR) Montreal (ca-mon) Chennai - Airtel (in-che) |
| APIs supported | Kafka API Admin REST API REST Producer API |
Kafka API Admin REST API REST Producer API |
Kafka API Admin REST API REST Producer API Schema Registry API |
Kafka API |
| Deployment timeframe | Instantaneous provisioning | Instantaneous provisioning | Expect provisioning to take up to 3 hours. As Enterprise has its own dedicated resources for each cluster, it requires more time for provisioning. | Typical: Minutes |
| Compliance | GDPR Privacy Shield |
GDPR Privacy Shield ISO 27001, 27017, 27018, 2701 SOC 1 Type SOC 2 Type 2 SOC 3 PCI DSS ISMAP C5 |
GDPR Privacy Shield ISO 27001, 27017, 27018, 2701 SOC 1 Type 2 SOC 2 Type 2 SOC 3 HIPAA ready PCI DSS ISMAP C5 IRAP ENS HITRUST ProtectedB |
New plan – pending certification |
| Manage security and compliance | No | No | Yes | Yes |
| IAM address restrictions | No | Yes | Yes | Future release |
| IAM token authentication only | No | No | Yes | Yes |
| Mirroring | No | No | Yes | Future release |
For more information about limits, see limits and quotas.
-
After 30 days of inactivity, your instance is deleted. (Inactivity is defined as a zero bytes_out metric, even though you might create a partition or produced messages.) ↩︎
-
For more information about availability, see single zone location deployments. ↩︎
-
Only supported on clusters that were created after October 2019. ↩︎
-
If you migrate from the Lite to the Standard plan, allow a few minutes for the cached limit of one partition to clear. You can then take advantage of the 100 partition limit for the Standard plan. ↩︎
-
This value scales relative to the maximum throughput. For example, if you have a throughput of 150 MB/s the maximum partitions would be 3000, for a throughput of 300 MB/s, 6000 and for 450 MB/s, 9000. This limit is a hard limit for partitions on the Enterprise plan. If you reach this limit, you can no longer create topics. If you want to adjust the number of partitions, you can use the self-service option described in Scaling Enterprise plan capacity. There is a 3000 partition limit per 2 TB storage with a maximum limit of 18000 partitions with a 12 TB option, which cannot be exceeded. ↩︎
-
Maximum message retention (storage) can be specified when the service instance is created. Storage can be later scaled independently as demands increase. The minimum usable storage available is dependent upon the number of capacity units that are configured for the service instance. For more information about capacity options, see Scaling Event Streams capacity. ↩︎
-
Maximum throughput can be specified when the service instance is created. Throughput is expressed as the sum of the number of bytes per second that can be both sent and received in a service instance. Throughput can be later scaled as demands increase. Although throughput scaling is independent of storage, a defined minimum storage amount is required for each tier. For more information about capacity options, see Scaling Event Streams capacity. ↩︎
-
Throughput can be specified when the service instance is created. The throughput achieved can vary according to the configuration of the workload, but for capacity planning, the figure represents the throughput which can be expected to be continually available as a minimim for a typical workload. Although throughput scaling is independent of storage, a defined minimum storage amount is required for each tier. For more information about capacity options, see Scaling Event Streams capacity. ↩︎