Skip to content

Azure Function App Hosting: Why we still can’t use Flex Consumption Plan!

We run a variety of applications on Azure Function Apps . As technology partners its our job to ensure the deployment is safe, scalable AND Cost effective!  And while Function apps give the promise of true pay per use and its excellent for POCs and dev environments, its really not been the case for any of our prod deployments— and up until now, everything has been running on the very expensive Premium Plan. Why? Because for most of our customers all the infrastructure lives behind a VNet, and VNet integration wasn’t supported in the Consumption Plan — the only plan that offered true pay-per-use pricing. The irony? Most of our functions don’t need to be always-on. Cold start isn’t even a real concern for us in many scenarios. Yet, we were stuck paying for always-on premium instances simply because of the networking limitations. So naturally, when Azure introduced the Flex Consumption Plan — offering per-execution billing with full VNet support — we were excited. 🧪 Round One: The POC That Didn’t Go Well We jumped on it when it was still in preview mode, ran a POC, and… hit a bunch of issues. So we shelved the idea for a while. But once it moved to General Availability (GA), we revisited the Flex plan with renewed hope. 🔍 What’s Holding Us Back Now? Despite the hype, we’re still not able to move our Function Apps to Flex Consumption in production. Here’s why: 🔐 1. Key Vault Networking Limitations One of the first things we noticed is that Key Vault references in Function App settings simply don’t work if your Key Vault has restricted network access — even when the Function App has VNet integration. The workaround? Manually reference the Key Vault in code and fetch secrets programmatically. ✅ Is it annoying? Yes. ✅ Is it a blocker? Not really — we have alternatives. 🚫 But it’s still something to keep in mind. 📉 2. Minimum Scaling – The Real Dealbreaker Here’s the big one: Flex Consumption’s minimum scaling limit is just too high for us.
  • The lowest max scale is 40 instances
  • Sounds great if you want massive parallelism, but…
  • Our databases can’t handle that many concurrent connections
Even with pgbouncer and connection pooling, our architecture just can’t support that level of scaling. For some apps, we deliberately keep scaling low to avoid blowing past DB connection limits. So until Azure allows more granular scaling controls in Flex Consumption, this one’s a hard blocker. 🌐 3. VNet and Subnet Limitations To support the aggressive scaling that Flex Consumption allows, you’ll need to expand your VNet and subnet ranges. That’s an infrastructure change with ripple effects. It’s not impossible, but it’s non-trivial — and for now, it adds one more hurdle to adoption. 💭 Final Thoughts We want to adopt Flex Consumption. We really do. It makes perfect sense for our workload profile — low usage, networking needs, and cost sensitivity. But until Microsoft addresses a few critical limitations — especially around scaling — Premium Plan remains the lesser evil.