Die Messlücke: Warum die Energieverbrauchsmessung bei Serverless so schwierig ist

Serverlose Plattformen wie Vercel sind auf Bequemlichkeit und Skalierbarkeit optimiert, nicht auf Transparenz. Daher ist die Messung ihres Energieverbrauchs alles andere als trivial. Abstraktionen, Multi-Tenancy und fehlende Transparenz verbergen die physische Realität hinter deinem Code. Entwickelnde sind auf Proxy-Metriken angewiesen, die zwar etwas beschreiben, aber niemals die ganze Wahrheit liefern. Solange Cloud-Anbietende keine echten Energiezahlen veröffentlichen, machen wir fundierte Schätzungen im Dunkeln.

Du kannst deine App optimieren, das Bundle verkleinern und perfekte Lighthouse-Scores erreichen. Doch wenn jemand fragt, wie viel Energie dein System wirklich verbraucht, ist die ehrliche Antwort: Wir wissen es nicht wirklich. Diese Metriken sind großartig für die Performance, aber sie verraten wenig über den tatsächlichen Stromverbrauch hinter den Kulissen. Serverless basiert auf der Idee, dass es egal ist, wo dein Code läuft. Das ist effizient für Teams, aber katastrophal für die Messung. Diese Abstraktion ist großartig für die Produktivität, aber sie trennt Software von den Hardware-Realitäten, die den Energieverbrauch bestimmen. Gleichzeitig führen genau diese Abstraktionen dazu, dass Serverless-Anbietende ihre Hardware extrem effizient auslasten können, was die Plattformen trotz schlechter Messbarkeit häufig „grüner“ macht.

Deine Funktion läuft nicht auf „einem Server“. Sie kann überall laufen, auf Hunderten von Maschinen in mehreren Regionen. Traditionelles Hosting erlaubte eine direkte Messung des physischen Energieverbrauchs. Serverless macht das komplett unmöglich.

Eine serverlose Funktion läuft auf einer geteilten Maschine. Vielleicht laufen gerade 50 weitere Funktionen auf derselben Hardware. Selbst wenn wir wüssten, dass der Server in diesem Moment 150 Watt verbraucht, ist es unmöglich, einen passenden Anteil für deine Funktion zu bestimmen, ohne die CPU-Nutzung, den Speicherbandbreitendurchsatz und die I/O-Muster aller Nutzende zu kennen. Cloud-Anbietende haben diese Daten intern, aber die Echtzeit-Offenlegung für Millionen von Funktionen bringt technische und wettbewerbsrechtliche Herausforderungen mit sich.

Während die oben genannten Probleme für alle serverlosen Plattformen gelten, unterscheiden sich die Anbietenden darin, was sie offenlegen. Vercel, das auf AWS Lambda basiert, erbt die Einschränkungen von Lambda, fügt aber eine weitere Abstraktionsschicht hinzu. Du erhältst Bereitstellungsmetriken und Edge-Netzwerkstatistiken, aber die zugrunde liegenden Lambda-Ausführungsdetails bleiben verborgen. Andere Plattformen wie Cloudflare Workers oder AWS Lambda bieten leicht unterschiedliche Metriken, aber keine echten Energieverbrauchsdaten.

Vercel stellt nur wenige Metriken zur Verfügung:

• Ausführungszeit: Wie lange deine Funktion lief
• Verwendeter Speicher: Tatsächlich während der Ausführung genutzter Speicher
• Zugewiesener Speicher: Gesamter für die Funktion reservierter Speicher
• Region: Geografischer Standort der Ausführung
• Cache-Status: Ob die Antwort aus dem Cache stammt
• Instanz-ID: Eindeutige Kennung für die Containerinstanz Damit ist eine Trendanalyse möglich, aber kein vollständiges Bild.

Daraus schätzen wir die Energie mit Proxy-Metriken wie Speicher-Zeit:

Das Modell geht von einer linearen Skalierung aus. In Wirklichkeit verändern CPU-Last, I/O-Wartezeiten und Speicherzugriffsmuster den Energieverbrauch stark. Zwei Funktionen mit identischem Memory-Time-Wert können sehr unterschiedlichen Energiebedarf haben je nachdem, ob sie rechnen oder nur auf ein langsames API warten.

Diese Formel eignet sich für interne Trendanalysen, aber nicht für absolute Werte oder Plattformvergleiche. Deshalb nutzen viele Teams am Ende die Kosten selbst als Proxy. Da sie aus Laufzeit, Speicher und Netzwerkverbrauch entstehen, spiegeln sie dieselben Ressourcen wider, die auch Energie verbrauchen.

Selbst wenn wir Compute-Energie genau hätten, fehlen drei weitere große Blöcke:

Die Power Usage Effectiveness (PUE) beschreibt, wie effizient ein Rechenzentrum ist. Eine PUE von 1,0 wäre perfekt. Höhere Werte bedeuten, dass zusätzliche Energie für Kühlung und sonstige Infrastruktur benötigt wird.

Rechenzentren verbrauchen zusätzliche Energie für Kühlung und Infrastruktur. AWS gibt für 2024 einen globalen durchschnittlichen PUE-Wert von 1,15 an. Das bedeutet: Für jede 100 Watt, die die Server selbst benötigen, kommen weitere 15 Watt für Kühlung und sonstige Infrastruktur hinzu. Der effizienteste europäische AWS-Standort erreichte einen PUE von 1,04 (AWS Data Center Sustainability).

Allerdings variiert der PUE je nach Rechenzentrum, Jahreszeit und aktueller Auslastung stark. Eine Funktion, die in einem modernen Rechenzentrum im Winter ausgeführt wird, könnte beispielsweise einen PUE von 1,10 haben, während dieselbe Funktion in einem älteren, tropischen Rechenzentrum auf einen Wert von 1,40 kommen könnte. Ohne PUE-Daten auf Ebene einzelner Funktionsaufrufe bleibt man auf statistische Durchschnittswerte angewiesen, die große reale Unterschiede verbergen.

Jede Anfrage wandert durch Router, Switches und Netze. Diese Energie wird nie deinem Workload zugeschrieben. Ein vermeintlich leichter API-Call kann im Netzwerk ähnlich viel Energie verbrauchen wie im Compute-Teil.

Etwa 30 % der Gesamtemissionen eines Servers fallen bei Herstellung, Transport und Entsorgung an.

Ein typischer Server verursacht über seinen gesamten Lebenszyklus hinweg etwa 1.726 kg CO₂e an „embodied emissions“, also Emissionen, die bei Herstellung, Transport und Entsorgung entstehen (Data Centre and Server Hardware Carbon). Auf eine erwartete Nutzungsdauer von sechs Jahren (AWS Server Lebensdauer) umgelegt, entspricht das rund 288 kg CO₂e pro Jahr. Auf Millionen von Funktionsaufrufen verteilt wirkt dieser Anteil pro Request zwar vernachlässigbar. In der Gesamtsumme macht der embodied carbon jedoch je nach Nutzungsmuster und Hardware-Refresh-Zyklen etwa 15-30 % der gesamten Lebenszyklus-Emissionen eines Rechenzentrums aus.

Eine exakte Zuteilung auf einzelne Funktionsaufrufe ist aktuell nicht möglich.

Auch ohne perfekte Sichtbarkeit gibt es sinnvolle Maßnahmen:

Relative Veränderungen sind wertvoll: Wenn nach einem Deployment Speicher oder Dauer um 40 % steigen, ist der Energieverbrauch wahrscheinlich ebenfalls gestiegen. Gleichzeitig lassen sich hier die Kosten heranziehen. Wenn die Ausführung teurer wird, bedeutet das meist auch höheren Energieverbrauch. Proxy-Metriken zeigen reale Anstiege an, die einer Untersuchung wert sind, selbst wenn die exakten Wattstunden unbekannt bleiben.

Cold Starts treten auf, wenn eine serverlose Funktion zum ersten Mal oder nach einer Phase der Inaktivität initialisiert wird. In diesem Fall muss die Plattform Dependencies laden, Verbindungen herstellen und die Ausführungsumgebung konfigurieren. Untersuchungen zeigen, dass Cold Starts einen Overhead verursachen können, der um ein Vielfaches mehr Energie verbraucht als Warmaufrufe von Funktionen.

Durch kleinere Bundles, weniger Abhängigkeiten und strategisches Caching lässt sich sowohl die Häufigkeit als auch der Initialisierungsaufwand reduzieren.

• Weniger Speicher → weniger DRAM-Energie
• Kürzere Dauer → weniger CPU-Energie
• Mehr Cache-Hits → weniger Rechen- und Netzwerkaufwand
• Weniger Fehler/Wiederholungen → weniger verschwendete Energie
• Geringere Kosten → weniger Rechen- und Speichernutzung

Die CO₂-Intensität gibt an, wie viele Gramm CO₂ pro erzeugter Kilowattstunde Strom ausgestoßen werden (Carbon Intensity by Country (Electricity Maps)). Der weltweite Durchschnitt liegt bei etwa 481 Gramm CO₂ pro kWh, doch die regionalen Unterschiede sind enorm.

Norwegen, dessen Strommix stark auf Wasserkraft basiert, verursacht nur rund 30 Gramm CO₂ pro kWh. In Indien hingegen, wo der Strom größtenteils aus Kohle stammt, liegt der Wert bei über 700 Gramm CO₂ pro kWh, ein nahezu 24-facher Unterschied. Wenn man Proxy-Metriken mit dem tatsächlichen Traffic-Anteil pro Region und deren CO₂-Intensität gewichtet, erhält man eine deutlich realistischere Einschätzung des ökologischen Fußabdrucks, als wenn man für alle Regionen denselben Emissionswert ansetzt.

Wir brauchen echte Transparenz: Energieverbrauch pro Funktion, Echtzeit-PUE-Werte, Zuordnung von Netzwerkenergie und standardisierte Berichtformate wie die Software Carbon Intensity (SCI)-Spezifikation, inzwischen als ISO/IEC 21031:2024 anerkannt.

Die technische Infrastruktur zur Messung dieser Daten existiert bereits. Sie wird schon für Kapazitätsplanung und Abrechnung genutzt. Die Herausforderung besteht darin, diese Informationen zugänglich zu machen, ohne wettbewerbsrelevante Details über Effizienz oder Hardwarekonfigurationen der Rechenzentren preiszugeben. Ein realistischer erster Schritt könnten aggregierte Energiewerte auf Projekt- oder Kontoebene sein, sodass Teams Trends verfolgen können, ohne Infrastrukturdetails offenlegen zu müssen.

Fordere Energiedaten als Kriterium bei der Anbietendenauswahl ein. Vergleiche Plattformen nicht nur nach Preis und Performance, sondern auch nach Nachhaltigkeitszielen und Messmöglichkeiten. Teile Ansätze zur Messung, normalisiere Diskussionen über Energieeffizienz in Code-Reviews und behandle Energie als gleichwertige Metrik neben Latenz und Kosten.

Etabliert gemeinsame Benchmarks, APIs für Energiedaten, Integration in CI/CD. Beispielsweise Energieverbrauch pro Build-Schritt sichtbar machen.

Der ITK-Sektor verursacht derzeit etwa 4 % der weltweiten Treibhausgasemissionen und dieser Anteil dürfte bei Fortsetzung der aktuellen Trends stark steigen. Die Nutzung von Serverless-Lösungen wächst rasant. Selbst wenn die Nutzung von serverless, im vergleich zu traditionellem Hosting "grüner" ist, können kleine Verbesserungen, die im großen Maßstab wirken, zu spürbaren Einsparungen führen.

Man sieht vielleicht nicht die exakten Wattstunden, aber Code für Geschwindigkeit und Effizienz zu optimieren bedeutet fast immer geringeren Energieverbrauch und einen kleineren CO₂-Fußabdruck. Eine Reduktion der Ausführungszeit um 20 % über Milliarden von Funktionsaufrufen hinweg spart monatlich Megawattstunden an Energie.

Auch wenn die Grenzen unserer Messbarkeit uns heute noch einschränken, liegt in Serverless-Architekturen bereits ein Schritt in die richtige Richtung. Sie ermöglichen eine insgesamt „grünere“ Nutzung von Rechenressourcen. Fehlende Perfektion darf uns dabei nicht bremsen. Entscheidend ist, dass wir mit dem arbeiten, was sichtbar ist und die technologische Entwicklung in eine nachhaltigere Richtung lenken.

Perfekte Zahlen sind zweitrangig. Entscheidend ist, dass wir handeln.

• AWS Data Center Sustainability
• Software Carbon Intensity Specification (ISO/IEC 21031:2024)
• Data Center Hardware Carbon Footprint
• Reducing Environmental Impact with Sustainable Serverless Computing
• Green Software Foundation
• Electricity Maps - Live Carbon Intensity
• AWS Server Lifespan