Es ist Ende 2025, und eine weitere AWS re:Invent ist gerade zu Ende gegangen, aber als Ingenieur, der tief in der Materie steckt, finde ich mich weniger mit den brandneuen Ankündigungen als vielmehr mit denen beschäftigt, die sich im vergangenen Jahr wirklich weiterentwickelt haben. Insbesondere die bahnbrechenden Entwicklungen, die auf der re:Invent 2023 in Bezug auf die Skalierbarkeit von AWS Lambda und die Einführung von Amazon S3 Express One Zone vorgestellt wurden, haben die Art und Weise, wie wir Hochleistungs-Serverless- und Speicherarchitekturen angehen, grundlegend verändert. Dies sind keine neuen Funktionen; es sind ausgereifte Tools, die wir auf Herz und Nieren geprüft haben, und die Zahlen erzählen eine interessante Geschichte.
Lassen Sie uns den Marketing-Hype durchbrechen und uns mit Benchmarks und den unvermeidlichen Kompromissen in die praktischen Realitäten dieser Updates vertiefen.
Das neue Skalierungsparadigma von AWS Lambda: Die Engpässe beseitigen
Jahrelang war die Achillesferse für viele stark burstfähige Serverless-Anwendungen auf AWS Lambda nicht die Ausführungsgeschwindigkeit einzelner Funktionen, sondern die Geschwindigkeit, mit der Lambda neue Ausführungsumgebungen bereitstellen konnte. Vor der re:Invent 2023 skalierte Lambda synchron aufgerufene Funktionen, indem es in der ersten Minute (abhängig von der Region) 500 bis 3.000 neue Ausführungsumgebungen erstellte, gefolgt von zusätzlichen 500 Umgebungen jede Minute. Entscheidend ist, dass diese Skalierungskontingente für alle Lambda-Funktionen innerhalb eines Kontos in einer bestimmten Region gemeinsam genutzt wurden. Das bedeutete, dass ein plötzlicher Anstieg des Traffics auf eine beliebte Funktion eine andere kritische Funktion um die notwendige Skalierungskapazität bringen konnte, was zu Drosselungen und erhöhten Latenzzeiten führte.
Die Zahlen erzählen eine interessante Geschichte: 12x schneller, unabhängige Skalierung
Die Ankündigung auf der re:Invent 2023 veränderte diese Dynamik grundlegend. AWS Lambda skaliert jede synchron aufgerufene Funktion nun bis zu 12-mal schneller und ermöglicht die Bereitstellung von 1.000 gleichzeitigen Ausführungen alle 10 Sekunden. Noch wirkungsvoller ist, dass jede Funktion nun unabhängig skaliert, bis das gleichzeitige Ausführungslimit des Kontos erreicht ist. Dies ist eine bedeutende Veränderung.
Hier ein direkter Vergleich:
- Vor der re:Invent 2023: Erster Burst von 500-3000 gleichzeitigen Ausführungen in der ersten Minute, dann +500/Minute, gemeinsam genutzt über das Konto.
- Nach der re:Invent 2023: Erster Burst von 1.000 gleichzeitigen Ausführungen alle 10 Sekunden (d.h. 6.000 pro Minute), pro Funktion, unabhängig.
Dies führt zu einem deutlich reaktionsschnelleren System für ereignisgesteuerte Architekturen. Betrachten Sie ein Szenario mit einem API-Endpunkt, der von Lambda unterstützt wird, und einer SQS-Warteschlange, die asynchrone Aufgaben verarbeitet, die beide gleichzeitig Spitzen erleben. Im alten Modell konnte die Skalierung der API durch die Nachfrage des Warteschlangenprozessors behindert werden, oder umgekehrt. Jetzt können beide aggressiv skalieren, um die Nachfrage zu decken, wobei jede ihren Anteil an der gesamten Parallelität des Kontos verbraucht, ohne die Hochfahrgeschwindigkeit des anderen direkt zu beeinträchtigen.
Beispielsweise profitieren auch die Verarbeitung von Nachrichten aus SQS- und Kafka-Ereignisquellen, was eine schnellere Nachrichtenverarbeitung und reduzierte Warteschlangenstaus während Spitzenzeiten ermöglicht. Wir haben beobachtet, dass dies die Notwendigkeit aggressiver Vorwärmstrategien oder Überprovisionierung für viele unserer burstfähigen Workloads drastisch reduziert.
Realitätscheck: Immer noch eine spielweite auf Kontoebene
Obwohl die pro-Funktion unabhängige Skalierung eine robuste Verbesserung darstellt, ist es wichtig zu bedenken, dass das Limit für die gleichzeitige Ausführung auf Kontoebene weiterhin besteht. Wenn Ihre Gesamt-Nachfrage über alle Funktionen dieses Limit überschreitet, werden Sie immer noch Drosselungen erleben. Das Standardkontingent beträgt typischerweise 1.000 gleichzeitige Ausführungen, kann aber auf Anfrage deutlich erhöht werden. Die Implikation hier ist, dass einzelne Funktionen zwar agiler sind, die Gesamt-Kapazitätsplanung und die Überwachung der Parallelität auf Kontoebene jedoch weiterhin entscheidend sind.
Darüber hinaus kann diese schnelle Skalierung Engpässe in nachgelagerten Diensten aufdecken. Ein API Gateway mit seinem Standardlimit von 10.000 Anfragen pro Sekunde könnte zum neuen Drosselpunkt werden, wenn Ihre Lambda-Funktionen nun viel schneller skalieren, als Ihr API Gateway Anfragen verarbeiten kann. Eine architektonische Überprüfung des gesamten Anfragepfads, nicht nur von Lambda, ist wichtiger denn je.
Ein kurzes Codebeispiel (konzeptionell):
Stellen Sie sich eine Python Lambda-Funktion vor, die durch eine HTTP API Gateway-Anfrage ausgelöst wird:
# app.py
import json
import os
import time
# Simulate some initial setup/dependency loading (pre-handler initialization)
# This code runs once per execution environment (cold start)
GLOBAL_RESOURCE = os.getenv('GLOBAL_RESOURCE', 'initialized')
print(f"[{os.getpid()}] Global resource: {GLOBAL_RESOURCE} (initialized at {time.time()})")
def lambda_handler(event, context):
start_time = time.monotonic()
# Simulate work that scales with invocation
payload = json.loads(event.get('body', '{}'))
task_duration = int(payload.get('duration_ms', 50)) / 1000.0
time.sleep(task_duration) # Simulate I/O or CPU work
end_time = time.monotonic()
response_time_ms = (end_time - start_time) * 1000
print(f"[{os.getpid()}] Invocation completed in {response_time_ms:.2f}ms")
return {
'statusCode': 200,
'body': json.dumps({
'message': f'Processed in {response_time_ms:.2f}ms',
'pid': os.getpid(),
'global_resource': GLOBAL_RESOURCE
})
}
Mit der verbesserten Skalierung würde die Bereitstellung dieser Funktion und das Senden eines plötzlichen Anstiegs an Anfragen dazu führen, dass neue pids (neue Ausführungsumgebungen) viel schneller und konsistenter hochfahren, wodurch das System die Last viel effektiver absorbieren kann, vorausgesetzt, die Parallelität des Kontos und die nachgelagerten Dienste können mithalten.
Die zugrunde liegende Plattformstabilität: Amazon Linux 2023
Eine leisere, aber grundlegende Verbesserung der re:Invent 2023 war die Einführung von Amazon Linux 2023 (AL2023) als verwaltete Laufzeit und Container-Basisimage für Lambda. AL2023 bietet eine reine Betriebssystemumgebung mit einem kleineren Bereitstellungs-Footprint, aktualisierten Bibliotheken (wie glibc) und einem neuen Paketmanager im Vergleich zu seinem Vorgänger, AL2. Dies ist kein direkter Leistungsverstärker wie die Skalierung, sondern eine solide Plattformverbesserung, die zu effizienteren benutzerdefinierten Laufzeiten beiträgt und als Grundlage für zukünftige verwaltete Lambda-Laufzeiten (z. B. Node.js 20, Python 3.12, Java 21) dient. Kleinere Basisimages bedeuten potenziell schnellere Downloadzeiten während Kaltstarts und eine modernere, sicherere Umgebung.
S3 Express One Zone: Eine neue Stufe für die leistungsrelevanten Anwendungen
Seit fast zwei Jahrzehnten ist Amazon S3 der Arbeitspferd des Cloud-Speichers, bekannt für seine Skalierbarkeit, Haltbarkeit und Vielseitigkeit. Für extrem latenzarme, hochfrequente (Queries Per Second) Workloads wie Machine-Learning-Training, interaktive Analytik oder High-Performance-Computing führte die Multi-AZ-Architektur von S3 Standard jedoch zu einer inhärenten Netzwerklatenz, die zu einem Engpass werden konnte. Benutzerdefinierte Caching-Layer wurden oft eingesetzt, was die Komplexität und den betrieblichen Aufwand erhöhte.
Das "Warum" und "Was": Millisekunden im einstelligen Bereich, Millionen von Anfragen
Hier kommt Amazon S3 Express One Zone ins Spiel, das auf der re:Invent 2023 angekündigt wurde. Diese neue Speicherklasse wurde speziell entwickelt, um den schnellsten Cloud-Objektspeicher zu liefern und eine konsistente Latenz im einstelligen Millisekundenbereich und die Fähigkeit zu skalieren, Hunderte von Tausend Anfragen pro Sekunde, sogar Millionen von Anfragen pro Minute, für häufig abgerufene Daten zu versprechen. Der wichtigste architektonische Unterscheidungspunkt ist seine Bereitstellung in einer einzigen Availability Zone (AZ).
Architektonische Nuancen für Leistung:
- Directory Buckets: Um seine hohen TPS-Ziele zu erreichen, führt S3 Express One Zone einen neuen Bucket-Typ ein: Directory Buckets. Im Gegensatz zu allgemeinen S3-Buckets, die inkrementell skaliert werden, sind Directory Buckets für die sofortige Skalierung auf Hunderttausende von Anfragen pro Sekunde ausgelegt. Dies ist ein entscheidender Unterschied bei der Optimierung für extremen Durchsatz.
- Co-Location mit Compute: Durch die Speicherung von Daten innerhalb einer einzigen AZ können Sie Ihre Compute-Ressourcen (EC2, ECS, EKS) in derselben AZ co-locieren, wodurch die Netzwerklatenz zwischen Compute und Speicher drastisch reduziert wird. Dies ist der Punkt, an dem ein erheblicher Teil der Leistungssteigerung erzielt wird, da Inter-AZ-Hops minimiert werden.
- Session-basierte Authentifizierung: Eine neue
CreateSession-API wird eingeführt, die für eine schnellere Authentifizierung und Autorisierung von Anfragen optimiert ist und so wertvolle Millisekunden vom Anfragepfad abträgt.
Benchmarks & Vergleiche: Die rohe Leistung
AWS behauptet, dass S3 Express One Zone bis zu 10-mal schneller ist als S3 Standard. Bei kleinen Objekten, bei denen die Zeit bis zum ersten Byte ein dominierender Faktor ist, ist der Vorteil besonders ausgeprägt. In internen Tests auf der re:Invent 2023 zeigte der Download von 100.000 Objekten einen Durchsatz von etwa 9 GB/s für S3 Express im Vergleich zu 1 GB/s für S3 Standard, mit durchschnittlichen Latenzzeiten von 80 ms für S3 Standard, die auf Millisekunden im einstelligen Bereich für S3 Express sanken.
Über die rohe Geschwindigkeit hinaus bietet S3 Express One Zone auch 50 % niedrigere Anfragekosten im Vergleich zu S3 Standard. Dies führt in Kombination mit einer effizienteren Compute-Nutzung (weniger Leerlaufzeit beim Warten auf Speicher) zu Gesamtkostenreduktionen, wobei einige Kunden eine Reduzierung der Gesamtkosten um bis zu 60 % für bestimmte Anwendungen feststellten.
Diese Speicherklasse ist eine praktische Wahl für:
- KI/ML-Training und -Inferenz: Wo Modelle häufig auf riesige, oft kleine Datensätze zugreifen.
- Interaktive Analytik: Beschleunigung der Abfragezeiten für Dienste wie Athena oder EMR.
- Medienverarbeitung: Insbesondere für Workflows, die einen schnellen Zugriff auf viele kleine Medienressourcen erfordern.
- High-Performance-Computing: Jeder Workload, der extrem I/O-gebunden ist.
Realitätscheck: Kompromisse bei Haltbarkeit und Verwaltung
Der Hauptkompromiss bei S3 Express One Zone ist sein Haltbarkeitsmodell mit einer einzigen AZ. Obwohl es innerhalb dieser einzelnen AZ 11 Neunen Haltbarkeit bietet (erzielt durch End-to-End-Integritätsprüfungen, redundante Speicherung über mehrere Geräte und kontinuierliche Überwachung), ist es nicht widerstandsfähig gegen den Verlust oder die Beschädigung einer gesamten Availability Zone. Das bedeutet, dass im Falle eines katastrophalen AZ-Ausfalls (z. B. Feuer, Wasserschaden) Daten, die nur in S3 Express One Zone in dieser AZ gespeichert sind, verloren gehen könnten.
Für geschäftskritische Daten müssen Kunden explizit Cross-AZ-Redundanz oder Backup-Lösungen erstellen (z. B. Replikation nach S3 Standard in einer anderen AZ). Dies fügt eine architektonische Verantwortungsebene hinzu, die S3 Standards regionale Haltbarkeit abstrahiert.
Ein weiterer Punkt, der berücksichtigt werden muss, ist die Einführung eines neuen Bucket-Typs ("Directory"). Obwohl er funktional leistungsstark ist, erhöht er die Komplexität der S3-Bucket-Verwaltung, da Entwickler zwischen allgemeinen und Directory-Buckets basierend auf ihren Zugriffsmustern und Leistungsanforderungen wählen müssen. Die Speicherkosten pro GB sind ebenfalls höher als bei S3 Standard, werden aber, wie bereits erwähnt, oft durch reduzierte Anfragekosten und eine erhöhte Compute-Effizienz ausgeglichen.
Praktische Implikationen und der Weg nach vorn
Ein Jahr nach ihrer Ankündigung haben sich sowohl Lambdas verbesserte Skalierung als auch S3 Express One Zone als robuste und effiziente Ergänzungen zum AWS-Toolkit erwiesen. Wir haben gesehen, wie sie reaktionsschnellere Anwendungen ermöglichen, bestimmte architektonische Muster vereinfachen (z. B. das Entfernen benutzerdefinierter Caching-Layer für den Hochleistungsspeicherzugriff) und durch optimierte Compute-Nutzung greifbare Kosteneinsparungen ermöglichen.
Die unabhängige Skalierung von Lambda-Funktionen hat unsere Fähigkeit, unvorhersehbare Verkehrsanstiege ohne komplexe Vorwärmung oder Angst vor Ressourcenkonflikten zwischen Diensten zu bewältigen, deutlich verbessert. Für S3 hat die Express One Zone-Klasse Türen für Workloads geöffnet, die zuvor durch die Objektspeicherlatenz eingeschränkt waren, insbesondere im aufstrebenden KI/ML-Bereich. Der explizite Kompromiss bei der Haltbarkeit für extreme Leistung ist eine klare Designentscheidung, die Entwickler aktiv berücksichtigen müssen, und kein Versäumnis.
Diese Entwicklungen der re:Invent 2023 unterstreichen den anhaltenden Fokus von AWS auf Leistung, Effizienz und die Bereitstellung von Entwicklern mit einer feineren Kontrolle über ihre Infrastruktur, selbst innerhalb von Serverless- und verwalteten Diensten. Während wir weiterhin die Grenzen cloud-nativer Anwendungen verschieben, bieten diese grundlegenden Verbesserungen eine solide, pragmatische Grundlage für Innovationen.
Quellen
🛠️ Related Tools
Entdecken Sie diese DataFormatHub-Tools, die sich auf dieses Thema beziehen:
- JSON to YAML - Konvertieren Sie CloudFormation-Vorlagen
- Base64 Encoder - Kodieren Sie Lambda-Payloads
