Lambda-Speicher-Kosten entstehen aus der Speichergröße, die eine Funktion je Aufruf reserviert, multipliziert mit ihrer Laufzeit; überprovisioniertes Serverless ist derselbe Fehler in jeder Form: zu viel Speicher je Funktion, Mindestinstanzen, die nachts leer laufen, immer bereite Instanzen für einen Endpunkt mit drei Aufrufen pro Stunde. Die Einsparung entsteht, weil Serverless je Sekunde und je reservierter Einheit abrechnet und jede Einheit, die niemand braucht, sofort aus der Rechnung fällt. Die Behebung gehört dem Team, das die Funktion oder den Dienst betreibt, weil nur ein Lasttest sagt, welche Einstellung reicht.

Symptom

Die Rechnung zeigt GB-Sekunden und Instanzstunden, die nicht zur Zahl der Anfragen passen. Bei AWS sind das Positionen mit lineItem/UsageType EUC1-Lambda-GB-Second oder EUC1-Lambda-GB-Second-ARM neben EUC1-Request, deren Verhältnis die mittleren GB-Sekunden je Aufruf ergibt, und Lambda-Provisioned-Concurrency-Positionen, die rund um die Uhr laufen. Bei Azure stehen die Flex-Consumption-Meter für Ausführungszeit und für die immer bereiten Instanzen unter MeterCategory Functions, und bei Container Apps die vCPU- und Speichermeter mit ihrem Leerlaufanteil. In Google Cloud trägt Cloud Run die SKUs für CPU- und Speicherzuteilungszeit, bei instanzbasierter Abrechnung über die gesamte Lebensdauer der Instanz. Was ein Serverless-Dienst grundsätzlich berechnet, steht in Serverless-Funktionen; diese Seite behandelt die drei Einstellungen, die den Betrag ohne Nutzen vervielfachen.

Anfragen: EUC1-RequestGB-Sekunden je Aufruf:Lambda-GB-Second geteiltdurch die AnfragenPositionen rund um die Uhr:Provisioned Concurrency,immer bereite Instanzen,instanzbasierte Cloud-Run-AbrechnungSDrei Einstellungenvervielfachen den Betragohne Nutzen
Überdimensionierung zeigt sich als GB-Sekunden je Aufruf und als Positionen reservierter Kapazität, die der Zahl der Anfragen nicht folgen

So erkennen Sie es

AWS

Lambda reserviert je Funktion 128 MB bis 10.240 MB in Schritten von 1 MB, und die CPU-Leistung wächst mit dem Speicher; eine Funktion mit zu wenig Speicher läuft länger, eine mit zu viel zahlt für Kapazität, die sie nicht nutzt (gelesen am 2026-10-21). Die Funktionen mit ihren Einstellungen:

aws lambda list-functions --query 'Functions[].[FunctionName,MemorySize,Timeout,Architectures[0],PackageType]' --output table

Die reservierten Kapazitäten, die unabhängig von Aufrufen laufen: aws lambda list-provisioned-concurrency-configs --function-name <fn>. Die Empfehlungen von Compute Optimizer für die Speichergröße, aus 14 Tagen Aufrufen:

aws compute-optimizer get-lambda-function-recommendations \
  --query 'lambdaFunctionRecommendations[].[functionArn,currentMemorySize,finding,memorySizeRecommendationOptions[0].memorySize]' --output table

Trusted Advisor führt daneben die Prüfungen "AWS Lambda over-provisioned functions for memory size" und "AWS Lambda functions with excessive timeouts", die Funktionen melden, bei denen an einem Tag der letzten sieben mehr als 10 Prozent der Aufrufe in ein Timeout laufen; jedes Timeout ist die volle Laufzeit zum vollen Speicher. Den tatsächlichen Verlauf misst AWS Lambda Power Tuning, eine Step-Functions-Zustandsmaschine unter Apache-2.0-Lizenz, die eine Funktion mit mehreren Speichergrößen aufruft und die Einstellung für Kosten, Geschwindigkeit oder beides empfiehlt. In den Abrechnungsdaten sind die GB-Sekunden je Funktion über lineItem/ResourceId zu sehen (AWS Cost and Usage Report).

Azure

Im Flex-Consumption-Plan von Azure Functions sind immer bereite Instanzen die Position, die ohne Aufrufe läuft: ihr Grundbetrag wird in GB-Sekunden über die gesamte Zeit berechnet, ohne die kostenlosen Kontingente des Bedarfsmodus, bei Instanzgrößen von 512, 2.048 und 4.096 MB (Flex Consumption). Die Einstellung je App:

az functionapp list --query "[].{name:name, rg:resourceGroup, plan:appServicePlanId}" -o table
az functionapp scale config show --name <app> --resource-group <rg>

Bei Container Apps läuft eine Revision mit Mindestreplikaten über null auch ohne Anfragen; ein Replikat gilt erst als Leerlauf, wenn es keine HTTP-Anfragen verarbeitet, unter 0,01 vCPU-Kernen bleibt und weniger als 1.000 Bytes pro Sekunde empfängt, und wird dann zum reduzierten Satz berechnet (Abrechnung von Container Apps):

az containerapp list --query "[].{name:name, rg:resourceGroup, min:properties.template.scale.minReplicas, max:properties.template.scale.maxReplicas, cpu:properties.template.containers[0].resources.cpu}" -o table

Azure Advisor empfiehlt zu Container Apps und Functions keine Mindestinstanzen; die Metrik Replica Count gegen Requests je App ist der Nachweis. Im Kostenexport sind die Meter je ResourceId unter MeterCategory Functions beziehungsweise Azure Container Apps zu finden (Azure-Kostenexporte).

Google Cloud

Cloud Run kennt zwei Abrechnungsarten: anfragebasiert, bei der eine Instanz nur während der Verarbeitung von Anfragen, beim Start und beim Herunterfahren berechnet wird, und instanzbasiert, bei der die ganze Lebensdauer zählt und die CPU immer zugeteilt bleibt; Mindestinstanzen werden in beiden Fällen berechnet, anfragebasiert zu einem niedrigeren Leerlaufsatz, instanzbasiert zum vollen Satz (CPU-Zuteilung, Mindestinstanzen). Die Dienste und ihre Einstellungen:

gcloud run services list --format="table(metadata.name,metadata.namespace,status.url)"
gcloud run services describe <service> --region=<region> --format="yaml(spec.template.metadata.annotations)"

Die Annotationen autoscaling.knative.dev/minScale und run.googleapis.com/cpu-throttling tragen die beiden Einstellungen. Der Recommender google.run.service.CostRecommender schlägt die CPU-Zuteilung vor, die zum Anfragemuster passt (Recommender-Übersicht):

gcloud recommender recommendations list --project=<project-id> --location=<region> \
  --recommender=google.run.service.CostRecommender --format="table(name.basename(),description,stateInfo.state)"

Im Abrechnungsexport stehen die Zuteilungszeiten je resource.name unter service.description Cloud Run (Google-Cloud-Abrechnungsexport).

So beheben Sie es

  1. Speicher messen statt schätzen: Power Tuning je Lambda-Funktion mit der Strategie cost laufen lassen und die empfohlene Größe mit aws lambda update-function-configuration --function-name <fn> --memory-size 512 setzen; das Timeout auf die gemessene Laufzeit plus Reserve senken, damit ein hängender Aufruf nicht die Maximaldauer zahlt.
  2. Reservierte Kapazität auf die Stunden begrenzen, in denen sie gebraucht wird: Provisioned Concurrency mit Application Auto Scaling nach Zeitplan, immer bereite Instanzen bei Azure mit az functionapp scale config always-ready set --resource-group <rg> --name <app> --settings http=1 auf die Gruppe, die den Kaltstart nicht verträgt, Mindestreplikate bei Container Apps mit az containerapp update --name <app> --resource-group <rg> --min-replicas 0 für Umgebungen ohne Latenzanforderung.
  3. Bei Cloud Run die Abrechnungsart zur Last wählen: gcloud run services update <service> --region=<region> --cpu-throttling für Dienste, die nur auf Anfragen arbeiten, --no-cpu-throttling nur für Dienste mit Hintergrundarbeit; Mindestinstanzen mit --min-instances 0 dort, wo ein Kaltstart erlaubt ist.
  4. Die Einstellungen in die Vorlage schreiben, aus der neue Funktionen und Dienste entstehen, mit einem Standard von null Mindestinstanzen und einer begründeten Ausnahme je Dienst.

Keine dieser Änderungen hat ein Dry-Run; die Liste aus dem ersten Schritt und ein Vergleich der Latenz nach der Änderung ersetzen es. Die Wirkung zeigt der Tagesexport nach der Änderung.

janeinneinjaSpeicher mit Power Tuningmessen, die Größe setzenund das Timeout senkenVerträgt der Diensteinen Kaltstart?Null Mindestinstanzen, keineimmer bereiten InstanzenReservierte Kapazitätnur in den Stunden, indenen sie gebraucht wird,nach ZeitplanHintergrundarbeitzwischen Anfragen?Cloud Run: CPU nurwährend der AnfrageCPU über die gesamteLebensdauer der InstanzDie Einstellungen in dieVorlage schreiben: nullMindestinstanzen alsStandard, eine begründeteAusnahme je DienstKein Dry-Run: die Liste undein Latenzvergleich nach derÄnderung ersetzen es
Der Speicher wird gemessen, reservierte Kapazität bleibt auf die Stunden begrenzt, die sie brauchen, und die Vorlage macht null Mindestinstanzen zum Standard

Risiken und Nebenwirkungen

  • Weniger Speicher kann teurer werden: bei Lambda sinkt mit dem Speicher die CPU-Leistung, eine CPU-gebundene Funktion läuft länger, und GB-Sekunden sind Speicher mal Zeit. Power Tuning zeigt das Minimum der Kurve, nicht die kleinste Zahl.
  • Null Mindestinstanzen heißt Kaltstarts; ein Dienst mit Latenzzusage braucht die Reserve, und die Frage ist dann ihre Größe und ihr Zeitplan, nicht ihr Wegfall.
  • Ein Timeout, das zu knapp sitzt, bricht legitime Aufrufe ab; die gemessene Verteilung der Laufzeiten, nicht der Mittelwert, bestimmt den Wert.
  • Instanzbasierte Abrechnung bei Cloud Run ist für Dienste mit Hintergrundarbeit die richtige Wahl; die Umstellung auf anfragebasiert stoppt diese Arbeit zwischen den Anfragen.
  • Ein Compute Savings Plan deckt Lambda-Dauer mit ab; die Einsparung senkt dann die abgedeckte Nutzung, und die Auslastung des Plans ist zu prüfen (Commitment-Abdeckung und -Auslastung).

So weisen Sie die Einsparung nach

Vorher: je Funktion oder Dienst die GB-Sekunden, Instanzstunden oder Zuteilungszeiten und die Zahl der Anfragen im letzten vollen Monat, und daraus der Betrag je tausend Anfragen. Nachher: dieselbe Kennzahl im ersten vollen Monat nach der Änderung bei gleicher oder höherer Anfragezahl; die Position für reservierte Kapazität muss auf die geplanten Stunden fallen. Der Vorschlag aus Compute Optimizer, Power Tuning oder dem Recommender ist die Schätzung, die Zustimmung des Teams macht sie akzeptiert, die Änderung umgesetzt, und die Rechnung des Folgemonats belegt sie nach dem Muster von geschätzt, akzeptiert, umgesetzt, verifiziert. Die Latenzmetrik des Dienstes gehört neben den Betrag, damit die Einsparung nicht mit einer Verschlechterung bezahlt wurde.

Quellen

Gelesen am 2026-10-21. AWS Lambda, Preise, Compute Optimizer, Lambda-Empfehlungen, Trusted Advisor, Kostenoptimierungsprüfungen, AWS Lambda Power Tuning, Azure Functions, Flex-Consumption-Plan, Flex Consumption verwalten, Abrechnung von Azure Container Apps, Cloud Run, CPU-Zuteilung, Cloud Run, Mindestinstanzen, Recommender-Übersicht.