Azure Functions Cheat Sheet
Reference for building, triggering, and deploying Azure Functions using bindings, triggers, and the Azure Functions Core Tools.
Python HTTP Trigger
Basic HTTP-triggered function.
import azure.functions as funcimport jsonapp = func.FunctionApp()@app.route(route="hello", auth_level=func.AuthLevel.ANONYMOUS)def hello(req: func.HttpRequest) -> func.HttpResponse: name = req.params.get('name', 'World') return func.HttpResponse( json.dumps({"message": f"Hello, {name}!"}), mimetype="application/json", status_code=200 )
Azure Functions Core Tools
Local development and deployment commands.
func init MyFunctionApp --python # Scaffold projectfunc new --name HttpExample --template "HTTP trigger"func start # Run locallyfunc azure functionapp publish myFuncApp # Deploy to Azure
Provisioning with az CLI
Create the Function App resource in Azure.
az functionapp create \ --resource-group myRG \ --consumption-plan-location eastus \ --runtime python --runtime-version 3.11 \ --functions-version 4 \ --name myUniqueFuncApp \ --storage-account mystorageacct
Triggers & Bindings
Key triggers & bindings to know.
- HTTP Trigger- Invokes the function on an incoming HTTP request
- Timer Trigger- Runs on a CRON schedule (e.g. "0 */5 * * * *")
- Blob Trigger- Fires when a blob is created/updated in Azure Storage
- Queue Trigger- Processes messages from Azure Storage Queue or Service Bus
- Output Binding- Declarative way to write data (e.g. to Cosmos DB) without SDK boilerplate
Hosting Plans
Key hosting plans to know.
- Consumption Plan- Pay-per-execution, auto-scales, has cold starts
- Premium Plan- Pre-warmed instances, VNet integration, no cold starts
- Dedicated (App Service) Plan- Runs on reserved VMs, predictable cost, no auto-scale to zero
- Container Apps hosting- Run functions as containers on Azure Container Apps
Durable Functions Orchestrator
Chain multiple activity functions into a reliable, stateful workflow.
import azure.durable_functions as dfapp = df.DFApp()@app.orchestration_trigger(context_name="context")def order_orchestrator(context: df.DurableOrchestrationContext): order = context.get_input() payment = yield context.call_activity("charge_payment", order) if not payment["success"]: yield context.call_activity("send_failure_email", order) return {"status": "failed"} shipment = yield context.call_activity("schedule_shipment", order) return {"status": "completed", "tracking": shipment["trackingId"]}@app.activity_trigger(input_name="order")def charge_payment(order: dict) -> dict: # idempotent activity code, may be retried on replay return {"success": True}
Durable Fan-Out/Fan-In
Run activities in parallel and aggregate results with context.task_all.
@app.orchestration_trigger(context_name="context")def batch_orchestrator(context: df.DurableOrchestrationContext): files = context.get_input() tasks = [context.call_activity("process_file", f) for f in files] results = yield context.task_all(tasks) total = sum(r["rowsProcessed"] for r in results) return {"filesProcessed": len(results), "totalRows": total}
Retry Policy on a Trigger
Configure automatic retries for a function via host.json or a decorator.
{ "retry": { "strategy": "exponentialBackoff", "maxRetryCount": 5, "minimumInterval": "00:00:02", "maximumInterval": "00:00:30" }, "extensions": { "queues": { "maxPollingInterval": "00:00:02", "visibilityTimeout": "00:00:30", "maxDequeueCount": 5 } }}
Managed Identity + Key Vault References
Bind app settings to Key Vault secrets without embedding connection strings.
# Enable system-assigned identity on the Function Appaz functionapp identity assign --resource-group myRG --name myUniqueFuncApp# Grant the identity access to read secretsaz keyvault set-policy --name myKeyVault \ --object-id $(az functionapp identity show -g myRG -n myUniqueFuncApp --query principalId -o tsv) \ --secret-permissions get list# Reference the secret instead of storing it as a plain app settingaz functionapp config appsettings set --resource-group myRG --name myUniqueFuncApp \ --settings SQL_CONN="@Microsoft.KeyVault(SecretUri=https://myKeyVault.vault.azure.net/secrets/sqlConn/)"
Cold Start Mitigations
Techniques to reduce or eliminate cold-start latency beyond just choosing a plan.
- Always Ready instances (Premium)- Pre-warmed instances that skip the scale-from-zero cold path entirely
- Trimmed dependencies- Smaller deployment package and fewer imports speed up worker init
- .NET AOT / isolated worker- Ahead-of-time compilation removes JIT warm-up time on cold start
- Avoid heavy global-scope init- Move expensive client construction lazily behind first-use checks
- Ping/warm-up timer trigger- A low-frequency timer function keeps a Consumption instance from fully idling out
- Reduce package size- Exclude test files, docs, and unused packages from the deployment zip
Use the Premium plan (not Consumption) for latency-sensitive production workloads — it keeps pre-warmed instances ready and eliminates the cold-start penalty that Consumption plans incur after idle periods.