AWS Lambda Kosten optimieren: warum die kleinste Einstellung selten die günstigste ist

Eine Cloud-Rechnung für so einen Dienst lässt sich leicht ignorieren – bis es zu spät ist. Du zahlst nur dann, wenn dein Code tatsächlich läuft, jeweils Bruchteile eines Cents, und so bleibt die Summe eine Weile klein genug, dass niemand hinschaut. Dann wächst der Traffic, ein paar Gewohnheiten summieren sich, und die monatliche Zahl verdoppelt sich klammheimlich. Genau darum geht es bei AWS Lambda, dem Dienst von Amazon, der kleine Code-Schnipsel auf Abruf ausführt und nur nach Nutzung abrechnet: Du übergibst Amazon deinen Code, Amazon führt ihn aus, sobald irgendetwas ihn auslöst, und es gibt keinen Server, den du monatlich mieten musst. Der Reiz liegt auf der Hand. Der Haken: Die Rechnung setzt sich aus einer Handvoll Posten zusammen, die kaum jemand liest – und einer davon verhält sich genau umgekehrt zu dem, was die Intuition erwartet.

Die Produktseite von AWS Lambda: Rechenleistung auf Abruf, abgerechnet nur, solange dein Code läuft.

Wo das Geld wirklich hingeht

Auf einer Lambda-Rechnung bewegen sich nur ein paar Posten wirklich. Der größte ist die Rechenzeit: die Zeit, die dein Code zum Laufen braucht, abgerechnet im Bruchteil einer Sekunde und multipliziert mit der Menge an Speicher, die du ihm gegeben hast. Amazons Einheit dafür ist die GB-Sekunde – nichts anderes als Speicher mal Laufzeit, und kein Stück mysteriöser als das. Der zweite Posten ist eine feste Gebühr pro Aufruf, eine Art Maut von wenigen Cent pro Million Aufrufe, die du fast nie drücken kannst, ohne schlicht weniger Traffic zu schicken. Der dritte ist der, der sich versteckt: die Logs, die dein Code bei jedem Lauf schreibt – unter einem eigenen Posten abgerechnet und standardmäßig für immer aufbewahrt.

Die Preisseite von AWS Lambda: die Zähler pro Aufruf und pro GB-Sekunde, die den Großteil der Rechnung ausmachen.

Was du wissen solltest, bevor du dir Sorgen machst: Amazon verschenkt jeden Monat ein Kontingent an Nutzung. Die erste Million Aufrufe und ein großzügiger Block an Rechenzeit kosten nichts, sodass ein kleines Projekt oft bei null bleibt, bis es in den kostenpflichtigen Bereich hineinwächst.

Warum eine größere Einstellung weniger kosten kann

Jetzt kommt der Teil, der fast alle überrascht. Die Menge an Speicher, die du einer Funktion gibst, ist zugleich die Menge an Rechenleistung, die sie bekommt. Verlangst du mehr Speicher, gibt Amazon dem Code ein schnelleres Stück Chip. Und weil die Rechnung Speicher mal Zeit ist, gilt: Eine zu knapp eingestellte Funktion kann so langsam laufen, dass sie mehr kostet als dieselbe Funktion mit mehr Leistung, die in einem Bruchteil der Zeit fertig ist. Hungerst du sie aus, kriecht sie nur noch dahin – die günstig aussehende Einstellung gewinnt auf dem Papier und verliert auf der Rechnung.

Ein kleines Beispiel macht es greifbar. Stell dir eine Funktion auf der niedrigsten Speichereinstellung vor, die eine volle Sekunde für ihre Aufgabe braucht – und dieselbe Funktion mit der vierfachen Speichermenge, die in einer Viertelsekunde fertig ist. Du zahlst jetzt den vierfachen Tarif, aber nur für ein Viertel der Zeit, also landen beide Rechnungen ungefähr beim selben Betrag – nur dass die größere fast augenblicklich fertig ist und niemand warten muss. Treibst du es weiter, kippt die Rechnung oft komplett in die andere Richtung: Irgendwo in der Mitte bezahlt sich das Tempo mehr als nur selbst, und die Gesamtsumme sinkt tatsächlich. Die ausgehungerte Einstellung war nie das Schnäppchen, nach dem sie aussah.

In dieser Kurve gibt es einen optimalen Punkt – und das ist fast nie die kleinste Einstellung. Es ist aber auch nicht die größte, bei der du für Leistung zahlst, die der Code gar nicht nutzen kann. Der einzige ehrliche Weg, ihn zu finden, ist die gleiche Funktion mit ein paar verschiedenen Speicherstufen laufen zu lassen und zu vergleichen, was jede tatsächlich kostet, statt zu raten – denn die richtige Antwort hängt davon ab, was der Code tut, und verschiebt sich von Funktion zu Funktion. Das ist die eine Idee, die du von hier mitnehmen solltest: Beim Bezahlen nach Nutzung sind günstiger und kleiner nicht dasselbe. Sobald du das siehst, hört der Rest der Rechnung auf, ein Rätsel zu sein, und wird zu einer Reihe von Entscheidungen.

Die Stellschrauben, die wirklich helfen

Ein paar weitere Hebel zahlen sich aus. Jeder ist kleiner als die Speicherfrage, aber leicht und kostenlos zu haben, sobald du weißt, dass es ihn gibt.

Amazon betreibt unter Lambda zwei Sorten von Prozessoren, und die eigenen Chips aus dem Hause Amazon kosten rund 20 % weniger bei gleichem Speicher, während sie tendenziell sogar einen Tick schneller laufen. Der Wechsel ist meist eine einzige Einstellung. Heikel wird es nur bei Software, die speziell für den älteren Chip gebaut wurde – die muss erst neu gebaut werden, also lohnt es sich, das vorher an einer sicheren Stelle zu testen, bevor du das laufende System umstellst.

Dann sind da diese Logs, und sie verdienen einen zweiten Blick, weil sie der Posten sind, dessen Existenz man vergisst. Jedes Mal, wenn eine Funktion läuft, kann sie eine Notiz darüber schreiben, was sie getan hat – und solche Notizen sind praktisch, wenn etwas kaputtgeht. Das Problem ist das Standardverhalten: Die meisten Funktionen schreiben weit mehr Details, als je jemand liest, und die Aufzeichnungen werden für immer aufbewahrt, solange du nichts anderes sagst. Eine gesprächige Funktion, die über Millionen von Aufrufen hinweg ein vollständiges Tagebuch jedes einzelnen Aufrufs führt, kann klammheimlich eine größere Log-Rechnung verursachen als der Code, den sie eigentlich überwachen soll. Die Aufzeichnungen häufen sich einfach an, Monat für Monat, für eine Fehlersuche, die längst vorbei ist. Zwei ruhige Korrekturen decken das ab: dem System sagen, dass es alte Logs nach ein paar Wochen löschen soll, und im Produktivbetrieb die Detailtiefe herunterdrehen, sodass es echte Probleme festhält, statt jeden Schritt zu kommentieren. Beides rührt den Code nicht an, und zusammen löschen sie oft einen Posten, der größer geworden war als die Rechenzeit daneben.

Es gibt auch die Versuchung, für Tempo zu bezahlen. Wenn eine Funktion eine Weile untätig war, ist ihr erster Lauf nach der Pause etwas langsamer, während die Umgebung aufwacht – eine Verzögerung, die als Cold Start bekannt ist. Amazon hält die Umgebungen für dich dauerhaft warm, sodass diese Verzögerung nie auftritt, berechnet diese Wärme aber rund um die Uhr, egal ob jemand aufruft oder nicht. Bei den meisten Workloads ist das Geld, das für untätige Kapazität um drei Uhr morgens ausgegeben wird. Für das Warmhalten zu zahlen ist eine Ausgabe, keine Ersparnis, und es rechnet sich nur bei einer Funktion mit Kundenkontakt, bei der diese Verzögerung beim ersten Aufruf wirklich spürbar ist.

Ein großzügiges Zeitlimit ist dasselbe stille Leck. Einer Funktion wird oft weit mehr Zeit zum Fertigwerden zugestanden, als sie je braucht – was bei einem gesunden Lauf nichts kostet, weil du nur für die genutzte Zeit zahlst. Es kostet dich bei den schlechten Läufen: Ein hängengebliebener Aufruf, der nach ein paar Sekunden aufgegeben hätte, wird jetzt für eine volle Minute abgerechnet, bevor er das tut. Das Limit nah an der tatsächlich benötigten Dauer zu setzen, verwandelt einen Ausreißer in ein schnelles, billiges Scheitern.

Die Gewohnheit, die wirklich Geld spart

Achte darauf, was all das gemeinsam hat. Keine einzige dieser Korrekturen beginnt mit dem Kürzen. Jede beginnt damit, die Rechnung zu lesen und zu sehen, welcher Posten tatsächlich groß ist – denn blind zu optimieren ist die Art, einen ganzen Nachmittag damit zu verbringen, ein paar Prozent von einem Posten abzuknapsen, der ohnehin schon klein war. AWS Lambda Kosten optimieren läuft im Kern auf diese Gewohnheit hinaus: zuerst die Kostenaufschlüsselung öffnen, den dominierenden Posten finden und genau dort ansetzen. Oft stellt sich die Funktion, die das Budget auffrisst, als eine heraus, auf die niemand achtet – nach einem Test laufen gelassen, der eigentlich nur vorübergehend sein sollte.

Und weil jede Optimierung mit der Zeit verfällt, zählt der letzte Schritt am meisten. Jemand hebt ein Limit an, eine neue Funktion geht mit der Standardeinstellung in Betrieb, eine alte Log-Gruppe rutscht zurück darauf, alles für immer aufzubewahren. Ein einfacher Budget-Alarm, der dich etwa bei 80 % der erwarteten Monatsausgaben warnt, macht aus der nächsten Überraschung eine E-Mail statt einer Quartalsrechnung. Das Feintuning lohnt sich einmal. Der Alarm ist das, was es dabei hält.

Häufig gestellte Fragen

Wie stark kann eine Rechnung realistisch sinken?

Das hängt ganz davon ab, welcher Posten von Anfang an aufgebläht war. Die beiden Änderungen, die sich gegenseitig verstärken – die richtige Speichereinstellung finden und auf den günstigeren Chip wechseln – holen für eine nie abgestimmte Funktion üblicherweise 40 bis 60 % von der Rechenzeit heraus. War in Wahrheit das Logging der Übeltäter, lässt sich prozentual sogar noch mehr einsparen, wenn man es zurechtstutzt. Die feste Gebühr pro Aufruf bewegt sich kaum, also kommt die echte Ersparnis aus Rechenzeit und Logs, nicht aus den Aufrufen selbst.

Kostet es immer mehr, einer Funktion mehr Speicher zu geben?

Nein – und genau das verstehen die meisten falsch herum. Du zahlst für Speicher mal Laufzeit, und mehr Speicher kauft mehr Rechenleistung, sodass die Arbeit oft schnell genug fertig ist, dass der kürzere Lauf den höheren Tarif ausgleicht. Genau deshalb kann eine zu knapp eingestellte Funktion mehr kosten als dieselbe mit mehr Spielraum. Der ehrliche Weg, das zu klären, ist ein paar Einstellungen zu messen und die günstigste zu behalten, statt anzunehmen, dass die kleinste gewinnt.

Ist der günstigere Chip immer die bessere Wahl?

Fast immer, denn dieselbe Arbeit kostet auf Amazons eigenen Chips rund 20 % weniger und läuft meist mindestens genauso schnell. Die Ausnahme ist Software, die speziell für den älteren Chip gebaut wurde und erst neu gebaut werden muss, bevor sie auf dem neueren läuft. Teste sie an einer sicheren Stelle, prüfe, dass die Laufzeit nicht schlechter wird, und behalte die Kombination, die in der Praxis wirklich günstiger ist.

Sollte ich fürs Warmhalten von Code zahlen, um zu sparen?

Meistens nicht. Code dauerhaft warmzuhalten beseitigt die Verzögerung beim ersten Aufruf, fügt aber Kosten hinzu, statt sie zu senken, weil du diese Wärme auch dann bezahlst, wenn niemand aufruft. Heb es dir für eine Funktion mit Kundenkontakt auf, bei der die Verzögerung wirklich auffällt, und fahre es in ruhigen Stunden herunter. Bei gleichmäßiger, vorhersehbarer Nutzung spart eine längerfristige Ausgabenzusage an Amazon Geld, ohne dass du für untätige Kapazität zahlst.