Platform Limits¶

Azure Functions has platform-imposed limits that vary by hosting plan. Understanding these limits is essential for capacity planning, architecture decisions, and avoiding unexpected failures. This reference documents the most impactful limits for Python function apps.

flowchart LR
    A[Hosting plan selection] --> B[Scale-out limits]
    A --> C[Execution timeout limits]
    A --> D[Networking and connection limits]
    A --> E[Memory and storage constraints]

Hosting Plan Comparison¶

Execution Timeout¶

The maximum time a single function invocation can run before being terminated:

Consumption Plan¶

Configure in host.json:

{
  "functionTimeout": "00:10:00"
}

When a function exceeds the timeout, the host terminates the worker process. For HTTP triggers, the client receives a 503 Service Unavailable.

Premium Plan¶

{
  "functionTimeout": "-1"
}

Tip: For operations that might exceed the timeout, use Durable Functions to break the work into smaller activity functions that each complete within the timeout.

Instance Limits¶

Consumption Plan: 100 Instances (Python on Linux)¶

For Python workloads (Linux), the Consumption plan scales to a maximum of 100 instances. Scale is event-driven and there isn't a per-app instance cap command for this plan.

Premium Plan: 20-100 Instances (Linux, region-dependent)¶

Premium plan maximum scale-out on Linux is region-dependent, typically in the 20-100 instance range. Configure always-ready and pre-warmed behavior in the Azure portal or with ARM/Bicep templates.

# Premium pre-warmed and always-ready settings are managed in
# the Azure portal or in ARM/Bicep resource configuration.

Flex Consumption Plan: 1,000 Instances¶

Flex Consumption supports up to 1,000 instances with per-function scaling behavior and optional always-ready instances.

# Set Flex maximum instance count
az functionapp scale config set \
  --resource-group $RG \
  --name $APP_NAME \
  --maximum-instance-count <count>

# Configure always-ready instances for HTTP triggers
az functionapp scale config always-ready set \
  --resource-group $RG \
  --name $APP_NAME \
  --settings http=<count>

Capacity planning should account for subnet sizing and outbound networking capacity when VNet integration is enabled.

HTTP Request and Response Limits¶

Important: The Azure load balancer has a 230-second idle timeout. For HTTP triggers, even if your function timeout is set higher, the client will receive a timeout error after 230 seconds. For long-running operations, return a 202 Accepted immediately and use a polling pattern.

Concurrent Connections¶

Outbound connection limits differ by hosting plan:

Avoiding Connection Exhaustion¶

Reuse HTTP clients across function invocations:

import httpx

# Module-level client — reused across invocations
_http_client = httpx.Client(timeout=30.0)

@bp.route(route="api/data", methods=["GET"])
def get_data(req: func.HttpRequest) -> func.HttpResponse:
    # Reuses the same client and connection pool
    resp = _http_client.get("https://api.example.com/data")
    return func.HttpResponse(resp.text, mimetype="application/json")

Creating a new client per invocation is a common cause of connection exhaustion under load.

Memory Limits¶

On the Consumption plan, exceeding 1.5 GB causes the instance to be recycled. Monitor memory usage with Application Insights:

performanceCounters
| where cloud_RoleName == "$APP_NAME"
| where name == "Private Bytes"
| summarize avg(value) by bin(timestamp, 5m)
| render timechart

Python Memory Considerations¶

Each Python worker process typically uses 50–150 MB at idle, plus memory for loaded packages. With FUNCTIONS_WORKER_PROCESS_COUNT=4, idle memory usage is approximately 200–600 MB, leaving limited headroom on the Consumption plan.

Storage Account Considerations¶

Azure Functions relies on an Azure Storage account for internal operations. Storage-account-level throughput limits can affect runtime behaviour, but those limits are Azure Storage service limits and can vary by storage redundancy, region, and workload pattern.

For authoritative storage throughput numbers, use the Azure Storage scalability targets documentation rather than treating storage figures as Azure Functions platform limits.

For high-throughput scenarios, consider using a dedicated storage account for AzureWebJobsStorage separate from application data storage.

Function App Limits¶

See Also¶

• Scaling
• Cost Optimization
• Python Runtime
• host.json Reference

Sources¶

• Azure Functions Scale and Service Limits (Microsoft Learn)
• Azure Storage Scalability and Performance Targets (Microsoft Learn)