Aws-lambda-dotnet: Fehler: S3-Bucket muss sich in derselben Region befinden wie die konfigurierte Region us-west-2. liegt in der Region us-east-1.

Ich habe die serverless.template die vom Dotnet neu in AWS generiert wurden, hochgeladen und beim Versuch, einen Stack daraus zu erstellen, die folgende Fehlermeldung erhalten:

Error creating change set: Transform AWS::Serverless-2016-10-31 failed with: Invalid Serverless Application Specification document. Number of errors found: 1. Resource with id [ProxyFunction] is invalid. 'CodeUri' is not a valid S3 Uri of the form "s3://bucket/key" with optional versionId query parameter.

Anscheinend stimmt etwas mit der Vorlage nicht. Ich habe nicht viel Erfahrung mit CloudFormation und recherchiere immer noch.

Heute habe ich einige Fortschritte gemacht, indem ich die Fehlermeldung endlich verstanden habe :)

Die Ressource "ProxyFunction" in der Cloud-Formationsvorlage hat den Parameter CodeUri auf einen leeren String gesetzt. Fortlaufende Untersuchung, warum leere Zeichenfolgen dort nicht unterstützt werden.

Anscheinend kann CodeUri relativ, ein dynamischer Parameter oder eine statische URL sein, aber niemals eine leere Zeichenfolge.

https://github.com/awslabs/serverless-application-model/blob/master/HOWTO.md

Haben Sie eine Seite, auf der Sie sagen, dass CodeUri durch etwas ersetzt werden muss? Die billigste Lösung wäre, es als Parameter aufzunehmen, dann müssen Sie es nicht dokumentieren.

Sieht so aus, als hätte alles funktioniert, es war verwirrend, weil es zwei S3-Buckets gibt, den Proxy-Bucket und den Bucket, in den der Lambda-Funktionscode hochgeladen wird. Nachdem ich einen Bucket für das Lambda erstellt und seinen Namen angegeben hatte und auch einen eindeutigen Namen für den nicht verwendeten Proxy-Bucket angegeben hatte, funktionierte die Severless-Transformation in der Wolkenbildung.

Es gibt immer noch ein Problem, bei dem sich der S3-Bucket, der Ihre ZIP-Datei mit Ihrem Lambda-Paket enthält, in derselben Region befinden muss, in der Ihre Lambda-Funktion erstellt wird. Das ist kontraintuitiv und meiner Meinung nach schrecklich. Wenn wir dieselbe Vorlage in mehreren Regionen verwenden möchten, müssen wir den Inhalt des Pakets in mehreren Buckets duplizieren. Sie könnten zumindest eine URL in der CodeUri-Eigenschaft akzeptieren, damit wir einen öffentlichen Bucket oder Github zum Speichern des Pakets verwenden könnten.

Dafür sollten Sie das Feedback an das CloudFormation-Team geben . Es würde den Rahmen dieses Repositorys sprengen, das Verhalten von CloudFormation zu ändern.

Es gibt immer noch ein Problem, bei dem sich der S3-Bucket, der Ihre ZIP-Datei mit Ihrem Lambda-Paket enthält, in derselben Region befinden muss, in der Ihre Lambda-Funktion erstellt wird. Das ist kontraintuitiv und meiner Meinung nach schrecklich. Wenn wir dieselbe Vorlage in mehreren Regionen verwenden möchten, müssen wir den Inhalt des Pakets in mehreren Buckets duplizieren. Sie könnten zumindest eine URL in der CodeUri-Eigenschaft akzeptieren, damit wir einen öffentlichen Bucket oder Github zum Speichern des Pakets verwenden könnten.

Ernsthaft, das ist schrecklich. Was nützen globale s3-Buckets, wenn Sie die Lambda-Funktionscode-Aktualisierung nicht von einem einzelnen s3-Bucket unterstützen können, anstatt in jeder Region doppelte Buckets zu erstellen.