Logic Apps and Azure Functions are two of the most common building blocks for event-driven workloads in Azure. On paper, they solve similar problems: respond to triggers, process data, connect services together. In practice, their pricing models are so fundamentally different that choosing the wrong one can cost you thousands of pounds a year without you noticing.
We see this regularly during FinOps assessments. A team builds an integration workflow in Logic Apps because the visual designer is quick and easy. Six months later, the monthly bill for that single workflow is higher than anyone expected, and nobody can quite explain why. The reverse happens too. Someone writes a Function to orchestrate calls across five different APIs, and the code complexity spirals while a Logic App would have done it in an afternoon with built-in connectors.
The answer is never "always use Functions" or "always use Logic Apps." The answer is understanding exactly how each one charges you, so you can make the right call for each workload.
Logic Apps Consumption: The Action-Based Model
Logic Apps on the Consumption plan charge per action execution. Every single step in your workflow is an action, and every action has a price. Standard connector actions (HTTP, Azure Blob, Service Bus, SQL) cost approximately £0.000125 per execution. Enterprise connectors (SAP, Salesforce, Oracle) cost around £0.001 per execution. Triggers fire at roughly £0.000125 each.
At first glance, those numbers look tiny. And for simple, low-volume workflows, they genuinely are. A workflow with 10 actions running 10,000 times a month costs something like £12.50 in action fees. That is cheap by any measure.
The trouble starts when workflows grow. And they always grow. A workflow with 50 actions running 100,000 times a month costs roughly £625 in action fees alone. That is no longer a rounding error. And 50 actions is not unusual for a real-world integration that handles validation, transformation, error handling, and routing.
The Hidden Action Trap
Here is where organisations consistently underestimate Logic Apps costs: every step counts as a billable action. That includes conditions, variable assignments, compose steps, parse JSON, and response actions. If you use a "For Each" loop, every action inside that loop is billed for every iteration.
This is where the maths gets uncomfortable. Say you have a loop that iterates 100 times, and inside that loop you have 5 actions. That is 500 action executions per single run of the workflow. If that workflow fires 1,000 times a day, you are looking at 500,000 billed actions per day just from that one loop. At £0.000125 per action, that is roughly £62.50 per day, nearly £1,900 per month, from a single loop in a single workflow.
Retry policies compound this further. If an action fails and retries three times, you are billed for all four attempts. If your workflow calls a flaky external API with a default retry policy, those retries silently inflate your bill every month.
The Integration Account Tax
If your Logic Apps workflows involve B2B scenarios (EDI, AS2, X12, or EBICS) you need an Integration Account. The Basic tier starts at around £250 per month and the Standard tier runs to roughly £2,500 per month. These are fixed monthly costs that sit on top of all your per-action charges. For organisations running a handful of B2B integrations, the Integration Account can easily become the single largest line item.
Connector Tier Confusion
Not all connectors are priced equally, and the distinction between built-in, standard, and enterprise connectors is not always obvious. Built-in connectors (HTTP, Control actions, inline code) run inside the Logic Apps runtime and are cheapest. Standard connectors cover most Azure services and common SaaS platforms. Enterprise connectors cover the big ERP and CRM platforms and cost roughly eight times more per action. If your workflow chains several enterprise connector calls together, the per-run cost adds up fast.
Logic Apps Standard: The Fixed-Cost Alternative
Logic Apps Standard runs on an App Service Plan, which means you pay a fixed monthly compute cost regardless of how many actions execute. For high-volume workloads, this flips the economics entirely. Instead of paying more as volume increases, your per-transaction cost decreases the more you use it.
A Workflow Standard WS1 plan starts at around £120 per month. If you are running workflows that would cost £500 or more on Consumption pricing, Standard almost certainly works out cheaper. The trade-off is that you are paying that fixed cost even during quiet periods, so it only makes sense when you have consistent volume.
Azure Functions Consumption: The Execution-Plus-Duration Model
Azure Functions on Consumption pricing charge on two axes: execution count and execution duration measured in GB-seconds.
The first 1 million executions per month are free. After that, you pay approximately £0.000016 per execution. For execution time, you pay around £0.000013 per GB-second, with a free grant of 400,000 GB-seconds per month.
For lightweight, infrequent workloads, this is astonishingly cheap. A function that runs 500,000 times a month, each execution lasting 200ms at 256MB of memory, falls comfortably within the free tier. You might pay literally nothing.
The cost model starts to bite when functions run for longer or consume more memory. A function processing large files at 1.5GB of memory for 30 seconds per execution will burn through the free GB-seconds grant quickly. At scale, memory-intensive or long-running functions can become surprisingly expensive on Consumption pricing.
Azure Functions Premium and Dedicated
Functions Premium provides pre-warmed instances, VNet integration, and no cold starts. You pay for at least one always-ready instance, which means a baseline cost of roughly £130 per month regardless of usage. Dedicated plans (running on App Service) are similar, with fixed compute costs that make sense when you have consistent, predictable load.
For workloads that need VNet connectivity or cannot tolerate cold start latency, Premium is often the only option. The trick is right-sizing the plan so you are not paying for idle capacity.
The Real Comparison
Putting these models side by side, clear patterns emerge.
Low volume, complex orchestration: Logic Apps Consumption wins. If you need to connect to 10 different services, handle retries, parse responses, and route based on content, the visual designer and built-in connectors save you weeks of development time. At low volumes, the per-action cost is negligible, and the speed-to-market value far outweighs it.
High volume, simple processing: Functions Consumption wins. If you are processing messages from a queue, transforming data, or running calculations, Functions will be dramatically cheaper at high volumes. The generous free tier means many workloads cost nothing at all.
Consistent high volume: Either service on a dedicated plan. Logic Apps Standard and Functions Premium both offer fixed-cost compute that becomes more economical as volume increases. The choice between them comes down to whether you need visual orchestration or code-level control.
The combination play: In many real-world architectures, the smartest approach is to use both. Logic Apps handles the orchestration and connector logic (calling APIs, routing messages, managing state). Functions handle the compute-heavy processing (data transformation, complex calculations, file manipulation). This way, each service does what it is cheapest and best at.
A Quick Decision Framework
Before you build, ask three questions. First, how many actions or executions will this run per month? If it is under 100,000 with fewer than 15 actions, Logic Apps Consumption is almost certainly fine. Second, do you need connectors to external services? Logic Apps has over 400 built-in connectors that would take weeks to replicate in code. Third, is the processing compute-intensive or long-running? If yes, Functions will handle it more efficiently and more cheaply.
The worst outcome is building something, deploying it, and never checking the cost. We see Logic Apps workflows that started as quick prototypes still running in production two years later, quietly billing tens of thousands of actions a month that nobody is monitoring. A five-minute review of your Logic Apps run history and your Functions execution metrics can reveal savings that pay for themselves immediately.
Not sure whether your integration workloads are on the right pricing model? Our free Azure cost assessment analyses your actual usage and shows you where the savings are.