Capacity units by tier
| Tier | Capacity unit | Notes |
|---|---|---|
| Basic | Throughput units (TU) | No Kafka endpoint, limited features. Dev/simple only |
| Standard | Throughput units (TU) | Each TU gives a fixed ingress/egress allowance (MB/s and events/s); auto-inflate; Kafka endpoint |
| Premium | Processing units (PU) | Isolated resources, more partitions, longer retention, better latency predictability |
| Dedicated | Capacity units (CU) | Single-tenant clusters for very high scale |
Check the current per-unit limits in the docs. Exceeding them causes ServerBusy throttling (see the throttling post).
1. Measure
Namespace metrics over 30 days: IncomingBytes, OutgoingBytes, IncomingMessages, ThrottledRequests, per event hub. Convert peaks to MB/s and events/s and compare with what your TUs/PUs allow. Remember egress counts every consumer group reading the data.
2. Throughput units and auto-inflate (Standard)
az eventhubs namespace update -g rg-stream -n ehns-prod --capacity 4 \
--enable-auto-inflate true --maximum-throughput-units 12
- Auto-inflate scales TUs up automatically when load needs it; it does not scale down.
- Add a scheduled job (Automation runbook / Function) that resets capacity to the baseline after peaks, or you'll pay peak TUs forever.
az eventhubs namespace update -g rg-stream -n ehns-prod --capacity 4 # nightly reset to baseline
3. Partitions: decide early
- Partitions set the maximum parallelism of consumers in a group (one reader per partition per consumer group).
- Standard: partition count is fixed at creation. Premium/Dedicated allow increasing it.
- Choose for target consumer parallelism and per-partition throughput, plus growth. Too many partitions on low volume adds overhead for consumers (checkpoints, connections).
- Use partition keys that spread load; a hot key throttles one partition while others idle.
4. Standard or Premium?
| Signal | Consider Premium |
|---|---|
| Frequent throttling at high TU counts | Yes, PUs give more headroom per unit |
| Noisy-neighbour latency spikes matter | Yes |
| Need more partitions or longer retention | Yes |
| Low, steady volume | Standard is cheaper |
Compare monthly cost at your measured load. Premium can be cheaper than many Standard TUs at high throughput.
5. Consumers
- Batch receives (prefetch, max batch size) to reduce requests.
- Checkpoint every N events or seconds, not every event (checkpoint storage costs and latency).
- Remove unused consumer groups. They don't cost directly, but readers attached to them consume egress.
6. Capture and retention
- Capture writes to storage in Avro/Parquet. It's billed on Standard (included on Premium/Dedicated). Turn it off for hubs where nobody reads the captured files.
- Retention: keep the minimum needed for consumer recovery; long retention may need Premium/Dedicated.
7. Review monthly
TU/PU baseline vs peak, throttled requests, top hubs by ingress/egress, unused hubs (no incoming messages for 30 days).
Warning
Partition count can't be reduced, and on Standard can't be increased. Changing it later means creating a new event hub and moving producers and consumers. Size partitions for the long term at creation.
Checklist
- Ingress, egress and events/s measured per hub
- Tier chosen by load and isolation needs
- Baseline TUs + auto-inflate + scheduled scale-down
- Partition count and keys planned for parallelism
- Consumers batch and checkpoint efficiently
- Capture and retention reviewed; unused hubs removed