Hosting Plans

⚠️ “Unbounded” timeout caveat: Flex Consumption, Premium, Dedicated, and Container Apps allow functionTimeout in host.json to be set unbounded, but the platform can still recycle a worker: a 60-minute idle timer, up to a 60-minute scale-in grace period, and a 10-minute grace period during platform upgrades. Design long-running work to be resumable (e.g., Durable Functions) rather than relying on a single uninterrupted execution.

Instance Sizing

💡 Flex Consumption instance memory is user-selectable per app (512 MB, 2,048 MB, or 4,096 MB), each mapping to a fixed vCPU allocation. Use 2,048 MB as the default; go smaller for high fan-out/low-per-invocation-cost workloads, larger for CPU- or memory-intensive functions. Each region has a default 250-core (512,000 MB) Flex quota shared across all Flex apps in that subscription/region — request an increase for large-scale deployments.

Cost Models

Decision Criteria

Plan-Specific Considerations

Consumption (Y1)

• Best for: low-traffic, event-driven workloads that tolerate occasional cold starts.
• Limits: 10-minute max execution, no VNet integration, no per-function scaling.
• Slots: 2 total (production + 1 staging) on Windows and Linux.

Flex Consumption (FC1)

• Recommended default for new Functions apps. Best for Linux workloads needing fast/large scale-out, VNet, per-function scaling, and configurable instance memory.
• Limits: Linux only, no deployment slots (use rolling/blue-green site update strategies (opens in a new tab) instead for zero-downtime deploys).
• Always-ready instances bypass the max-instance-count ceiling and are billed continuously — start small and measure.

Premium (EP1–EP3)

• Best for: latency-sensitive workloads, longer executions, VNet + private endpoints on Windows, or apps needing 3 deployment slots.
• Always allocates at least 1 instance (no scale-to-zero); minimum instance count and maximum burst are both configurable.
• Migrating an existing app between Consumption and Premium on Windows is supported in place via CLI/PowerShell (no new app required). This migration path is not supported on Linux — Linux apps require a new function app on the target plan.

Dedicated (App Service Plan)

• Best for: consolidating Functions onto App Service Plan capacity you already run, or workloads needing the broadest App Service feature set (Hybrid Connections, custom domains, Always On).
• Slot count depends on the underlying App Service Plan tier (Basic = 1, Standard = 5, Premium = 20; see App Service limits (opens in a new tab)).
• No automatic scale-to-zero; the plan runs (and is billed) continuously unless you scale it down manually.

Container Apps (Functions-on-ACA)

• Best for: teams standardizing on Container Apps/Dapr/microservices, or needing a custom container image for Functions.
• For new deployments, use the native Microsoft.App/containerApps integration with kind: 'functionapp'. The older Microsoft.Web/sites integration is legacy and planned for future deprecation. See cold-start.md for the current Bicep shape.
• Scale-to-zero via minReplicas: 0; revisions replace deployment slots for staged rollout.

Migration Notes

Switching hosting plans generally requires creating a new function app, except: Consumption ↔ Premium migration on Windows is supported in place via az functionapp update (see Plan migration (opens in a new tab)). All Linux plan changes, and any move to/from Flex Consumption, require redeploying to a new app on the target plan. See azure-upgrade skill for Consumption→Flex migration guidance.