Azure Functions

Executive Summary

Azure Functions is Azure's Functions-as-a-Service (FaaS) platform: you write a small unit of code bound to a trigger, and the platform handles process lifecycle, scaling, and (on serverless plans) billing per execution. The same Functions runtime and programming model can run in five very different places — Consumption, Flex Consumption, Premium, Dedicated (App Service Plan), or as a plain container on Kubernetes/AKS scaled by KEDA — and picking the wrong one is the single most consequential (and most common) mistake teams make.

Core Concepts

Trigger, binding, function app

Azure Functions uses triggers to start function execution and bindings to connect code to other services like storage, queues, and databases, without hand-written SDK plumbing for the common case.

Programming models

The v2 programming model uses a decorator-based approach to define triggers and bindings directly in code, replacing the v1 model's separate function.json metadata file per function. This is now the recommended model across Python, Node.js (v4), and other supported languages.

Architecture Overview

Every hosting option is built from the same two logical layers: the Functions host/runtime (your code + the language worker + the extension/binding framework) and a scaling substrate that decides how many instances of that host should run.

Fig 1. One portable Functions host, four different scaling substrates.

Internal Working

How event-driven scaling actually decides "add an instance"

When a function is deployed, it runs inside the Functions runtime host process, which pulls events from the source defined by the trigger and passes them to your function code. One instance of the runtime is rarely adequate: it's wasteful if you get one message a day, and insufficient if you get thousands of events per second — so a separate autoscaling mechanism monitors the trigger source and adjusts instance count.

• On Azure-hosted plans: the built-in scale controller polls the trigger source directly (e.g., Storage Queue length, Event Hub partition lag) roughly every few seconds and issues scale decisions independent of Kubernetes/HPA — there's no cluster involved at all.
• On Kubernetes: KEDA exposes custom metrics for the Kubernetes Horizontal Pod Autoscaler; by default HPA can only use CPU/memory, which is limiting when you want to scale on e.g. requests/second or queue depth — KEDA's metrics adapter fills that gap.

Cold start mechanics

A cold start = provisioning a brand-new host instance: pull the runtime/worker image (or spin up a new App Service worker), load your app's dependencies, run any startup code, then invoke the trigger. Pre-warmed ("always ready") instances on Premium/Flex sidestep this by keeping idle-but-ready hosts around.

Key Components

Request / Execution Flow

Trace of a queue-triggered function scaling out under load, contrasting the Azure-hosted path with the Kubernetes/KEDA path:

Fig 2. Same function code, two different scaling substrates for the same queue trigger.

Hosting Plans Compared

Azure Functions + KEDA + AKS

Every Azure Functions trigger implementation has a matching KEDA scaler, which is what makes it possible to run the Functions runtime in a Docker container with event-driven scaling through KEDA on any Kubernetes cluster, including AKS — replicating serverless scale-to-zero/scale-to-N behavior outside Azure's managed platform entirely.

Why you'd choose this over a managed plan

How the pieces fit together on AKS

Fig 3. KEDA sits between the event source and the standard Kubernetes HPA; the Functions container is just a Deployment.

AKS-native KEDA integration

AKS ships a managed KEDA add-on supporting ScaledObjects (Deployments, StatefulSets, or any custom resource with a /scale subresource) and ScaledJobs for job-like workloads, with production-grade security by decoupling autoscaling authentication from workloads, support for bring-your-own external scalers, and integration with Microsoft Entra Workload ID. On AKS Automatic, KEDA is preconfigured by default; on AKS Standard it's an opt-in add-on, and if you plan to use workload identity you must enable that before enabling KEDA.

Building and deploying a Functions container to AKS

# 1. Scaffold and containerize a function app locally
func init OrdersProcessor --docker
cd OrdersProcessor
func new --name ProcessOrder --template "Azure Queue Storage trigger"

# 2. Build and push the image
docker build -t myacr.azurecr.io/orders-processor:1.0 .
az acr login --name myacr
docker push myacr.azurecr.io/orders-processor:1.0

# 3. Generate Kubernetes manifests (Deployment + KEDA ScaledObject) from the func app
func kubernetes deploy \
  --name orders-processor \
  --image-name myacr.azurecr.io/orders-processor:1.0 \
  --namespace orders

Explanation: func kubernetes deploy generates the Deployment, Secret (for trigger connection strings), and a KEDA ScaledObject wired to the function's trigger — the same artifact you could hand-author for full GitOps control.

Example: hand-authored ScaledObject for a queue-triggered function

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: orders-processor-scaledobject
  namespace: orders
spec:
  scaleTargetRef:
    name: orders-processor
  minReplicaCount: 0
  maxReplicaCount: 20
  cooldownPeriod: 60
  triggers:
    - type: azure-queue
      metadata:
        queueName: orders-incoming
        queueLength: "5"
      authenticationRef:
        name: azure-queue-auth

Explanation: minReplicaCount: 0 is what gives true scale-to-zero; queueLength: "5" tells KEDA to add a replica for roughly every 5 queued messages, mirroring the Consumption plan's own queue-scaling heuristic. authenticationRef points at a TriggerAuthentication object — ideally backed by Entra Workload ID rather than a static connection string.

Triggers, Bindings & APIs

Trigger types requiring runtime-driven triggers are supported only in Kubernetes, Azure IoT Edge, and other self-hosted modes — not on the Consumption plan, which is one reason some workloads deliberately choose Kubernetes hosting.

Command Cheat Sheets

Azure Functions Core Tools (func)

az CLI — function app lifecycle

kubectl / helm — Functions-on-Kubernetes operations

Configuration Examples

host.json — extension bundle and concurrency

{
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.*, 5.0.0)"
  },
  "extensions": {
    "queues": {
      "maxPollingInterval": "00:00:02",
      "batchSize": 16
    }
  }
}

Python v2 — HTTP + Service Bus trigger in one app

import azure.functions as func
import json

app = func.FunctionApp(http_auth_level=func.AuthLevel.FUNCTION)

@app.route(route="embed", methods=["POST"])
def embed(req: func.HttpRequest) -> func.HttpResponse:
    body = req.get_json()
    # ... call model, build response ...
    return func.HttpResponse(json.dumps({"ok": True}), mimetype="application/json")

@app.service_bus_queue_trigger(
    arg_name="msg", queue_name="orders-incoming", connection="ServiceBusConnection"
)
def process_order(msg: func.ServiceBusMessage):
    payload = json.loads(msg.get_body().decode())
    # ... process payload ...

Explanation: the runtime opens the connection, holds the message lock, calls the function, and completes/abandons the message automatically based on disposition — no manual receive/complete boilerplate is required.

Dockerfile for a Functions app targeting Kubernetes

FROM mcr.microsoft.com/azure-functions/python:4-python3.11
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
    AzureFunctionsJobHost__Logging__Console__IsEnabled=true
COPY . /home/site/wwwroot
RUN pip install -r /home/site/wwwroot/requirements.txt

TriggerAuthentication backed by Entra Workload Identity

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: azure-queue-auth
  namespace: orders
spec:
  podIdentity:
    provider: azure-workload
    identityId: "<managed-identity-client-id>"

Explanation: this avoids putting a Storage/Service Bus connection string in a Kubernetes Secret — KEDA authenticates to Azure using the same Workload Identity federation pattern used for application pods.

Best Practices

• Default new serverless workloads to Flex Consumption; reserve Premium for genuinely latency-sensitive, always-warm requirements.
• Keep Durable Functions orchestrator code deterministic — push all I/O, randomness, and wall-clock reads into Activity functions.
• Set a realistic functionTimeout in host.json rather than relying on plan defaults, especially on Consumption where the ceiling is short.
• On Kubernetes, size minReplicaCount/maxReplicaCount per ScaledObject deliberately — an unbounded maxReplicaCount can starve cluster capacity from other workloads during a burst.
• Use Entra Workload Identity (via KEDA's TriggerAuthentication with podIdentity.provider: azure-workload) instead of static connection strings for both the function's own bindings and KEDA's scaler authentication.
• For HTTP-triggered functions on Kubernetes, don't rely on default resource-based HPA for scale-to-zero — use an HTTP-aware KEDA scaler.
• Version and pin your extension bundle range in host.json; an unpinned range can silently pull breaking binding changes.
• Load-test with realistic trigger burst patterns before committing to a plan — Consumption's per-function-app scale cap is a common surprise under multi-function fan-out.

Common Mistakes

Performance Considerations

• Cold starts: most pronounced on classic Consumption; Flex Consumption and Premium mitigate via always-ready/pre-warmed instances; on Kubernetes, cold start = pod scheduling + image pull + container start, so image size and node capacity headroom matter directly.
• Trigger scaling granularity: Flex Consumption scales HTTP/SignalR, Durable, and blob (Event Grid) triggers as separate groups, while everything else scales independently per function — this avoids one noisy timer trigger starving HTTP capacity, a real problem on classic Consumption.
• KEDA polling interval: the default polling interval for most scalers is ~30 seconds — tune pollingInterval down for latency-sensitive scale-out, understanding the added load on the metrics source.
• Node capacity on AKS: KEDA can decide to scale a Deployment out, but if no node has room, the pod sits Pending until the cluster's node autoprovisioner (Karpenter) reacts — plan for that extra latency versus Azure-hosted plans' effectively instant compute allocation.
• Durable Functions orchestrator replay: long-running orchestrations with large history logs replay slower over time; use sub-orchestrations or continue-as-new to bound history size.

Security Considerations

• Prefer Microsoft Entra ID-based authentication (managed identity / Workload Identity) over connection-string-based bindings wherever the extension supports it.
• Set the appropriate authLevel (Function/Admin) on HTTP triggers, and rotate function keys regularly if not using Entra auth for HTTP endpoints.
• Restrict inbound access via VNet integration and private endpoints on Flex Consumption/Premium/Dedicated; on AKS, use NetworkPolicy to scope which namespaces can reach the Functions pods.
• On Kubernetes, never store event-source credentials as plain Kubernetes Secrets when a Workload Identity-based TriggerAuthentication is available.
• Keep extension bundles and the Functions runtime major version current — the v1.x runtime is end-of-life and no longer receives security fixes.
• Apply least-privilege RBAC/Azure role assignments to the managed identity backing both the function app and any KEDA scaler authentication.

Troubleshooting Guide

Interview Questions

Revision Cheat Sheet

Glossary