Bewährte Methoden für Lambda-Webfunktionen

Jeder Endpunkt ist unabhängig von seinem Authentifizierungstyp über das Internet erreichbar. Mit ApplicationManaged authentifiziert Lambda keine Anfragen, sodass jeder Client, der die Domain kennt, Ihre Anwendung aufrufen kann. Implementieren Sie Authentifizierung, Autorisierung, Eingabevalidierung, Überprüfung der Anforderungsgröße und Schutz vor Missbrauch in der Anwendung oder an einer Vordertür.

Verwenden Sie diese IamAuth Option, wenn Anrufer Anfragen signieren können und IAM-Richtlinien das erforderliche Autorisierungsmodell bereitstellen. Richten Sie die Ressourcenrichtlinien auf bestimmte Endpunkt-ARNs und Prinzipale ein.

Stellen Sie Amazon CloudFront oder Amazon API Gateway vor einen Endpunkt, wenn Sie eine benutzerdefinierte Domain, AWS WAF Inspektion, Caching oder zentrale Edge-Kontrollen benötigen. Schränken Sie den Ursprung ein, damit Kunden die Eingangstür nicht umgehen können. Verwenden Sie mit CloudFront einen IamAuth Endpunkt und eine Zugriffskontrolle (Origin CloudFront Integration Access Control, OAC), wie unter beschrieben. Bei anderen Eingangstüren ist der Endpunkt weiterhin direkt erreichbar. Überprüfen Sie daher, ob ein gemeinsam genutzter Schlüssel oder ein Token in der Anwendung verwendet wird.

Verwenden Sie eine dedizierte Ausführungsrolle mit den geringsten Rechten. Trennen Sie die Bereitstellungsidentität, den Code-Uploader, den Lambda-Serviceprinzipal, die Ausführungsrolle und die Endpunkt-Aufruferberechtigungen voneinander.

Speichern Sie keine Geheimnisse in Bereitstellungspaketen oder Protokollen. Laden Sie Geheimnisse zur Laufzeit aus einem geeigneten Geheimspeicher, speichern Sie sie nur so lange wie nötig im Cache und redigieren Sie sensible Anforderungsfelder.

Aktivieren Sie die Versionierung im Code-Bucket und notieren Sie die Versions-ID des Objekts für jede Bereitstellung.

Überschreiben oder löschen Sie keine Objektversionen, die von aktiven Revisionen oder Rollback-Revisionen verwendet werden. Behalten Sie den Lambda-Serviceprinzipalzugriff so lange bei, wie eine Revision auf das Objekt verweist.

Erstellen Sie Bereitstellungspakete in einer wiederholbaren Pipeline. Installieren Sie Produktionsabhängigkeiten aus einer Sperrdatei, schließen Sie Entwicklungsdateien aus und testen Sie das genaue Archiv vor dem Upload.

Erstellen Sie native Abhängigkeiten für Arm64. Ein für x86_64 erstelltes systemeigenes Modul läuft nicht in der Ausführungsumgebung der Webfunktionen.

Verwenden Sie separate Buckets, Präfixe, Rollen oder Konten, wenn Umgebungen unterschiedliche Vertrauens- oder Aufbewahrungsanforderungen haben.

Behalten Sie anforderungsspezifische Daten im Umfang der Anfrage bei. Speichern Sie keine Anmeldeinformationen, Kundendaten, Antwortobjekte oder veränderbaren Status pro Anfrage in globalen Variablen.

Verwenden Sie asynchron. I/O Synchrone CPU- oder Dateisystemarbeit blockiert die Node.js Ereignisschleife und verzögert jede laufende Anfrage in der Umgebung.

Wird worker_threads für CPU-intensive Arbeiten verwendet, bei denen mehrere vCPUs oder weniger verwendet werden sollen, maxConcurrencyPerEnvironment um Konflikte zu vermeiden.

Bewahren Sie den Node.js Heap getrennt vom Umgebungsspeicher auf. Die Umgebung hat 2 GB, während der Standard-V8-Heap 1.024 MB groß ist. Wenn Sie den Heap mit --max-old-space-size in startenNODE_OPTIONS, lassen Sie Speicherplatz für Puffer, native Module, die Laufzeit und gleichzeitige Anfragen übrig.

Verwenden Sie initialisierte Clients und Verbindungspools anforderungsübergreifend wieder, überprüfen Sie jedoch veraltete Verbindungen und gebundenes Cache-Wachstum. Behält den erforderlichen Status außerhalb der Ausführungsumgebung bei.

Halten Sie ausgehende Verbindungen aufrecht, sodass Anfragen an Datenbanken und andere Abhängigkeiten sie wiederverwenden können, anstatt jedes Mal eine neue Verbindung zu öffnen. Node.jsaktiviert Keep-Alive standardmäßig in seinem globalen HTTP-Agenten. Wenn Sie Ihren eigenen Agenten erstellen oder einen SDK-Client konfigurieren, lassen Sie Keep-Alive aktiviert. Behandeln Sie auch Verbindungen, die von der Remote-Seite geschlossen werden, während sie inaktiv sind.

Verwenden Sie eindeutige Namen für temporäre Dateien und entfernen Sie sie, wenn sie nicht mehr benötigt werden. Mehrere Anfragen teilen sich das 512 MB große /tmp Dateisystem der Umgebung, und Dateien können über mehrere Anfragen hinweg bestehen bleiben, bis die Umgebung entfernt wird.

Starten Sie den HTTP-Server umgehend und hören Sie sich den genauen Wert von anAWS_LAMBDA_HTTP_ENDPOINT.

Halten Sie das Paket klein und entfernen Sie ungenutzte Produktionsabhängigkeiten.

Initialisieren Sie nur die Ressourcen, die benötigt werden, bevor der Server Datenverkehr annehmen kann. Führen Sie optionale Arbeiten langsam durch, verhindern Sie jedoch, dass gleichzeitige Anfragen kostspielige Initialisierungen duplizieren.

Übernehmen Sie SIGTERM die Bereinigung, die innerhalb von 1 Sekunde abgeschlossen ist, verlassen Sie sich jedoch nicht auf Shutdown-Callbacks, um die erforderlichen Daten dauerhaft zu speichern.

Belastungstest mit denselben Anwendungsabhängigkeiten und nachgelagerten Diensten, die in der Produktion verwendet werden. Erhöhen Sie die Parallelität, bis Latenz, CPU-Auslastung, Arbeitsspeicher oder Downstream-Kapazität zur Bindungsbeschränkung werden.

Wird verwendetmaxConcurrencyPerEnvironment, um Konflikte pro Prozess zu begrenzen, maxEnvironments um die horizontale Skalierung zu begrenzen und um nachgelagerte Abhängigkeiten vor Anforderungs-Bursts rateLimit zu schützen.

Prüfen Sie vor Leistungstests und Starts die geltenden Konto- und Regionallimits. Durch die Endpunktkonfiguration kann keine Kapazität geschaffen werden, die über ein Kontolimit hinausgeht.

Versuchen Sie es erneut mit HTTP 429-Antworten und HTTP 503-Antworten ohne lambda-web-error-type Header. Verwenden Sie Backoff und Jitter und wiederholen Sie den Vorgang nur, wenn der Vorgang idempotent ist. Verwenden Sie für Schreibvorgänge Idempotenzschlüssel oder Deduplizierung auf Anwendungsebene.

Verwenden Sie manuelle Revisionsgewichte für Produktionsendpunkte. Sorgen Sie für die automatische Bereitstellung der neuesten Version für Entwicklungsumgebungen, in denen ein sofortiger Rollout akzeptabel ist.

Warten Sie, bis die neue Version verfügbar ist Active und das Endpunkt-Update abgeschlossen ist, bevor Sie es auswerten. Überprüfen Sie für MultiRegion PerRegion Endgeräte den Aktualisierungsstatus in jeder Region.

Verwenden Sie bei Bereitstellungen auf Canary Anwendungsprotokolle oder benutzerdefinierte Messwerte, die die Revisions-ID enthalten. Service-vended Metriken enthalten keine Revisionsdimension.

Bevor Sie den Traffic verlagern, definieren Sie die Metriken, die eine neue Version erfüllen muss, und definieren Sie, wie lange Sie sie einhalten (Bake-Kriterien), sowie die Schwellenwerte, die ein Rollback auslösen. Behalten Sie die Codeobjektversion, den Schlüsselzugriff und die Konfiguration der vorherigen Revision bei, bis das Rollback-Fenster endet. Lambda löscht automatisch die ältesten Revisionen, zu denen kein Endpunkt weiterleitet, wenn eine Webfunktion ihr Revisionslimit überschreitet. Behalten Sie die Rollback-Revision also auf einem Endpunkt (z. B. einem Testendpunkt) bei oder seien Sie bereit, sie aus derselben Objektversion neu zu erstellen. Details hierzu finden Sie unter Revisionsgrenzen und automatische Bereinigung.

Geben Sie strukturierte Anwendungsprotokolle mit Anforderungs-ID, Revisions-ID, Route, Statuscode, Dauer und den Identifikatoren aus, die für die Diagnose von Downstream-Ausfällen erforderlich sind. Protokollieren Sie keine Anmeldeinformationen, Token oder vertraulichen Anfragetexte.

Alarmierung bei 5xx-Antworten und Drosselung sowie Überwachung der ausgeführten Anfragen, der aktiven Umgebungen und der Kontokapazität. Konfigurieren Sie wenige Fehlermetriken, um fehlende Daten angemessen zu behandeln.

Verwenden Sie die Antwortanforderungs-ID und die Log-Stream-Header, um Client-Fehler mit Protokollen zu korrelieren. Aktivieren Sie DEBUG-Systemprotokolle nur, solange Sie die zusätzlichen Ereignisse benötigen.

Erfassen Sie Verwaltungsvorgänge und Datenereignisse beim Aufrufen von Endpunkten AWS CloudTrail , wenn Ihre Prüfanforderungen sie benötigen.

Stellen Sie Anwendungsdaten, Geheimnisse, Schlüssel und Downstream-Abhängigkeiten in jeder Region zur Verfügung, die Datenverkehr empfangen kann.

Testen Sie Fehler bei der teilweisen Bereitstellung und Fehler bei regionalen Abhängigkeiten. Gehen Sie nicht davon aus, dass in allen Regionen dieselbe Version ausgeführt wird, bis jedes regionale Update einen Erfolg meldet.

Suchen Sie nach jedem Endpunkt-Update updateStatus nach jedem Eintrag inregionalEndpoints. Die Replikation kann in einigen Regionen fehlschlagen, während sie in anderen erfolgreich ist. Daher kann ein Update teilweise angewendet werden. Versuchen Sie es erneut, oder führen Sie ein Rollback durch, bevor Sie die Bereitstellung als abgeschlossen betrachten.

Testen Sie bei PerRegion Endgeräten Ihr externes DNS oder Ihr Front-Door-Failover unabhängig von der Bereitstellung der Web Function.

Zentralisieren Sie die Betriebsansichten in der Heimatregion, behalten Sie jedoch einen Wiederherstellungspfad für Telemetrieverzögerungen oder -unterbrechungen bei.