Zusammenfassung

  • AWS kündigt eine ausdrückliche Wahl direkter S3-Files-Lesezugriffe unabhängig von Lambdas Speichergröße an.
  • Erfolgreiche Ausführung, tatsächlicher Lesepfad und Kostenvorteil sind getrennte Aussagen.

Wer eine andere Speicherzugriffsart möchte, sollte dafür nicht zwangsläufig mehr Rechenressourcen anfordern müssen. Die Lambda-Ankündigung vom 11. September trennt die ausdrückliche Wahl direkter S3-Files-Lesezugriffe von der Speichergröße der Funktion. Sie eröffnet eine zusätzliche Einstellung, keinen nachgewiesenen Preisvorteil.

Die API bietet AUTO, ENABLED und DISABLED und beschreibt einen Rückfall auf das Dateisystem, wenn direktes Lesen scheitert. Das kann eine Ausführung erhalten. Es bedeutet aber auch: Eine erfolgreiche Anfrage belegt noch nicht, dass der beabsichtigte Lesepfad genutzt wurde.

Die CPU bleibt an den Speicher gekoppelt

Lambda weist CPU weiterhin proportional zum konfigurierten Arbeitsspeicher zu. Wer mit dem neuen Schalter weniger Speicher einstellt, kann deshalb zugleich die Lesepräferenz und die verfügbaren Rechenressourcen verändern. Die veränderte Laufzeit gehört in die Bewertung.

Die einfache Rechnung hilft: Halbiert sich der Speicher, während sich die abgerechnete Dauer verdoppelt, bleibt ihr Produkt gleich. Das ist ein Rechenbeispiel, kein AWS-Benchmark. Die Standardabrechnung für Lambda Functions umfasst Anfragen und speichergewichtete Laufzeit. Eine kleinere Megabyte-Zahl entscheidet daher nicht über die Ersparnis.

Beim Speicherdienst greifen andere Zähler. S3 Files unterscheidet Dateisystem-Datenzugriffe von direkten Lesevorgängen, für die weiterhin S3-GET- und Metadaten-Lesekosten anfallen. Eine Gebührenart zu vermeiden macht nicht den gesamten Vorgang kostenlos. Sinnvoll ist der Gesamtaufwand je korrekt erledigter Aufgabe, einschließlich der ausgelösten Speicheraktivität.

Der Schalter ist kein Ablaufprotokoll

Eine sprachliche Grenze der Dokumentation ist ebenfalls wichtig. Die Ankündigung beschreibt eine Aufteilung nach Dateigröße; der API-Eintrag für ENABLED spricht breiter von allen Lesevorgängen. Daraus sollte nicht stillschweigend eine einzige, als geprüft ausgegebene Regel für jede Operation entstehen. Für diesen Bericht wurde kein Laufzeittest durchgeführt.

Der gemeinsame Kern ist klar: Eine ausdrückliche Lesepräferenz lässt sich unabhängig vom Speicher setzen. Der genaue Weg jeder einzelnen Operation einer gemischten Arbeitslast folgt daraus allein jedoch nicht.

Eine Anwendung mit vielen kleinen Lesevorgängen und eine andere, die einen großen Datenbestand durchläuft, können unterschiedliche Einstellungen brauchen. Das sind Analysebeispiele, keine gemessenen Kundenfälle. Das Team muss sehen, wo Zeit verbraucht wird und welche Gebühren sich verschieben. Sonst kann eine Speicheroptimierung langsamere Berechnung verdecken; ein erfolgreicher Rückfall kann unbemerkt die Vergleichsbedingungen ändern.