This chapter covers the critical distinction between Azure Logic Apps Standard and Consumption hosting plans, a key topic in the AZ-204 exam domain 'Integrate' (Objective 5.1). Approximately 10-15% of exam questions touch on Logic Apps, with a significant portion focusing on plan selection based on cost, performance, and integration needs. Understanding when to use each plan is essential for designing cost-effective, scalable integration solutions. We will dissect the architecture, pricing, networking, and feature differences that the exam expects you to know cold.
Jump to a section
Think of Logic Apps as food service. Consumption plan is like a catering company: you pay per plate served, scaling instantly from 10 to 10,000 guests with no upfront cost. Each order (workflow run) is independent, and you only pay when food is prepared. However, the menu is fixed at order time, and you can't customize the kitchen equipment. Standard plan is like a full-service restaurant: you lease the space and kitchen (always-on VMs), pay a fixed monthly rent (base compute) plus per-customer cost (execution). You can install your own ovens (custom connectors, VNet integration), store ingredients on-site (private storage), and keep the kitchen running 24/7 for instant service. But you pay for idle time if no customers come. Catering is great for unpredictable, bursty events; restaurant is better for steady business with need for control and low latency.
What Are Logic Apps Standard and Consumption?
Azure Logic Apps is a serverless integration platform for automating workflows and orchestrating business processes. It offers two hosting plans: Consumption and Standard. The Consumption plan is the original serverless model, where workflows run in a multi-tenant environment and you pay only per execution. The Standard plan, introduced later, runs on dedicated single-tenant infrastructure (App Service plan) and provides more control, better performance, and additional features.
Why Two Plans Exist
The Consumption plan was designed for simple, lightweight integrations with unpredictable traffic patterns. It abstracts away infrastructure completely. However, as customers adopted Logic Apps for enterprise-grade scenarios, limitations emerged: no VNet integration, limited execution duration (90 days), cold start delays, and lack of private storage. The Standard plan addresses these by offering:
Dedicated compute (always-on VMs)
VNet integration (outbound and inbound)
Private storage accounts
Higher execution duration limits (1 year)
Custom connector hosting
Stateful and stateless workflow support
Internal Architecture Comparison
Consumption Plan: - Workflows run in a shared multi-tenant pool of Azure Logic Apps engines. - Each workflow is triggered by a connector (e.g., HTTP, Service Bus, Blob Storage). - On trigger, the engine allocates compute from a shared pool; there may be a cold start if the app has been idle. - All workflow state is stored in Azure Storage in a hidden resource group (managed by Azure). - Scaling is automatic and instantaneous, but you have no control over it. - Maximum execution duration: 90 days (for stateful workflows). - Outbound IP addresses are shared across all tenants.
Standard Plan: - Workflows run on a dedicated App Service Plan (single-tenant). You choose the VM size (e.g., P1v2, P1v3) and number of instances. - The Logic Apps runtime is deployed as a container on each VM. - You can enable zone redundancy and scale out manually or via autoscale rules. - Workflow state is stored in your own Azure Storage account (you create it). - VNet integration is configured via regional VNet integration (outbound) or private endpoints (inbound). - Maximum execution duration: 1 year (stateful), 5 minutes (stateless). - Dedicated outbound IPs (can be static). - Supports private storage, custom connectors, and hybrid connectivity.
Key Components, Values, Defaults, and Timers
Consumption Plan Defaults: - Retry policy: exponential backoff (interval 7s, max 10 retries) - Execution timeout: 90 days (stateful), 5 minutes (stateless) - Payload size limit: 100 MB (with chunking for >100 MB) - Connector throughput: varies, but generally throttled at 1,200 requests per minute per connector - Cold start latency: typically 2-10 seconds
Standard Plan Defaults: - Retry policy: same as Consumption (configurable) - Execution timeout: 1 year (stateful), 5 minutes (stateless) - Payload size limit: 1 GB (with chunking) - Connector throughput: depends on VM size; no hard throttle - Cold start: none (always-on VMs) - Minimum always-ready instances: 1 (configurable)
Pricing Model: - Consumption: Pay per action execution (first 4,000 actions free, then ~$0.000025 per action). Free grant of 1 million actions per month. - Standard: Pay for App Service Plan VMs (fixed hourly cost) plus per-action execution cost (same as Consumption but with free grant per VM).
Configuration and Verification
To create a Consumption Logic App:
az logic workflow create --resource-group myRG --name myLogicApp --location eastus --definition @workflow.jsonTo create a Standard Logic App:
az logicapp create --resource-group myRG --name myLogicApp --storage-account mystorage --plan myAppServicePlan --runtime dotnetTo check the plan type:
az logic workflow show --resource-group myRG --name myLogicApp --query kind
# Output: "Stateful" or "Stateless" (Consumption)
az logicapp show --resource-group myRG --name myLogicApp --query kind
# Output: "stateful" or "stateless" (Standard)Note: The kind property for Consumption is "Stateful" or "Stateless"; for Standard it's "stateful" or "stateless" (lowercase).
Interaction with Related Technologies
Azure Functions: - Consumption Logic Apps can call Azure Functions via the Azure Functions connector. - Standard Logic Apps can host custom code directly via inline code actions or call Functions.
API Management: - Both plans can be exposed via APIM for governance and security. - Standard plan supports private endpoints for internal APIs.
Event Grid: - Consumption Logic Apps can subscribe to Event Grid events with a webhook trigger. - Standard Logic Apps can use Event Grid as a trigger with managed identity.
Service Bus: - Both plans support Service Bus triggers, but Standard can use VNet integration to access a private Service Bus namespace.
Performance Considerations
Consumption: Best for low-volume, bursty workloads. Cold start can be problematic for latency-sensitive apps. High throughput may hit connector throttling limits.
Standard: Best for high-volume, predictable workloads. Always-on eliminates cold start. You can scale up to 30 instances (or more with request). Supports private network access and larger payloads.
Exam Trap: Plan Type vs. Workflow Type
A common mistake is confusing the hosting plan (Consumption vs Standard) with the workflow type (Stateful vs Stateless). Both plans support both stateful and stateless workflows. The plan determines infrastructure; the workflow type determines state management. The exam may ask: "Which plan supports stateless workflows?" Answer: Both. But only Standard supports running stateless workflows with no storage costs.
Summary of Differences
| Feature | Consumption | Standard | |---------|-------------|----------| | Hosting | Multi-tenant | Single-tenant (App Service) | | Cold start | Yes | No | | VNet integration | No | Yes (outbound) | | Private endpoints | No | Yes (inbound) | | Max execution | 90 days | 1 year | | Max payload | 100 MB | 1 GB | | Custom connectors | No (only built-in) | Yes (custom connectors) | | Private storage | No (managed by Azure) | Yes (your own storage) | | Scaling | Automatic, no control | Manual or autoscale | | Pricing | Pay per action | Pay for VM + action | | Outbound IPs | Shared, dynamic | Dedicated, static possible |
When to Use Which
Use Consumption when:
Low to medium volume, unpredictable traffic
Simple integrations with built-in connectors
No VNet or private storage requirements
Cost-sensitive with minimal baseline
Use Standard when:
High volume or predictable traffic
Need for low latency (no cold start)
VNet integration required
Custom connectors or private storage needed
Longer execution duration (up to 1 year)
Static outbound IPs needed for whitelisting
Exam Focus: Objective 5.1
The AZ-204 exam tests your ability to choose the right hosting plan based on given requirements. You must know the key differences listed above. Be prepared for scenario-based questions where you need to select between Consumption and Standard based on cost, performance, networking, or feature needs.
Identify Workload Requirements
Start by analyzing the integration workload: expected volume (actions per month), latency sensitivity, network connectivity needs (VNet, private endpoints), payload sizes, execution duration, and custom connector requirements. For example, a workflow that processes large files (>100 MB) or runs for more than 90 days must use Standard. If the app must be always available with no cold start, Standard is required. If traffic is sporadic and low volume, Consumption may be more cost-effective.
Evaluate Cost Implications
Compute total cost of ownership for both plans. For Consumption, estimate monthly actions (including retries) and multiply by $0.000025 per action (after free grant). For Standard, calculate VM cost (e.g., P1v2 ~$75/month) plus action cost (~$0.000025 per action). For low volumes (<1M actions/month), Consumption is cheaper. For high volumes (>10M actions/month), Standard can be cheaper because the VM cost is fixed and action cost is lower per action due to free grant. Use the Azure Pricing Calculator for precise numbers.
Assess Networking Needs
Determine if the workflow needs to access resources inside a virtual network (e.g., SQL Server, Service Bus with private endpoints). Consumption plan cannot integrate with VNets; it only uses public endpoints. Standard plan supports regional VNet integration for outbound traffic and private endpoints for inbound. If the workflow must connect to on-premises resources via VPN or ExpressRoute, Standard with VNet integration is necessary. If only public endpoints are needed, Consumption suffices.
Check Feature Requirements
List required features: custom connectors, private storage, stateless workflows, long-running workflows (>90 days), large payloads (>100 MB). Consumption lacks custom connectors and private storage; it supports stateful workflows up to 90 days and payloads up to 100 MB. Standard supports all these. If any of these features are needed, choose Standard. Also, if you need to host custom code inline (e.g., JavaScript), Standard supports inline code actions; Consumption does not.
Select and Deploy Plan
Based on the evaluation, choose the plan. For Consumption, create a Logic App resource in the Azure portal or via CLI. For Standard, first create an App Service Plan (e.g., using az appservice plan create), then create the Logic App resource specifying the plan and a storage account. Ensure the storage account has hierarchical namespace disabled (Standard requires general-purpose v2). After deployment, configure VNet integration if needed, set scaling rules, and test the workflow.
Monitor and Optimize
After deployment, monitor performance and cost. For Consumption, use Azure Monitor to track action execution counts and throttling. For Standard, monitor VM CPU/memory and scale out if needed. Adjust scaling rules based on load. Consider moving to Standard if Consumption becomes expensive due to high volume. Conversely, if Standard has idle capacity, consider scaling down or switching to Consumption if features are not needed.
Enterprise Scenario 1: Order Processing System
A large e-commerce company processes millions of orders daily. They need a workflow that validates payment, updates inventory, and sends confirmation emails. The workload is high volume (50M actions/month) and latency-sensitive (must complete within 2 seconds). They chose Standard plan with a P1v3 App Service Plan (3 instances) to handle the load. They enabled VNet integration to connect to a private SQL database and used private endpoints for the storage account. The always-on VMs eliminated cold start, and they scaled out to 10 instances during peak hours using autoscale rules based on CPU. The cost was $300/month for VMs plus $1,250 for actions (after free grant) = $1,550/month. If they had used Consumption, the action cost alone would be $1,250 (same) but with no VM cost, but they would have faced throttling and cold start issues, making it infeasible.
Enterprise Scenario 2: Event-Driven Notifications
A startup needs a simple workflow that triggers on new blob uploads and sends an email notification. Volume is low (~10,000 actions/month). They chose Consumption plan because it's free for the first 1M actions/month. They pay $0. No need for VNet or custom connectors. The workflow runs within seconds, and cold start is acceptable. If they had used Standard, they would pay at least $75/month for the VM, which is wasteful.
Enterprise Scenario 3: Hybrid Integration with On-Premises
A financial institution needs to integrate with an on-premises mainframe via an API that is only accessible through a VPN. They require private storage for compliance. The workflow runs for up to 6 months (long-running reconciliation). They chose Standard plan with VNet integration and a private storage account. They also created a custom connector for the mainframe API. Consumption was not an option due to VNet and storage requirements. The cost was higher ($200/month for VM + storage) but necessary for compliance.
Common Pitfalls
Misjudging volume: Many choose Consumption for high volume and face throttling or high costs. Always calculate break-even point.
Ignoring cold start: For latency-sensitive apps, cold start in Consumption can cause timeouts. Standard is mandatory.
Overlooking VNet needs: If you later need VNet integration, you must migrate to Standard, which is disruptive.
Wrong storage account type: Standard requires general-purpose v2 with hierarchical namespace disabled. Using blob storage or enabling hierarchical namespace causes deployment failure.
What AZ-204 Tests on This Topic
The AZ-204 exam objective 5.1 (Integrate) includes "Choose the appropriate hosting plan for Azure Logic Apps." Questions typically present a scenario with requirements (cost, performance, networking, features) and ask which plan to use. You must know the exact differences.
Common Wrong Answers and Why
Choosing Consumption for VNet integration: Candidates see 'serverless' and assume it supports everything. Reality: Consumption has no VNet support.
Choosing Standard for low-volume, low-latency workloads: Candidates think Standard is always better because it's 'Standard'. But for low volume, Consumption is cheaper and simpler.
Confusing hosting plan with workflow type: A question might ask 'Which plan supports stateless workflows?' The answer is both, but some think only Standard does because it's newer. Actually, Consumption also supports stateless (since 2020).
Assuming Standard always costs more: For high volume, Standard can be cheaper because action cost is the same but VM cost is fixed. Candidates often overlook the free action grant per VM.
Numbers and Terms That Appear Verbatum
Maximum execution duration: 90 days (Consumption), 1 year (Standard)
Payload size limit: 100 MB (Consumption), 1 GB (Standard)
Cold start: yes (Consumption), no (Standard)
VNet integration: not supported (Consumption), supported (Standard)
Custom connectors: not supported (Consumption), supported (Standard)
Outbound IPs: shared (Consumption), dedicated (Standard)
Edge Cases the Exam Loves
Stateless workflows in Consumption: They have a 5-minute execution limit and no state storage. They are free (no action cost) but cannot use connectors that require state (e.g., Service Bus sessions).
Standard plan with zero always-ready instances: You can set always-ready count to 0 to save cost, but then cold start occurs (like Consumption). The exam may test that this is possible.
Private storage in Standard: You must create a storage account with the same region as the Logic App and disable hierarchical namespace. The exam may ask what happens if you use a blob storage account (answer: deployment fails).
How to Eliminate Wrong Answers
If the question mentions 'VNet', 'private network', or 'hybrid connectivity', eliminate Consumption immediately.
If the question mentions 'lowest cost' and 'sporadic traffic', eliminate Standard (unless the volume is very high).
If the question mentions 'custom connector' or 'private storage', eliminate Consumption.
If the question mentions 'long-running workflow >90 days', eliminate Consumption.
If the question mentions 'no cold start', eliminate Consumption (unless they mention always-ready instances=0).
By applying these elimination rules, you can quickly narrow down to the correct answer.
Consumption plan is serverless, pay-per-action; Standard plan uses dedicated VMs with additional fixed cost.
Consumption does not support VNet integration, custom connectors, or private storage; Standard does.
Maximum execution duration: 90 days (Consumption) vs 1 year (Standard).
Maximum payload size: 100 MB (Consumption) vs 1 GB (Standard).
Cold start occurs in Consumption but not in Standard (unless always-ready instances set to 0).
Both plans support stateful and stateless workflows.
For high-volume workloads, Standard can be more cost-effective than Consumption due to free action grants per VM.
These come up on the exam all the time. Here's how to tell them apart.
Consumption Plan
Multi-tenant, shared infrastructure
Pay per action execution only
No VNet integration
Max execution duration: 90 days
Max payload: 100 MB
Standard Plan
Single-tenant, dedicated App Service Plan
Pay for VM + action execution
Supports VNet integration (outbound and inbound via private endpoints)
Max execution duration: 1 year
Max payload: 1 GB
Mistake
Consumption plan supports VNet integration.
Correct
Consumption plan runs in a multi-tenant environment and cannot be integrated with a virtual network. Only Standard plan supports regional VNet integration for outbound traffic and private endpoints for inbound.
Mistake
Standard plan is always more expensive than Consumption.
Correct
For low volumes, Consumption is cheaper. But for high volumes (millions of actions per month), the fixed VM cost of Standard can be offset by the free action grant per VM, making Standard cheaper overall.
Mistake
Stateless workflows are only available in Standard plan.
Correct
Both Consumption and Standard plans support stateless workflows. Stateless workflows in Consumption have a 5-minute execution limit and do not store state, but they are available.
Mistake
You can convert a Consumption Logic App to Standard without downtime.
Correct
There is no direct migration path. You must recreate the workflow in a Standard Logic App and update connections. This can cause downtime.
Mistake
Standard plan requires at least one always-ready instance at all times.
Correct
You can set the always-ready count to 0. In that case, the app will cold start on first request, similar to Consumption. However, you still pay for the App Service Plan VM (if running).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Consumption is a multi-tenant serverless plan where you pay only per action execution. It has no VNet integration, a 90-day execution limit, and 100 MB payload limit. Standard runs on a dedicated App Service Plan, supports VNet integration, custom connectors, private storage, up to 1 year execution, and 1 GB payload. Standard has a fixed VM cost plus action cost.
No. Consumption Logic Apps run in a shared multi-tenant environment and cannot be integrated with a virtual network. You must use the Standard plan for VNet integration (regional VNet integration for outbound, private endpoints for inbound).
Consumption is cheaper for low-volume workloads because you pay only per action, and the first 1 million actions per month are free. Standard has a fixed VM cost (e.g., $75/month for P1v2) even if you run no workflows.
Yes. Both Consumption and Standard plans support stateless workflows. Stateless workflows do not store state and have a 5-minute execution limit. They are useful for fire-and-forget scenarios.
There is no direct migration tool. You must manually recreate the workflow in a Standard Logic App, reconfigure connections, and update any references. Plan for downtime during migration.
Standard Logic Apps require a general-purpose v2 storage account with hierarchical namespace disabled (flat namespace). The storage account must be in the same region as the Logic App.
The maximum execution duration for a stateful workflow in Standard plan is 1 year. In Consumption plan, it is 90 days.
You've just covered Logic Apps Standard vs Consumption — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?