.NET Workloads on AWS Lambda

El servicio AWS Lambda proporciona una variedad de versiones ejecutables populares en las que puede ejecutar su código. En relación con las versiones ejecutables de .NET, AWS mantiene la versión ejecutable actualizada y aplica los parches necesarios con las últimas versiones disponibles de Microsoft. Como desarrollador, no necesita hacer nada en relación con la administración de la versión ejecutable que usará su código, aparte de especificar la versión que desea usar en su conocido archivo .csproj.

En la actualidad, AWS solo ofrece versiones ejecutables administradas para las versiones de soporte a largo plazo (LTS) de .NET Runtime, en el momento de escribir este artículo, es decir, .NET 3.1 y .NET 6. Los versiones ejecutables administradas de .NET están disponibles para las arquitecturas x86_64 y arm64 y se ejecutan en Amazon Linux 2. Si desea utilizar una versión de .NET distinta de las que ofrece AWS, puede crear su propia versión ejecutable personalizada o crear una imagen de contenedor que se adapte a sus necesidades.

Si está interesado en salir del mundo de .NET, le alegrará saber que el servicio Lambda también ofrece versiones ejecutables administradas para otros lenguajes: Node.js, Python, Ruby, Java y Go. Para obtener información completa sobre la lista de versiones ejecutables administradas y las versiones de los idiomas compatibles, consulte esta página sobre las versiones ejecutables disponibles.

Las versiones ejecutables personalizadas son versiones ejecutables que usted mismo crea y agrupa. Hay varias razones por las que lo haría. Lo más habitual es que desee utilizar una versión de .NET que el servicio Lambda no ofrezca como versión ejecutable administrada. Otra razón menos común sería si quisiera tener un control preciso sobre las versiones secundarias y de parches de la versión ejecutable.

Crear la versión ejecutable personalizada requiere muy poco esfuerzo de su parte. Lo único que tiene que hacer es pasar:

“--self-contained true” al comando de compilación.

Esto se puede hacer directamente con dotnet build. También puede hacerlo a través del archivo aws-lambda-tools-defaults.json con el siguiente parámetro:

“msbuild-parameters”: “--self-contained true”

Eso es todo, un simple indicador de compilación al agrupar la función de Lambda para .NET. El paquete que se va a implementar ahora contendrá el código, además de los archivos necesarios de la versión ejecutable de .NET que haya elegido.

Ahora depende de usted parchear y actualizar la versión ejecutable como mejor le parezca. Para actualizar la versión ejecutable es necesario volver a implementar la función, ya que el código de la función y la versión ejecutable se empaquetan juntos.

El paquete que se implementa es considerablemente más grande en comparación con la versión ejecutable administrada porque contiene todos los archivos necesarios de la versión ejecutable. Esto afecta negativamente a los tiempos de arranque en frío (se explicará en detalle más adelante). Para reducir este tamaño, considere la posibilidad de utilizar las características de compilación de .NET, Recortar y ReadyToRun. Sin embargo, lea la documentación sobre estas características antes de hacerlo.

Puede crear una versión ejecutable personalizada con cualquier versión de .NET que se ejecute en Linux. Un caso de uso común es implementar funciones con las versiones “actuales” o de preliminares de .NET.

Al utilizar versiones ejecutables personalizadas, puede utilizar una amplia variedad de lenguajes que ofrece la comunidad. O incluso cree su propia versión ejecutable personalizada, como lo han hecho otros para ejecutar lenguajes como Erlang y COBOL.

Debe instalar las herramientas necesarias para continuar con esto; consulte el módulo 3 para obtener más detalles sobre cómo hacerlo.

Si no quiere hacerlo ahora mismo, aquí está un recordatorio rápido.

Instale las plantillas de funciones de Lambda para .NET:

dotnet new -i Amazon.Lambda.Templates

Instale las herramientas de .NET para implementar y administrar las funciones de Lambda:

dotnet tool install -g Amazon.Lambda.Tools

Ahora que tiene las plantillas instaladas, puede crear una nueva función

Desde la línea de comandos, ejecute:

dotnet new lambda.EmptyFunction -n HelloEmptyFunction

Esto crea un nuevo directorio llamado HelloEmptyFunction. En su interior hay dos directorios más, src y test. Como sugieren los nombres, el directorio src contiene el código de la función y el directorio test contiene las pruebas unitarias de la función. Cuando navegue por estos directorios, verá que cada uno contiene otro directorio. Dentro de estos subdirectorios se encuentran los archivos de código de la función y los archivos de prueba unitaria.

HelloEmptyFunction
    ├───src
    │   └───HelloEmptyFunction
    │           aws-lambda-tools-defaults.json // The default configuration file
    │           Function.cs // The code for the function
    │           HelloEmptyFunction.csproj // Standard C# project file
    │           Readme.md // A readme file
    │
    └───test
        └───HelloEmptyFunction.Tests
                FunctionTest.cs // The unit tests for the function
                HelloEmptyFunction.Tests.csproj // Standard C# project file

Primero echemos un vistazo al archivo Function.cs.

using Amazon.Lambda.Core;

// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]

namespace HelloEmptyFunction;

public class Function
{
    
    /// <summary>
    /// A simple function that takes a string and does a ToUpper
    /// </summary>
    /// <param name="input"></param>
    /// <param name="context"></param>
    /// <returns></returns>
    public string FunctionHandler(string input, ILambdaContext context)
    {
        return input.ToUpper();
    }
}

{
  "Information": [
    "This file provides default values for the deployment wizard inside Visual Studio and the AWS Lambda commands added to the .NET Core CLI.",
    "To learn more about the Lambda commands with the .NET Core CLI execute the following command at the command line in the project root directory.",
    "dotnet lambda help",
    "All the command line options for the Lambda command can be specified in this file."
  ],
  "profile": "",
  "region": "",
  "configuration": "Release",
  "function-runtime": "dotnet6",
  "function-memory-size": 256,
  "function-timeout": 30,
  "function-handler": "HelloEmptyFunction::HelloEmptyFunction.Function::FunctionHandler"
}

using Xunit;
using Amazon.Lambda.Core;
using Amazon.Lambda.TestUtilities;

namespace HelloEmptyFunction.Tests;

public class FunctionTest
{
    [Fact]
    public void TestToUpperFunction()
    {

        // Invoke the lambda function and confirm the string was upper cased.
        var function = new Function();
        var context = new TestLambdaContext();
        var upperCase = function.FunctionHandler("hello world", context);

        Assert.Equal("HELLO WORLD", upperCase);
    }
}

Puede utilizar las herramientas de Lambda de dotnet para invocar la función desde el shell de su elección:

dotnet lambda invoke-function HelloEmptyFunction --payload "Invoking a Lambda function"

En el caso de las funciones de Lambda sencillas como las anteriores, no hay ningún JSON que escapar, pero cuando quiera pasar un JSON que deba deserializarse, el escape de la carga útil variará según el shell que utilice.

Verá una salida similar a la siguiente:

Amazon Lambda Tools for .NET Core applications (5.4.1)
Project Home: https://github.com/aws/aws-extensions-for-dotnet-cli, https://github.com/aws/aws-lambda-dotnet

Payload:
"INVOKING A LAMBDA FUNCTION"

Log Tail:
START RequestId: 3d43c8be-8eca-48a1-9e51-96d9c84947b2 Version: $LATEST
END RequestId: 3d43c8be-8eca-48a1-9e51-96d9c84947b2
REPORT RequestId: 3d43c8be-8eca-48a1-9e51-96d9c84947b2  Duration: 244.83 ms      Billed Duration: 245 ms                                                                                                                  
Memory Size: 256 MB      Max Memory Used: 68 MB      Init Duration: 314.32 ms

La salida “Payload:” es la respuesta de la función de Lambda.

Observe cómo la cola de registro contiene información útil sobre la invocación de la función de Lambda, como cuánto tiempo se ejecutó y cuánta memoria se utilizó. Para una función simple como esta, 244,83 ms puede parecer mucho, pero esta es la primera vez que se invoca la función, lo que significa que es necesario realizar más trabajo y las invocaciones posteriores habrían sido más rápidas. Consulte la sección sobre arranques en frío para obtener más información.

Hagamos un pequeño cambio en el código para agregar algunas de nuestras propias instrucciones de registro.

Agregue lo siguiente encima de la instrucción return en el método FunctionHandler:

context.Logger.LogInformation("Input: " + input);

Vuelva a realizar la implementación mediante:

dotnet lambda deploy-function HelloEmptyFunction

Esta vez no habrá preguntas sobre el rol o los permisos.

Una vez implementada la función, puede volver a invocarla.

dotnet lambda invoke-function HelloEmptyFunction --payload "Invoking a Lambda function" 

Esta vez, la salida contendrá una instrucción de registro adicional.

Payload:
"INVOKING A LAMBDA FUNCTION"

Log Tail:
START RequestId: 7f77a371-c183-494f-bb44-883fe0c57471 Version: $LATEST
2022-06-03T15:36:20.238Z        7f77a371-c183-494f-bb44-883fe0c57471    info    Input: Invoking a Lambda function
END RequestId: 7f77a371-c183-494f-bb44-883fe0c57471
REPORT RequestId: 7f77a371-c183-494f-bb44-883fe0c57471  Duration: 457.22 ms     Billed Duration: 458 ms                                                                                                       
Memory Size: 256 MB      Max Memory Used: 62 MB  Init Duration: 262.12 ms

Ahí, en la línea 6, está la instrucción de registro. Los registros de funciones de Lambda también se escriben en los registros de CloudWatch (siempre que haya otorgado permisos a la función de Lambda para hacerlo).

Otra forma de invocar la función es desde la Consola de AWS.

Inicie sesión en la Consola de AWS y seleccione la función de Lambda que desea invocar.

Haga clic en la pestaña Prueba.

Desplácese hacia abajo hasta la sección JSON del evento y escriba “Invocar una función de Lambda”, incluidas las comillas.

A continuación, haga clic en el botón Probar.

Verá una salida similar a la siguiente.

Tenga en cuenta que la salida del registro también está visible.

Como antes, cree una función nueva con el siguiente comando:

dotnet new lambda.EmptyFunction -n HelloPersonFunction

Navegue hasta el archivo Function.cs en HelloPersonFunction/src/HelloPersonFunction.

Cambie el código del método FunctionHandler para que tenga este aspecto:

public string FunctionHandler(Person input, ILambdaContext context)
{
    return $"Hello, {input.FirstName} {input.LastName}";
}

En la parte inferior del archivo, agregue una nueva clase:

public class Person 
{
    public string FirstName { get; init; }
    public string LastName { get; init; }  
}

Este es el mismo comando que utilizó hace unos minutos:

dotnet lambda deploy-function HelloPersonFunction

Ahora, su función de Lambda puede aceptar una carga JSON, pero la forma en que la invoque depende del shell que utilice, debido a la forma en que JSON se escapa en cada shell.

Si usa PowerShell o bash, use:

dotnet lambda invoke-function HelloPersonFunction --payload '{ \"FirstName\": \"Alan\", \"LastName\": \"Adams\" }'

Pero si utiliza la línea de comandos de Windows, utilice:

dotnet lambda invoke-function HelloPersonFunction --payload "{ \"FirstName\": \"Alan\", \"LastName\": \"Adams\" }"

Este es solo un ejemplo sencillo. Pero, por supuesto, el JSON puede ser tan complejo como sea necesario.

Otra forma de invocar la función es desde la Consola de AWS.

Inicie sesión en la Consola de AWS y seleccione la función de Lambda que desea invocar.

Haga clic en la pestaña Prueba.

Desplácese hacia abajo hasta la sección JSON de eventos e introduzca:

{
  "FirstName": "Alan",
  "LastName": "Adams"
}

A continuación, haga clic en el botón Probar.

Verá una salida similar a la siguiente.

Estos últimos ejemplos han sido bastante sencillos y la función de Lambda no ha utilizado ningún otro servicio de AWS, pero son una excelente manera de empezar y familiarizarse con el servicio de AWS Lambda, escribir funciones de Lambda, implementar paquetes compilados e invocar las funciones.

En la siguiente sección, verá cómo implementar una función de Lambda que responda a las solicitudes HTTP.

Desde la línea de comandos, ejecute el siguiente comando:

dotnet new serverless.AspNetCoreWebAPI -n HelloAspNetCoreWebAPI

Esto crea un nuevo directorio llamado HelloAspNetCoreWebAPI. En su interior hay dos directorios más, src y test. Como sugieren los nombres, el directorio src contiene el código de la función y el directorio test contiene las pruebas unitarias de la función. Cuando navegue por estos directorios, verá que cada uno contiene otro directorio. Dentro de estos subdirectorios se encuentran los archivos de código de la función y los archivos de prueba unitaria.

├───src
│   └───AspNetCoreWebAPI
│       │   appsettings.Development.json
│       │   appsettings.json
│       │   AspNetCoreWebAPI.csproj
│       │   aws-lambda-tools-defaults.json // basic Lambda function config, and points to serverless.template file for deployment
│       │   LambdaEntryPoint.cs // Contains the function handler method, this handles the incoming JSON payload
│       │   LocalEntryPoint.cs // Equivalent to Program.cs when running locally, starts Kestrel (only locally)
│       │   Readme.md  
│       │   serverless.template // CloudFormation template for deployment
│       │   Startup.cs // Familiar Startup.cs, can use dependency injection, read config, etc.
│       │
│       └───Controllers
│               ValuesController.cs // Familiar API controller
│
└───test
    └───AspNetCoreWebAPI.Tests
        │   appsettings.json
        │   AspNetCoreWebAPI.Tests.csproj
        │   ValuesControllerTests.cs // Unit test for ValuesController
        │
        └───SampleRequests
                ValuesController-Get.json // JSON representing an APIGatewayProxyRequest, used by the unit test

La implementación de una función basada en una plantilla serverless.* es un poco más compleja que la implementación de una función basada en una plantilla lambda.*.

Antes de intentar implementar la función sin servidor, necesita un bucket de S3. Las herramientas de implementación lo utilizarán para almacenar una pila de CloudFormation.

Puede usar un bucket de S3 existente o, si no tiene uno, siga las instrucciones que se indican a continuación.

Si usa la región us-east-1, puede usar el siguiente comando para crear el bucket:

aws s3api create-bucket --bucket your-unique-bucket-name1234 

O si utiliza una región diferente

aws s3api create-bucket --bucket your-unique-bucket-name1234 --create-bucket-configuration LocationConstraint=REGION

Creé un bucket en us-east-1, llamado lambda-course-2022.

aws s3api create-bucket --bucket lambda-course-2022 

Ahora que tiene un S3, puede ejecutar el comando de implementación:

dotnet lambda deploy-serverless

Se le pedirá que introduzca un nombre de pila de CloudFormation.

Enter CloudFormation Stack Name: (CloudFormation stack name for an AWS Serverless application)

Escriba AspNetCoreWebAPI

A continuación, se le pedirá el nombre del bucket de S3. Use el nombre del bucket que creó anteriormente o un bucket existente que quiera usar para este fin.

Una vez introducido esto, comience el proceso de creación e implementación.

Esto llevará más tiempo que los ejemplos que utilizan plantillas de proyectos lambda.* porque hay más infraestructura que crear y conectar.

La salida se dividirá en dos secciones distintas.

La sección superior será similar a la que vio al implementar funciones anteriormente, una publicación y un zip del proyecto, pero esta vez el artefacto se carga en S3.

..snip
... zipping: AspNetCoreWebAPI.runtimeconfig.json
... zipping: aws-lambda-tools-defaults.json
Created publish archive (C:\Users\someuser\AppData\Local\Temp\AspNetCoreFunction-CodeUri-Or-ImageUri-637907144179228995.zip).
Lambda project successfully packaged: C:\Users\ someuser\AppData\Local\Temp\AspNetCoreFunction-CodeUri-Or-ImageUri-637907144179228995.zip
Uploading to S3. (Bucket: lambda-course-2022 Key: AspNetCoreWebAPI/AspNetCoreFunction-CodeUri-Or-ImageUri-637907144179228995-637907144208759417.zip)
... Progress: 100%

Después de esto, se crea la pila de CloudFormation y se implementan todos los recursos necesarios para ella.

Uploading to S3. (Bucket: lambda-course-2022 Key: AspNetCoreWebAPI/AspNetCoreWebAPI-serverless-637907144211067892.template)
... Progress: 100%
Found existing stack: False
CloudFormation change set created
... Waiting for change set to be reviewed
Created CloudFormation stack AspNetCoreWebAPI

Timestamp            Logical Resource Id                      Status
-------------------- ---------------------------------------- ---------------------------------------- 
6/10/2022 09:53 AM   AspNetCoreWebAPI                         CREATE_IN_PROGRESS
6/10/2022 09:53 AM   AspNetCoreFunctionRole                   CREATE_IN_PROGRESS
6/10/2022 09:53 AM   AspNetCoreFunctionRole                   CREATE_IN_PROGRESS
6/10/2022 09:54 AM   AspNetCoreFunctionRole                   CREATE_COMPLETE
6/10/2022 09:54 AM   AspNetCoreFunction                       CREATE_IN_PROGRESS
6/10/2022 09:54 AM   AspNetCoreFunction                       CREATE_IN_PROGRESS
6/10/2022 09:54 AM   AspNetCoreFunction                       CREATE_COMPLETE
6/10/2022 09:54 AM   ServerlessRestApi                        CREATE_IN_PROGRESS
6/10/2022 09:54 AM   ServerlessRestApi                        CREATE_IN_PROGRESS
6/10/2022 09:54 AM   ServerlessRestApi                        CREATE_COMPLETE
6/10/2022 09:54 AM   ServerlessRestApiDeploymentcfb7a37fc3    CREATE_IN_PROGRESS
6/10/2022 09:54 AM   AspNetCoreFunctionProxyResourcePermissionProd CREATE_IN_PROGRESS
6/10/2022 09:54 AM   AspNetCoreFunctionRootResourcePermissionProd CREATE_IN_PROGRESS
6/10/2022 09:54 AM   AspNetCoreFunctionProxyResourcePermissionProd CREATE_IN_PROGRESS
6/10/2022 09:54 AM   AspNetCoreFunctionRootResourcePermissionProd CREATE_IN_PROGRESS
6/10/2022 09:54 AM   ServerlessRestApiDeploymentcfb7a37fc3    CREATE_IN_PROGRESS
6/10/2022 09:54 AM   ServerlessRestApiDeploymentcfb7a37fc3    CREATE_COMPLETE
6/10/2022 09:54 AM   ServerlessRestApiProdStage               CREATE_IN_PROGRESS
6/10/2022 09:54 AM   ServerlessRestApiProdStage               CREATE_IN_PROGRESS
6/10/2022 09:54 AM   ServerlessRestApiProdStage               CREATE_COMPLETE
6/10/2022 09:54 AM   AspNetCoreFunctionProxyResourcePermissionProd CREATE_COMPLETE
6/10/2022 09:54 AM   AspNetCoreFunctionRootResourcePermissionProd CREATE_COMPLETE
6/10/2022 09:54 AM   AspNetCoreWebAPI                         CREATE_COMPLETE
Stack finished updating with status: CREATE_COMPLETE

Output Name                    Value
------------------------------ --------------------------------------------------
ApiURL                         https://xxxxxxxxx.execute-api.us-east-1.amazonaws.com/Prod/

Justo en la parte inferior está la URL pública que puede usar para invocar la API.

Al abrir esa URL en su navegador, o en Fiddler/Postman, etc., verá una respuesta como “Bienvenido a la ejecución de ASP.NET Core en AWS Lambda”.

A continuación, intente abrir https://xxxxxxxx.execute-api.us-east-1.amazonaws.com/Prod/api/values e invocará el método GET del controlador de valores, tal como lo haría en una aplicación de API web normal.

Tenga en cuenta que, al usar una puerta de enlace de API, la puerta de enlace impone su propio tiempo de espera de 29 segundos. Si la función de Lambda se ejecuta durante más tiempo, no recibirá ninguna respuesta.

Si está interesado, hay varias maneras de revisar los recursos que se crearon.

Para revisar los recursos de AWS creados, puede utilizar:

aws cloudformation describe-stack-resources --stack-name AspNetCoreWebAPI

Esto le dará detalles sobre todos los recursos de la pila.

Si desea una salida más concisa, utilice:

aws cloudformation describe-stack-resources --stack-name AspNetCoreWebAPI --query 'StackResources[].[{ResourceType:ResourceType, LogicalResourceId:LogicalResourceId, PhysicalResourceId:PhysicalResourceId}]'

Otra forma es abrir la Consola de AWS y navegar hasta el servicio Lambda. En la parte izquierda de la pantalla, seleccione Aplicación (en lugar de funciones).

Verá la aplicación que creó. Selecciónela y desplácese hasta la parte inferior de la página que se abre. Verá todos los recursos que se crearon aquí.

Ya ha visto tres ejemplos de funciones de Lambda: el primero era un Hello World simple que tomaba una cadena, el segundo también era muy simple pero tomaba un objeto JSON, y el tercero era un poco más complejo, pero aún así muy fácil de crear e implementar.

Con estos ejemplos, puede crear e implementar sus propias funciones de Lambda. Y es posible que haya aprendido un poco sobre cómo se invocan las funciones de Lambda para .NET. Este es el tema de la siguiente sección.

Si todo lo que necesita es una función de Lambda que responda a una solicitud HTTP simple, debería considerar el uso de las URL de la función de Lambda.

Permiten asignar un punto de conexión HTTPS a una función de Lambda. A continuación, invoque la función de Lambda mediante una solicitud al punto de conexión HTTPS. Para obtener más información, consulte esta publicación de blog y estos documentos.

Para eliminar las funciones de Lambda, ejecute:

dotnet lambda delete-function HelloEmptyFunction  
dotnet lambda delete-function HelloPersonFunction

Tenga en cuenta que los comandos anteriores no eliminan el rol que creó.

Para eliminar la función de Lambda que alojaba la aplicación de API web y todos los recursos asociados, ejecute:

dotnet lambda delete-serverless AspNetCoreWebAPI

Lo que hace que sea muy fácil para un servicio de AWS invocar una función de Lambda para .NET es que estos servicios emiten JSON y, como se ha descrito anteriormente, la función de Lambda para .NET acepta entradas JSON. Todos los eventos generados por los diferentes servicios producen un JSON con formas diferentes, pero los paquetes NuGet de eventos de AWS Lambda incluyen todos los tipos de objetos relevantes necesarios para volver a serializar el JSON en un objeto con el que pueda trabajar.

Consulte https://www.nuget.org/packages?packagetype=&sortby=relevance&q=Amazon.Lambda&prerel=True para obtener una lista de los paquetes de Lambda disponibles; tendrá que buscar en esos resultados el tipo de evento que le interesa.

Por ejemplo, si desea activar una función de Lambda en respuesta a un cambio de archivo en un bucket de S3, debe crear una función de Lambda que acepte un objeto de tipo S3Event. A continuación, agregue el paquete Amazon.Lambda.S3Events a su proyecto. A continuación, cambie el método del controlador de la función a:

public async string FunctionHandler(S3Event s3Event, ILambdaContext context)
{
    ...
}

Eso es todo lo que necesita para gestionar el evento de S3; puede examinar el evento mediante programación, ver qué acción se realizó en el archivo, en qué bucket se encontraba, etc. Amazon.Lambda.S3Events le permite trabajar con el evento, no con el propio S3. Si desea interactuar con el servicio S3, también debe agregar el paquete NuGet AWSSDK.S3 a su proyecto. Un módulo posterior abordará el tema de los servicios de AWS que invocan funciones de Lambda.

Se sigue el mismo patrón para otros tipos de eventos: agregue el paquete NuGet, cambie el parámetro al controlador de la función y, a continuación, podrá trabajar con el objeto de evento.

Estos son algunos de los paquetes comunes que puede utilizar para gestionar eventos de otros servicios:

https://www.nuget.org/packages/Amazon.Lambda.SNSEvents

https://www.nuget.org/packages/Amazon.Lambda.DynamoDBEvents

https://www.nuget.org/packages/Amazon.Lambda.CloudWatchEvents

https://www.nuget.org/packages/Amazon.Lambda.KinesisEvents

https://www.nuget.org/packages/Amazon.Lambda.APIGatewayEvents

No está limitado a utilizar tipos de eventos definidos por AWS al invocar una función de Lambda. Puede crear cualquier tipo de evento usted mismo; recuerde que la función de Lambda puede tomar cualquier JSON que le envíe

Recordará que hay dos categorías amplias de plantillas de proyectos de Lambda: aquellas que comienzan por “lambda.” y las que comienzan por “serverless.”.

En el caso de las plantillas “lambda.”, hay un atributo de ensamblaje cerca de la parte superior del archivo Function.cs, que se encarga de deserializar el evento entrante al tipo .NET en el controlador de la función. En el archivo .csproj, hay una referencia al paquete Amazon.Lambda.Serialization.SystemTextJson.

[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]

No tiene que hacer nada más.

Para las plantillas “serverless.”, funciona de forma un poco diferente.

El controlador de la función se especifica en el archivo serverless.template. Si va a implementar una aplicación Serverless.AspNetCoreWebAPI, busque el valor en Resources.AspNetCoreFunction.Properties.Handler. El controlador para este tipo de proyecto tendrá la forma Assembly::Namespace.LambdaEntryPoint::FunctionHandlerAsync.

La clase LambdaEntryPoint estará en su proyecto y hereda de una clase que tiene un método FunctionHandlerAsync.

El controlador de la función se puede configurar para gestionar cuatro tipos de eventos diferentes: una API de REST de puerta de enlace de API, una carga útil de API HTTP de puerta de enlace de API versión 1.0, una carga útil de API HTTP de puerta de enlace de API versión 2.0 y un equilibrador de carga de aplicación.

Al cambiar la clase de la que hereda LambdaEntryPoint, puede cambiar el tipo de evento JSON que gestiona el controlador de la función.

Aunque parezca que la función de Lambda responde a una solicitud HTTP que usted le envía, con el JSON que usted defina, ese no es el caso. En realidad, la solicitud HTTP la gestiona una puerta de enlace o un equilibrador de carga, que luego crea un evento JSON que se envía al controlador de la función. Este evento JSON incluirá los datos originalmente incluidos en la solicitud HTTP, hasta la dirección IP de origen y los encabezados de la solicitud.