Unexpected cost decrease on our Elastic Premium (EP1) plan that hosts our Azure Functions after August 23rd, as well as function execution failures due to deserialization issues

Question

Hello,

To give a bit more context before proceeding with issue explanation. We have a setup on Microsoft Azure that utilizes IoT Hub, Service Bus topics and Azure Functions with SB topic triggers. How everything works is pretty simple: messages arrive to IoT Hub from our devices, those messages are routed to custom endpoints and sent to specific Service Bus topics. For those topics, we have subscriptions registered (exactly 1 per), and we have Azure Functions that are triggered every time a message arrives to that topic and it processes the message and does our business logic (but not a lot more than: decore/deserialize message -> store in database). We're hosting our function apps under Elastic Premium EP1 plan. On average, we have several million function invocations per month.

Starting on August 23rd 2025, we have started noticing issues with Azure Function executions. Mainly, the issue was around serialization, which is part of our own logic of how we serialize and deserialize the content. The most heavily utilized functions started reporting deserialization errors somewhat randomly. Our retry logic is 10 times, and after that messages are sent to dead-letter sub-queue of a particular topic. There were no code changes or deployments that happened around that time that might've caused it, and it all started on it's own during the night CEST. And of course, it is not consistent - sometimes it happens, sometimes not. The weird thing is that there is no deserialization error in logic, because if I just resubmit the messages from DLQ, they get processed by the same function without an issue.

This has been bugging us for some time, and we started making changes to our serializer (which utilizes Newtonsoft.Json), to try to and somehow eliminate the issue.

Then, couple of days ago, we noticed that our Azure bill is significantly reduced - in particular, we saw that Elastic Premium plan we are using was reduced 10x - from an average cost of CHF50-60 per day, to average CHF4-6 per day. We haven't been making changes to it in any way, and the cost drop started happening on the same day - August 23rd.

We immediately considered that app service plan stopped scaling properly, but we checked and the functions are scaling out the same way as they did in the past, and the average numbers per function are consistent.

So at the moment we are stumped. Has the similar issue been reported recently? I'm writing here before opening a dedicated support request.

Thank you,

Milan Stojanovic

Answer 1

Hello Milan !

Thank you for posting on Microsoft Learn Q&A.

Premium is billed on vCPU-seconds with GiB-seconds across active instances no per execution fee and if each instance can process more messages concurrently, you’ll need fewer instance seconds.

From mid 2025, Microsoft guidance emphasizes fixed per instance concurrency, and the service bus trigger default maxConcurrentCalls is 16 per core. On a 2-core EP1 instance that’s effectively 32 concurrent callbacks per instance unless you override it and dynamic concurrency can push throughput further. If your app (or the platform) picked up a newer runtime/extension, you may have silently moved to higher effective concurrency per instance and lower total instance time. https://learn.microsoft.com/en-us/azure/azure-functions/functions-concurrency

If you’re on FUNCTIONS_EXTENSION_VERSION = "~4" and using extension bundles or floating NuGet ranges, your app can adopt newer Service Bus extension v5.x behavior without a redeploy. (v4 reached retirement many apps upgraded in 2025.) Newer versions changed batching/concurrency behavior and defaults for the isolated worker. That can increase per instance throughput to fewer instance seconds to a 10× cost drop is plausible on steady traffic.

https://docs.azure.cn/en-us/azure-functions/migrate-service-bus-version-4-version-5