Umgang mit CDK-Custom-Ressourcen und Fehlern.

Der AWS-CustomResource-Konstrukt vereinfacht AWS-SDK-Aufrufe während der CloudFormation-Bereitstellung, die häufig für Aufgaben wie das Abrufen von Parameter-Store-Werten oder das Aufrufen von Lambda-Funktionen verwendet werden. Er verwendet eine Singleton-Lambda-Funktion, um SDK-Aufrufe während der CloudFormation-Lebenszyklusereignisse (ERSTELLEN, AKTUALISIEREN, LÖSCHEN) auszuführen und speichert die Antworten in S3. Wenn jedoch die aufgerufene Lambda-Funktion fehlschlägt, kann die CloudFormation-Bereitstellung unerwartet erfolgreich sein. Dies liegt daran, dass der Erfolg oder Misserfolg der Singleton-Lambda nur den Status des API-Aufrufs und nicht den der aufgerufenen Lambda-Funktion widerspiegelt. Um dies zu beheben, ersetzt ein benutzerdefinierter Anbieter die Standard-Singleton-Lambda. Dieser benutzerdefinierte Anbieter bietet, entweder über das Provider-Framework oder einen direkten Lambda-Ansatz, eine feinere Kontrolle über den Erfolg oder Misserfolg der Bereitstellung basierend auf dem Ergebnis der benutzerdefinierten Ressourcen-Lambda-Funktion. Das Provider-Framework vereinfacht die Antwortbehandlung, indem es Antworten automatisch an den S3-Bucket sendet; die direkte Lambda-Verarbeitung erfordert manuelle PUT-Anfragen an eine vorab unterzeichnete S3-URL. AWS empfiehlt das Provider-Framework. Benutzerdefinierte Ressourcen werden standardmäßig nur bei Änderungen der Eigenschaften während der Aktualisierung ausgeführt; ein Zeitstempel kann die Ausführung erzwingen. Die Provider-Lambda-Funktion wird bei allen Lebenszyklusereignissen ausgeführt und erfordert bedingte Logik innerhalb der Lambda-Funktion selbst. Eine sorgfältige Berücksichtigung der Lebenszyklusereignisse (ERSTELLEN, AKTUALISIEREN, LÖSCHEN) ist für ein ordnungsgemäßes Verhalten der Funktion von entscheidender Bedeutung.