Azure Functions Dedicated Plan

by

In this article, I will explain the Azure Functions Dedicated Plan, explore its architecture and underlying mechanics, provide a detailed comparison against alternative hosting models, and walk you through configuring and scaling your dedicated function apps for maximum reliability and cost efficiency.

Azure Functions Dedicated Plan

What Is the Azure Functions Dedicated Plan?

The Azure Functions Dedicated Plan runs your Function Apps on standard Azure App Service Virtual Machines (VMs) rather than the dynamic, multi-tenant compute fleet used by the Consumption plan.

Check out Azure Functions Premium Plan

When you deploy a Function App to a Dedicated Plan, you allocate dedicated compute infrastructure (CPU, RAM, and disk storage) defined by an App Service Plan SKU. Your functions run within this designated VM allocation, sharing underlying resources with any other web apps, API apps, or mobile backends assigned to the exact same App Service Plan.

Under this model, billing is not based on execution count or gigabyte-seconds (GB-s). Instead, you pay a flat, predictable hourly rate for the allocated virtual machine instances, regardless of whether your functions process a million requests per minute or remain completely idle.

Core Architectural Pillars of the Dedicated Plan

Understanding the technical differentiators of the Dedicated hosting model helps clarify why enterprise architects select it for mission-critical workloads.

1. Predictable, Fixed Budgeting

In dynamic consumption hosting, billing scales linearly with execution duration and volume. For organizations with high-volume, continuous background processing, consumption costs can fluctuate significantly. The Dedicated plan provides predictable monthly operational expenditures (OpEx), allowing finance and engineering teams to forecast cloud infrastructure spend with precision.

2. Elimination of Cold Starts with “Always On”

In serverless compute, a cold start occurs when an idle runtime environment is de-allocated and must spin up fresh compute containers upon receiving a new event. Because the Dedicated Plan runs on persistent virtual machines, you can enable the Always On feature. This ensures the Azure Functions host runtime remains loaded in memory 24/7, reducing latency to near zero for incoming HTTP requests.

3. Unbounded Execution Timeouts

Default Consumption plans enforce a strict default timeout of 5 minutes (configurable up to a hard ceiling of 10 minutes). If a complex computational task, long-running database indexing job, or batch export exceeds this ceiling, the Azure host terminates the thread abruptly.

On a Dedicated Plan, the execution duration is unbounded by default (timeout = null or -1 in host.json), allowing single executions to run continuously without platform interruption.

4. High-Density Colocation

If your organization already maintains underutilized Azure App Service instances hosting enterprise web applications or API microservices, you can host Azure Function Apps on the same existing App Service Plan at zero incremental hosting cost.

5. Enterprise Network Isolation (App Service Environments)

When deployed on an Isolated v2 (Isv2) App Service Plan, your dedicated functions run within an Azure App Service Environment (ASE). This gives you single-tenant dedicated hardware deployed directly into your private Azure Virtual Network (VNet), complete with dedicated front-ends and zero shared multi-tenant infrastructure.

Compute Tiers and SKU Breakdown

The Dedicated Plan utilizes standard Azure App Service pricing tiers. Selecting the proper tier depends directly on your networking, scaling, and compliance requirements.

App Service Plan Tier Hierarchy:
Basic (Dev/Test) ---> Standard (Production baseline) ---> Premium v3 (High Perf/VNet) ---> Isolated v2 (Air-gapped ASE)

1. Basic Tier (B1, B2, B3)

  • Target Audience: Non-production testing, development sandboxes, and low-priority internal jobs.
  • Capabilities: Dedicated compute, manual scaling up to 3 instances, custom domains, SSL bindings.
  • Limitations: Lacks native autoscaling rules, zero support for VNet integration, and no staging deployment slots.

2. Standard Tier (S1, S2, S3)

  • Target Audience: Baseline production workloads with steady processing traffic.
  • Capabilities: Autoscaling up to 10 instances based on resource metrics, deployment slots (up to 5), standard Virtual Network integration, and scheduled scaling rules.

3. Premium v3 Tier (P1v3, P2v3, P3v3)

  • Target Audience: High-performance, low-latency enterprise workloads.
  • Capabilities: Runs on modern hyper-threaded hardware with faster NVMe storage, scales up to 30 instances, includes zone redundancy options, and provides cost-effective memory-to-core ratios.

4. Isolated v2 Tier (I1v2, I2v2, I3v2)

  • Target Audience: Regulated industries (healthcare, banking, federal government) requiring strict isolation.
  • Capabilities: Complete hardware isolation running inside a private subnet via App Service Environment v3 (ASEv3), scaling up to 100 instances, with no public internet ingress unless explicitly configured.

Step-by-Step Configuration Guide

To get the most reliability and performance out of an Azure Functions Dedicated Plan, you must configure key underlying runtime settings properly.

Step 1: Enable the “Always On” Setting

By default, the App Service fabric will idle out worker processes if no incoming HTTP requests arrive within 20 minutes. For non-HTTP triggered functions (such as Azure Service Bus queues, Timer triggers, or Event Hub consumers), idling causes the triggers to stop listening entirely until an HTTP wake-up occurs.

To ensure non-HTTP triggers remain permanently active:

  1. Navigate to your Function App in the Azure Portal.
  2. Under the Settings blade, select Configuration.
  3. Select the General settings tab.
  4. Locate the Always On toggle and set it to On.
  5. Click Save and confirm the application restart.

Step 2: Configure Host Execution Timeouts in host.json

While the Dedicated Plan supports unlimited execution times, the default runtime configuration still applies a baseline timeout unless explicitly modified in the application’s root host.json configuration file.

To remove execution limits for long-running batch or extract-transform-load (ETL) routines, modify the functionTimeout property as shown below:

JSON

{
    "version": "2.0",
    "functionTimeout": "-1",
    "logging": {
        "applicationInsights": {
            "samplingSettings": {
                "isEnabled": true,
                "maxTelemetryItemsPerSecond": 20
            }
        }
    }
}

Architecture Tip: Setting "functionTimeout": "-1" (or omitting the value in Dedicated hosting) establishes an unbounded timeout. However, good architectural hygiene dictates that individual functions should still be modular and handle transient retries gracefully.

Step 3: Configure Storage Account Decoupling

Every Azure Function App requires an associated Azure Storage Account (AzureWebJobsStorage) to manage execution state, internal locks, and trigger synchronization.

On a Dedicated Plan:

  • Use a General Purpose v2 (GPv2) storage account located in the same Azure region as your App Service Plan.
  • Avoid sharing the same storage account connection string across multiple high-throughput Dedicated Function Apps to prevent storage throttling.

Scaling Mechanics: Metric-Based vs. Event-Driven

One of the most critical operational distinctions of the Dedicated Plan is how scaling executes.

1. Scale Controller vs. Autoscale Engine

In the Consumption and Premium hosting tiers, the Azure Scale Controller monitors event queue depths, HTTP request rates, and stream partitions, scaling worker containers out horizontally in fractions of a second.

In a Dedicated Plan, scaling relies on the standard Azure Monitor Autoscale Engine. The platform scales your underlying virtual machine count based on resource thresholds such as:

  • Average CPU percentage across the plan (e.g., scale out when CPU > 75% for 5 minutes).
  • Memory working set percentage.
  • Custom Azure Monitor metrics (e.g., Azure Service Bus queue length).

2. Scale-Up vs. Scale-Out Dimensions

  • Scaling Up (Vertical): Changing your App Service Plan tier from an S1 (1 Core, 1.75 GB RAM) to an S3 (4 Cores, 7 GB RAM) or P2v3. This requires a brief deployment handoff.
  • Scaling Out (Horizontal): Adding more virtual machine instances of your current SKU (e.g., expanding from 2 instances to 8 instances) to distribute incoming execution load across identical nodes.

Networking and Security Architecture

Enterprise environments typically mandate private connectivity and zero data exposure over the public internet. The Dedicated Plan natively supports the full suite of Azure App Service enterprise networking capabilities.

Outbound Traffic via Regional VNet Integration

By deploying your Dedicated Function App on a Standard tier or higher, you can configure Regional VNet Integration. This routes all outbound network calls through a dedicated, delegated subnet inside your virtual network. This allows your functions to securely query:

  • On-premises databases over ExpressRoute or site-to-site VPN tunnels.
  • Azure PaaS resources (such as Azure Key Vault, Azure SQL, or Storage) protected by Private Endpoints.
  • Internal APIs without exposing traffic to the public internet.

Inbound Traffic Restrictions

To lock down incoming HTTP invocations:

  • Configure Access Restrictions to whitelist specific CIDR blocks, Azure Virtual Network subnets, or Azure Front Door instances.
  • Attach an Azure Private Endpoint to assign the Function App an internal private IP address from your subnet, completely disabling public DNS resolution.

When to Choose (and When to Avoid) the Dedicated Plan

Selecting the wrong hosting plan can lead to inflated cloud bills or degraded runtime performance. Use this decision rubric to determine if the Dedicated Plan fits your workload.

Ideal Use Cases for the Dedicated Plan

  • Existing Underutilized Compute: You already operate an App Service Plan with excess CPU and memory capacity, allowing you to run microservices at zero additional cloud cost.
  • Continuous, Predictable Workloads: Background jobs, continuous queue listeners, and processing tasks that run 24/7 where consumption billing would be cost-prohibitive.
  • Long-Running Computational Batch Jobs: Extract, Transform, Load (ETL) routines or document processing tasks that run longer than the 10-minute maximum timeout of the Consumption tier.
  • Strict Hardware Isolation Requirements: Regulated enterprise systems that mandate single-tenant compute hardware via App Service Environments (ASEv3).

When to Avoid the Dedicated Plan

  • Highly Bursting, Intermittent Traffic: Workloads that sit idle for hours and then spike to thousands of concurrent requests benefit far more from the rapid scaling and scale-to-zero capabilities of the Consumption Plan.
  • Zero-Compute Inactive Periods: If you do not want to pay for idle VMs when no code is executing.
  • Rapid Elastic Scaling: If your application requires scaling from 1 to 100 instances in under 30 seconds to absorb sudden traffic surges, use the Elastic Premium Plan or Azure Container Apps instead.

Cost Optimization Strategies

If you run your serverless functions on a Dedicated Plan, implementing the following cost governance strategies will maximize your return on compute investment:

  1. Leverage Azure Reserved VM Instances (RI):Committing to a 1-year or 3-year term for your underlying App Service Plan instances can reduce compute costs by up to 40% to 55% compared to standard pay-as-you-go rates.
  2. Implement Azure Savings Plans:If your infrastructure fleet changes instance types frequently, an Azure Savings Plan for Compute offers dynamic discounts across flexible compute options.
  3. Consolidate Multiple Function Apps:Group complementary microservices into a single App Service Plan. You can run dozens of individual Function Apps on a single Standard or Premium App Service Plan, optimizing overall memory and CPU utilization.
  4. Use Scheduled Auto-Scaling:If your batch workloads run exclusively overnight or on weekends, configure scheduled autoscale rules to scale down the VM instance count or drop the SKU tier during known off-peak hours.

Frequently Asked Questions (FAQs)

Can I run both Web Apps and Function Apps in the same App Service Plan?

Yes. Azure allows you to deploy standard Azure Web Apps, API Apps, and Azure Function Apps into the same App Service Plan. They will share the underlying VM’s CPU, memory, and local disk resources.

Does the Dedicated Plan support Linux and Windows operating systems?

Yes. You can provision Dedicated Plans running either Windows or Linux. However, a single App Service Plan must host exclusively Windows or exclusively Linux workloads—you cannot mix operating systems within the same plan.

Why are my non-HTTP triggered functions not running on my Dedicated Plan?

This almost always occurs when the Always On feature is disabled. If your app is idle for 20 minutes, the Azure host process sleeps, and non-HTTP triggers (like Service Bus or Queue listeners) stop receiving messages until the runtime is manually woken up by an HTTP request.

Is scaling in a Dedicated Plan as fast as the Consumption Plan?

No. Consumption and Premium plans scale out instances in seconds using the specialized Azure Scale Controller. A Dedicated Plan relies on Azure Monitor Autoscale, which typically requires a few minutes to provision and integrate additional VM nodes into your pool.

The Azure Functions Dedicated Plan bridges the gap between serverless execution and traditional enterprise infrastructure management. By providing full control over compute capacity, eliminating cold starts with Always On, removing execution time ceilings, and enabling comprehensive VNet integration, it gives cloud architects the stability and predictability needed to run demanding enterprise workloads.

You may also like the following articles:

Azure Virtual Machine

DOWNLOAD FREE AZURE VIRTUAL MACHINE PDF

Download our free 25+ page Azure Virtual Machine guide and master cloud deployment today!