Claude Code Azure Functions: Serverless-APIs in Minuten entwickeln und deployen

Azure Functions ist Microsofts Antwort auf Serverless Computing: Code schreiben, deployen, fertig — keine Server provisionieren, keine Container konfigurieren, kein Skalierungskonzept entwerfen. Die Plattform übernimmt alles darunter. Was bleibt, ist die Businesslogik.

Claude Code Azure Functions ist eine natürliche Kombination: Azure Functions hat ein klares, gut strukturiertes Konzept (Triggers, Bindings, Pläne) das sich hervorragend als Kontext übergeben lässt — und Claude Code generiert daraus vollständige, produktionsreife Functions, erklärt Cold-Start-Verhalten, konfiguriert Bindings und debuggt lokale Setups. Dieser Artikel zeigt, wie das konkret funktioniert.

1. Was sind Azure Functions?

Azure Functions ist ein Function-as-a-Service (FaaS)-Dienst auf der Microsoft Azure-Plattform. Das Grundprinzip: Du schreibst eine einzelne Funktion, definierst was sie auslöst (Trigger) und womit sie kommuniziert (Bindings) — der Rest ist Plattformaufgabe.

Das unterscheidet FaaS fundamental von einem klassischen Backend: Kein dauerhaft laufender Prozess, keine idle-Kosten, keine manuelle Skalierung. Eine Function reagiert auf ein Ereignis, läuft, schreibt ihr Ergebnis weg — und ist danach wieder inaktiv. Azure skaliert automatisch auf null, wenn nichts zu tun ist, und auf hunderte parallele Instanzen, wenn der Traffic es verlangt.

Consumption Plan vs. Premium Plan

Azure Functions bietet zwei primäre Hosting-Modelle:

• Consumption Plan: Zahle nur für tatsächliche Ausführungen. Perfekt für unregelmäßigen Traffic und niedrige Grundlast. Nachteil: Cold-Start-Latenz von bis zu mehreren Sekunden, wenn die Function lange nicht aufgerufen wurde.
• Premium Plan: Vorab bereitgestellte, aufgewärmte Instanzen — kein Cold-Start, garantierte Mindestleistung. Höhere Fixkosten, aber vorhersagbare Latenz. Sinnvoll für APIs die auf jede Anfrage in unter 200 ms antworten müssen.
• Dedicated (App Service Plan): Klassisches Hosting auf dedizierten VMs. Sinnvoll wenn du bereits App Service Plans nutzt und Funktionen auf derselben Infrastruktur betreiben willst.

2. Triggers und Bindings verstehen

Das Kernkonzept von Azure Functions ist die saubere Trennung von Trigger (was löst die Function aus?) und Bindings (womit kommuniziert sie?). Wer das verinnerlicht hat, versteht warum Azure Functions so weit skaliert — und warum Claude Code so effektiv dabei hilft, Bindings korrekt zu konfigurieren.

HTTP-Trigger

Der häufigste Trigger: Eine HTTP-Anfrage löst die Function aus. Ideal für REST-APIs, Webhooks und Integrationen mit Drittdiensten.

import azure.functions as func

app = func.FunctionApp()

@app.route(route="hello", methods=["GET", "POST"])
def http_trigger(req: func.HttpRequest) -> func.HttpResponse:
    name = req.params.get("name") or "Welt"
    return func.HttpResponse(
        f"Hallo, {name}!",
        status_code=200
    )

Timer-Trigger

Cron-Syntax definiert den Ausführungsrhythmus. Nützlich für Bereinigungsaufgaben, tägliche Reports, Datensynchronisation:

@app.timer_trigger(schedule="0 0 8 * * *", arg_name="mytimer",
                   run_on_startup=False)
def daily_report(mytimer: func.TimerRequest) -> None:
    # Läuft täglich um 08:00 UTC
    logging.info("Tages-Report gestartet")

Queue- und Blob-Trigger

Für asynchrone Verarbeitung: Queue-Trigger reagieren auf neue Nachrichten in Azure Storage Queues oder Service Bus. Blob-Trigger feuern, wenn eine neue Datei in Azure Blob Storage erscheint:

# Queue-Trigger: verarbeitet jede neue Nachricht
@app.queue_trigger(arg_name="msg", queue_name="auftraege",
                   connection="AzureWebJobsStorage")
def process_queue(msg: func.QueueMessage) -> None:
    body = msg.get_body().decode("utf-8")
    logging.info(f"Verarbeite: {body}")

# Blob-Trigger: reagiert auf neue Uploads
@app.blob_trigger(arg_name="blob", path="uploads/{name}",
                  connection="AzureWebJobsStorage")
def process_upload(blob: func.InputStream) -> None:
    logging.info(f"Neue Datei: {blob.name}, {blob.length} Bytes")

Input und Output Bindings

Bindings sind deklarative Verbindungen zu externen Diensten — ohne Connection-Management-Code. Eine Function kann gleichzeitig aus Blob Storage lesen (Input Binding) und das Ergebnis in eine Queue schreiben (Output Binding), ohne eine einzige Connection-Klasse zu instanziieren:

@app.route(route="transform")
@app.blob_input(arg_name="inputblob",
                path="input/{name}",
                connection="AzureWebJobsStorage")
@app.queue_output(arg_name="outputqueue",
                  queue_name="ergebnisse",
                  connection="AzureWebJobsStorage")
def transform(req: func.HttpRequest,
              inputblob: func.InputStream,
              outputqueue: func.Out[str]) -> func.HttpResponse:
    data = inputblob.read().decode("utf-8")
    outputqueue.set(data.upper())
    return func.HttpResponse("Fertig", status_code=200)

Azure kümmert sich um Authentifizierung, Retry-Logik und Connection-Pooling. Der Function-Code enthält keine Azure-SDK-Aufrufe — nur Businesslogik.

3. Sprachen, function.json und Decorators

Azure Functions unterstützt nativ Python, C#, JavaScript/TypeScript, Java, PowerShell und weitere Sprachen via Custom Handler. Die wichtigsten im Alltag:

• Python: Decorators-Modell (v2) oder function.json (v1). V2 ist die aktuelle Empfehlung — alles in einer Datei, keine JSON-Konfiguration nötig.
• C#: Isolated Worker oder In-Process. Isolated Worker ist der moderne Ansatz und ermöglicht eigene .NET-Versionen unabhängig vom Functions-Host.
• JavaScript/TypeScript: Native asynchrone Unterstützung, ideal für schnelle HTTP-Endpunkte und Event-Verarbeitung.

Im alten Python v1-Modell steuerte function.json Trigger und Bindings als JSON-Datei neben dem Code. Im modernen v2-Modell ersetzen Decorators diese Datei vollständig — Konfiguration und Implementierung leben in derselben Datei, was Refactoring erheblich vereinfacht.

4. Lokale Entwicklung: Core Tools und func start

Azure Functions Core Tools ermöglichen vollständige lokale Entwicklung ohne Cloud-Verbindung. Installation via npm:

npm install -g azure-functions-core-tools@4 --unsafe-perm true

Neues Projekt erstellen und lokal starten:

# Neues Python-Projekt
func init MeinProjekt --python

cd MeinProjekt

# Neue Function hinzufügen
func new --name HttpExample --template "HTTP trigger"

# Lokal starten
func start

Die local.settings.json enthält alle Umgebungsvariablen und Connection-Strings für die lokale Entwicklung. Diese Datei darf nicht ins Repository — sie enthält Credentials und wird von func start automatisch geladen:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "python",
    "MEINE_API_KEY": "lokaler-test-key"
  }
}

Mit Azurite (lokalem Azure Storage Emulator) laufen auch Queue-, Blob- und Table-Trigger vollständig lokal — keine Cloud-Verbindung während der Entwicklung nötig.

5. Deployment und Application Settings

Das einfachste Deployment-Verfahren nutzt die Azure CLI direkt aus dem Projektverzeichnis:

# Function App in Azure erstellen (einmalig)
az functionapp create \
  --resource-group meine-gruppe \
  --consumption-plan-location germanywestcentral \
  --runtime python \
  --runtime-version 3.11 \
  --functions-version 4 \
  --name meine-function-app \
  --storage-account meinstorage

# Code deployen
func azure functionapp publish meine-function-app

Umgebungsvariablen und Secrets werden in Azure als Application Settings gespeichert — das serverseitige Äquivalent zu local.settings.json. Nie direkt in den Code einbauen:

az functionapp config appsettings set \
  --name meine-function-app \
  --resource-group meine-gruppe \
  --settings MEINE_API_KEY="prod-key-hier"

Im Code werden Application Settings wie normale Umgebungsvariablen gelesen: os.environ.get("MEINE_API_KEY") — lokal aus local.settings.json, in Azure aus den Application Settings.

Durable Functions: Überblick

Durable Functions erweitern Azure Functions um zustandsbehaftete Workflows — etwas, was Standard-Functions nicht können. Das Kernkonzept: ein Orchestrator koordiniert mehrere Activity Functions und merkt sich den Zustand zwischen den Schritten, auch wenn der Prozess zwischenzeitlich beendet wird.

Typische Anwendungsfälle: mehrstufige Genehmigungsprozesse, Fan-Out/Fan-In (parallele Verarbeitung, dann Zusammenführung), menschliche Interaktion in Workflows (warte auf externe Bestätigung), und langläufige Prozesse die Stunden oder Tage dauern können.

import azure.durable_functions as df

# Orchestrator
def orchestrator_function(context: df.DurableOrchestrationContext):
    result1 = yield context.call_activity("VerarbeiteA", "input")
    result2 = yield context.call_activity("VerarbeiteB", result1)
    return result2

main = df.Orchestrator.create(orchestrator_function)

6. Claude Code Azure Functions: Konkrete Tipps

Wer Claude Code und Azure Functions kombiniert, spart Zeit an den richtigen Stellen: Function-Boilerplate generieren, Bindings konfigurieren, Cold-Start-Verhalten verstehen, lokale Probleme debuggen. Hier die Workflows, die im Alltag am meisten bringen.

Function mit Trigger generieren lassen

Beschreibe, was die Function tun soll — Claude Code generiert den vollständigen Code inklusive Trigger, Bindings und Fehlerbehandlung:

claude "Erstelle eine Azure Function in Python (v2, Decorators-Modell)
die auf einen HTTP POST Trigger reagiert, die JSON-Body-Daten validiert,
in Azure Table Storage speichert und bei Fehler eine sinnvolle HTTP-Fehlermeldung
zurückgibt. Verwende Table Storage Output Binding."

Claude Code generiert nicht nur den Function-Code, sondern erklärt auch, welche Packages in requirements.txt nötig sind, welche Application Settings gesetzt werden müssen und was in local.settings.json für die lokale Entwicklung konfiguriert werden muss.

Cold-Start analysieren und reduzieren

Cold-Start ist das wichtigste Performance-Thema bei Consumption-Plan Functions. Claude Code kann das Problem analysieren und konkrete Maßnahmen empfehlen:

claude "Meine Azure Function (Python, Consumption Plan) hat gelegentlich
Latenz-Spikes von 3-5 Sekunden. Was sind die häufigsten Cold-Start-Ursachen
bei Python Functions und wie lässt sich die Startup-Zeit reduzieren?
Zeige konkrete Code-Anpassungen."

"Die häufigste Ursache bei Python: Heavy Imports auf Modul-Ebene. Verschiebe imports die nur in bestimmten Code-Pfaden gebraucht werden in die Funktion selbst. Zweite Ursache: große Dependency-Trees. Prüfe via pip show <paket> die transitive Größe — Pandas zieht NumPy und mehr mit, was die Startup-Zeit verdoppeln kann..."

Lokale Debugging-Probleme lösen

Wenn func start einen kryptischen Fehler wirft oder ein Binding lokal nicht funktioniert, ist Claude Code der schnellste Weg zur Lösung:

func start 2>&1 | claude "Was ist das Problem und wie lässt es sich beheben?"

Claude Code liest die Fehlermeldung, fragt ggf. nach local.settings.json-Inhalt (ohne Secrets, nur Struktur) und führt durch die Lösung Schritt für Schritt — ob fehlende Azurite-Konfiguration, falsche Binding-Syntax oder inkompatible Runtime-Version.

Bestehende Function auf v2-Modell migrieren

claude "Migriere diese Azure Function von function.json (v1) auf
das Python v2 Decorator-Modell. Behalte exakt dieselbe Funktionalität."

Claude Code liest function.json und __init__.py, generiert eine neue Datei mit Decorators und erklärt, was sich ändert — inklusive Hinweis auf alle Tests, die angepasst werden müssen.

Verwandte Artikel aus dem Blog:

• Claude Code AWS Lambda — Serverless auf AWS im Vergleich: SAM, Layers, Kaltstart-Optimierung
• Claude Code GitHub Actions — CI/CD-Pipelines generieren, debuggen und optimieren