Throughput Units Left Inflated After Event Hubs Auto-Inflate

Auto-inflate only scales up. Microsoft documents that it does not scale TUs back down when traffic drops, so after a one-off spike, a backfill, a replay or a load test the namespace stays at the higher TU count and is billed for it every hour until someone lowers it.

Because auto-inflate is usually enabled precisely so that nobody has to watch capacity, the ratchet goes unnoticed. Over months a namespace can drift to its configured maximum even though normal traffic needs a fraction of that. Teams running many namespaces, or namespaces with Capture enabled, feel it most, since Capture on Standard is also charged per TU.

Standard tier capacity is billed per throughput unit per hour, independent of how much of that capacity is used.

Throughput unit

Billed hourly based on the maximum number of TUs selected during the hour; each TU allows up to 1 MB/s or 1,000 events per second of ingress and 2 MB/s of egress for the namespace

Ingress events

Billed separately per million events on Basic and Standard, regardless of TU count

Capture on Standard

Billed hourly per purchased throughput unit, so inflated TUs also raise the Capture charge

Auto-inflate maximum

The upper TU limit auto-inflate may reach; the limit itself costs nothing, only the TUs actually in place each hour are billed

• List Standard namespaces with auto-inflate enabled (isAutoInflateEnabled true) and compare the current TU capacity (sku.capacity) with maximumThroughputUnits; namespaces sitting at or near the maximum deserve review
• Chart IncomingBytes, IncomingMessages and OutgoingBytes at the namespace level over several weeks and compare peak per-second rates with the per-TU limits; sustained use far below the current TU allowance indicates excess TUs
• Check ThrottledRequests and Quota Exceeded Errors to confirm that a lower TU count would not have caused throttling at recent peaks
• Enable the autoscale logs diagnostic category (AZMSAutoscaleLogs table) to see each inflate action with the previous and new TU values and what triggered it; a step up with no later step down marks a ratchet
• In Cost Management, group Event Hubs cost by resource and meter to find namespaces whose throughput unit charge has stepped up and stayed flat

• Manually lower the TU count on the namespace Scale page (or by updating sku.capacity) to what recent peaks require, leaving headroom; auto-inflate will raise it again if traffic genuinely grows
• Automate scale-down with an Azure Automation runbook or an Azure Function triggered by metric alerts or a schedule, as the Well-Architected guide for Event Hubs suggests
• Set the auto-inflate maximum from a budget and capacity plan rather than leaving it at a high value, and use Azure Policy to cap TUs where appropriate
• Before planned backfills or load tests, record the TU count and restore it afterwards
• For development and test namespaces, use Basic or Standard with minimal TUs and shorter retention

• Auto inflate in Azure Event Hubslearn.microsoft.com
• Pricing - Event Hubsazure.microsoft.com
• Architecture Best Practices for Azure Event Hubs - Microsoft Azure Well-Architected Frameworklearn.microsoft.com
• Monitoring data reference for Azure Event Hubslearn.microsoft.com