Lambda@Edge Request-Flow: Viewer Request und Viewer Response laufen am CloudFront-Edge-Standort nah am User, Origin Request und Origin Response laufen auf dem Weg zum Backend.

01Standard-Lambda hat eine Heimat

Und die ist oft einen Kontinent weit weg.

Eine klassische Lambda-Funktion läuft in genau einer Region. Sagen wir eu-central-2 in Zürich. Wenn ein User aus Sydney zugreift, reist die Request einmal quer über den Pazifik, die Funktion antwortet, die Antwort reist zurück. 200 bis 400 Millisekunden extra, bevor dein Code überhaupt anfängt.

Für viele Anwendungen ist das fein. Für Auth-Checks, Security-Header oder Routing-Entscheidungen, die bei jeder Request passieren, ist es Verschwendung.

02Lambda@Edge dreht das um

Dein Code läuft dort, wo der User ist.

Lambda@Edge deployed deine Funktion auf über 400 CloudFront-Edge-Standorte weltweit. AWS repliziert den Code global, CloudFront führt ihn am Standort aus, der dem User am nächsten ist. 10 bis 50 Millisekunden statt 200 bis 400, egal wo die Request herkommt.

Du schreibst die Funktion wie eine normale Lambda (JavaScript oder Python). Der einzige Unterschied ist, wo sie läuft und wann sie getriggert wird.

03Die vier Trigger-Punkte

Vier Momente im CloudFront-Request-Lifecycle, an denen du eingreifen kannst.

  • Viewer RequestLäuft bevor CloudFront den Cache prüft. Perfekt für Auth-Checks, Redirects, URL-Rewrites, Bot-Detection. Wenn du hier eine Request ablehnst, sieht dein Backend sie nie.
  • Origin RequestLäuft bevor die Request die Origin trifft (aber nur bei Cache-Miss). Gut für Header-Manipulation, die nicht im Cache-Key landen soll, und für Origin-Routing.
  • Origin ResponseLäuft nachdem die Origin geantwortet hat, bevor das Ergebnis cached wird. Ideal für Response-Sanitization, das Hinzufügen von Metadaten, das Umbauen von Backend-Fehlern.
  • Viewer ResponseLäuft direkt bevor der User die Response bekommt. Der richtige Platz für Security-Header wie CSP, HSTS, X-Frame-Options und Referrer-Policy.

04Was du damit baust

Edge-Use-Cases, die sich wirklich lohnen.

  • Edge-Authentifizierung, Cognito-JWTs werden am Edge validiert, ungültige Tokens treffen nie die Origin
  • Security-Header zentral, CSP, HSTS, X-Frame-Options auf einmal für die ganze Seite, ohne Anpassung im Backend
  • Geolocation-Routing, CH-User an Zürich, EU-User an Frankfurt, US-User an us-east-1, basierend auf CloudFront-Country-Header
  • A/B-Testing am CDN, 10 % der Viewer Requests werden auf eine andere Origin umgeleitet, ohne Änderung im App-Code
  • URL-Rewrites und Pretty-URLs, /impressum wird auf /impressum.html umgeschrieben, bevor die Origin es sieht
  • Bot- und Crawler-Handling, Abuse-Requests abfangen, legitime Crawler durchlassen, alles am Edge

05Die harten Limits

Was Lambda@Edge nicht ist.

  • Viewer-Trigger: max. 128 MB RAM, 5 Sekunden Timeout, 1 MB Package
  • Origin-Trigger: max. 10 GB RAM, 30 Sekunden Timeout, 50 MB Package
  • Keine VPC, kein Zugriff auf private RDS, keine Security-Groups
  • Keine Environment Variables, Konfiguration muss im Code oder via signiertem Config-Fetch kommen
  • Deployment ist global, bis zu 15 Minuten Replikations-Delay pro Version
  • Supported Runtimes: Node.js und Python, keine neuen Versionen sofort verfügbar

Lambda@Edge ist kein Ersatz für klassische Lambda. Es ist für schnelle Checks, Header-Manipulation und Routing. Datenbank-Calls und Heavy-Compute gehören woanders hin.

06In Produktion bei SCMC

Der komplette Auth-Flow läuft am Edge.

Bei SCMC.ch validiert Lambda@Edge jede geschützte Request auf Viewer Request, bevor CloudFront überhaupt in den Cache schaut. JWT geprüft, Claims extrahiert, Request durchgelassen oder mit 401 abgewiesen. Security-Header kommen auf Viewer Response dazu, CSP, HSTS, X-Frame-Options, Referrer-Policy, einmalig für die ganze Site.

Das Ergebnis: ungültige Requests treffen die Origin nie. Das spart Compute-Kosten, senkt die Latenz für legitime User, und hält die Backend-Code-Base frei von Auth-Boilerplate.

Am Edge gehört nicht alles hin. Aber das, was dorthin gehört, nirgendwo sonst.