AWS Lambda Preise bestehen aus zwei Positionen je Funktion: einem Preis je Million Aufrufe und einem Preis je GB-Sekunde, also dem konfigurierten Arbeitsspeicher mal der abgerechneten Laufzeit auf die Millisekunde, mit einem niedrigeren Satz für arm64, dazu je GB-Sekunde für temporären Speicher über 512 MB, für Provisioned Concurrency und für SnapStart-Snapshots, und für Lambda@Edge mit eigenen Sätzen. Auf der Rechnung dominieren fast immer die GB-Sekunden, nicht die Aufrufe, und der zweitgrößte Posten einer Lambda-Architektur steht meist nicht unter Lambda, sondern unter CloudWatch für die Logs.
Preisdimensionen
Lambda bepreist die Arbeit, nicht die Bereitstellung: Es gibt keine Instanz, keine Stunde und keinen Speicher, der läuft, während nichts passiert, bis Provisioned Concurrency das ändert. Die Einheit ist die GB-Sekunde, das Produkt aus konfiguriertem Arbeitsspeicher und Laufzeit, und jede Position trägt ihren eigenen Usage Type.
| Dimension | Einheit | Was sie treibt | Optional |
|---|---|---|---|
| Aufrufe | Million Anfragen, die erste Million im Monat frei | Jeder Aufruf, aus welcher Quelle auch immer; ein Wiederholungsversuch zählt neu | Nein |
| Laufzeit | GB-Sekunde in drei Stufen nach Monatsvolumen, die ersten 400.000 frei | Konfigurierter Arbeitsspeicher (128 MB bis 10.240 MB) mal abgerechnete Laufzeit auf die Millisekunde, seit 2025-08-01 einschließlich der INIT-Phase bei jedem Kaltstart | Nein |
| Architektur | Eigener Satz je GB-Sekunde für arm64, ein Fünftel unter x86 | Die Architektur der Funktion; die Stufen gelten je Architektur getrennt | Ja |
| Temporärer Speicher | GB-Sekunde des konfigurierten Speichers über 512 MB | Jede Funktion mit mehr als 512 MB unter /tmp, über die ganze Laufzeit | Ja |
| Provisioned Concurrency | GB-Sekunde je konfigurierter Einheit ab Einschalten, auf fünf Minuten gerundet, plus ein niedrigerer Laufzeitsatz für Aufrufe darüber; ohne Freimenge | Jede Funktionsversion mit eingeschalteter Provisioned Concurrency, ob aufgerufen oder nicht | Ja |
| SnapStart | GB-Sekunde für den gespeicherten Snapshot, mindestens drei Stunden; GB je Wiederherstellung | Jede veröffentlichte Version mit SnapStart, außer bei Java | Ja |
| Lambda@Edge | Million Anfragen und GB-Sekunde zu eigenen, höheren Sätzen, ohne Freimenge | Funktionen, die CloudFront an seinen Standorten ausführt | Ja (CloudFront-Preise) |
| Antwort-Streaming | GB verarbeiteter Antwortdaten über 100 GB im Monat | Funktionen, die ihre Antwort streamen | Ja |
| Logs, Metriken und Traces | Unter CloudWatch und X-Ray, nicht unter Lambda | Jede Zeile, die die Funktion schreibt, und jede Metrik, die sie meldet | Ja (CloudWatch-Preise) |
| Datentransfer | GB nach Standardsätzen, auch zwischen Lambda und dem eigenen VPC | Antworten ins Internet, Zugriffe auf andere Regionen | Ja (Datentransfer-Preise) |
| Kaufoption | Compute Savings Plan auf Laufzeit, Provisioned Concurrency und temporären Speicher, nicht auf Aufrufe | Ein- oder Dreijahreslaufzeit | Ja (AWS Savings Plans) |
Der Preis je Aufruf ist in jeder Region derselbe und klein; was den Preis einer Funktion ausmacht, ist der Arbeitsspeicher. Lambda teilt CPU und Netzwerk proportional zum konfigurierten Speicher zu, sodass eine Funktion mit 1.024 MB doppelt so viel je Millisekunde kostet wie eine mit 512 MB, aber oft weniger als doppelt so schnell läuft; der Preis je Aufruf ist Speicher mal Laufzeit, und das Minimum liegt oft nicht beim kleinsten Speicher. Die abgerechnete Laufzeit wird auf die volle Millisekunde aufgerundet, und seit dem 2025-08-01 zählt die INIT-Phase eines Kaltstarts, also das Laden des Codes und das Ausführen des statischen Initialisierungscodes, bei jeder Konfiguration mit, was vorher nur für Container-Images, eigene Laufzeiten und Provisioned Concurrency galt. Funktionen mit schwerer Initialisierung und vielen Kaltstarts sahen seitdem eine höhere Rechnung bei gleichem Verkehr.
Die Stufen gelten je Architektur und Region auf das Monatsvolumen des Kontos: Bis sechs Milliarden GB-Sekunden auf x86 gilt der erste Satz, bis fünfzehn Milliarden der zweite, darüber der dritte; arm64 hat eigene, höhere Stufengrenzen bei niedrigeren Sätzen. Die Freimenge von einer Million Aufrufen und 400.000 GB-Sekunden im Monat läuft nicht ab, gilt aber nicht für Funktionen mit Provisioned Concurrency. Provisioned Concurrency hält eine konfigurierte Zahl von Ausführungsumgebungen initialisiert und berechnet sie je GB-Sekunde ab dem Einschalten, ob Aufrufe kommen oder nicht; Aufrufe darauf zahlen einen niedrigeren Laufzeitsatz, und Aufrufe über die konfigurierte Zahl hinaus den normalen. Lambda@Edge zählt jede Ausführung an einem CloudFront-Standort als Anfrage zum dreifachen Satz und die Laufzeit zum dreifachen Satz je GB-Sekunde, mit 1 ms Granularität und ohne Freimenge. Function URLs, die Funktionen direkt über HTTPS erreichbar machen, haben keine eigene Position; ihre Aufrufe zählen als Anfragen und Laufzeit. Neben den klassischen Event Functions bepreist AWS inzwischen Web Functions je Anfrage und aktiver CPU-Zeit und MicroVMs je Instanzsekunde; diese Seite beschreibt die Event Functions, auf denen die anderen beiden aufbauen.
So erscheint es in den Abrechnungsdaten
Im Cost and Usage Report tragen die Zeilen den Produktcode AWSLambda, lineItem/Operation Invoke und lineItem/ResourceId den ARN der Funktion; der Usage Type nennt die Dimension, das Präfix ist der Regionscode, EUC1 für Frankfurt. Aufrufe stehen als EUC1-Request und EUC1-Request-ARM, die Laufzeit als EUC1-Lambda-GB-Second und EUC1-Lambda-GB-Second-ARM in GB-Sekunden, wobei die Stufen als getrennte Zeilen desselben Usage Type mit eigenem Satz erscheinen. Die Freimenge steht als Global-Request und Global-Lambda-GB-Second mit Preis 0 und zieht sich über alle Regionen hin, weshalb eine Funktion in Frankfurt im Report teurer aussehen kann als eine in Irland, obwohl beide denselben Satz haben.
Provisioned Concurrency steht als EUC1-Lambda-Provisioned-Concurrency für die konfigurierten GB-Sekunden und EUC1-Lambda-Provisioned-GB-Second für die Laufzeit darauf, jeweils mit -ARM für arm64; der temporäre Speicher als EUC1-Lambda-Storage-GB-Second, SnapStart als EUC1-Lambda-SnapStart-Cached-GB-S und EUC1-Lambda-SnapStart-Restored-GB, das Antwort-Streaming als EUC1-Lambda-Streaming-Response-Processed-Bytes. Lambda@Edge steht als EUC1-Lambda-Edge-Request und EUC1-Lambda-Edge-GB-Second unter dem Regionscode, in dem die Ausführung stattfand, nicht unter dem der Funktion. Das Volumen je Funktion liefert der Report über lineItem/ResourceId; welche Aufrufe wie lange liefen, nur CloudWatch mit Invocations, Duration und der Zeile REPORT im Log, die Billed Duration, Memory Size, Max Memory Used und Init Duration je Aufruf nennt.
Was nicht unter AWSLambda steht: die Logs der Funktionen, die unter AmazonCloudWatch als EUC1-DataProcessing-Bytes und EUC1-TimedStorage-ByteHrs erscheinen, die Traces unter AWSXRay, die Aufrufe über API Gateway unter AmazonApiGateway und der Datentransfer der Antworten. Eine Lambda-Architektur kostet im Report deshalb an vier bis fünf Stellen, und die Funktion selbst ist selten die größte davon. Den Aufbau des Reports beschreibt der AWS Cost and Usage Report. Im FOCUS-Export trägt ServiceName AWS Lambda und x_ServiceCode AWSLambda; Aufrufe, Laufzeit und Provisioned Concurrency sind ChargeCategory Usage, Laufzeit unter einem Compute Savings Plan PricingCategory Committed (FOCUS-Spalten).
Stellhebel
Konfiguration: Der Arbeitsspeicher ist der erste Hebel, weil er den Preis je Millisekunde linear und die Laufzeit nicht linear bestimmt; der günstigste Punkt liegt dort, wo Speicher mal Laufzeit am kleinsten ist, und das zeigt nur eine Messung über mehrere Speichergrößen. Die Architektur ist der zweite: arm64 kostet ein Fünftel weniger je GB-Sekunde und läuft bei vielen Laufzeiten ohne Codeänderung. Das Timeout ist der dritte: Eine Funktion, die auf eine Antwort wartet, zahlt die Wartezeit in GB-Sekunden, weshalb Warten auf Ereignisse in Step Functions oder in Warteschlangen gehört, nicht in die Funktion. Die Initialisierung ist seit 2025-08-01 der vierte: Kleine Pakete, wenige Abhängigkeiten und Initialisierungscode, der nur lädt, was der Handler braucht, verkürzen die INIT-Phase, die bei jedem Kaltstart bezahlt wird; die allgemeine Methode steht unter Serverless-Funktionen.
Kaufoption: Ein Compute Savings Plan senkt den Satz für Laufzeit, Provisioned Concurrency und temporären Speicher gegen eine Stundenzusage über ein oder drei Jahre, über Lambda, Fargate und EC2 hinweg; Aufrufe und Lambda@Edge deckt er nicht. Wo Lambda die Grundlast eines Kontos ist, gehört die Laufzeit in die Rechnung der Commitment-Strategie.
Architektur: Provisioned Concurrency nur für Funktionen, deren Kaltstart ein Nutzer bemerkt, in der Zahl, die der Verkehr tagsüber braucht, mit Zeitplan für die Nacht; SnapStart als günstigere Antwort auf lange Initialisierungen. Logs auf das Nötige beschränken und mit einer Aufbewahrungsfrist versehen, weil jede Zeile unter CloudWatch kostet. Funktionen, die rund um die Uhr unter Last stehen, sind je GB-Sekunde teurer als ein Container auf Fargate oder eine Instanz; die Grenze zeigt der Vergleich in EKS, ECS und Fargate.
Wo es schiefgeht
- Die Rechnung stieg im August 2025 ohne mehr Verkehr. Seit dem 2025-08-01 zählt die INIT-Phase bei jedem Kaltstart. Die Zeile
REPORTim Log zeigtInit Duration; Funktionen mit langer Initialisierung und niedrigem Verkehr verlieren am meisten. - Provisioned Concurrency läuft nachts weiter. Konfigurierte Einheiten kosten je GB-Sekunde, ob Aufrufe kommen oder nicht, und die Freimenge entfällt. Zeilen mit
Lambda-Provisioned-Concurrencyohne Aufrufe in der Nacht sind der Hinweis; Application Auto Scaling mit Zeitplan schaltet sie ab. - Die Funktion wartet und zahlt. Eine Funktion, die zehn Sekunden auf eine Datenbank oder eine API wartet, zahlt zehn Sekunden mal Speicher. Asynchrone Muster über Warteschlangen oder Step Functions nehmen das Warten aus der Funktion.
- Der Speicher ist zu klein, nicht zu groß. Eine Funktion mit 128 MB, die CPU-gebunden ist, läuft achtmal so lange wie mit 1.024 MB und kostet dasselbe oder mehr. Messen Sie die Laufzeit über mehrere Speichergrößen, bevor Sie den kleinsten wählen.
- Die Logs kosten mehr als die Funktion. Debug-Ausgaben in jedem Aufruf erzeugen unter CloudWatch GB je Monat, die unter Lambda nicht sichtbar sind. Loggen Sie strukturiert und mit Aufbewahrungsfrist.
- Wiederholungen verdoppeln die Zeile. Fehlgeschlagene asynchrone Aufrufe werden bis zu zweimal wiederholt, und ein Konsument einer Warteschlange ohne Dead-Letter-Queue versucht es immer wieder. Jeder Versuch zählt als Aufruf und Laufzeit.
- Lambda@Edge rechnet dreifach. Eine Funktion an CloudFront-Standorten zahlt das Dreifache je Anfrage und je GB-Sekunde und keine Freimenge. CloudFront Functions kosten für einfache Header-Änderungen einen Bruchteil davon.
Beispiel
Listenpreise in USD für Frankfurt (eu-central-1), gelesen am 2026-10-21 aus der AWS-Preisliste: Aufrufe kosten 0,20 USD je Million, die Laufzeit 0,0000166667 USD je GB-Sekunde auf x86 bis sechs Milliarden GB-Sekunden im Monat, 0,000015 USD bis fünfzehn Milliarden und 0,0000133334 USD darüber, auf arm64 0,0000133334 USD bis 7,5 Milliarden, 0,0000120001 USD bis 18,75 Milliarden und 0,0000106667 USD darüber. Provisioned Concurrency kostet 0,0000050147 USD je konfigurierter GB-Sekunde und 0,0000117011 USD je GB-Sekunde Laufzeit darauf, auf arm64 0,0000040118 USD und 0,0000093609 USD; temporärer Speicher 0,0000000367 USD je GB-Sekunde über 512 MB; SnapStart 0,0000015046 USD je GB-Sekunde Snapshot und 0,0001398 USD je wiederhergestelltem GB; Lambda@Edge 0,60 USD je Million Anfragen und 0,00005001 USD je GB-Sekunde.
Eine Funktion mit 1.024 MB auf x86, die im Monat zehn Millionen Aufrufe mit im Mittel 200 ms abgerechneter Laufzeit erhält, verbraucht zwei Millionen GB-Sekunden und kostet 33,33 USD Laufzeit plus 2,00 USD Aufrufe, abzüglich 6,67 USD und 0,20 USD Freimenge, zusammen 28,46 USD; dieselbe Funktion auf arm64 kostet 26,67 plus 2,00 abzüglich 5,33 und 0,20, zusammen 23,14 USD. Mit zehn Einheiten Provisioned Concurrency rund um die Uhr kommen 10 × 1 GB × 2.628.000 Sekunden × 0,0000050147 = 131,79 USD hinzu, während die Laufzeit auf 23,40 USD sinkt und die Freimenge entfällt: 157,19 USD statt 28,46 USD, das Fünffache. Dieselbe Funktion mit 2.048 MB temporärem Speicher zahlt für die 1,5 GB über 512 MB 1,5 × 2.000.000 × 0,0000000367 = 0,11 USD. Als Lambda@Edge mit 128 MB und 10 ms je Ausführung kosten dieselben zehn Millionen Aufrufe 6,00 USD Anfragen und 12.500 GB-Sekunden × 0,00005001 = 0,63 USD Laufzeit. Die Zahlen zeigen, dass die Laufzeit in GB-Sekunden die Aufrufe um mehr als das Fünfzehnfache übersteigt, dass arm64 ein knappes Fünftel spart, und dass Provisioned Concurrency aus einer Funktion für 28 USD eine für 157 USD macht, bevor der erste Aufruf kommt.
Quellen
Gelesen am 2026-10-21. Preise: AWS Lambda Pricing, AWS Price List, Angebot AWSLambda für eu-central-1. Abrechnungsdaten: Spalten des Cost and Usage Report: lineItem, FOCUS 1.0 mit AWS-Spalten. Dienst: AWS Lambda standardisiert die Abrechnung der INIT-Phase, Lebenszyklus der Ausführungsumgebung, Provisioned Concurrency, Temporärer Speicher, Function URLs.