Over the last few years, our integration estate grew the way most enterprise Azure estates grow: one Logic App at a time. A sync here, an approval flow there, a webhook for the ATS, a scheduled job for the ERP — and one day I looked up and we had more than 140 Consumption Logic Apps in production. They worked. But three problems kept resurfacing, and they eventually pushed me into a proper hosting evaluation. This post is about how I ran that evaluation and what I chose.
The three problems that started it
The bill grew with usage, not with value. Consumption bills every single action — including every polling trigger firing on an empty poll, and every iteration inside a loop. With 140+ apps, a meaningful chunk of our monthly spend was triggers checking whether there was anything to do. The bill was variable, hard to forecast, and grew linearly with volume even when the business value didn't.
Everything had a public endpoint. Every "When an HTTP request is received" trigger gets a public URL protected only by a SAS signature in the query string. We fronted everything with API Management, but the backend URLs were still technically reachable from the internet. Security reviews kept flagging it, and they weren't wrong.
Partner IP whitelisting was impossible. One of our external partner APIs required a fixed source IP for whitelisting. Consumption Logic Apps egress from shared regional IP ranges — there is no clean way to hand a partner a single stable IP. That integration stayed blocked for months, and it turned out to be the forcing function for this whole exercise.
The options on the table
The Logic Apps "Create" screen today offers five hosting plans. Here's the short version of how they differ:
| Plan | Compute | Pricing model |
|---|---|---|
| Consumption (multi-tenant) | Shared | Pay per action |
| Standard — Workflow Service Plan | Dedicated, single-tenant | Fixed per plan instance (WS1/WS2/WS3) |
| Standard — App Service Environment v3 | Dedicated, fully isolated | Per App Service plan instance inside the ASE |
| Hybrid | Your own Kubernetes | Per vCPU-hour of your cluster |
| Automation Project (preview) | Dedicated, scale-to-zero | Base + per vCPU-second |
I eliminated two quickly. Hybrid only makes sense if you are already a Kubernetes-first shop willing to own the infrastructure — we aren't. Automation Project is genuinely interesting (Consumption-like economics with the Standard runtime), but it's in preview: no SLA, and no auditor will accept it for production workloads. Worth a pilot later, not a bet for 140 production workflows today.
That left the two Standard flavours: Workflow Service Plan (WSP) and ASE v3.
The cost math
The economics of Standard hinge on one fact: built-in actions, triggers, loops and variables become free. The runtime executes on your dedicated compute, so you stop paying per action for anything that runs locally. Managed connectors (the cloud-hosted ones for your ERP, ITSM, HR systems) are still billed per call at the same rates as Consumption — that part doesn't change, and it matters.
The break-even is easy to compute. A WS1 plan costs roughly $175/month. A Consumption built-in action costs $0.000025. So: $175 ÷ $0.000025 ≈ 7 million built-in actions per month. If your estate executes more than that — and 140 apps full of polling triggers and loops almost certainly does — the fixed plan wins. Before deciding, pull three months of billing meters and split them into built-in actions vs managed connector calls. If most of your spend is managed connector calls, your savings shrink and the case weakens. That split is the business case; don't skip it.
The second unlock is consolidation. In Consumption, one Logic App = one workflow, which is how you end up with 140 resources. In Standard, a single Logic App resource holds many workflows, and many Logic App resources share one plan. Our 140 workflows map to roughly a dozen Logic App resources — grouped by product domain — running on a single plan instance. One fixed monthly cost instead of 140 meters.
Why I went one step further to ASE v3
Workflow Service Plan already gives you the important things: single-tenant runtime, VNET integration, private endpoints, static egress IP, and it costs roughly a third of an ASE setup. For most teams it is the right answer, and I want to be clear about that — I nearly stopped there.
ASE v3 adds one thing WSP cannot: the entire environment is injected into your VNET with an internal load balancer, so there is no public surface at all. Trigger URLs resolve to a private IP. Nothing outside the VNET can reach them — not "blocked by a firewall rule", but "no route exists". Our API gateway becomes the only front door: internet → APIM (auth, WAF, rate limits) → private ILB → workflow. For an estate that handles HR, finance and partner data, that story simplifies every security review from "here are our compensating controls" to "there is no public endpoint".
The trade-off is cost and capacity discipline. A single Isolated v2 instance runs $300–400/month, and one instance means no high availability: platform patching causes brief pauses, and a zone failure means waiting for recovery. Two things make single-instance tolerable as a starting point: stateful workflows checkpoint to storage and auto-resume after a restart (you lose minutes, not data), and autoscale rules can add a second instance only under sustained load. The genuine risk isn't downtime — it's saturation. Two vCPUs carrying 140 workflows' worth of triggers is something you load-test, not assume. If the pilot shows sustained pressure, the real cost is two instances, and that number should be in the business case from day one.
What we get beyond the bill
The migration pays for itself in cost and security, but the day-to-day wins were almost as persuasive:
Workflows become code. Standard workflows are JSON files in a folder structure — you develop locally in VS Code with a full designer and runner, commit to a repo, review actual diffs in pull requests, and deploy via a pipeline zip-deploy with per-environment parameters. The portal stops being the source of truth. If you've ever maintained a scripted "export Logic Apps to a repo" backup job, this makes it obsolete.
Runs become searchable. Run history still exists per action, but the real upgrade is Application Insights plus two features: clientTrackingId on the trigger stamps every run with a business identifier (an order ID, an employee ID), and trackedProperties on actions push business fields into telemetry. Support stops scrolling run lists by timestamp and starts answering "find the run for record 48213" with one KQL query. For big loops, you stop clicking through iterations in the designer and query the failed ones directly.
Access control becomes granular. Standard ships purpose-built RBAC roles — Reader (view workflows and runs), Operator (resubmit, enable/disable), Developer (edit) — scoped per Logic App resource. Developers get read-only debugging on their own product's apps, support gets resubmit rights, and the pipeline is the only write path to production. In Consumption, that separation was effectively impossible.
The decision, and the plan
We chose Standard on ASE v3 with an internal load balancer, starting on a single Isolated v2 instance, with the estate organised as ~12 Logic App resources grouped by product domain on one shared plan.
The migration is deliberately not big-bang. Consumption workflow definitions aren't lift-and-shift into Standard — the connections model differs and each app needs conversion and testing. So: pilot with two product domains (~25 workflows), watch CPU, memory and queue latency in App Insights for two weeks, then move the remaining waves and decommission Consumption apps as each wave stabilises.
If you're facing the same decision
Three questions will get you 90% of the way:
- Where does your Consumption spend actually go? Split your billing meters into built-in actions vs managed connector calls. Heavy built-in/polling spend → Standard wins clearly. Mostly managed connectors → the savings are smaller; decide on security and DevOps merits instead.
- Is "no shared infrastructure" a real requirement or a perceived one? If your security mandate is satisfied by single-tenant runtime + private endpoints + static egress, Workflow Service Plan gives you that at a third of the cost. Pay for ASE v3 only if full network isolation is genuinely required.
- Can you tolerate minutes of pause, and is your volume load-tested? Single-instance economics are attractive, but go in knowing the HA trade-off and with autoscale configured as a safety net.
The thing I'd emphasise most: this decision looks like a pricing comparison, but it's really an architecture decision. The fixed monthly cost is what gets it approved; the private endpoints, the fixed egress IP, the pipeline-driven deployments and the searchable telemetry are what you'll be glad about a year later.
Top comments (0)