How Event Streams uses limits and quotas
Gen 2
Event Streams uses quotas to control the resources, such as network bandwidth, that a service can consume. The types and levels of quotas depend on the plan being used.
Enterprise plan
Network throughput
The figure represents the minumim throughput that can be expected to be continually available for a typical workload and should be used for capacity planning. It takes in to account the possible impact of operational actions, such as internal updates or failure modes (for example, the loss of an availability zone). In normal operation, up to 30% more may be possible, but should not be assumed to be continuously available. The maximum achievable throughput can also vary according to the configuration of the workload.
| Throughput (continously available) |
|---|
| 100 MB/s (50 MB/s producing and 50 MB/s consuming) |
Throughput is expressed as the number of bytes per second that can be both sent and received in a service instance. This capacity can be selected when the service instance is created.
Throughput capacity cannot be scaled down. To move to a lower throughput capacity would require creating a new Event Streams service instance at the lower capacity unit.
For more information, see Scaling Event Streams.
Partitions
The maximum number of partitions scales in proportion to the selected throughput. For 100MB/s, 3000 partitions can be used.
Retention
The storage capacity can be selected when the service instance is created, and later scaled as demands increase. Storage capacity is dependent upon the configured throughput capacity. For more information, see Scaling Event Streams on storage capacity options.
Storage capacity cannot be scaled down. To move to a lower storage capacity would require creating a new Event Streams service instance at the lower capacity unit.
Other limits
- Maximum message size: 1 MB
- Maximum concurrently active Kafka clients: 10,000
- Maximum concurrent connections: 100,000