Functions Hosting Plans

Azure Functions Hosting Plans Compared

Azure Functions is Microsoft's serverless compute platform that lets you run event-driven code without managing infrastructure. However, “serverless” doesn't mean there are no servers; it means you don't manage them. The hosting plan you choose fundamentally affects cold start behavior, scaling limits, networking capabilities, pricing model, and available features.

Choosing the wrong hosting plan is one of the most common mistakes teams make with Azure Functions. A startup that picks the Premium plan for a low-traffic webhook wastes hundreds of dollars per month. An enterprise that picks the Consumption plan for a latency-sensitive API serving production traffic deals with cold starts that frustrate users. This guide provides the detailed comparison and decision framework you need to make the right choice.

Hosting Plan Overview

Azure Functions offers four hosting options, each with fundamentally different trade-offs around cost, performance, and capabilities:

*Unlimited execution time requires specific host.json configuration. Timer-triggered functions on Consumption have a 10-minute maximum.

Consumption Plan: True Serverless

The Consumption plan is the original serverless offering and remains the best choice for workloads with sporadic, unpredictable traffic patterns. Azure automatically allocates compute resources when your function is triggered, scales out based on demand, and bills only for actual execution time. When no functions are executing, you pay nothing.

Cold Start Deep Dive

Cold starts are the most discussed limitation of the Consumption plan. When a function hasn't been invoked recently, Azure needs to allocate a worker, load the runtime, restore dependencies, and initialize your code. This process adds latency to the first invocation.

Minimizing Cold Starts on Consumption

While cold starts cannot be eliminated on Consumption, several strategies can reduce them:

• Minimize dependencies: Every package your function loads adds to cold start time. Remove unused dependencies and prefer lightweight libraries.
• Use the latest runtime version: Microsoft continuously improves cold start performance in newer runtime versions. Always target the latest Functions runtime.
• Lazy initialization: Defer heavy initialization (database connections, client creation) to the first actual invocation rather than module load time.
• Keep functions warm with a timer: A timer-triggered function that runs every 5 minutes keeps the instance allocated. However, this adds cost and is essentially a hack; consider Flex Consumption or Premium if you need consistent warm starts.

{
  "version": "2.0",
  "functionTimeout": "00:10:00",
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond": 20,
        "excludedTypes": "Request;Dependency"
      }
    },
    "logLevel": {
      "default": "Warning",
      "Host.Results": "Information",
      "Function": "Information"
    }
  },
  "extensions": {
    "http": {
      "routePrefix": "api",
      "maxOutstandingRequests": 200,
      "maxConcurrentRequests": 100
    },
    "queues": {
      "maxPollingInterval": "00:00:02",
      "visibilityTimeout": "00:00:30",
      "batchSize": 16,
      "maxDequeueCount": 5,
      "newBatchThreshold": 8
    }
  }
}

Flex Consumption Plan: The Best of Both Worlds

Flex Consumption is the newest hosting option and represents a significant evolution of the serverless model. It addresses nearly every limitation of the original Consumption plan while retaining pay-per-use pricing. For most new serverless projects, Flex Consumption should be the default choice.

Key Advantages Over Standard Consumption

• VNet integration: Full virtual network support for accessing private resources, a critical requirement for enterprise workloads that standard Consumption cannot provide.
• Always-ready instances: Configure a minimum number of pre-provisioned instances to eliminate cold starts for critical functions, while still scaling to zero for non-critical ones. You only pay for always-ready instances when they are provisioned.
• Higher scale limits: Scales up to 1,000 instances compared to 200 for standard Consumption and 100 for Premium.
• Configurable instance memory: Choose between 2,048 MB and 4,096 MB instance sizes depending on workload needs.
• Private endpoint support: Inbound private endpoints are supported, enabling fully private function apps accessible only from within your VNet.
• Faster scaling: Improved concurrency management and faster instance allocation compared to standard Consumption.

# Create a Flex Consumption function app with VNet integration
az functionapp create \
  --name my-flex-func \
  --resource-group myRG \
  --storage-account mystorageaccount \
  --runtime node \
  --runtime-version 20 \
  --functions-version 4 \
  --flexconsumption-location "East US 2" \
  --instance-memory 2048

# Configure always-ready instances for the HTTP trigger group
az functionapp scale config set \
  --name my-flex-func \
  --resource-group myRG \
  --always-ready-instances http=1

# Set maximum instance count
az functionapp scale config set \
  --name my-flex-func \
  --resource-group myRG \
  --maximum-instance-count 100

# Enable VNet integration
az functionapp vnet-integration add \
  --name my-flex-func \
  --resource-group myRG \
  --vnet my-vnet \
  --subnet functions-subnet

Premium Plan: Enterprise Serverless

The Premium plan (Elastic Premium, EP1/EP2/EP3) is designed for production workloads that need predictable performance with zero cold starts, VNet integration, and longer execution times. It maintains at least one pre-warmed instance at all times, ensuring that the first invocation is always fast.

Premium SKU Comparison

# Create an Elastic Premium plan
az functionapp plan create \
  --name my-premium-plan \
  --resource-group myRG \
  --location eastus2 \
  --sku EP1 \
  --min-instances 1 \
  --max-burst 20

# Create the Function App on the Premium plan
az functionapp create \
  --name my-premium-func \
  --resource-group myRG \
  --plan my-premium-plan \
  --runtime node \
  --runtime-version 20 \
  --storage-account mystorageaccount \
  --functions-version 4

# Enable VNet integration for accessing private resources
az functionapp vnet-integration add \
  --name my-premium-func \
  --resource-group myRG \
  --vnet my-vnet \
  --subnet functions-subnet

# Configure deployment slots for zero-downtime updates
az functionapp deployment slot create \
  --name my-premium-func \
  --resource-group myRG \
  --slot staging

# Swap staging to production
az functionapp deployment slot swap \
  --name my-premium-func \
  --resource-group myRG \
  --slot staging \
  --target-slot production

Pre-Warmed vs Minimum Instances

Premium plans have two scaling controls that are often confused:

• Minimum instances (plan level): The minimum number of instances that are always allocated and billed. Set this to at least 1 to eliminate cold starts. Each minimum instance is fully billed at the EP SKU rate.
• Pre-warmed instances (app level): Additional instances kept warm beyond the minimum, ready to handle burst traffic. These are billed at a reduced rate (~50% of a fully active instance). Set this to the number of additional instances you typically need during traffic spikes.

Dedicated (App Service) Plan

Running Functions on a Dedicated App Service plan means your functions share compute with other App Service apps on the same plan. This is practical when you already have underutilized App Service plans, need App Service Environment (ASE) for full network isolation, or prefer predictable, fixed-cost billing over usage-based pricing.

When Dedicated Makes Sense

• Existing underutilized App Service plans: If you have an App Service plan running web apps at 20% utilization, adding Functions to the same plan costs nothing extra and maximizes your investment.
• Long-running functions: Dedicated plans have no execution time limit, making them suitable for functions that process for minutes or hours (video encoding, data migration, ETL pipelines).
• App Service Environment (ASE) requirements: For single-tenant, fully isolated compute environments required by compliance standards, ASEv3 with Dedicated plans provides the highest level of network isolation.
• Predictable billing: You pay for the App Service plan regardless of function execution count, making costs completely predictable for budgeting.

Triggers, Bindings, and Plan Compatibility

Azure Functions supports dozens of trigger types that connect your code to events from various Azure services and third-party systems. While most triggers work on all plans, some have plan-specific behaviors or limitations.

Durable Functions and Orchestration

Durable Functions is an extension of Azure Functions that lets you write stateful workflows in code. It provides orchestration patterns like chaining, fan-out/fan-in, human interaction, and monitoring without external state stores.

const df = require("durable-functions");

// Orchestrator function - coordinates the workflow
df.app.orchestration("processOrderOrchestrator", function* (context) {
  const orderId = context.df.getInput();

  // Step 1: Validate the order
  const validation = yield context.df.callActivity("validateOrder", orderId);
  if (!validation.isValid) {
    return { status: "rejected", reason: validation.reason };
  }

  // Step 2: Fan-out - process items in parallel
  const items = validation.items;
  const parallelTasks = items.map((item) =>
    context.df.callActivity("processItem", { orderId, item })
  );
  const results = yield context.df.Task.all(parallelTasks);

  // Step 3: Calculate totals after all items are processed
  const total = yield context.df.callActivity("calculateTotal", results);

  // Step 4: Charge payment
  const payment = yield context.df.callActivity("chargePayment", {
    orderId,
    amount: total,
  });

  return { status: "completed", orderId, total, paymentId: payment.id };
});

// Activity functions - the actual work
df.app.activity("validateOrder", { handler: async (orderId) => {
  // Validate against database
  return { isValid: true, items: ["item1", "item2", "item3"] };
}});

df.app.activity("processItem", { handler: async ({ orderId, item }) => {
  // Process each item (inventory check, reservation, etc.)
  return { item, processed: true, price: 29.99 };
}});

Monitoring and Observability

Azure Functions integrates with Application Insights for comprehensive monitoring. Proper instrumentation is critical for understanding performance, identifying failures, and optimizing costs.

# Create Application Insights
az monitor app-insights component create \
  --app my-func-insights \
  --resource-group myRG \
  --location eastus2

# Connect Function App to Application Insights
az functionapp config appsettings set \
  --name my-premium-func \
  --resource-group myRG \
  --settings \
    APPLICATIONINSIGHTS_CONNECTION_STRING=$(az monitor app-insights component show --app my-func-insights -g myRG --query connectionString -o tsv) \
    FUNCTIONS_WORKER_RUNTIME=node \
    WEBSITE_RUN_FROM_PACKAGE=1

# View function execution logs
az monitor app-insights query \
  --app my-func-insights \
  --resource-group myRG \
  --analytics-query "requests | where timestamp > ago(1h) | summarize count(), avg(duration) by name | order by count_ desc"

Key Metrics to Monitor

Cost Comparison Scenarios

Understanding cost at different traffic levels helps you choose the most economical plan. These scenarios compare monthly costs for identical workloads across plans.

Scenario 1: Low-Traffic API (10K requests/day)

Scenario 2: High-Traffic API (1M requests/day, 200ms avg)

Security and Networking Best Practices

Securing Azure Functions requires attention to authentication, network isolation, and secret management.

Authentication Options

• Function keys: Built-in API keys (function-level and host-level). Simple but not recommended for production; keys are stored in the function app and can be leaked.
• Azure AD authentication (EasyAuth): Built-in authentication middleware that validates Azure AD tokens. No code changes required. Configure in the portal or via CLI.
• Custom authentication: Implement your own JWT validation in code for maximum flexibility (multiple identity providers, custom claims).
• API Management: Place Azure API Management in front of Functions for rate limiting, API versioning, subscription keys, and OAuth 2.0 validation.

# Restrict function app to VNet-only access (Premium/Flex required)
az functionapp config access-restriction add \
  --name my-premium-func \
  --resource-group myRG \
  --rule-name "AllowVNet" \
  --priority 100 \
  --vnet-name my-vnet \
  --subnet functions-subnet

# Enable managed identity for Key Vault access
az functionapp identity assign \
  --name my-premium-func \
  --resource-group myRG

# Set Key Vault references for secrets (no secrets in app settings)
az functionapp config appsettings set \
  --name my-premium-func \
  --resource-group myRG \
  --settings \
    "DB_CONNECTION=@Microsoft.KeyVault(VaultName=myapp-kv;SecretName=db-connection)" \
    "API_KEY=@Microsoft.KeyVault(VaultName=myapp-kv;SecretName=external-api-key)"

# Enable Azure AD authentication
az webapp auth update \
  --name my-premium-func \
  --resource-group myRG \
  --enabled true \
  --action LoginWithAzureActiveDirectory

Decision Guide

Use this framework to select the right hosting plan for your workload:

1. Is the workload sporadic with low traffic and no VNet requirement?→ Use Consumption. The free grant and scale-to-zero make it the cheapest option for lightweight workloads, prototypes, and scheduled tasks.
2. Do you need VNet access with pay-per-use pricing? → UseFlex Consumption. It bridges the gap between Consumption and Premium at a fraction of the cost.
3. Is latency critical with no cold starts allowed? → UsePremium with pre-warmed instances. The always-on minimum instance ensures sub-second response times for every request.
4. Do you have existing App Service plans with spare capacity? → Use Dedicated. Consolidate functions onto existing plans to maximize utilization without additional cost.
5. Need full network isolation (ASE)? → Use Dedicatedwith App Service Environment v3 for single-tenant, fully isolated compute.
6. Running event-driven microservices with KEDA? → ConsiderAzure Container Apps as an alternative that provides Kubernetes-based scaling with built-in KEDA support.