Tradeoffs involved in count of partitions of event hub with azure functions

Question

I realize this may be a duplicate of Why not always configure for max number of event hub partitions?. However, the product has evolved and the defaults have changed, and the original issues may no longer be a factor.

Consider the scenario where the primary consumers of an event hub will be eventHubTrigger Azure Functions. The trigger function is backed by an EventProcessorHost which will automatically scale up or down to consume from all available partitions as needed without any administration effort.

As I understand it, the monetary cost of the Azure Function is based on the execution duration and count of invocations, which would be driven by only by the count of events consumed and not affected by the degree parallelism due to the count of partitions.

In this case, would there be any higher costs or complexity from creating a hub with the max of 32 partitions, compared to one with a small number like 4?

Answer 1

Your thought process makes sense: I found myself creating 32 partitions by default in this exact scenario and had no issues with that so far.

You pay per provisioned in-/egress, partition count doesn't add cost.

The only requirement is that your partition key has enough unique values to load partitions more or less evenly.