Runtime .NET 10 agora disponível no AWS Lambda

Por Henrique Graca, Senior AI Engineer e Jonathan Tuliani, Principal, PMT.

AWS Lambda agora suporta .NET 10 como runtime gerenciado e imagem base de container. .NET é uma linguagem popular para desenvolver aplicações Serverless. Os desenvolvedores agora podem usar os novos recursos e melhorias do .NET ao criar aplicações Serverless no Lambda. Isso inclui suporte para aplicações baseadas em arquivo para simplificar seus projetos ao implementar funções usando apenas um único arquivo.

.NET 10 oferece otimizações de runtime e compilador, incluindo melhorias no compilador JIT e aprimoramentos no Native AOT que reduzem o tamanho do executável e o tempo de inicialização. Para conhecer os recursos do .NET 10, você pode acessar a visão geral do .NET 10.

Você pode desenvolver funções Lambda em .NET 10 usando o AWS Management Console, AWS Command Line Interface (AWS CLI), AWS Toolkit for Visual Studio, AWS Extensions for .NET CLI (Amazon.Lambda.Tools), AWS Serverless Application Model (AWS SAM), AWS Cloud Development Kit (AWS CDK), e outras ferramentas de infraestrutura como código (IaC).

Você também pode usar .NET 10 com Powertools for AWS Lambda (.NET), um kit de ferramentas para desenvolvedores que ajuda você a implementar as melhores práticas Serverless. Os casos de uso incluem observabilidade, processamento em lote, integração com AWS Systems Manager Parameter Store, idempotência e muito mais.

Esta publicação demonstra o que há de novo no runtime .NET 10 do Lambda e como você pode usar o novo runtime .NET 10 em suas aplicações Serverless.

Aplicações C# baseadas em arquivo

.NET 10 introduz aplicações baseadas em arquivo, que são programas contidos em um único arquivo .cs, sem um arquivo .csproj ou uma estrutura de pastas complexa. Aplicações baseadas em arquivo são uma maneira ideal de simplificar o desenvolvimento e gerenciamento de funções Lambda .NET. Elas são totalmente suportadas pelo runtime .NET 10 do Lambda e ferramentas de desenvolvedor associadas.

Criando aplicações C# baseadas em arquivo

A forma mais rápida de criar uma função Lambda C# baseada em arquivo é usar o pacote Amazon.Lambda.Templates. A versão 8.0.1 do pacote adiciona o template lambda.FileBased, além de atualizar o restante dos templates no pacote para .NET 10.

Instale o pacote executando o seguinte comando:

dotnet new install Amazon.Lambda.Templates

Crie uma nova função Lambda C# baseada em arquivo executando o seguinte comando:

dotnet new lambda.FileBased -n MyLambdaFunction

Isso gera um arquivo no diretório atual chamado MyLambdaFunction.cs com todo o código de inicialização necessário para uma função Lambda. A seguir está o conteúdo inicial do arquivo:

// C# file-based Lambda functions can be deployed to Lambda using the 
// .NET Tool Amazon.Lambda.Tools version 6.0.0 or later. 
// 
// Command to install Amazon.Lambda.Tools 
//   dotnet tool install -g Amazon.Lambda.Tools 
// 
// Command to deploy function 
//    dotnet lambda deploy-function <lambda-function-name> MyLambdaFunction.cs 
// 
// Command to package function 
//    dotnet lambda package MyLambdaFunction.zip MyLambdaFunction.cs 
 
 
#:package Amazon.Lambda.Core@2.8.0 
#:package Amazon.Lambda.RuntimeSupport@1.14.1 
#:package Amazon.Lambda.Serialization.SystemTextJson@2.4.4 
 
// Explicitly setting TargetFramework here is done to avoid 
// having to specify it when packaging the function with Amazon.Lambda.Tools 
#:property TargetFramework=net10.0 
 
// By default File-based C# apps publish as Native AOT. When packaging Lambda function 
// unless the host machine is Amazon Linux a container build will be required. 
// Amazon.Lambda.Tools will automatically initate a container build if docker is installed. 
// Native AOT also requires the code and dependencies be Native AOT compatible. 
// 
// To disable Native AOT uncomment the following line to add the .NET build directive 
// that disables Native AOT. 
//#:property PublishAot=false 
 
using Amazon.Lambda.Core; 
using Amazon.Lambda.RuntimeSupport; 
using Amazon.Lambda.Serialization.SystemTextJson; 
using System.Text.Json.Serialization; 
 
// The function handler that will be called for each Lambda event 
var handler = (string input, ILambdaContext context) => 
{ 
    return input.ToUpper(); 
}; 
 
// Build the Lambda runtime client passing in the handler to call for each 
// event and the JSON serializer to use for translating Lambda JSON documents 
// to .NET types. 
await LambdaBootstrapBuilder.Create(handler, new SourceGeneratorLambdaJsonSerializer<LambdaSerializerContext>()) 
        .Build() 
        .RunAsync(); 
 
// Since Native AOT is used by default with C# file-based Lambda functions the source generator 
// based Lambda serializer is used. Ensure the input type and return type used by the function 
// handler are registered on the JsonSerializerContext using the JsonSerializable attribute. 
[JsonSerializable(typeof(string))] 
public partial class LambdaSerializerContext : JsonSerializerContext 
{ 
}

Funções baseadas em arquivo usam handlers de assembly executável, onde o compilador gera o método Main() contendo o código da sua função. Por isso, seu código deve incluir o pacote NuGet Amazon.Lambda.RuntimeSupport e implementar o método LambdaBootstrapBuilder.Create para inicializar o cliente de runtime.

Aplicações baseadas em arquivo também usam .NET Native AOT por padrão. Você pode desabilitar o Native AOT adicionando #:property PublishAot=false no topo do arquivo. Para mais informações sobre o uso de Native AOT no Lambda, acesse Compilar código de função Lambda .NET para um formato de runtime nativo na documentação do Lambda.

Implantando aplicações C# baseadas em arquivo

Para implantar sua função usando o dotnet CLI com a extensão Amazon.Lambda.Tools, passe o nome do arquivo .cs como um argumento adicional. O Native AOT está ativado por padrão, portanto a compilação deve corresponder à arquitetura de destino. Se estiver compilando na mesma arquitetura da função Lambda de destino e no Amazon Linux 2023, então a compilação é executada nativamente. Do contrário, Amazon.Lambda.Tools usa um container Docker para compilar a função.

Por exemplo, para implantar para x86_64 (arquitetura padrão):


dotnet lambda deploy-function ToUpper ToUpper.cs --function-runtime 
dotnet10 --function-role <role-arn>

Alternativamente, para implantar para arm64:


dotnet lambda deploy-function ToUpper ToUpper.cs --function-runtime 
dotnet10 --function-role <role-arn> --function-architecture arm64

Depurando aplicações C# baseadas em arquivo

Visual Studio Code com o C# Dev Kit suporta depuração de aplicações C# baseadas em arquivo.

1. Instale a ferramenta de teste.

dotnet tool install -g Amazon.Lambda.TestTool

2. Inicie o emulador.

dotnet lambda-test-tool start --lambda-emulator-port 5050

3. Configure .vscode/launch.json para anexar ao processo.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "LambdaDebugFile",
      "type": "coreclr",
      "request": "launch",
      "program": "${fileDirname}/artifacts/Debug/${fileBasenameNoExtension}.dll",
      "cwd": "${workspaceFolder}",
      "console": "internalConsole",
      "stopAtEntry": false,
      "env": {
        "AWS_LAMBDA_RUNTIME_API": "localhost:5050/${fileBasenameNoExtension}"
      },
      "preLaunchTask": "build-active-file"
    }
  ]
}

4. Configure .vscode/tasks.json para compilar o arquivo ativo.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "build-active-file",
      "command": "dotnet",
      "type": "process",
      "args": [
        "build",
        "${file}",
        "--output",
        "./artifacts/Debug"
      ],
      "problemMatcher": "$msCompile"
    }
  ]
}

Esta configuração usa ${file}, que permite que a tarefa de compilação direcione qualquer arquivo C# que esteja ativo no seu editor. Isso possibilita depuração contínua em múltiplas funções de arquivo único.

Lambda Managed Instances

O runtime Lambda para .NET 10 inclui suporte para Lambda Managed Instances, permitindo executar funções Lambda .NET 10 em instâncias Amazon Elastic Compute Cloud (Amazon EC2) mantendo a clareza operacional Serverless. Assim, é possível usar instâncias EC2 de geração atual, incluindo Graviton4, instâncias otimizadas para rede e outras opções de computação especializadas, sem gerenciar ciclos de vida de instâncias, patches de sistema operacional ou políticas de escalabilidade. Lambda Managed Instances fornece acesso a modelos de preços baseados em compromisso do Amazon EC2, como Compute Savings Plans e Reserved Instances, que podem fornecer até 72% de desconto sobre os preços sob demanda do Amazon EC2. Isso oferece economias significativas de custo para cargas de trabalho em estado estável, mantendo o modelo de programação familiar do Lambda. Para mais informações, acesse Lambda Managed Instances.

Com Lambda Managed Instances, cada ambiente de execução de função pode processar múltiplas invocações de função ao mesmo tempo. No .NET, o Lambda usa .NET Tasks para processamento assíncrono de múltiplas solicitações simultâneas. É necessário aplicar as mesmas práticas de segurança de concorrência ao usar Lambda Managed Instances que você usaria em qualquer outro ambiente multi-concorrente. Por exemplo, qualquer estado mutável—incluindo coleções compartilhadas, conexões de banco de dados e objetos estáticos—deve ser thread-safe. Para mais informações, acesse Runtime .NET para Lambda Managed Instances.

Considerações de desempenho

No lançamento, novos runtimes Lambda recebem menos uso do que runtimes estabelecidos existentes. Isso pode resultar em tempos de cold start mais longos devido à residência de cache reduzida dentro dos subsistemas internos do Lambda. Os tempos de cold start normalmente melhoram nas semanas seguintes ao lançamento à medida que o uso aumenta. Por isso, a AWS recomenda não tirar conclusões de comparações de desempenho lado a lado com outros runtimes Lambda até que o desempenho tenha se estabilizado.

O desempenho é altamente dependente da carga de trabalho, por isso é recomendável conduzir seus próprios testes em vez de confiar em benchmarks de teste genéricos. Há uma variedade de recursos disponíveis para reduzir o impacto de cold starts para funções Lambda que usam .NET 10, incluindo SnapStart, concorrência provisionada, Native AOT e Lambda Managed Instances.

Além disso, as cargas de trabalho Lambda .NET 10 podem experimentar desempenho ligeiramente inferior até que algumas melhorias de runtime adicionais sejam lançadas. Acesse dotnet/runtime#120288 para detalhes.

Migrando do .NET 8 para o .NET 10

Para usar .NET 10 e os novos recursos baseados em arquivo, é necessário atualizar suas ferramentas.

1. Instale ou atualize o .NET 10 SDK.

2. Se você estiver usando AWS SAM, instale ou atualize para a versão mais recente.

3. Se você estiver usando Visual Studio, instale ou atualize o AWS Toolkit for Visual Studio para a versão 1.83.0.0 ou posterior.

4. Se você usar a extensão .NET Lambda Global Tools (Amazon.Lambda.Tools) para o .NET CLI, atualize para a versão 6.0.0 ou posterior para suportar C# baseado em arquivo.

Para atualizar uma função para .NET 10, verifique seu código e dependências quanto à compatibilidade com .NET 10, execute testes e atualize conforme necessário. IA generativa pode ajudar: considere usar AWS Transform custom ou assistentes de codificação como Kiro para ajudar com atualizações.

Atualizando usando o dotnet CLI

Para projetos usando o dotnet CLI com a extensão Amazon.Lambda.tools:

1. Abra o arquivo de projeto .csproj.

2. Atualize o TargetFramework para net10.0.

3. Atualize os pacotes NuGet Amazon.Lambda.* para as versões mais recentes.

4. Se estiver usando aws-lambda-tools-defaults.json, defina function-runtime como dotnet10.

5. Execute dotnet lambda deploy-function para implantar.

Atualizando usando o AWS Toolkit for Visual Studio

Para atualizar uma função para .NET 10:

1. Abra o arquivo de projeto .csproj e atualize o TargetFramework para net10.0.

2. Atualize os pacotes NuGet para as versões mais recentes.

3. Clique com o botão direito no projeto no Solution Explorer e escolha Publish to AWS Lambda.

Atualizando funções de imagem de container

Junto com as alterações anteriores, os runtimes .NET 8 e .NET 10 são construídos no runtime provided.al2023, que é baseado na imagem de container mínima do Amazon Linux 2023. A imagem mínima do Amazon Linux 2023 usa microdnf como gerenciador de pacotes, com link simbólico como dnf. Isso substitui o gerenciador de pacotes yum usado no .NET 6 e em imagens anteriores baseadas no Amazon Linux 2. Se você implantar suas funções Lambda como imagens de container, atualize seus Dockerfiles para usar dnf em vez de yum ao atualizar para a imagem base .NET 10 a partir de imagens base .NET 6 ou anteriores.

Saiba mais sobre o runtime provided.al2023 no post Apresentando o runtime Amazon Linux 2023 para AWS Lambda.

Usando o runtime .NET 10 no Lambda

As seções a seguir demonstram como usar o runtime .NET 10 no Lambda.

O console

Na página Create Function do console Lambda, escolha .NET 10 no menu suspenso Runtime, conforme mostrado na figura a seguir.

Figura 1: Criando uma função .NET 10 no console Lambda

Para atualizar uma função Lambda existente para .NET 10, navegue até a função no console Lambda. Escolha Edit no painel Runtime settings, depois escolha .NET 10 no menu suspenso Runtime, conforme mostrado na figura a seguir.

Figura 2: Editando configurações de runtime para escolher .NET 10

Imagem de container Lambda

Altere a versão da imagem base .NET modificando a instrução FROM no seu Dockerfile:

FROM public.ecr.aws/lambda/dotnet:10
# Copy function code
COPY artifacts/publish/ ${LAMBDA_TASK_ROOT}

AWS SAM

No AWS SAM, defina o atributo Runtime como dotnet10:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Simple Lambda Function
Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Description: My .NET Lambda Function
      CodeUri: ./src/MyFunction/
      Handler: MyFunction::MyFunction.Function::FunctionHandler
      Runtime: dotnet10

Para funções baseadas em arquivo, defina CodeUri como o caminho do arquivo C# relativo ao template AWS SAM. Comandos AWS CloudFormation como deploy-serverless e package-ci empacotam a função Lambda baseada em arquivo como um executável .NET. O campo Handler deve ser definido como o nome do assembly .NET, que para aplicações C# baseadas em arquivo é o nome do arquivo menos a extensão .cs:

ToUpperFunction:
  Type: AWS::Serverless::Function
  Properties:
    Handler: ToUpperFunction
    Runtime: dotnet10
    CodeUri: ./ToUpperFunction.cs
    MemorySize: 512
    Timeout: 30

AWS SAM suporta a geração de novas aplicações serverless .NET 10 usando o comando sam init. Consulte a documentação do AWS SAM para detalhes.

Conclusão

AWS Lambda agora suporta .NET 10 como um runtime de linguagem gerenciado para ajudar os desenvolvedores a construir aplicações Serverless mais eficientes, poderosas e escaláveis. As adições de linguagem do .NET 10 incluem recursos do C# 14, otimizações de runtime e suporte aprimorado ao Native AOT. Esta versão também introduz aplicações C# baseadas em arquivo para funções Lambda simplificadas de arquivo único, e inclui suporte para Lambda Managed Instances para requisitos de computação especializados e eficiência de custo em escala.

Você pode construir e implantar funções usando .NET 10 usando o AWS Management Console, AWS CLI, AWS SDK, AWS SAM, AWS CDK ou sua ferramenta de IaC de escolha. Você também pode usar a imagem base de container .NET 10 se preferir construir e implantar suas funções usando imagens de container.

Experimente o runtime .NET 10 no Lambda hoje e experimente os benefícios desta versão de linguagem atualizada.

Para encontrar mais exemplos .NET, use a Coleção de Padrões Serverless. Para mais recursos de aprendizado serverless, visite Serverless Land.

Este conteúdo foi traduzido do post original do blog, que pode ser encontrado aqui.

Autores

	Henrique Graca, Senior AI Engineer
	Jonathan Tuliani, Principal, PMT

Tradutores

Rodrigo Peres é Arquiteto de Soluções na AWS, com mais de 20 anos de experiência trabalhando com arquitetura de soluções, desenvolvimento de sistemas e modernização de sistemas legados.

Daniel Abib é arquiteto de soluções sênior na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem.

https://www.linkedin.com/in/danielabib/

O blog da AWS