Aws-lambda-dotnet: Error: el depósito S3 debe estar en la misma región que la región configurada us-west-2. está en la región us-east-1.

Cargué el serverless.template generado por dotnet nuevo en AWS y obtuve el siguiente error al intentar crear una pila a partir de él:

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.

Parece que algo anda mal con la plantilla. No tengo mucha experiencia con CloudFormation, sigo investigando.

Hoy progresé un poco al finalmente entender el mensaje de error :)

El recurso "ProxyFunction" en la plantilla de formación de nubes tiene el parámetro CodeUri establecido en una cadena vacía. Continuando la investigación sobre por qué no se admite la cadena vacía allí.

Aparentemente, CodeUri puede ser relativo, un parámetro dinámico o una URL estática, pero nunca una cadena vacía.

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

¿Tiene una página en la que dice que CodeUri debe ser reemplazado por algo? La solución más económica sería incluirlo como un parámetro, entonces no necesita documentarlo.

Parece que todo funcionó, fue confuso porque hay dos cubos S3 involucrados, el cubo proxy y el cubo donde se carga el código de la función lambda. Una vez que creé un depósito para la lambda y especifiqué su nombre, y también especifiqué un nombre único para el depósito de proxy que no estaba en uso, la transformación sin servidor en la formación de nubes funcionó.

Todavía hay un problema en el que el depósito S3 que contiene su archivo zip con su paquete lambda debe estar en la misma región en la que se está creando su función lambda. Esto es contrario a la intuición y, en mi opinión, horrible. Si queremos aprovechar la misma plantilla en varias regiones, debemos duplicar el contenido del paquete en varios depósitos. Al menos podrían aceptar una URL en la propiedad CodeUri para que podamos usar un depósito público o github para almacenar el paquete.

Para eso, debe enviar sus comentarios al equipo de CloudFormation . Está más allá del alcance de este repositorio cambiar el comportamiento de CloudFormation.

Todavía hay un problema en el que el depósito S3 que contiene su archivo zip con su paquete lambda debe estar en la misma región en la que se está creando su función lambda. Esto es contrario a la intuición y, en mi opinión, horrible. Si queremos aprovechar la misma plantilla en varias regiones, debemos duplicar el contenido del paquete en varios depósitos. Al menos podrían aceptar una URL en la propiedad CodeUri para que podamos usar un depósito público o github para almacenar el paquete.

En serio, esto es horrible. ¿Cuál es el uso de depósitos s3 globales cuando no puede admitir la actualización del código de función lambda desde un solo depósito s3 en lugar de crear depósitos duplicados en cada región?