Plan choice and scale-out settings decide the bill long before the code does

Overview

Azure Functions cost is driven mostly by hosting plan and scaling configuration. Consumption, Elastic Premium, and Dedicated plans have very different cost curves, and an estate that picked one plan for everything is usually overpaying for some workloads while suffering cold starts on others.

Challenge

Everything ran on a single Premium plan chosen years earlier to solve a cold start problem on one latency-sensitive API. Most of the estate was low-volume batch work that would have been far cheaper on Consumption. Meanwhile the always-ready instance count and maximum burst limits had never been tuned, so the plan was sized for a peak that occurred a few times a month.

Environment

Azure Functions across HTTP-triggered APIs, queue consumers, and scheduled batch jobs on a shared Premium plan. AceMQ advises on the customer's plan selection, configuration, and architecture; Microsoft operates the platform.

Approach

AceMQ profiled each function app's invocation pattern, execution duration, and latency sensitivity, then modeled cost per plan option per workload class. Cold start tolerance was measured against real latency requirements rather than assumed, which is usually where the money is.

Solution

• Profiled invocation patterns, duration distributions, and latency sensitivity per function app
• Modeled cost across Consumption, Elastic Premium, and Dedicated plans for each workload class
• Recommended plan placement per app instead of a single plan for the whole estate
• Tuned always-ready instance counts and maximum burst limits against measured peak, not worst-case fear
• Identified functions where cold start genuinely matters and those where it demonstrably does not
• Delivered a migration sequence with expected savings and the latency risk for each move

Outcome

Technologies