Eine Frontend-Anwendung verwendet ein Amazon API Gateway API-Backend, das in AWS Lambda integriert ist. Wenn Anfragen eingehen, lädt die Lambda-Funktion viele Bibliotheken, stellt eine Verbindung zu einer Amazon RDS-Datenbank her, verarbeitet die Daten und gibt sie an das Frontend zurück. Das Unternehmen möchte die Antwortlatenz für alle Benutzer mit den geringsten betrieblichen Änderungen minimieren. Welche Lösung erfüllt diese Anforderung?

Die Konfiguration von bereitgestellter Parallelität (provisioned concurrency) für die Lambda-Funktion ist die effektivste Lösung. Provisioned Concurrency hält die Lambda-Funktion initialisiert und bereit, Anfragen zu verarbeiten, wodurch Kaltstarts vermieden werden. Kaltstarts sind die Hauptursache für hohe Latenz bei Lambda-Funktionen, da sie das Laden von Bibliotheken und die Initialisierung der Laufzeitumgebung umfassen. Durch die Eliminierung von Kaltstarts wird die Antwortlatenz für alle Benutzer minimiert, ohne dass größere betriebliche Änderungen an der Anwendungsarchitektur erforderlich sind. Die Verbindung der Frontend-Anwendung direkt mit der Datenbank ist ein Sicherheitsrisiko und eine schlechte Architekturpraxis. Das Zwischenspeichern von Abfrageergebnissen in Amazon S3 würde nur bei wiederholten Abfragen mit identischen Daten helfen und erfordert zusätzliche Logik für die Cache-Invalidierung, was die betrieblichen Änderungen erhöht. Das Erhöhen der Datenbankgröße verbessert nicht direkt die Lambda-Latenz, da die Latenz durch die Initialisierung der Lambda-Funktion und den Verbindungsaufbau verursacht wird, nicht durch die Datenbankkapazität.