
Cloudflare Workers oder AWS Lambda: Die Laufzeit bestimmt die Rechnung

Cloudflare Workers kann für viele kurze API-Aufrufe günstiger sein, wenn die Funktion wenig CPU-Zeit benötigt und überwiegend auf Netzwerkantworten wartet. AWS Lambda Event Functions kann bei seltenen Hintergrundjobs vom kostenlosen Kontingent profitieren; für eine Verarbeitung mit hohem Speicherbedarf bietet Lambda zudem mehr Spielraum. Welche Plattform weniger kostet, hängt deshalb auch davon ab, wie lange der Code aktiv rechnet, wie lange der Aufruf insgesamt dauert und wie viel Speicher er benötigt.
Die Workers-Preistabelle nennt für Paid einen Mindestbetrag von 5 US-Dollar pro Monat mit 10 Millionen enthaltenen Anfragen und 30 Millionen CPU-Millisekunden; danach kosten weitere Anfragen 0,30 US-Dollar je Million und weitere CPU-Zeit 0,02 US-Dollar je Million Millisekunden. AWS Lambda Event Functions werden dagegen nach Anfragen und Ausführungsdauer in GB-Sekunden berechnet; monatlich sind eine Million Anfragen und 400.000 GB-Sekunden kostenlos enthalten. Für die folgenden Lambda-Rechnungen gelten die auf der AWS-Seite verwendeten x86-Beispielpreise für US East (N. Virginia): 0,0000166667 US-Dollar je GB-Sekunde und 0,20 US-Dollar je weiterer Million Anfragen.
Was die Laufzeitmodelle erfassen
Bei Workers belastet das Warten auf einen Netzwerkaufruf den CPU-Zähler nicht wie die aktive Ausführung von Code. Die verstrichene Zeit kann trotzdem für die Antwortzeit einer API wichtig sein. Bei Lambda Event Functions wird die abgerechnete Ausführungsdauer mit dem zugewiesenen Speicher multipliziert. Zwei Funktionen mit gleich vielen Aufrufen können deshalb sehr unterschiedliche Rechnungen erzeugen, selbst wenn sie für Nutzer dieselbe Aufgabe erfüllen.
Die Speicherwahl ist bei Lambda auch eine Leistungsentscheidung: Mit mehr zugewiesenem Speicher stehen der Funktion anteilig mehr CPU-Ressourcen zur Verfügung. Eine höhere Speicherstufe erhöht somit den Preis pro Sekunde, kann aber die Ausführung verkürzen. Workers bietet keinen vergleichbaren Regler für zugewiesenen Arbeitsspeicher; mehr aktive Rechenarbeit erhöht dort die abgerechneten CPU-Millisekunden. Der bloße Vergleich von Aufrufzahlen lässt diese Unterschiede verschwinden.
Drei bedingte Rechenfälle

Jeder Fall beschreibt einen eigenen Monat mit sonst ungenutzten Kontingenten. Die angenommenen Laufzeiten sind keine Messwerte und setzen keine gleiche Ausführungsgeschwindigkeit auf beiden Plattformen voraus. Die Beträge sind auf Cent gerundet und betreffen nur die Funktionen; Steuern, Datenverkehr und zusätzliche Dienste bleiben außerhalb der Rechnung.
Kurze API mit Wartezeit
Angenommen, eine API erhält 50 Millionen Aufrufe im Monat. Der Worker benötigt je Aufruf 2 Millisekunden CPU-Zeit. Für Lambda werden 128 MB zugewiesener Speicher und 200 Millisekunden abgerechnete Dauer je Aufruf angesetzt. Die längere Lambda-Dauer ist hier eine Annahme für einen Aufruf mit Wartezeit, kein gemessener Latenzunterschied.
Workers verbraucht damit 100 Millionen CPU-Millisekunden. Über den enthaltenen Mengen liegen 40 Millionen Anfragen für 12 US-Dollar und 70 Millionen CPU-Millisekunden für 1,40 US-Dollar. Zusammen mit dem Mindestbetrag ergibt das 18,40 US-Dollar. Bei Lambda entstehen 1,25 Millionen GB-Sekunden; nach Abzug des kostenlosen Kontingents kosten 850.000 GB-Sekunden rund 14,17 US-Dollar. Für 49 Millionen zusätzliche Anfragen kommen 9,80 US-Dollar hinzu, insgesamt also rund 23,97 US-Dollar. Bei kürzerer Lambda-Dauer oder höherer Worker-CPU-Zeit kann die Reihenfolge wechseln.
Rechenintensiver stündlicher Cronjob
Im zweiten Fall läuft ein Job 720-mal im Monat und beansprucht je Ausführung 180 Sekunden CPU-Zeit bei Workers. Das ergibt 129,6 Millionen CPU-Millisekunden. Für die 99,6 Millionen Millisekunden oberhalb des enthaltenen Kontingents fallen rund 1,99 US-Dollar an; mit dem monatlichen Mindestbetrag sind es rund 6,99 US-Dollar. Die angenommene CPU-Zeit liegt innerhalb des für stündliche Cron Triggers vorgesehenen Limits.
Die separate Lambda-Annahme lautet 1 GB zugewiesener Speicher und 180 Sekunden abgerechnete Dauer je Lauf. Daraus folgen 129.600 GB-Sekunden und 720 Anfragen, beides innerhalb der kostenlosen Monatskontingente. Der reine Lambda-Funktionspreis beträgt unter diesen Bedingungen 0 US-Dollar. Das Ergebnis setzt voraus, dass keine anderen Lambda-Funktionen des Kontos die Kontingente bereits nutzen. Bei CPU-lastigem Code kann sich die tatsächliche Dauer mit der gewählten Speicherstufe ändern.
Verarbeitung mit großem Arbeitssatz
Angenommen, ein Verarbeitungsschritt muss 512 MB gleichzeitig im Arbeitsspeicher halten und wird eine Million Mal im Monat aufgerufen. Die Workers-Limits erlauben pro Isolate 128 MB einschließlich JavaScript-Heap und WebAssembly-Zuweisungen. Dieser Arbeitssatz passt daher nicht unverändert in einen einzelnen Worker-Isolate. Streaming oder eine Aufteilung der Verarbeitung könnte den Speicherbedarf je Schritt senken, würde aber eine andere Architektur voraussetzen.
Für Lambda werden 1 GB zugewiesener Speicher und zwei Sekunden abgerechnete Dauer je Aufruf angenommen. Eine Million Aufrufe erzeugen so zwei Millionen GB-Sekunden; nach Abzug von 400.000 kostenlosen GB-Sekunden bleiben rund 26,67 US-Dollar Rechenkosten. Die Anfragen liegen innerhalb des kostenlosen Anfragekontingents. Die Lambda-Kontingente erlauben für gewöhnliche Funktionen 128 bis 10.240 MB Speicher und eine Laufzeit von bis zu 15 Minuten pro Aufruf. In diesem Fall entscheidet die Speichergrenze vor dem Preisvergleich.
Kaltstarts und Antwortzeit getrennt bewerten

Die Kostenbeispiele sagen nichts über die Antwortzeit einer produktiven API aus. Eine EuroSys-Studie untersuchte eine minimale Funktion, die lediglich eine leere Antwort liefert: Für die getesteten AWS-Lambda-Konfigurationen mit Long Polling lag der durchschnittliche Plattform-Overhead bei etwa 1,17 Millisekunden; der für Cloudflare Workers berichtete Wert lag unter Cloudflares Auflösung von 0,01 Millisekunden. Die Untersuchung wertete dazu von den Anbietern gemeldete Ausführungsdauern aus. Diese Werte beschreiben den Versuchsaufbau und sind weder allgemeine Kaltstartzeiten noch die gesamte Antwortzeit einer Anwendung.
Bei einer API mit Datenbankzugriff kommen Initialisierung, Bibliotheken und die Netzstrecke zur Datenbank hinzu. Auch die Verteilung der Anfragen beeinflusst, wie oft eine Ausführungsumgebung neu starten muss. Ein kleiner Unterschied beim Plattform-Overhead kann bei einem entfernten Dienst gegenüber dessen Wartezeit in den Hintergrund treten. Für die Kostenrechnung bleiben dennoch die jeweils abgerechneten Laufzeitgrößen maßgeblich.
Datenverkehr verändert die Gesamtrechnung
Im Workers-Paid-Tarif fallen für den Worker-Datenverkehr keine zusätzlichen Egress- oder Bandbreitengebühren an. Bei Lambda Event Functions kann Datenverkehr in eine andere AWS-Region oder von außerhalb der ausführenden Region zusätzliche Kosten auslösen; Transfers zu bestimmten AWS-Diensten innerhalb derselben Region sind ausgenommen. Hinzu kommen gegebenenfalls Kosten für einen API-Einstieg, Datenbankzugriffe, Speicher oder besondere Bereitstellungsoptionen. Keine dieser Positionen steckt in den drei Funktionsrechnungen.
Für kurze Aufrufe mit wenig CPU-Arbeit zeigt das API-Beispiel einen Vorteil für Workers, während im seltenen Cronjob Lambdas kostenloses Kontingent den reinen Funktionspreis bestimmt. Beim großen Arbeitssatz entfällt der direkte Vergleich derselben Ausführung wegen der Workers-Speichergrenze. Für einen konkreten Workload müssen deshalb Aufrufzahl, aktive CPU-Zeit, abgerechnete Dauer, Speicherbedarf und Datenweg gemeinsam betrachtet werden.
Lesen Sie auch:
Ähnliche Artikel


Lambda leiht sich 926 Millionen Dollar – die Rechenchips dienen als Sicherheit

Playwright oder Cypress: Cypress koppelt Parallelität an die Cloud

PACMAN steuert Fusionsplasma – fünf Experimente bestanden den Echtzeittest

AWS Activate oder Google Cloud: Die Förderhöhe allein führt in die Irre

Asana oder monday.com: Automationslimits entscheiden vor dem Funktionsumfang
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.