Deploy Serverless Functions with Consumption Plan

Architecture Overview

This architecture deploys an Azure Functions application using the consumption plan, which is Azure’s serverless execution model. With the consumption plan, you pay only for the time your functions execute, and the platform scales from zero to hundreds of instances automatically based on demand. There are no reserved VMs or pre-provisioned capacity to manage or pay for when your functions are idle.

The deployment packages your function code from a local directory, uploads it to Azure Blob Storage, and configures the Function App to run from the uploaded package. This approach keeps your code artifact versioned in storage and makes deployments repeatable. The Function App references the code blob through a SAS URL, which provides time-limited access to the package without exposing storage credentials.

Azure Functions support HTTP triggers, timer triggers, queue triggers, and many other event sources. This deployment configures an HTTP-triggered function, but the same infrastructure pattern applies to any trigger type. You change the function code and bindings, not the infrastructure, when switching between trigger types.

Storage Account

The storage account serves two purposes: it stores the uploaded function code package, and it provides the backing storage that the Azure Functions runtime requires for internal state management (like distributed locks and lease management for scaling). Every Azure Functions deployment needs a storage account, regardless of the trigger type.

The function code is packaged as a ZIP archive, uploaded as a blob, and referenced by the Function App through the WEBSITE_RUN_FROM_PACKAGE setting. This run-from-package approach is the recommended deployment method because it ensures the function host runs from an immutable package, avoiding file-locking issues and making rollbacks straightforward.

Consumption Plan

The consumption plan is the App Service plan type that enables true serverless execution. Azure manages the underlying compute, scaling instances up when requests arrive and scaling back to zero when the function is idle. You are billed per execution, per GB-second of memory used, with a generous free grant each month.

The tradeoff is cold start latency. When a function scales from zero, the first invocation may take a few seconds longer while Azure provisions a host. For latency-sensitive workloads, Azure offers premium plans that keep instances warm, but for most event-driven workloads, cold starts are acceptable and the cost savings are significant.

Function App Configuration

The Function App is the runtime host for your functions. It is configured with the appropriate language runtime, the storage connection string, and the package URL. Application settings control runtime behavior, and you can add environment variables for API keys, connection strings, or feature flags.

The Function App automatically discovers functions within the deployed package based on function bindings defined in your code. For HTTP-triggered functions, each function gets its own HTTPS endpoint under the Function App’s domain.

Common Customizations

• Add timer triggers: Create functions that run on a schedule (cron expressions) for periodic tasks like data cleanup, report generation, or health checks.
• Connect to a database: Add environment variables with connection strings to Azure SQL, Cosmos DB, or other data stores for functions that need persistent state.
• Upgrade to a premium plan: Switch from consumption to a premium plan if you need VNet integration, longer execution times, or predictable warm-start latency.
• Add Application Insights: Enable Application Insights for detailed performance telemetry, request tracing, and failure alerts beyond what basic function monitoring provides.