# Runtimes do Lambda
O Lambda oferece suporte a vários idiomas por meio do uso de *runtimes*. Um runtime fornece um ambiente específico da linguagem que retransmite eventos de invocação, informações de contexto e respostas entre o Lambda e a função. É possível usar runtimes fornecidos pelo Lambda ou criar seus próprios.
O Lambda não faz distinção do runtime que você escolher usar. Para funções simples, as linguagens interpretadas, como Python e Node.js, oferecem a performance mais rápida. Para funções com computação mais complexa, as linguagens compiladas, como Java, em geral demoram mais para inicializar, mas são executadas rapidamente no manipulador do Lambda. A escolha do runtime também é influenciada pela preferência do desenvolvedor e pela familiaridade com a linguagem.
Cada versão principal da linguagem de programação lançada tem um runtime separado, com um *identificador de runtime* exclusivo, como `nodejs24.x` ou `python3.14`. Para alterar uma função com a finalidade de usar uma nova versão principal da linguagem, é necessário alterar o identificador de runtime. Como o AWS Lambda não pode garantir a compatibilidade com versões anteriores entre as versões principais, essa é uma operação direcionada ao cliente.
Em uma [função definida como uma imagem de contêiner](images-create.md), você escolhe um runtime e a distribuição Linux ao criar a imagem de contêiner. Para alterar o runtime, crie uma nova imagem de contêiner.
Quando você usa um arquivo .zip para o pacote de implantação, escolhe um runtime ao criar a função. Para alterar o runtime, você pode [atualizar a configuração da sua função](configuration-function-zip.md). O runtime é emparelhado com uma das distribuições do Amazon Linux. O ambiente de execução subjacente fornece bibliotecas e [variáveis de ambiente](configuration-envvars.md) adicionais que podem ser acessadas no código de sua função.
O Lambda invoca sua função em um [ambiente de execução](lambda-runtime-environment.md). Um ambiente de execução fornece um ambiente de runtime isolado e seguro, que gerencia os recursos necessários para executar a função. O Lambda reutiliza o ambiente de execução de uma invocação anterior, caso haja alguma disponível, ou pode criar um novo ambiente de execução.
Para usar outras linguagens no Lambda, como [Go](lambda-golang.md) ou [Rust](lambda-rust.md), use um [runtime somente para sistema operacional](runtimes-provided.md). O ambiente de execução do Lambda fornece uma [interface de runtime](runtimes-api.md) para obter eventos de invocação e enviar respostas. É possível implantar outras linguagens implementando um [runtime personalizado](runtimes-custom.md) junto com o código da função ou em uma [camada](chapter-layers.md).
## Tempos de execução compatíveis
A tabela a seguir lista os runtimes do Lambda compatíveis e as datas de descontinuação projetadas. Depois que um runtime for descontinuado, você ainda poderá criar e atualizar funções por um período limitado. Para obter mais informações, consulte [Uso do runtime após a descontinuação](#runtime-deprecation-levels). A tabela fornece as datas previstas atuais para a descontinuação do runtime com base em nossa [Política de descontinuação de runtime](#runtime-support-policy). Essas datas são fornecidas para fins de planejamento e estão sujeitas a alterações.
**Importante**
O Amazon Linux 2 está programado para chegar ao fim da vida útil em 30 de junho de 2026. Os runtimes do Lambda e as imagens base de contêineres para Java 8 (AL2), Java 11, Java 17, Python 3.10, Python 3.11 e provided.al2 continuarão recebendo patches para problemas de segurança [críticos e importantes](https://alas.aws.amazon.com/faqs.html) do Amazon Linux 2, além dos patches de runtime da linguagem, até as datas de descontinuação mostradas na tabela abaixo.
Recomendamos que os clientes atualizem para um runtime baseado no Amazon Linux 2023 o mais rápido possível. Para clientes que estão atualizando para o Java 21 ou Java 25, você pode usar o [AWS Transform personalizado](https://docs.aws.amazon.com/transform/latest/userguide/custom.html) para ajudar com essas atualizações. Para clientes que não conseguem atualizar sua versão Java, planejamos lançar runtimes baseados no Amazon Linux 2023 para Java 8, Java 11 e Java 17 antes do final do segundo trimestre de 2026.
| Nome | Identificador | Sistema operacional | Data da substituição | Bloquear a criação de funções | Bloquear a atualização de funções |
| --- | --- | --- | --- | --- | --- |
| Node.js 24 | `nodejs24.x` | Amazon Linux 2023 | 30 de abril de 2028 | 1º de junho de 2028 | 1º de julho de 2028 |
| Node.js 22 | `nodejs22.x` | Amazon Linux 2023 | 30 de abril de 2027 | 1º de junho de 2027 | 1º de julho de 2027 |
| Node.js 20 | `nodejs20.x` | Amazon Linux 2023 | 30 de abril de 2026 | 31 de agosto de 2026 | 30 de setembro de 2026 |
| Python 3.14 | `python3.14` | Amazon Linux 2023 | 30 de junho de 2029 | 31 de julho de 2029 | 31 de agosto de 2029 |
| Python 3.13 | `python3.13` | Amazon Linux 2023 | 30 de junho de 2029 | 31 de julho de 2029 | 31 de agosto de 2029 |
| Python 3.12 | `python3.12` | Amazon Linux 2023 | 31 de outubro de 2028 | 30 de novembro de 2028 | 10 de janeiro de 2029 |
| Python 3.11 | `python3.11` | Amazon Linux 2 | 30º de junho de 2027 | 31º de julho de 2027 | 31 de agosto de 2027 |
| Python 3.10 | `python3.10` | Amazon Linux 2 | 31 de outubro de 2026 | 30 de novembro de 2026 | 15 de janeiro de 2027 |
| Java 25 | `java25` | Amazon Linux 2023 | 30 de junho de 2029 | 31 de julho de 2029 | 31 de agosto de 2029 |
| Java 21 | `java21` | Amazon Linux 2023 | 30 de junho de 2029 | 31 de julho de 2029 | 31 de agosto de 2029 |
| Java 17 | `java17` | Amazon Linux 2 | 30º de junho de 2027 | 31º de julho de 2027 | 31 de agosto de 2027 |
| Java 11 | `java11` | Amazon Linux 2 | 30º de junho de 2027 | 31º de julho de 2027 | 31 de agosto de 2027 |
| Java 8 | `java8.al2` | Amazon Linux 2 | 30º de junho de 2027 | 31º de julho de 2027 | 31 de agosto de 2027 |
| .NET 10 | `dotnet10` | Amazon Linux 2023 | 14 de novembro de 2028 | 14 de dezembro de 2028 | 15 de janeiro de 2029 |
| .NET 9 (somente contêiner) | `dotnet9` | Amazon Linux 2023 | 10 de novembro de 2026 | Não programado | Não programado |
| .NET 8 | `dotnet8` | Amazon Linux 2023 | 10 de novembro de 2026 | 10 de dezembro de 2026 | 11 de janeiro de 2027 |
| Ruby 3.4 | `ruby3.4` | Amazon Linux 2023 | 31 de março de 2028 | 30 de abril de 2028 | 31 de maio de 2028 |
| Ruby 3.3 | `ruby3.3` | Amazon Linux 2023 | 31 de março de 2027 | 30 de abril de 2027 | 31 de maio de 2027 |
| Ruby 3.2 | `ruby3.2` | Amazon Linux 2 | 31 de março de 2026 | 31 de agosto de 2026 | 30 de setembro de 2026 |
| Runtime somente para sistema operacional | `provided.al2023` | Amazon Linux 2023 | 30 de junho de 2029 | 31 de julho de 2029 | 31 de agosto de 2029 |
| Runtime somente para sistema operacional | `provided.al2` | Amazon Linux 2 | 31 de julho de 2026 | 31 de agosto de 2026 | 30 de setembro de 2026 |
**nota**
Para novas regiões, o Lambda não oferecerá suporte a runtimes que deverão ser descontinuados nos próximos seis meses.
O Lambda mantém os runtimes gerenciados e suas imagens base de contêiner correspondentes atualizados com patches e suporte para lançamentos de versões menores. Para obter mais informações, consulte [Atualizações de runtime do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-update.html).
Para interagir programaticamente com outros Serviços da AWS e recursos da sua função do Lambda, é possível usar um dos AWS SDKs. Os runtimes do Node.js, Python e Ruby incluem uma versão do AWS SDK. No entanto, para manter o controle total de suas dependências e maximizar a [compatibilidade com versões anteriores](runtimes-update.md#runtime-update-compatibility) durante as atualizações automáticas de runtime, recomendamos incluir sempre os módulos do SDK que seu código usa (junto com quaisquer dependências) no pacote de implantação da sua função ou em uma [camada do Lambda](chapter-layers.md).
Recomendamos também usar a versão do SDK incluída no runtime somente quando não puder incluir pacotes adicionais em sua implantação. Por exemplo, ao criar sua função usando o editor de códigos do console do Lambda ou usando um código de função embutido em um modelo do CloudFormation.
O Lambda atualiza periodicamente as versões dos AWS SDKs incluídos nos runtimes do Node.js, Python e Ruby. Para determinar a versão do AWS SDK incluída no runtime que você está usando, consulte as seguintes seções:
+ [Versões do SDK incluídas no runtime (Node.js)](lambda-nodejs.md#nodejs-sdk-included)
+ [Versões do SDK incluídas no runtime (Python)](lambda-python.md#python-sdk-included)
+ [Versões do SDK incluídas no runtime (Ruby)](lambda-ruby.md#ruby-sdk-included)
O Lambda continua oferecendo suporte à linguagem de programação Go após a descontinuação do runtime Go 1.x. Para obter mais informações, consulte [Migrating AWS Lambda functions from the Go1.x runtime to the custom runtime on Amazon Linux 2](https://aws.amazon.com/blogs/compute/migrating-aws-lambda-functions-from-the-go1-x-runtime-to-the-custom-runtime-on-amazon-linux-2/) no *AWS Compute Blog*.
Todos os runtimes do Lambda compatíveis oferecem suporte às arquiteturas x86\$164 e arm64.
## Novas versões de runtime
O Lambda só fornece runtimes gerenciados para novas versões de linguagem quando a versão atinge a fase de suporte de longo prazo (LTS) do ciclo de lançamento da linguagem. Por exemplo, para o [ciclo de lançamento do Node.js](https://nodejs.org/en/about/previous-releases), quando a versão atinge a fase de LTS ativo.
Antes de a versão atingir a fase de suporte de longo prazo, permanece em desenvolvimento e ainda pode estar sujeita a alterações significativas. O Lambda aplica atualizações de runtime automaticamente por padrão. Portanto, alterações significativas na versão de um runtime podem impedir que as funções funcionem conforme o esperado.
O Lambda não fornece runtimes gerenciados para versões de linguagem que não estão programadas para a fase de LTS.
A lista a seguir mostra o mês de lançamento previsto para os próximos runtimes do Lambda. Essas datas são apenas indicativas e estão sujeitas a alterações.
+ **Ruby 3.5**: março de 2026
+ **Java 8, 11 e 17 no AL2023** - 2º trimestre de 2026
+ **Node.js 26**: novembro de 2026
+ **Python 3.15**: novembro de 2026
## Política de descontinuação de runtime
Os runtimes do Lambda para arquivos .zip se baseiam em uma combinação de sistema operacional, linguagem de programação e bibliotecas de software que estão sujeitos a manutenção e atualizações de segurança. A política de descontinuação padrão do Lambda é descontinuar um runtime quando qualquer um de seus componentes importantes chegar ao fim do suporte de longo prazo (LTS) da comunidade e as atualizações de segurança não estiverem mais disponíveis. Geralmente, isso ocorre para runtimes de linguagens, mas, em alguns casos, um runtime pode ser descontinuado porque o sistema operacional (SO) chegou ao fim do LTS.
Depois que um runtime é descontinuado, o AWS pode não aplicar mais patches de segurança a ele, e as funções que o utilizam não são mais elegíveis para suporte técnico. Esses runtimes descontinuados são fornecidos “como estão”, sem nenhuma garantia, e podem conter bugs, erros, defeitos ou outras vulnerabilidades.
Para saber mais sobre como gerenciar atualizações e descontinuações de runtime, consulte as seções a seguir e [Managing AWS Lambda runtime upgrades](https://aws.amazon.com/blogs/compute/managing-aws-lambda-runtime-upgrades/) on the *AWS Compute Blog*.
**Importante**
Ocasionalmente, o Lambda atrasa a descontinuação de um runtime do Lambda por um período limitado além da data de término do suporte da versão da linguagem compatível com o runtime. Durante esse período, o Lambda aplica apenas patches de segurança ao sistema operacional do runtime. O Lambda não aplica patches de segurança aos runtimes de linguagem de programação depois que eles atingem a data de término do suporte.
## Modelo de responsabilidade compartilhada
O Lambda é responsável por selecionar e publicar atualizações de segurança para todos os runtimes gerenciados e imagens de base de contêiner compatíveis. Por padrão, o Lambda aplicará essas atualizações automaticamente às funções que usam runtimes gerenciados. Se a configuração padrão de atualização automática de runtime foi alterada, consulte o [modelo de responsabilidade compartilhada dos controles de gerenciamento de runtime](runtime-management-shared.md). Em funções implantadas usando imagens de contêiner, você é responsável por recompilar a imagem de contêiner da função a partir da imagem de base mais recente e por implantá-la novamente.
Quando um runtime é descontinuado, cessa a responsabilidade do Lambda de atualizar o runtime gerenciado e as imagens de base de contêiner. Você é responsável por atualizar suas funções para usar um runtime ou imagem de base compatível.
Em todos os casos, você é responsável por aplicar as atualizações ao código de função, incluindo suas dependências. Suas responsabilidades no modelo de responsabilidade compartilhada estão resumidas na tabela a seguir.
| Fase do ciclo de vida do runtime | Responsabilidades do Lambda | Suas responsabilidades |
| --- | --- | --- |
| Runtime gerenciado compatível | Fornecer atualizações de runtime periódicas com patches de segurança e outras atualizações. Aplicar automaticamente as atualizações de runtime por padrão, (consulte [Modos de atualização de runtime](runtimes-update.md#runtime-management-controls) para ver os comportamentos não padrão). | Atualizar seu código de função, incluindo dependências, para resolver qualquer vulnerabilidade de segurança. |
| Imagem de contêiner compatível | Fornecer atualizações regulares de imagens de base de contêiner com patches de segurança e outras atualizações,. | Atualizar seu código de função, incluindo dependências, para resolver qualquer vulnerabilidade de segurança. Recompilar e reimplantar regularmente sua imagem de contêiner usando a imagem de base mais recente. |
| Runtime gerenciado prestes a ser descontinuado | Notifique os clientes por meio da documentação, Health Dashboard, e-mail e Trusted Advisor antes de descontinuar um runtime. A responsabilidade por atualizações do runtime termina quando ele é descontinuado. | Monitore a documentação do Lambda, Health Dashboard, e-mail ou Trusted Advisor para obter informações sobre a descontinuação de runtimes. Atualize as funções para um runtime compatível antes que o runtime anterior seja descontinuado. |
| Imagem de contêiner prestes a ser descontinuada | Notificações de descontinuação não disponíveis para funções que usam imagens de contêiner. A responsabilidade pelas atualizações de imagens de base de contêiner termina quando elas são descontinuadas. | Preste atenção aos cronogramas de descontinuação e atualize as funções para uma imagem de base compatível antes que a imagem anterior seja descontinuada. |
## Uso do runtime após a descontinuação
Depois que um runtime é descontinuado, o AWS pode não aplicar mais patches de segurança a ele, e as funções que o utilizam não são mais elegíveis para suporte técnico. Embora você possa continuar invocando as funções indefinidamente, a AWS recomenda migrar para um runtime compatível. Runtimes descontinuados são fornecidos “como estão”, sem nenhuma garantia e podem conter bugs, erros, defeitos ou outras vulnerabilidades. As funções que usam um runtime descontinuado também podem apresentar degradação de performance ou outros problemas, como a expiração de um certificado, que podem fazer com que elas deixem de funcionar bem.
É possível atualizar uma função para usar uma versão compatível mais nova do runtime a qualquer momento após o runtime ser descontinuado. Recomendamos testar a função com o novo runtime antes de aplicar as alterações em ambientes de produção. Não será possível reverter para o runtime descontinuado após as atualizações da função serem bloqueadas. Recomendamos o uso de [versões](configuration-versions.md) e [aliases](configuration-aliases.md) de função para permitir uma implantação segura com reversão.
O cronograma a seguir descreve o que acontece quando um runtime é descontinuado:
| Fase do ciclo de vida do runtime | Quando | O que |
| --- | --- | --- |
| Prazo de aviso sobre a descontinuação | Pelo menos 180 dias antes da descontinuação | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/lambda-runtimes.html) |
| Desaprovação | Data da substituição | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/lambda-runtimes.html) |
| Bloquear a criação de funções | Pelo menos 30 dias após a descontinuação | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/lambda-runtimes.html) |
| Bloquear a atualização de funções | Pelo menos 60 dias após a descontinuação | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/lambda-runtimes.html) |
**nota**
Para alguns runtimes, a AWS está atrasando as datas de block-function-create e block-function-update além dos habituais 30 e 60 dias após a descontinuação. A AWS fez essa alteração em resposta ao feedback dos clientes, a fim de proporcionar mais tempo para você atualizar suas funções. Consulte as tabelas em [Tempos de execução compatíveis](#runtimes-supported) e [Runtimes defasados](#runtimes-deprecated) para ver as datas do seu runtime. O Lambda não começará o bloqueio de criações ou atualizações de funções antes das datas fornecidas nessas tabelas.
## Receber notificações de descontinuação de runtime
Quando um runtime se aproxima da data de descontinuação, o Lambda envia um alerta por e-mail se alguma função da sua Conta da AWS usa esse runtime. As notificações também são exibidas no Health Dashboard e no AWS Trusted Advisor.
+ Receber notificações por e-mail:
O Lambda envia um alerta por e-mail pelo menos **180 dias** antes da descontinuação de um runtime. Este e-mail lista as versões \$1LATEST de todas as funções que usam o runtime. Para ver uma lista completa das versões de funções afetadas, use o Trusted Advisor ou consulte [Recuperar dados sobre as funções do Lambda que usam um runtime obsoleto](runtimes-list-deprecated.md).
O Lambda envia uma notificação por e-mail ao contato principal da sua Conta da AWS. Para obter informações sobre como visualizar ou atualizar os endereços de e-mail em sua conta, consulte [Updating contact information](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html) na *Referência geral da AWS*.
+ Receber notificações por meio do Health Dashboard:
O Health Dashboard exibe uma notificação pelo menos **180 dias** antes da descontinuação do runtime. As notificações aparecem na página **Integridade da sua conta**, em [Outras notificações](https://health.aws.amazon.com/health/home#/account/dashboard/other-notifications). A guia **Recursos afetados** da notificação lista as versões \$1LATEST de todas as funções que usam o runtime.
**nota**
Para ver uma lista completa e atualizada das versões de funções afetadas, use o Trusted Advisor ou consulte [Recuperar dados sobre as funções do Lambda que usam um runtime obsoleto](runtimes-list-deprecated.md).
As notificações do Health Dashboard expiram 90 dias após a descontinuação do runtime.
+ Usar o AWS Trusted Advisor
O Trusted Advisor exibe uma notificação pelo menos **180 dias** antes da descontinuação do runtime. As notificações são exibidas na página [Segurança](https://console.aws.amazon.com/trustedadvisor/home#/category/security). Uma lista das funções afetadas é exibida em **AWS Lambda Functions Using Deprecated Runtimes**. Essa lista de funções mostra versões \$1LATEST e publicadas, e é atualizada automaticamente para refletir o status atual das funções.
É possível ativar notificações semanais por e-mail no Trusted Advisor na página [Preferências](https://console.aws.amazon.com/trustedadvisor/home?#/preferences) do console do Trusted Advisor.
## Runtimes defasados
Os seguintes runtimes atingiram o fim do suporte:
| Nome | Identificador | Sistema operacional | Data da substituição | Bloquear a criação de funções | Bloquear a atualização de funções |
| --- | --- | --- | --- | --- | --- |
| Python 3.9 | python3.9 | Amazon Linux 2 | 15 de dezembro de 2025 | 31 de agosto de 2026 | 30 de setembro de 2026 |
| Node.js 18 | nodejs18.x | Amazon Linux 2 | 1.º de setembro de 2025 | 31 de agosto de 2026 | 30 de setembro de 2026 |
| .NET 6 | dotnet6 | Amazon Linux 2 | 20 de dezembro de 2024 | 31 de agosto de 2026 | 30 de setembro de 2026 |
| Python 3.8 | python3.8 | Amazon Linux 2 | 14 de outubro de 2024 | 31 de agosto de 2026 | 30 de setembro de 2026 |
| Node.js 16 | nodejs16.x | Amazon Linux 2 | 12 de junho de 2024 | 31 de agosto de 2026 | 30 de setembro de 2026 |
| .NET 7 (somente contêiner) | dotnet7 | Amazon Linux 2 | 14 de maio de 2024 | N/D | N/D |
| Java 8 | java8 | Amazon Linux | 8 de janeiro de 2024 | 8 de fevereiro de 2024 | 30 de setembro de 2026 |
| Go 1.x | go1.x | Amazon Linux | 8 de janeiro de 2024 | 8 de fevereiro de 2024 | 30 de setembro de 2026 |
| Runtime somente para sistema operacional | provided | Amazon Linux | 8 de janeiro de 2024 | 8 de fevereiro de 2024 | 30 de setembro de 2026 |
| Ruby 2.7 | ruby2.7 | Amazon Linux 2 | 7 de dezembro de 2023 | 9 de janeiro de 2024 | 30 de setembro de 2026 |
| Node.js 14 | nodejs14.x | Amazon Linux 2 | 4 de dezembro de 2023 | 9 de janeiro de 2024 | 30 de setembro de 2026 |
| Python 3.7 | python3.7 | Amazon Linux | 4 de dezembro de 2023 | 9 de janeiro de 2024 | 30 de setembro de 2026 |
| .NET Core 3.1 | dotnetcore3.1 | Amazon Linux 2 | 3 de abril de 2023 | 3 de abril de 2023 | 3 de maio de 2023 |
| Node.js 12 | nodejs12.x | Amazon Linux 2 | 31 de março de 2023 | 31 de março de 2023 | 30 de abril de 2023 |
| Python 3.6 | python3.6 | Amazon Linux | 18 de julho de 2022 | 18 de julho de 2022 | 29 de agosto de 2022 |
| .NET 5 (somente contêiner) | dotnet5.0 | Amazon Linux 2 | 10 de maio de 2022 | N/D | N/D |
| .NET Core 2.1 | dotnetcore2.1 | Amazon Linux | 5 de janeiro de 2022 | 5 de janeiro de 2022 | 13 de abril de 2022 |
| Node.js 10 | nodejs10.x | Amazon Linux 2 | 30 de julho de 2021 | 30 de julho de 2021 | 14 de fevereiro de 2022 |
| Ruby 2.5 | ruby2.5 | Amazon Linux | 30 de julho de 2021 | 30 de julho de 2021 | 31 de março de 2022 |
| Python 2.7 | python2.7 | Amazon Linux | 15 de julho de 2021 | 15 de julho de 2021 | 30 de maio de 2022 |
| Node.js 8.10 | nodejs8.10 | Amazon Linux | 6 de março de 2020 | 4 de fevereiro de 2020 | 6 de março de 2020 |
| Node.js 4.3 | nodejs4.3 | Amazon Linux | 5 de março de 2020 | 3 de fevereiro de 2020 | 5 de março de 2020 |
| Borda do Node.js 4.3 | nodejs4.3-edge | Amazon Linux | 5 de março de 2020 | 31 de março de 2019 | 30 de abril de 2019 |
| Node.js 6.10 | nodejs6.10 | Amazon Linux | 12 de agosto de 2019 | 12 de julho de 2019 | 12 de agosto de 2019 |
| .NET Core 1.0 | dotnetcore1.0 | Amazon Linux | 27 de junho de 2019 | 30 de junho de 2019 | 30 de julho de 2019 |
| .NET Core 2.0 | dotnetcore2.0 | Amazon Linux | 30 de maio de 2019 | 30 de abril de 2019 | 30 de maio de 2019 |
| Node.js 0.10 | nodejs | Amazon Linux | 30 de agosto de 2016 | 30 de setembro de 2016 | 31 de outubro de 2016 |
Em quase todos os casos, a data do fim da vida útil de uma versão da linguagem ou de um sistema operacional é conhecida com antecedência. Os links a seguir fornecem programações relacionadas com o fim da vida útil para cada linguagem compatível com o Lambda como um runtime gerenciado.
**Políticas de suporte de framework e linguagem**
+ **Node.js**: [github.com](https://github.com/nodejs/Release#release-schedule)
+ **Python**: [devguide.python.org](https://devguide.python.org/versions/#versions)
+ **Ruby**: [www.ruby-lang.org](https://www.ruby-lang.org/en/downloads/branches/)
+ **Java**: [www.oracle.com](https://www.oracle.com/java/technologies/java-se-support-roadmap.html) [Perguntas frequentes sobre o Corretto](https://aws.amazon.com/corretto/faqs/)
+ **Go** – [golang.org](https://golang.org/doc/devel/release.html)
+ **.NET**: [dotnet.microsoft.com](https://dotnet.microsoft.com/platform/support/policy/dotnet-core)
# Entender como o Lambda gerencia as atualizações de versão do runtime
O Lambda mantém cada runtime gerenciado atualizado com atualizações de segurança, correções de bugs, novos recursos, aprimoramentos de performance e suporte para lançamentos de versões secundárias. Essas atualizações de runtime são publicadas como *versões de runtime*. O Lambda aplica atualizações de runtime às funções ao migrar a função de uma versão de runtime anterior para uma nova versão de runtime.
Por padrão, para funções que usam runtimes gerenciados, o Lambda aplica atualizações de runtime automaticamente. Com as atualizações automáticas de runtime, o Lambda assume a responsabilidade operacional de corrigir as versões de runtime. Para a maioria dos clientes, as atualizações automáticas são a escolha mais adequada. Você pode alterar esse comportamento padrão [definindo as configurações de gerenciamento de runtime](runtime-management-configure-settings.md).
O Lambda também publica cada nova versão de runtime como uma imagem de contêiner. Para atualizar as versões de runtime para as funções baseadas em contêiner, é necessário [criar uma nova imagem de contêiner](images-create.md) a partir da imagem base atualizada e implantar novamente a função.
Cada versão de runtime está associada a um número de versão e a um ARN (nome do recurso da Amazon). Os números de versão de runtime usam um esquema de numeração definido pelo Lambda, independentemente dos números de versão usados pela linguagem de programação. Números de versão de runtimes nem sempre são sequenciais. Por exemplo, a versão 42 pode ser seguida pela versão 45. O ARN da versão de runtime corresponde a um identificador exclusivo para cada versão de runtime. Você pode visualizar o ARN da versão atual do runtime da função no console do Lambda ou na [linha `INIT_START` dos logs da função](runtime-management-identify.md).
As versões de runtime não devem ser confundidas com os identificadores de runtime. Cada runtime tem um **identificador de runtime** exclusivo, como `python3.14` ou `nodejs24.x`. Eles correspondem a cada lançamento da versão principal da linguagem de programação. As versões de runtime descrevem a versão de patch de um runtime individual.
**nota**
O ARN para o mesmo número de versão de runtime pode variar entre as Regiões da AWS e as arquiteturas de CPU.
**Topics**
+ [
## Compatibilidade retroativa
](#runtime-update-compatibility)
+ [
## Modos de atualização de runtime
](#runtime-management-controls)
+ [
## Lançamento da versão de runtime em duas fases
](#runtime-management-two-phase)
+ [
# Configurar o gerenciamento de runtime do Lambda
](runtime-management-configure-settings.md)
+ [
# Reverter uma versão do runtime do Lambda
](runtime-management-rollback.md)
+ [
# Identificar alterações de versão do runtime do Lambda
](runtime-management-identify.md)
+ [
# Entender o modelo de responsabilidade compartilhada para o gerenciamento do runtime do Lambda
](runtime-management-shared.md)
+ [
# Controlar permissões de atualização de runtime para aplicações de alta conformidade
](runtime-management-hc-applications.md)
## Compatibilidade retroativa
O Lambda se empenha para fornecer atualizações de runtime compatíveis com as funções existentes. No entanto, como acontece com a aplicação de patches de software, há casos raros em que uma atualização de runtime pode afetar negativamente uma função existente. Por exemplo, os patches de segurança podem expor um problema subjacente em uma função existente que depende do comportamento inseguro anterior.
Ao criar e implantar sua função, é importante entender como gerenciar suas dependências para evitar possíveis incompatibilidades com uma futura atualização de runtime. Por exemplo, suponha que sua função tenha uma dependência do pacote A, que por sua vez depende do pacote B. Ambos os pacotes estão incluídos no runtime do Lambda (por exemplo, eles podem ser partes do SDK ou de suas dependências, ou partes das bibliotecas do sistema de runtime).
Considere os seguintes cenários:
| Implantação | Compatível com patches | Motivo |
| --- | --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/runtimes-update.html) | Sim | As futuras atualizações de runtime dos pacotes A e B são compatíveis com versões anteriores. |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/runtimes-update.html) | Sim | Sua implantação tem precedência, portanto, futuras atualizações de runtime nos pacotes A e B não terão efeito. |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/runtimes-update.html) | Sim\$1 | As futuras atualizações de runtime do pacote B são compatíveis com versões anteriores. \$1Se A e B estiverem fortemente acoplados, problemas de compatibilidade poderão ocorrer. Por exemplo, os pacotes `boto3` e `botocore` no AWS SDK para Python devem ser implantados juntos. |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/runtimes-update.html) | Não | Futuras atualizações de runtime do pacote A podem exigir uma versão atualizada do pacote B. No entanto, a versão implantada do pacote B tem precedência e pode não ser compatível com versões futuras da versão atualizada do pacote A. |
Para manter a compatibilidade com futuras atualizações de runtime, siga estas práticas recomendadas:
+ **Quando possível, empacote todas as dependências:** inclua todas as bibliotecas necessárias, incluindo o AWS SDK e suas dependências, no seu pacote de implantação. Isso garante um conjunto estável e compatível de componentes.
+ **Use SDKs fornecidos com o runtime com moderação:** confie apenas no SDK fornecido com o runtime quando não puder incluir pacotes adicionais (por exemplo, ao usar o editor de código do console do Lambda ou código embutido em um modelo do AWS CloudFormation).
+ **Evite substituir as bibliotecas do sistema:** não implante bibliotecas personalizadas do sistema operacional que possam entrar em conflito com futuras atualizações de runtime.
## Modos de atualização de runtime
O Lambda se empenha para fornecer atualizações de runtime compatíveis com as funções existentes. No entanto, como acontece com a aplicação de patches de software, há casos raros em que uma atualização de runtime pode afetar negativamente uma função existente. Por exemplo, os patches de segurança podem expor um problema subjacente em uma função existente que depende do comportamento inseguro anterior. Os controles de gerenciamento de runtime do Lambda ajudam a reduzir o risco de impacto em suas workloads no caso raro de uma incompatibilidade de versão de runtime. Para cada [versão de função](configuration-versions.md) (`$LATEST` ou a versão publicada), é possível escolher um dos seguintes modos de atualização de runtime:
+ **Auto** (Automático) (padrão): atualize automaticamente para a versão de runtime mais recente e segura usando [Lançamento da versão de runtime em duas fases](#runtime-management-two-phase). Recomendamos este modo para a maioria dos clientes, para que você sempre se beneficie das atualizações de runtime.
+ **Atualização da função**: atualize para a versão de runtime mais recente e segura ao atualizar a função. Quando você atualiza a função, o Lambda atualiza o runtime da função para a versão de runtime mais recente e segura. Essa abordagem sincroniza as atualizações de runtime com as implantações de função, oferecendo a você controle sobre quando o Lambda aplicará as atualizações de runtime. Com esse modo, é possível detectar e mitigar incompatibilidades raras de atualização de runtime com antecedência. Ao usar esse modo, é necessário atualizar regularmente as funções para manter o runtime atualizado.
+ **Manual**: atualize manualmente sua versão do runtime. Especifique uma versão de runtime em sua configuração de função. A função usa essa versão de runtime indefinidamente. No caso raro em que uma nova versão de runtime é incompatível com uma função existente, você pode usar este modo para reverter a função para uma versão de runtime anterior. Não recomendamos o uso do modo **Manual** para tentar obter a consistência de runtime entre as implantações. Para obter mais informações, consulte [Reverter uma versão do runtime do Lambda](runtime-management-rollback.md).
A responsabilidade pela aplicação de atualizações de runtime às funções varia de acordo com o modo de atualização de runtime escolhido. Para obter mais informações, consulte [Entender o modelo de responsabilidade compartilhada para o gerenciamento do runtime do Lambda](runtime-management-shared.md).
## Lançamento da versão de runtime em duas fases
O Lambda apresenta novas versões de runtime nesta ordem:
1. Na primeira fase, o Lambda aplica a nova versão de runtime sempre que você cria ou atualiza uma função. Uma função é atualizada quando você chama as operações de API [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) ou [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html).
1. Na segunda fase, o Lambda atualiza qualquer função que usa o modo de atualização de runtime **Auto** (Automático) e que ainda não tenha sido atualizada para a nova versão de runtime.
A duração geral do processo de implantação varia de acordo com diversos fatores, incluindo a gravidade de quaisquer patches de segurança inclusos na atualização de runtime.
Se você estiver desenvolvendo e implantando ativamente as funções, provavelmente adquirirá novas versões de runtime durante a primeira fase. Isso sincroniza as atualizações de runtime com as atualizações de função. No caso raro de a versão de runtime mais recente impactar negativamente a aplicação, essa abordagem permitirá que você tome medidas corretivas imediatas. As funções que não estão em desenvolvimento ativo ainda recebem o benefício operacional de atualizações automáticas de runtime durante a segunda fase.
Essa abordagem não afeta as funções definidas como os modos **Function update** (Atualização da função) ou **Manual**. As funções que usam o modo **Function update** (Atualização da função) recebem as atualizações de runtime mais recentes somente quando você as cria ou atualiza. As funções que usam o modo **Manual** não recebem as atualizações de runtime.
O Lambda publica novas versões de runtime de maneira gradual e contínua nas Regiões da AWS. Se as funções estiverem definidas para os modos **Auto** (Automático) ou **Function update** (Atualização da função), é possível que as funções implantadas ao mesmo tempo em regiões diferentes ou em momentos diferentes na mesma região selecionem diferentes versões de runtime. Os clientes que requerem consistência de versão de runtime garantida em seus ambientes devem [usar imagens de contêiner para implantar as funções do Lambda](images-create.md). O modo **Manual** foi criado como mitigação temporária para permitir a reversão de versão runtime no caso raro de uma versão de runtime ser incompatível com a função.
# Configurar o gerenciamento de runtime do Lambda
É possível definir as configurações de gerenciamento de runtime usando o console do Lambda ou a AWS Command Line Interface (AWS CLI).
**nota**
Você pode definir as configurações de gerenciamento de runtime separadamente para cada [versão de função](configuration-versions.md).
**Para configurar como o Lambda atualiza a versão de runtime (console)**
1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda.
1. Escolha o nome de uma função.
1. Na guia **Code** (Código), em **Runtime settings** (Configurações de runtime), escolha **Edit runtime management configuration** (Editar configuração de gerenciamento de runtime).
1. Em **Configuração de gerenciamento de runtime**, escolha uma das seguintes opções:
+ Para que a função seja atualizada automaticamente para a versão de runtime mais recente, escolha **Auto** (Automático).
+ Para que a função seja atualizada para a versão de runtime mais recente ao alterar a função, escolha **Function update** (Atualização da função).
+ Para que a função seja atualizada para a versão de runtime mais recente somente ao alterar o ARN da versão de runtime, escolha **Manual**. É possível encontrar o ARN da versão de runtime em **Runtime management configuration** (Configuração de gerenciamento de runtime). Também é possível encontrar o ARN na linha `INIT_START` de seus logs de função.
Para obter mais informações sobre essas opções, consulte [Modos de atualização de runtime](runtimes-update.md#runtime-management-controls).
1. Escolha **Salvar**.
**Para configurar como o Lambda atualiza a versão de runtime (AWS CLI)**
Para configurar o gerenciamento de runtime para uma função, execute o comando da AWS CLI [put-runtime-management-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/put-runtime-management-config.html). Ao usar o modo `Manual`, você também deve fornecer o ARN da versão de runtime.
```
aws lambda put-runtime-management-config \
--function-name my-function \
--update-runtime-on Manual \
--runtime-version-arn arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1
```
Você deve ver saída semelhante a:
```
{
"UpdateRuntimeOn": "Manual",
"FunctionArn": "arn:aws:lambda:us-east-2:111122223333:function:my-function",
"RuntimeVersionArn": "arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1"
}
```
# Reverter uma versão do runtime do Lambda
No caso raro de uma nova versão de runtime ser incompatível com a função existente, é possível reverter a versão de runtime para uma anterior. Isso mantém sua aplicação funcionando e minimiza as interrupções, fornecendo tempo para corrigir a incompatibilidade antes de retornar à versão de runtime mais recente.
O Lambda não impõe um limite de tempo para o uso de qualquer versão de runtime específica. No entanto, recomendamos fortemente atualizar para a versão de runtime mais recente o mais rápido possível para se beneficiar dos patches de segurança, melhorias de performance e recursos mais recentes. O Lambda oferece a opção de reverter para uma versão de runtime anterior somente como uma mitigação temporária no caso raro de um problema de compatibilidade de atualização de runtime. As funções que usam uma versão de runtime anterior por um período prolongado podem, futuramente, apresentar performance degradada ou problemas, como a expiração de um certificado, que podem fazer com que parem de funcionar corretamente.
É possível reverter uma versão de runtime das seguintes formas:
+ [Usar o modo manual de atualização de runtime](#runtime-management-rollback-manual)
+ [Usando versões de funções publicadas](#runtime-management-rollback-published)
Para obter mais informações, consulte [Introdução aos controles de gerenciamento de runtime do AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-aws-lambda-runtime-management-controls/) no Blog de computação da AWS.
## Reverter uma versão de runtime usando o modo de atualização de runtime Manual
Se você estiver usando o modo de atualização de versão de runtime **Auto** (Automático) ou estiver usando a versão de runtime `$LATEST`, poderá reverter a versão de runtime usando o modo **Manual**. Para a [versão de função](configuration-versions.md) que você deseja reverter, altere o modo de atualização de versão de runtime para **Manual** e especifique o ARN da versão de runtime anterior. Para obter mais informações sobre como localizar o ARN da versão de runtime anterior, consulte [Identificar alterações de versão do runtime do Lambda](runtime-management-identify.md).
**nota**
Se a versão `$LATEST` de sua função estiver configurada para usar o modo **Manual**, não será possível alterar a arquitetura da CPU ou a versão de runtime que sua função usa. Para realizar essas alterações, você deve alterar para os modos **Auto** (Automático) ou **Function update** (Atualização da função).
## Reverter uma versão de runtime usando versões de funções publicadas
As [versões de função](configuration-versions.md) publicadas correspondem a um snapshot imutável do código da função `$LATEST` e da configuração no momento em que você os criou. No modo **Auto** (Automático), o Lambda atualiza automaticamente a versão de runtime das versões de funções publicadas durante a segunda fase da implantação da versão de runtime. No modo **Function update** (Atualização da função), o Lambda não atualiza a versão de runtime das versões de função publicadas.
Portanto, as versões de função publicadas usando o modo **Function update** (Atualização da função) criam um snapshot estático do código da função, da configuração e da versão de runtime. Ao usar o modo **Function update** (Atualização da função) com versões de função, é possível sincronizar as atualizações de runtime com as implantações. Também é possível coordenar a reversão do código, da configuração e das versões de runtime ao redirecionar o tráfego para uma versão de função publicada anteriormente. É possível integrar essa abordagem na integração e entrega contínuas (CI/CD) para reversão totalmente automática no caso raro de incompatibilidade de atualização de runtime. Ao usar essa abordagem, é necessário atualizar a função regularmente e publicar novas versões de função para obter as atualizações de runtime mais recentes. Para ter mais informações, consulte [Entender o modelo de responsabilidade compartilhada para o gerenciamento do runtime do Lambda](runtime-management-shared.md).
# Identificar alterações de versão do runtime do Lambda
O [número e o ARN da versão de runtime](runtimes-update.md) são registrados na linha de log `INIT_START`, que o Lambda emite para o CloudWatch Logs sempre que um novo [ambiente de execução](concepts-basics.md#gettingstarted-concepts-runtime) é criado. Como o ambiente de execução usa uma versão de runtime semelhante para todas as invocações de função, o Lambda emite a linha de log `INIT_START` somente quando o Lamba executa a fase de inicialização. O Lambda não emite essa linha de log para cada invocação de função. O Lambda emite a linha de log para o CloudWatch Logs, mas não é algo visível no console.
**nota**
Números de versão de runtimes nem sempre são sequenciais. Por exemplo, a versão 42 pode ser seguida pela versão 45.
**Example Exemplo de linha de log “INIT\$1START”**
```
INIT_START Runtime Version: python:3.13.v14 Runtime Version ARN: arn:aws:lambda:eu-south-1::runtime:7b620fc2e66107a1046b140b9d320295811af3ad5d4c6a011fad1fa65127e9e6I
```
Em vez de trabalhar diretamente com os logs, é possível usar o [Amazon CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-CreateRule.html) para identificar transições entre as versões de runtime. A regra a seguir contabiliza as versões de runtime distintas de cada linha de log `INIT_START`. Para usar a regra, substitua o nome do grupo de logs de exemplo `/aws/lambda/*` pelo prefixo apropriado para sua função ou grupo de funções.
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "eventType",
"In": [
"INIT_START"
]
}
],
"Keys": [
"runtimeVersion",
"runtimeVersionArn"
]
},
"LogFormat": "CLF",
"LogGroupNames": [
"/aws/lambda/*"
],
"Fields": {
"1": "eventType",
"4": "runtimeVersion",
"8": "runtimeVersionArn"
}
}
```
O relatório do CloudWatch Contributor Insights apresentado a seguir mostra um exemplo de uma transição de versão de runtime conforme capturado pela regra anterior. A linha laranja mostra a inicialização do ambiente de execução para a versão de runtime anterior (**python:3.13.v12**) e a linha azul mostra a inicialização do ambiente de execução para a nova versão de runtime (**python:3.13.v14**).
![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/runtime_version_graph.png)
# Entender o modelo de responsabilidade compartilhada para o gerenciamento do runtime do Lambda
O Lambda é responsável por selecionar e publicar atualizações de segurança para todos os runtimes gerenciados e imagens de contêiner com suporte. A responsabilidade pela atualização das funções existentes para usar a versão de runtime mais recente varia de acordo com o modo de atualização de runtime usado.
O Lambda é responsável por aplicar atualizações de runtime a todas as funções configuradas para usar o modo de atualização de runtime **Auto** (Automático).
Para funções configuradas com o modo de atualização de runtime **Function update** (Atualização da função), você é responsável por atualizar regularmente a função. O Lambda é responsável por aplicar as atualizações de runtime quando você faz essas atualizações. Se você não atualizar sua função, o Lambda não atualizará o runtime. Se você não atualiza regularmente sua função, recomendamos fortemente configurá-la para atualizações automáticas de runtime a fim de que continue recebendo atualizações de segurança.
Para funções configuradas para usar o modo de atualização de runtime **Manual**, você é responsável por atualizar a função para usar a versão de runtime mais recente. É altamente recomendável que você use esse modo somente para reverter a versão de runtime como uma mitigação temporária no caso raro de incompatibilidade de atualização de runtime. Também é recomendado que você altere para o modo **Auto** (Automático) o mais rápido possível para minimizar o tempo em que suas funções não são corrigidas.
Se você estiver [usando imagens de contêiner para implantar as funções](images-create.md), o Lambda será responsável por publicar imagens de base atualizadas. Nesse caso, você é responsável por recriar a imagem de contêiner da função a partir da imagem de base mais recente e implantar novamente a imagem de contêiner.
Isso está resumido na seguinte tabela:
****
| Modo de implantação | Responsabilidade do Lambda | Responsabilidade do cliente |
| --- | --- | --- |
| Runtime gerenciado, modo Auto (Automático) | Publicar novas versões de runtime contendo os patches mais recentes. Aplicar os patches de runtime para as funções existentes. | Reverter para uma versão de runtime anterior no caso raro de um problema de compatibilidade de atualização de runtime. Siga as práticas recomendadas para [compatibilidade com versões anteriores](runtimes-update.md#runtime-update-compatibility). |
| Runtime gerenciado, modo Function update (Atualização da função) | Publicar novas versões de runtime contendo os patches mais recentes. | Atualizar as funções regularmente para obter a versão de runtime mais recente. Alterar uma função para o modo **Auto** (Automático) quando não estiver atualizando a função regularmente. Reverter para uma versão de runtime anterior no caso raro de um problema de compatibilidade de atualização de runtime. Siga as práticas recomendadas para [compatibilidade com versões anteriores](runtimes-update.md#runtime-update-compatibility). |
| Runtime gerenciado, modo Manual | Publicar novas versões de runtime contendo os patches mais recentes. | Usar esse modo somente para reversão temporária de runtime no caso raro de um problema de compatibilidade de atualização de runtime. Alterar as funções para os modos **Auto** (Automático) ou **Function update** (Atualização da função) e para a versão de runtime mais recente o mais rápido possível. |
| Imagem de contêiner | Publicar novas imagens de contêiner contendo os patches mais recentes. | Reimplantar as funções regularmente usando a imagem de contêiner de base mais recente para obter os patches mais recentes. |
Para obter mais informações sobre a responsabilidade compartilhada com a AWS, consulte [Modelo de responsabilidade compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/).
# Controlar permissões de atualização de runtime para aplicações de alta conformidade
Para atender aos requisitos de aplicação de patches, os clientes do Lambda normalmente contam com atualizações automáticas de runtime. Se sua aplicação estiver sujeita a requisitos estritos de atualização de patches, convém limitar o uso de versões de runtime anteriores. É possível restringir os controles de gerenciamento de runtime do Lambda usando o AWS Identity and Access Management (IAM) para negar aos usuários em sua conta da AWS acesso à operação de API [PutRuntimeManagementConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutRuntimeManagementConfig.html). Esta operação é usada para escolher o modo de atualização de runtime para uma função. Negar o acesso a esta operação faz com que todas as funções sejam padronizadas para o modo **Auto** (Automático). É possível aplicar essa restrição em toda a organização usando [políticas de controle de serviços (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). Se você precisar reverter uma função para uma versão anterior do runtime, poderá fazer uma exceção à política caso a caso.
# Recuperar dados sobre as funções do Lambda que usam um runtime obsoleto
Quando um runtime do Lambda está se prestes a ser descontinuado, o Lambda alerta você por e-mail e fornece notificações no Health Dashboard e no Trusted Advisor. Esses e-mails e notificações listam as versões \$1LATEST das funções que usam o runtime. Para listar todas as versões da função que usam um determinado runtime, você pode usar a AWS Command Line Interface (AWS CLI) ou um dos AWS SDKs.
Se tiver muitas funções que usam um runtime que está prestes a ser descontinuado, você também poderá usar a AWS CLI ou os AWS SKLs para ajudar a priorizar as atualizações das funções mais invocadas.
Consulte as seções a seguir para saber como usar a AWS CLI e os AWS SDKs para coletar dados sobre as funções que usam um determinado runtime.
## Listar as versões da função que usam um determinado runtime
Para usar a AWS CLI para listar todas as versões da função que usam um determinado runtime, execute o comando a seguir. Substitua `RUNTIME_IDENTIFIER` pelo nome do runtime que está sendo descontinuado e escolha sua própria Região da AWS. Para listar somente as versões da função \$1LATEST, omita `--function-version ALL` do comando.
```
aws lambda list-functions --function-version ALL --region us-east-1 --output text --query "Functions[?Runtime=='RUNTIME_IDENTIFIER'].FunctionArn"
```
**dica**
O exemplo de comando lista as funções na região `us-east-1` para uma determinada Conta da AWS. Você precisará repetir esse comando para cada região na qual sua conta tiver funções e para cada uma das suas Contas da AWS.
Você também pode listar funções que usam um determinado runtime usando um dos AWS SDKs. O exemplo de código a seguir usa o AWS SDK para JavaScript V3 e o AWS SDK para Python (Boto3) para retornar uma lista dos ARNs de função para as funções que usam um determinado runtime. O código de exemplo também retorna o grupo de logs do CloudWatch para cada uma das funções listadas. Você pode usar esse grupo de logs para encontrar a data da última invocação da função. Consulte a seção [Identificar as funções invocadas com maior frequência e as invocadas mais recentemente](#runtimes-list-deprecated-statistics) a seguir para obter mais informações.
------
#### [ Node.js ]
**Example Código JavaScript para listar as funções que usam um determinado runtime**
```
import { LambdaClient, ListFunctionsCommand } from "@aws-sdk/client-lambda";
const lambdaClient = new LambdaClient();
const command = new ListFunctionsCommand({
FunctionVersion: "ALL",
MaxItems: 50
});
const response = await lambdaClient.send(command);
for (const f of response.Functions){
if (f.Runtime == ''){ // Use the runtime id, e.g. 'nodejs24.x' or 'python3.14'
console.log(f.FunctionArn);
// get the CloudWatch log group of the function to
// use later for finding the last invocation date
console.log(f.LoggingConfig.LogGroup);
}
}
// If your account has more functions than the specified
// MaxItems, use the returned pagination token in the
// next request with the 'Marker' parameter
if ('NextMarker' in response){
let paginationToken = response.NextMarker;
}
```
------
#### [ Python ]
**Example Código Python para listar as funções que usam um determinado runtime**
```
import boto3
from botocore.exceptions import ClientError
def list_lambda_functions(target_runtime):
lambda_client = boto3.client('lambda')
response = lambda_client.list_functions(
FunctionVersion='ALL',
MaxItems=50
)
if not response['Functions']:
print("No Lambda functions found")
else:
for function in response['Functions']:
if function['PackageType']=='Zip' and function['Runtime'] == target_runtime:
print(function['FunctionArn'])
# Print the CloudWatch log group of the function
# to use later for finding last invocation date
print(function['LoggingConfig']['LogGroup'])
if 'NextMarker' in response:
pagination_token = response['NextMarker']
if __name__ == "__main__":
# Replace python3.12 with the appropriate runtime ID for your Lambda functions
list_lambda_functions('python3.12')
```
------
Para saber mais sobre como usar um AWS SDK para listar suas funções usando a ação [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html), consulte a [documentação do SDK](https://aws.amazon.com/developer/tools/) para sua linguagem de programação preferida.
Você também pode usar o recurso Consultas avançadas do AWS Config para listar todas as suas funções que usam um runtime afetado. Essa consulta retorna apenas as versões da função \$1LATEST, mas você pode agregar consultas para listar funções em todas as regiões e em várias Contas da AWS com um único comando. Para saber mais, consulte [Querying the Current Configuration State of AWS Auto Scaling Resources](https://docs.aws.amazon.com/config/latest/developerguide/querying-AWS-resources.html) no *AWS Config Developer Guide*.
## Identificar as funções invocadas com maior frequência e as invocadas mais recentemente
Se a sua Conta da AWS contém funções que usam um runtime que está prestes a ser descontinuado, você deve priorizar a atualização de funções que são invocadas com frequência ou que foram invocadas recentemente.
Se você tiver apenas algumas funções, poderá usar o console do CloudWatch Logs para coletar essas informações examinando os fluxos de logs das funções. Consulte [Visualizar dados de log enviados para o CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) para obter mais informações.
Para ver o número de invocações recentes da função, você também pode usar as informações de métricas do CloudWatch mostradas no console do Lambda. Para visualizar essas informações, faça o seguinte:
1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda.
1. Selecione a função cujas estatísticas de invocação você deseja ver.
1. Escolha a guia **Monitor** (Monitorar).
1. Defina o período para o qual deseja visualizar estatísticas usando o seletor de intervalo de datas. As invocações recentes são exibidas no painel **Invocações**.
Para contas com mais funções, pode ser mais eficiente coletar esses dados programaticamente usando a AWS CLI ou um dos AWS SDKs com as ações de API [DescribeLogStreams](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DescribeLogStreams.html) e [GetMetricStatistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html).
Os exemplos a seguir fornecem trechos de código usando o AWS SDK para JavaScript V3 e o AWS SDK para Python (Boto3) para identificar a data da última invocação de uma determinada função e especificar o número de invocações de uma determinada função nos últimos 14 dias.
------
#### [ Node.js ]
**Example Código JavaScript para encontrar a hora da última invocação de uma função**
```
import { CloudWatchLogsClient, DescribeLogStreamsCommand } from "@aws-sdk/client-cloudwatch-logs";
const cloudWatchLogsClient = new CloudWatchLogsClient();
const command = new DescribeLogStreamsCommand({
logGroupName: '',
orderBy: 'LastEventTime',
descending: true,
limit: 1
});
try {
const response = await cloudWatchLogsClient.send(command);
const lastEventTimestamp = response.logStreams.length > 0 ?
response.logStreams[0].lastEventTimestamp : null;
// Convert the UNIX timestamp to a human-readable format for display
const date = new Date(lastEventTimestamp).toLocaleDateString();
const time = new Date(lastEventTimestamp).toLocaleTimeString();
console.log(`${date} ${time}`);
} catch (e){
console.error('Log group not found.')
}
```
------
#### [ Python ]
**Example Código Python para encontrar a hora da última invocação de uma função**
```
import boto3
from datetime import datetime
cloudwatch_logs_client = boto3.client('logs')
response = cloudwatch_logs_client.describe_log_streams(
logGroupName='',
orderBy='LastEventTime',
descending=True,
limit=1
)
try:
if len(response['logStreams']) > 0:
last_event_timestamp = response['logStreams'][0]['lastEventTimestamp']
print(datetime.fromtimestamp(last_event_timestamp/1000)) # Convert timestamp from ms to seconds
else:
last_event_timestamp = None
except:
print('Log group not found')
```
------
**dica**
Você pode encontrar o nome do grupo de logs da função usando a operação de API [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html). Veja o código em [Listar as versões da função que usam um determinado runtime](#runtimes-list-deprecated-versions) para ter um exemplo de como fazer isso.
------
#### [ Node.js ]
**Example Código JavaScript para encontrar o número de invocações nos últimos 14 dias**
```
import { CloudWatchClient, GetMetricStatisticsCommand } from "@aws-sdk/client-cloudwatch";
const cloudWatchClient = new CloudWatchClient();
const command = new GetMetricStatisticsCommand({
Namespace: 'AWS/Lambda',
MetricName: 'Invocations',
StartTime: new Date(Date.now()-86400*1000*14), // 14 days ago
EndTime: new Date(Date.now()),
Period: 86400 * 14, // 14 days.
Statistics: ['Sum'],
Dimensions: [{
Name: 'FunctionName',
Value: ''
}]
});
const response = await cloudWatchClient.send(command);
const invokesInLast14Days = response.Datapoints.length > 0 ?
response.Datapoints[0].Sum : 0;
console.log('Number of invocations: ' + invokesInLast14Days);
```
------
#### [ Python ]
**Example Código Python para encontrar o número de invocações nos últimos 14 dias**
```
import boto3
from datetime import datetime, timedelta
cloudwatch_client = boto3.client('cloudwatch')
response = cloudwatch_client.get_metric_statistics(
Namespace='AWS/Lambda',
MetricName='Invocations',
Dimensions=[
{
'Name': 'FunctionName',
'Value': ''
},
],
StartTime=datetime.now() - timedelta(days=14),
EndTime=datetime.now(),
Period=86400 * 14, # 14 days
Statistics=[
'Sum'
]
)
if len(response['Datapoints']) > 0:
invokes_in_last_14_days = int(response['Datapoints'][0]['Sum'])
else:
invokes_in_last_14_days = 0
print(f'Number of invocations: {invokes_in_last_14_days}')
```
------
# Modificar o ambiente de runtime
É possível usar [extensões internas](lambda-extensions.md) para modificar o processo de runtime. As extensões internas não são processos separados. Elas são executadas como parte do processo de runtime.
O Lambda fornece específicos do idioma[Variáveis de ambiente](configuration-envvars.md) que você pode definir para adicionar opções e ferramentas ao runtime. O Lambda também fornece [scripts wrapper](#runtime-wrapper), que permitem ao Lambda delegar o startup do runtime ao seu script. Você pode criar um script wrapper para personalizar o comportamento de startup do runtime.
## Variáveis de ambiente específicas de linguagem
O Lambda é compatível com formas somente de configuração para permitir que o código seja pré-carregado durante a inicialização da função por meio das seguintes variáveis de ambiente específicas do idioma:
+ `JAVA_TOOL_OPTIONS`: no Java, o Lambda é compatível com essa variável de ambiente para definir variáveis da linha de comando adicionais no Lambda. Essa variável de ambiente permite especificar a inicialização de ferramentas, especificamente o lançamento de agentes de linguagem de programação nativa ou Java usando as opções `agentlib` ou `javaagent`. Para obter mais informações, consulte [Variável de ambiente `JAVA_TOOL_OPTIONS`](https://docs.aws.amazon.com/lambda/latest/dg/java-customization.html#java-tool-options).
+ `NODE_OPTIONS`: disponível em [runtimes do Node.js](lambda-nodejs.md).
+ `DOTNET_STARTUP_HOOKS`: no .NET Core 3.1 e superior, essa variável de ambiente especifica um caminho para um assembly (dll) que o Lambda pode usar.
Usar variáveis de ambiente específicas de linguagem é a maneira preferida de definir propriedades de startup.
## Scripts wrapper
Você pode criar um *script wrapper* para personalizar o comportamento de startup do runtime da função do Lambda. Um script wrapper permite que você defina parâmetros de configuração que não podem ser definidos por meio de variáveis de ambiente específicas de linguagem.
**nota**
As chamadas podem falhar se o script wrapper não iniciar com êxito o processo de runtime.
Os scripts wrapper são compatíveis com todos os runtimes nativos do [Lambda](lambda-runtimes.md). Os scripts wrapper não são compatíveis com [Runtimes somente para sistema operacional](runtimes-provided.md) (a família de runtime `provided`).
Quando você usa um script wrapper para sua função, o Lambda inicia o runtime usando seu script. O Lambda envia ao script o caminho para o intérprete e todos os argumentos originais para o startup padrão do runtime. O script pode estender ou transformar o comportamento de startup do programa. Por exemplo, o script pode injetar e alterar argumentos, definir variáveis de ambiente ou capturar métricas, erros e outras informações de diagnóstico.
Você especifica o script definindo o valor da variável de ambiente `AWS_LAMBDA_EXEC_WRAPPER` como o caminho do sistema de arquivos de um binário ou script executável.
### Exemplo: criar e usar um script wrapper como uma camada do Lambda
No exemplo a seguir, você cria um script wrapper para iniciar o interpretador Python com a opção `-X importtime`. Quando você executa a função, o Lambda gera uma entrada de log para mostrar a duração de cada importação.
**Para criar e usar um script wrapper como uma camada**
1. Crie um diretório para a camada:
```
mkdir -p python-wrapper-layer/bin
cd python-wrapper-layer/bin
```
1. No diretório `bin`, cole o código a seguir em um novo arquivo chamado `importtime_wrapper`. Este é o script wrapper.
```
#!/bin/bash
# the path to the interpreter and all of the originally intended arguments
args=("$@")
# the extra options to pass to the interpreter
extra_args=("-X" "importtime")
# insert the extra options
args=("${args[@]:0:$#-1}" "${extra_args[@]}" "${args[@]: -1}")
# start the runtime with the extra options
exec "${args[@]}"
```
1. Dê as permissões executáveis de scripts:
```
chmod +x importtime_wrapper
```
1. Crie um arquivo .zip para a camada:
```
cd ..
zip -r ../python-wrapper-layer.zip .
```
1. Confirme se o arquivo .zip tem a seguinte estrutura de diretórios:
```
python-wrapper-layer.zip
└ bin
└ importtime_wrapper
```
1. [Crie uma camada](creating-deleting-layers.md#layers-create) usando o pacote .zip.
1. Crie uma função usando o console do Lambda.
1. Abra o [console do lambda](https://console.aws.amazon.com/lambda).
1. Escolha a opção **Criar função**.
1. Insira um **Nome de função**.
1. Em **Runtime**, escolha o último runtime Python em **Últimos compatíveis**.
1. Escolha a opção **Criar função**.
1. Adicione a camada à função.
1. Escolha sua função e, em seguida, escolha a guia **Código** se ela ainda não estiver selecionada.
1. Role para baixo até a seção **Camadas** e depois escolha **Adicionar uma camada**.
1. Em **Origem da camada**, selecione **Camadas personalizadas** e, em seguida, escolha sua camada na lista suspensa **Camadas personalizadas**.
1. Em **Version**, selecione **1**.
1. Escolha **Adicionar**.
1. Adicione a variável de ambiente do wrapper.
1. Escolha a guia **Configuração** e, em seguida, selecione **Variáveis de ambiente**.
1. Em **Environment variables (Variáveis de ambiente)**, selecione **Edit (Editar)**.
1. Escolha **Add environment variable (Adicionar variável de ambiente)**.
1. Em **Chave**, digite `AWS_LAMBDA_EXEC_WRAPPER`.
1. Em **Valor**, insira `/opt/bin/importtime_wrapper` (`/opt/` \$1 a estrutura de pastas da sua camada .zip).
1. Escolha **Salvar**.
1. Teste o script wrapper.
1. Selecione a guia **Testar**.
1. Em **Evento de teste**, escolha **Testar**. Não é necessário criar um evento de teste; o evento padrão funcionará.
1. Role para baixo até **Resultado de saída do log**. Como o script wrapper iniciou o interpretador Python com a opção `-X importtime`, os logs mostram o tempo necessário para cada importação. Por exemplo:
```
532 | collections
import time: 63 | 63 | _functools
import time: 1053 | 3646 | functools
import time: 2163 | 7499 | enum
import time: 100 | 100 | _sre
import time: 446 | 446 | re._constants
import time: 691 | 1136 | re._parser
import time: 378 | 378 | re._casefix
import time: 670 | 2283 | re._compiler
import time: 416 | 416 | copyreg
```
# Usar a API de runtime do Lambda para runtimes personalizados
O AWS Lambda fornece uma API HTTP para [runtimes personalizados](runtimes-custom.md) para receber eventos de invocação do Lambda e enviar dados de resposta de volta para o [ambiente de execução](lambda-runtimes.md) do Lambda. Esta seção contém a referência de API para a API do runtime do Lambda.
**As instâncias gerenciadas do Lambda oferecem suporte a solicitações simultâneas**
As instâncias gerenciadas do Lambda usam a mesma API de runtime das funções do Lambda (padrão). A principal diferença é que as instâncias gerenciadas podem aceitar solicitações simultâneas `/next` e `/response` até o limite configurado `AWS_LAMBDA_MAX_CONCURRENCY`. Isso permite que várias invocações sejam processadas simultaneamente em um único ambiente de execução. Para obter mais informações sobre instâncias gerenciadas, consulte [Noções básicas sobre o ambiente de execução das instâncias gerenciadas do Lambda](lambda-managed-instances-execution-environment.md).
![\[Diagrama de arquitetura do ambiente de execução.\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
A especificação OpenAPI para a versão da API de runtime **2018-06-01** está disponível aqui: [runtime-api.zip](samples/runtime-api.zip)
Para criar um URL de solicitação de API, os runtimes obtêm o endpoint da API da variável de ambiente do `AWS_LAMBDA_RUNTIME_API`, adiciona a versão da API e o caminho de recurso desejado.
**Example Solicitação**
```
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next"
```
**Topics**
+ [
## Próxima invocação
](#runtimes-api-next)
+ [
## Resposta de invocação
](#runtimes-api-response)
+ [
## Erro de inicialização
](#runtimes-api-initerror)
+ [
## Erro de invocação
](#runtimes-api-invokeerror)
## Próxima invocação
**Caminho** – `/runtime/invocation/next`
**Método** – **GET**
O runtime envia essa mensagem ao Lambda para solicitar um evento de invocação. O corpo da resposta contém a carga útil da invocação, que é um documento JSON que contém os dados do evento do acionador da função. Os cabeçalhos de resposta contêm dados adicionais sobre a invocação.
**Cabeçalhos de resposta**
+ `Lambda-Runtime-Aws-Request-Id`: o ID da solicitação, que identifica a solicitação que acionou a invocação da função.
Por exemplo, `8476a536-e9f4-11e8-9739-2dfe598c3fcd`.
+ `Lambda-Runtime-Deadline-Ms`: a data em que a função expira tempo em milissegundos do Unix.
Por exemplo, `1542409706888`.
+ `Lambda-Runtime-Invoked-Function-Arn`: o ARN da função do Lambda, versão ou alias especificado na invocação.
Por exemplo, `arn:aws:lambda:us-east-2:123456789012:function:custom-runtime`.
+ `Lambda-Runtime-Trace-Id`: o [cabeçalho de rastreamento do AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html#xray-concepts-tracingheader).
Por exemplo, `Root=1-5bef4de7-ad49b0e87f6ef6c87fc2e700;Parent=9a9197af755a6419;Sampled=1`.
+ `Lambda-Runtime-Client-Context`: para invocações do AWS Mobile SDK, os dados sobre a aplicação cliente e o dispositivo.
+ `Lambda-Runtime-Cognito-Identity`: para invocações do AWS Mobile SDK, os dados sobre o provedor de identidade do Amazon Cognito.
Não defina um tempo limite na solicitação `GET`, pois a resposta poderá estar atrasada. Entre o momento em que o Lambda inicializa o runtime e o momento em que o runtime tem um evento para retornar, o processo do runtime pode ficar congelado por vários segundos.
O ID da solicitação rastreia a invocação dentro do Lambda. Use-o para especificar a invocação ao enviar a resposta.
O cabeçalho de rastreamento contém o ID de rastreamento, o ID pai e a decisão de amostragem. Se a solicitação for de amostra, a amostra da solicitação foi feita pelo Lambda ou um serviço upstream. O runtime deve definir o `_X_AMZN_TRACE_ID` com o valor do cabeçalho. O X-Ray SDK lê isso para obter os IDs e determinar se deve rastrear a solicitação.
## Resposta de invocação
**Caminho** – `/runtime/invocation/AwsRequestId/response`
**Método** – **POST**
Depois que a função for executada até a conclusão, o runtime envia uma resposta de invocação para o Lambda. Para invocações síncronas, o Lambda envia a resposta de volta para o cliente.
**Example solicitação com êxito**
```
REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "SUCCESS"
```
## Erro de inicialização
Se a função retornar um erro ou o runtime encontrar um erro durante a inicialização, o runtime usará esse método para relatar o erro ao Lambda.
**Caminho** – `/runtime/init/error`
**Método** – **POST**
**Cabeçalhos**
`Lambda-Runtime-Function-Error-Type`: o tipo de erro encontrado pelo tempo de execução. Obrigatório: não
Este cabeçalho consiste em um valor de string. Lambda aceita qualquer string, mas recomendamos o formato . Por exemplo:
+ Runtime.NoSuchHandler
+ Runtime.APIKeyNotFound
+ Runtime.ConfigInvalid
+ Runtime.UnknownReason
**Body parameters (Parâmetros do corpo**
`ErrorRequest`: informações adicionais sobre o erro. Obrigatório: não
Este campo é um objeto JSON com a seguinte estrutura:
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
Observe que o Lambda aceita qualquer valor para `errorType`.
O exemplo a seguir mostra uma mensagem de erro de função do Lambda na qual a função não pôde analisar os dados do evento fornecidos na chamada.
**Example Erro de função**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Parâmetros do corpo da resposta**
+ `StatusResponse` – String. Informações de status, enviadas com 202 códigos de resposta.
+ `ErrorResponse`: informações adicionais de erro, enviadas com os códigos de resposta de erro. O ErrorResponse contém um tipo de erro e uma mensagem de erro.
**Códigos de resposta**
+ 202: aceito
+ 403: proibido
+ 500: erro de contêiner. Estado não recuperável. O tempo de execução deve sair imediatamente.
**Example solicitação com erro de inicialização**
```
ERROR="{\"errorMessage\" : \"Failed to load function.\", \"errorType\" : \"InvalidFunctionException\"}"
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/init/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled"
```
## Erro de invocação
Se a função retornar um erro ou o runtime encontrar um erro, o runtime usará esse método para relatar o erro ao Lambda.
**Caminho** – `/runtime/invocation/AwsRequestId/error`
**Método** – **POST**
**Cabeçalhos**
`Lambda-Runtime-Function-Error-Type`: o tipo de erro encontrado pelo tempo de execução. Obrigatório: não
Este cabeçalho consiste em um valor de string. Lambda aceita qualquer string, mas recomendamos o formato . Por exemplo:
+ Runtime.NoSuchHandler
+ Runtime.APIKeyNotFound
+ Runtime.ConfigInvalid
+ Runtime.UnknownReason
**Body parameters (Parâmetros do corpo**
`ErrorRequest`: informações adicionais sobre o erro. Obrigatório: não
Este campo é um objeto JSON com a seguinte estrutura:
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
Observe que o Lambda aceita qualquer valor para `errorType`.
O exemplo a seguir mostra uma mensagem de erro de função do Lambda na qual a função não pôde analisar os dados do evento fornecidos na chamada.
**Example Erro de função**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Parâmetros do corpo da resposta**
+ `StatusResponse` – String. Informações de status, enviadas com 202 códigos de resposta.
+ `ErrorResponse`: informações adicionais de erro, enviadas com os códigos de resposta de erro. O ErrorResponse contém um tipo de erro e uma mensagem de erro.
**Códigos de resposta**
+ 202: aceito
+ 400: solicitação inválida
+ 403: proibido
+ 500: erro de contêiner. Estado não recuperável. O tempo de execução deve sair imediatamente.
**Example solicitação com erro**
```
REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9
ERROR="{\"errorMessage\" : \"Error parsing event data.\", \"errorType\" : \"InvalidEventDataException\"}"
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled"
```
# Quando usar runtimes somente para sistema operacional do Lambda
O Lambda fornece [runtimes gerenciados](lambda-runtimes.md) para Java, Python, Node.js, .NET e Ruby. Para criar funções do Lambda em uma linguagem de programação que não esteja disponível como um runtime gerenciado, use um runtime somente para sistema operacional (a família de runtime `provided`). Há três casos de uso principais para runtimes somente para sistema operacional:
+ **Compilação nativa antecipada (AOT)**: linguagens, como Go, Rust, Swift e C\$1\$1 compilam nativamente em um binário executável, o que não requer um runtime de linguagem dedicado. Essas linguagens precisam apenas de um ambiente de sistema operacional no qual o binário compilado possa ser executado. Também é possível usar runtimes somente para sistema operacional do Lambda para implantar binários compilados com .NET Native AOT e Java GraalVM Native Image.
Você deve incluir um cliente de interface de runtime no binário. O cliente de interface de runtime chama o [Usar a API de runtime do Lambda para runtimes personalizados](runtimes-api.md) para recuperar as invocações da função e, em seguida, chama o manipulador da função. O Lambda fornece clientes de interface de runtime para [Rust](lambda-rust.md), [Go](golang-package.md#golang-package-mac-linux), [.NET Native AOT](dotnet-native-aot.md), [Swift](https://github.com/awslabs/swift-aws-lambda-runtime) (experimental) e [C\$1\$1](https://github.com/awslabs/aws-lambda-cpp) (experimental).
Você deve compilar o binário para um ambiente Linux e para a mesma arquitetura de conjunto de instruções que planeja usar para a função (x86\$164 ou arm64).
+ **Runtimes de terceiros**: é possível executar funções do Lambda usando runtimes prontos para uso, como o [Bref](https://bref.sh/docs/news/01-bref-1.0.html#amazon-linux-2) para PHP.
+ **Runtimes personalizados**: você pode criar seu próprio runtime para uma linguagem ou versão de linguagem para a qual o Lambda não fornece um runtime gerenciado, como Node.js 19. Para obter mais informações, consulte [Criar um runtime personalizado para AWS Lambda](runtimes-custom.md). Esse é o caso de uso menos comum para runtimes somente para sistema operacional.
O Lambda oferece suporte aos seguintes runtimes somente para sistema operacional:
| Nome | Identificador | Sistema operacional | Data da substituição | Bloquear a criação de funções | Bloquear a atualização de funções |
| --- | --- | --- | --- | --- | --- |
| Runtime somente para sistema operacional | `provided.al2023` | Amazon Linux 2023 | 30 de junho de 2029 | 31 de julho de 2029 | 31 de agosto de 2029 |
| Runtime somente para sistema operacional | `provided.al2` | Amazon Linux 2 | 31 de julho de 2026 | 31 de agosto de 2026 | 30 de setembro de 2026 |
O runtime do Amazon Linux 2023 (`provided.al2023`) oferece várias vantagens em relação ao Amazon Linux 2, incluindo uma área de implantação menor e versões atualizadas de bibliotecas, como `glibc`.
O runtime `provided.al2023` usa `dnf` como gerenciador de pacotes em vez de `yum`, que é o gerenciador de pacotes padrão no Amazon Linux 2. Para obter mais informações sobre as diferenças entre `provided.al2023` e`provided.al2`, consulte [Introducing the Amazon Linux 2023 runtime for AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/) no Blog AWS Compute.
# Criar um runtime personalizado para AWS Lambda
É possível implementar um runtime do AWS Lambda em qualquer linguagem de programação. O runtime é um programa que executa um método de manipulador da função do Lambda quando a função é invocada. É possível incluir o runtime no pacote de implantação da função ou distribuí-lo em uma [camada](chapter-layers.md). Ao criar a função do Lambda, escolha um [runtime somente do sistema operacional](runtimes-provided.md) (a família de runtime `provided`).
**nota**
Criar um runtime personalizado é um caso de uso avançado. Se você estiver procurando informações sobre como compilar em um binário nativo ou usar um runtime pronto para uso de terceiros, consulte [Quando usar runtimes somente para sistema operacional do Lambda](runtimes-provided.md).
Para obter uma explicação passo a passo do processo de implantação de runtime personalizado, consulte [Tutorial: criar um runtime personalizado](runtimes-walkthrough.md).
**Topics**
+ [
## Requisitos
](#runtimes-custom-build)
+ [
## Implementação do streaming de resposta em um runtime personalizado
](#runtimes-custom-response-streaming)
+ [
## Criação de runtimes personalizados para instâncias gerenciadas do Lambda
](#runtimes-custom-managed-instances)
## Requisitos
Os runtimes personalizados devem realizar determinadas tarefas de inicialização e processamento. Um runtime executa o código de configuração da função, lê o nome do manipulador de uma variável de ambiente e lê eventos de invocação da API de runtime do Lambda. O runtime transmite os dados de eventos para o manipulador de funções e publica a resposta do manipulador de volta no Lambda.
### Tarefas de inicialização
As tarefas de inicialização são executadas uma vez [ por instância da função ](lambda-runtime-environment.md) a fim de preparar o ambiente para processar invocações.
+ **Recuperar configurações**: leia variáveis de ambiente para obter detalhes sobre a função e o ambiente.
+ `_HANDLER`: a localização do manipulador, da configuração da função. O formato padrão é `file.method`, em que `file` é o nome do arquivo sem uma extensão, e `method` é o nome de um método ou da função que é definido no arquivo.
+ `LAMBDA_TASK_ROOT`: o diretório que contém o código da função.
+ `AWS_LAMBDA_RUNTIME_API`: o host e a porta da API do runtime.
Para obter uma lista completa das variáveis disponíveis, consulte [Variáveis de ambiente com runtime definido](configuration-envvars.md#configuration-envvars-runtime).
+ **Inicializar a função**: carregar o arquivo do manipulador e executar qualquer código global ou estático que ele contenha. As funções devem criar recursos estáticos como clientes SDK e conexões de banco de dados uma vez e reutilizá-los para várias invocações.
+ **Lidar com erros**: se ocorrer um erro, chame a API [erro de inicialização](runtimes-api.md#runtimes-api-initerror) e saia imediatamente.
A inicialização é considerada no runtime e tempo limite cobrados. Quando uma execução aciona a inicialização de uma nova instância da função, é possível ver o tempo de inicialização nos logs e no [rastreamento do AWS X-Ray](services-xray.md).
**Example log**
```
REPORT RequestId: f8ac1208... Init Duration: 48.26 ms Duration: 237.17 ms Billed Duration: 300 ms Memory Size: 128 MB Max Memory Used: 26 MB
```
### Tarefas de processamento
Enquanto ela é executada, um [ usa a interface de runtime do ](runtimes-api.md) Lambda para gerenciar eventos de entrada e relatar erros. Depois de executar as tarefas de inicialização, o runtime processa eventos de entrada em um loop. No código do seu runtime, execute as seguintes etapas em ordem.
+ **Obter um evento**: chame a API [próxima invocação](runtimes-api.md#runtimes-api-next) para obter o próximo evento. O corpo da resposta contém os dados do evento. Os cabeçalhos da resposta contêm o ID da solicitação e outras informações.
+ **Propagar o cabeçalho de rastreamento**: obtenha o cabeçalho de rastreamento do X-Ray do cabeçalho `Lambda-Runtime-Trace-Id` na resposta da API. Defina a variável de ambiente `_X_AMZN_TRACE_ID` localmente com o mesmo valor. O X-Ray SDK usa esse valor para conectar dados de rastreamento entre serviços.
+ **Criar um contexto de objeto**: crie um objeto com informações de contexto de variáveis do ambiente e cabeçalhos na resposta da API.
+ **Invocar o manipulador de funções**: transmita o evento e o objeto de contexto para o manipulador.
+ **Processar a resposta**: chame a API de [resposta de invocação](runtimes-api.md#runtimes-api-response) para publicar a resposta do manipulador.
+ **Processar erros**: se ocorrer um erro, chame a API [erro de invocação](runtimes-api.md#runtimes-api-invokeerror).
+ **Limpeza**: libere recursos não utilizados, envie dados para outros serviços ou execute tarefas adicionais antes de receber o próximo evento.
### Entrypoint
O ponto de entrada de um runtime personalizado é um arquivo executável denominado `bootstrap`. O arquivo de bootstrap pode ser o runtime ou ele pode invocar outro arquivo que criará o runtime. Se a raiz do pacote de implantação não contiver um arquivo denominado `bootstrap`, o Lambda procurará o arquivo nas camadas da função. Se o arquivo `bootstrap` não existir ou não for executável, a função retornará um erro de `Runtime.InvalidEntrypoint` na invocação.
Veja um exemplo em que o arquivo `bootstrap` usa um pacote de versão do Node.js para executar um runtime do JavaScript em um arquivo separado denominado `runtime.js`.
**Example bootstrap**
```
#!/bin/sh
cd $LAMBDA_TASK_ROOT
./node-v11.1.0-linux-x64/bin/node runtime.js
```
## Implementação do streaming de resposta em um runtime personalizado
Para [funções de streaming de resposta](configuration-response-streaming.md), os endpoints `response` e `error` têm um comportamento ligeiramente modificado que possibilita que o runtime faça o streaming de respostas parciais para o cliente e retorne cargas úteis em blocos. Para obter mais informações sobre o comportamento específico, consulte o seguinte:
+ `/runtime/invocation/AwsRequestId/response`: propaga o cabeçalho `Content-Type` do runtime para enviar ao cliente. O Lambda retorna a carga de resposta em blocos por meio de codificação de transferência em blocos do HTTP/1.1. Para fazer o streaming da resposta para o Lambda, o runtime deve:
+ Definir o cabeçalho HTTP `Lambda-Runtime-Function-Response-Mode` como `streaming`.
+ Defina o cabeçalho `Transfer-Encoding` como `chunked`.
+ Gravar a resposta em conformidade com a especificação de codificação de transferência em blocos HTTP/1.1.
+ Encerrar a conexão subjacente após escrever a resposta com êxito.
+ `/runtime/invocation/AwsRequestId/error`: o runtime pode usar esse endpoint para relatar erros de função ou de runtime ao Lambda, que também aceita o cabeçalho `Transfer-Encoding`. Esse endpoint pode ser chamado somente antes que o runtime comece a enviar uma resposta de invocação.
+ Relatar erros intermediários usando trailers de erro em `/runtime/invocation/AwsRequestId/response`: para relatar erros ocorridos após o runtime começar a gravar a resposta da invocação, o runtime pode, opcionalmente, anexar cabeçalhos HTTP no final, chamados de `Lambda-Runtime-Function-Error-Type` e `Lambda-Runtime-Function-Error-Body`. O Lambda trata isso como uma resposta com êxito e encaminha os metadados de erro fornecidos pelo runtime ao cliente.
**nota**
Para vincular cabeçalhos à direita, o runtime deve definir o valor do cabeçalho `Trailer` no início da solicitação HTTP. Isso é um requisito da especificação de codificação de transferência em blocos do HTTP/1.1.
+ `Lambda-Runtime-Function-Error-Type`: o tipo de erro encontrado pelo runtime. Este cabeçalho consiste em um valor de string. O Lambda aceita qualquer string, mas recomendamos um formato **. Por exemplo, `Runtime.APIKeyNotFound`.
+ `Lambda-Runtime-Function-Error-Body`: informações sobre o erro codificadas em Base64.
## Criação de runtimes personalizados para instâncias gerenciadas do Lambda
As instâncias gerenciadas do Lambda usam a mesma API de runtime das funções do Lambda (padrão). No entanto, existem diferenças importantes na forma como os runtimes personalizados devem ser implementados para oferecer suporte ao modelo de execução simultânea das instâncias gerenciadas.
### Tratamento simultâneo de solicitações
A principal diferença ao criar runtimes personalizados para instâncias gerenciadas é o suporte a invocações simultâneas. Ao contrário das funções do Lambda (padrão), nas quais o runtime processa uma invocação por vez, as instâncias gerenciadas podem processar várias invocações simultaneamente em um único ambiente de execução.
Seu runtime personalizado deve:
+ **Oferecer suporte a solicitações simultâneas `/next`**: o runtime pode fazer várias chamadas simultâneas para a API de [próxima invocação](runtimes-api.md#runtimes-api-next), até o limite especificado pela variável de ambiente `AWS_LAMBDA_MAX_CONCURRENCY`.
+ **Tratar solicitações simultâneas `/response`**: várias invocações podem chamar a API de [resposta de invocação](runtimes-api.md#runtimes-api-response) simultaneamente.
+ **Implementar o tratamento de solicitações com segurança de thread**: garanta que as invocações simultâneas não interfiram umas nas outras gerenciando adequadamente os recursos e o estado compartilhados.
+ **Usar IDs de solicitação exclusivos**: acompanhe cada invocação separadamente usando o cabeçalho `Lambda-Runtime-Aws-Request-Id` para combinar as respostas com as solicitações correspondentes.
### Padrão de implementação
Um padrão de implementação típico para runtimes de instâncias gerenciadas envolve a criação de processos ou threads de operadores para tratar invocações simultâneas:
1. **Ler o limite de simultaneidade**: na inicialização, leia a variável de ambiente `AWS_LAMBDA_MAX_CONCURRENCY` para determinar para quantas invocações simultâneas deve haver suporte.
1. **Criar um grupo de operadores**: inicialize um grupo de operadores (threads, processos ou tarefas assíncronas) igual ao limite de simultaneidade.
1. **Ciclo de processamento do operador**: cada operador, de forma independente:
+ Chama `/runtime/invocation/next` para obter um evento de invocação
+ Invoca o manipulador da função com os dados do evento
+ Publica a resposta em `/runtime/invocation/AwsRequestId/response`
+ Repete o loop
### Considerações adicionais
+ **Formato de registro em log**: as instâncias gerenciadas só oferecem suporte ao formato de log JSON. Certifique-se de que seu runtime respeite a variável de ambiente `AWS_LAMBDA_LOG_FORMAT` e use somente o formato JSON. Para obter mais informações, consulte [Configurar logs em formato de texto simples e JSON](monitoring-cloudwatchlogs-logformat.md).
+ **Recursos compartilhados**: tenha cuidado ao usar recursos compartilhados, como o diretório `/tmp` com invocações simultâneas. Implemente mecanismos de travamento adequados para evitar condições de corrida.
Para obter mais informações sobre os ambientes de execução das instâncias gerenciadas do Lambda, consulte [Noções básicas sobre o ambiente de execução das instâncias gerenciadas do Lambda](lambda-managed-instances-execution-environment.md).
# Tutorial: criar um runtime personalizado
Neste tutorial, você criará uma função do Lambda com um runtime personalizado. Você começa incluindo o runtime no pacote de implantação da função. Em seguida, você o migra para uma camada gerenciada de forma independente da função. Por fim, você compartilha a camada de runtime com o mundo atualizando sua política de permissões com base em recursos.
## Pré-requisitos
Este tutorial presume que você tenha algum conhecimento de operações básicas do Lambda e do console do Lambda. Caso ainda não tenha feito isso, siga as instruções em [Criar uma função do Lambda com o console](getting-started.md#getting-started-create-function) para criar sua primeira função do Lambda.
Para concluir as etapas apresentadas a seguir, é necessário ter a [versão 2 da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). Os comandos e a saída esperada são mostrados em blocos separados:
```
aws --version
```
A seguinte saída deverá ser mostrada:
```
aws-cli/2.13.27 Python/3.11.6 Linux/4.14.328-248.540.amzn2.x86_64 exe/x86_64.amzn.2
```
Para comandos longos, um caractere de escape (`\`) é usado para dividir um comando em várias linhas.
No Linux e no macOS, use seu gerenciador preferido de pacotes e de shell.
**nota**
No Windows, alguns comandos da CLI do Bash que você costuma usar com o Lambda (como `zip`) não são compatíveis com os terminais integrados do sistema operacional. Para obter uma versão do Ubuntu com o Bash integrada no Windows, [instale o Subsistema do Windows para Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10). Os exemplos de comandos da CLI neste guia usam a formatação Linux. Os comandos que incluem documentos JSON em linha deverão ser reformatados se você estiver usando a CLI do Windows.
Você precisa de uma função do IAM para criar uma função do Lambda. O perfil precisa de permissão para enviar logs ao CloudWatch Logs e acessar os Serviços da AWS que a função usa. Se você ainda não tiver uma função para o desenvolvimento de funções, crie uma agora.
**Para criar uma função de execução**
1. Abra a [página Roles](https://console.aws.amazon.com/iam/home#/roles) (Funções) no console do IAM.
1. Selecione **Criar perfil**.
1. Crie uma função com as propriedades a seguir.
+ **Entidade confiável**–**Lambda**.
+ **Permissions** (Permissões): **AWSLambdaBasicExecutionRole**.
+ **Role name** (Nome da função): **lambda-role**.
A política **AWSLambdaBasicExecutionRole** tem as permissões necessárias para a função gravar logs no CloudWatch Logs.
## Criar uma função
Criar uma função do Lambda com um runtime personalizado. Este exemplo inclui dois arquivos: um arquivo `bootstrap` de runtime e um manipulador de funções. Ambos são implementados em Bash.
1. Crie um diretório para o projeto e depois mude para esse diretório.
```
mkdir runtime-tutorial
cd runtime-tutorial
```
1. Crie um novo arquivo chamado `bootstrap`. Esse é o runtime personalizado.
**Example bootstrap**
```
#!/bin/sh
set -euo pipefail
# Initialization - load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
O runtime carrega um script de função do pacote de implantação. Ele usa duas variáveis para localizar o script. `LAMBDA_TASK_ROOT` informa onde o pacote foi extraído e `_HANDLER` inclui o nome do script.
Depois que o runtime carrega o script da função, ele usa a API de runtime para recuperar um evento de invocação do Lambda, transmite o evento para o manipulador e publica a resposta de volta no Lambda. Para obter o ID de solicitação, o runtime salva os cabeçalhos na resposta da API em um arquivo temporário e lê o cabeçalho `Lambda-Runtime-Aws-Request-Id` do arquivo.
**nota**
Os runtimes têm responsabilidades adicionais, incluindo o processamento de erros e o fornecimento de informações de contexto para o manipulador. Para obter detalhes, consulte [Requisitos](runtimes-custom.md#runtimes-custom-build).
1. Crie um script para a função. O exemplo de script a seguir define uma função do manipulador que usa dados de eventos, os registra no log `stderr` e os retorna.
**Example function.sh**
```
function handler () {
EVENT_DATA=$1
echo "$EVENT_DATA" 1>&2;
RESPONSE="Echoing request: '$EVENT_DATA'"
echo $RESPONSE
}
```
Agora, diretório `runtime-tutorial` será desta forma:
```
runtime-tutorial
├ bootstrap
└ function.sh
```
1. Torne os arquivos executáveis e os adicione a um arquivo .zip. Esse é o pacote de implantação.
```
chmod 755 function.sh bootstrap
zip function.zip function.sh bootstrap
```
1. Crie uma função chamada `bash-runtime`. Para `--role`, insira o ARN do seu [perfil de execução](lambda-intro-execution-role.md) do Lambda.
```
aws lambda create-function --function-name bash-runtime \
--zip-file fileb://function.zip --handler function.handler --runtime provided.al2023 \
--role arn:aws:iam::123456789012:role/lambda-role
```
1. Invoque a função.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
A opção **cli-binary-format** será necessária se você estiver usando a AWS CLI versão 2. Para que essa seja a configuração padrão, execute `aws configure set cli-binary-format raw-in-base64-out`. Para obter mais informações, consulte [A AWS CLI comporta opções de linha de comando globais](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) no *Guia do usuário da AWS Command Line Interface versão 2*.
Você obterá uma resposta parecida com esta:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Verifique a resposta.
```
cat response.txt
```
Você obterá uma resposta parecida com esta:
```
Echoing request: '{"text":"Hello"}'
```
## Criar uma camada
Para separar o código do runtime do código da função, crie uma camada que contenha apenas o runtime. As camadas permitem que você desenvolva dependências da sua função de forma independente e podem reduzir o uso de armazenamento quando você usa a mesma camada com várias funções. Para ter mais informações, consulte [Gerenciar dependências do Lambda com camadas](chapter-layers.md).
1. Crie um arquivo .zip que contenha o arquivo `bootstrap`.
```
zip runtime.zip bootstrap
```
1. Crie uma camada com o comando [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html?highlight=nodejs16%20x).
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
Isso cria a primeira versão da camada.
## Atualizar a função
Para usar a camada de runtime com a função, configure a função para usar a camada e remova o código de runtime da função.
1. Atualize a configuração de função para extrair na camada.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:1
```
Isso adiciona o runtime à função no diretório `/opt`. Para garantir que o Lambda use o runtime na camada, você precisa remover o `boostrap` do pacote de implantação da função, conforme mostrado nas próximas duas etapas.
1. Crie um arquivo .zip que contenha o código da função.
```
zip function-only.zip function.sh
```
1. Atualize o código da função para incluir apenas o script do manipulador.
```
aws lambda update-function-code --function-name bash-runtime --zip-file fileb://function-only.zip
```
1. Invoque a função para confirmar se ela funciona com a camada de runtime.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
A opção **cli-binary-format** será necessária se você estiver usando a AWS CLI versão 2. Para que essa seja a configuração padrão, execute `aws configure set cli-binary-format raw-in-base64-out`. Para obter mais informações, consulte [A AWS CLI comporta opções de linha de comando globais](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) no *Guia do usuário da AWS Command Line Interface versão 2*.
Você obterá uma resposta parecida com esta:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Verifique a resposta.
```
cat response.txt
```
Você obterá uma resposta parecida com esta:
```
Echoing request: '{"text":"Hello"}'
```
## Atualizar o runtime
1. Para registrar informações sobre o ambiente de execução, atualize o script de runtime para gerar variáveis de ambiente.
**Example bootstrap**
```
#!/bin/sh
set -euo pipefail
# Configure runtime to output environment variables
echo "## Environment variables:"
env
# Load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
1. Crie um arquivo .zip que contenha a nova versão do arquivo `bootstrap`.
```
zip runtime.zip bootstrap
```
1. Crie uma nova versão da camada `bash-runtime`.
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
1. Configure a função para usar a nova versão da camada.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2
```
## Compartilhar a camada
Para compartilhar uma camada com outra Conta da AWS, adicione uma instrução de permissões entre contas à [política baseada no recurso](access-control-resource-based.md) da camada. Execute o comando [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) e especifique o ID da conta como a `principal`. Em cada instrução, você pode conceder permissão apenas a uma conta, a todas as contas ou a uma organização do [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html).
O exemplo a seguir concede à conta 111122223333 acesso à versão 2 da camada `bash-runtime`.
```
aws lambda add-layer-version-permission \
--layer-name bash-runtime \
--version-number 2 \
--statement-id xaccount \
--action lambda:GetLayerVersion \
--principal 111122223333 \
--output text
```
A saída deve ser semelhante a:
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
```
As permissões se aplicam apenas a uma única versão de camada. Repita o processo sempre que criar uma nova versão da camada.
## Limpeza
Exclua cada versão da camada.
```
aws lambda delete-layer-version --layer-name bash-runtime --version-number 1
aws lambda delete-layer-version --layer-name bash-runtime --version-number 2
```
Como a função contém uma referência à versão 2 da camada, ela ainda existe no Lambda. A função continua a funcionar, mas as funções não podem mais ser configuradas para usar a versão excluída. Se você modificar a lista de camadas na função, precisará especificar uma nova versão ou omitir a camada excluída.
Exclua a função com o comando [delete-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-function.html).
```
aws lambda delete-function --function-name bash-runtime
```
# Repositórios de código aberto
O AWS Lambda fornece uma variedade de ferramentas, bibliotecas e componentes de código aberto para ajudar você a criar, personalizar e otimizar suas aplicações com tecnologia sem servidor. Esses recursos incluem clientes de interface de runtime, bibliotecas de eventos, imagens de base de contêineres, ferramentas de desenvolvimento e projetos de amostra que são mantidos pela AWS e estão disponíveis no GitHub. Ao aproveitar esses repositórios de código aberto, você pode ampliar os recursos do Lambda, criar runtimes personalizados, processar eventos de vários serviços da AWS e obter insights mais profundos sobre a performance da sua função. Esta página fornece uma visão geral dos principais projetos de código aberto que viabilizam o desenvolvimento com Lambda.
## Clientes de interface de runtime
Os RICs (Lambda Runtime Interface Clients, ou clientes de interface de runtime do Lambda) são bibliotecas de código aberto que implementam a [API Runtime](runtimes-api.md) e gerenciam a interação entre seu código de função e o serviço Lambda. Esses clientes lidam com o recebimento de eventos de invocação, a transmissão de informações de contexto e a emissão de relatórios de erros.
Os clientes de interface de runtime usados pelos runtimes gerenciados e pelas imagens de base de contêineres do Lambda são publicados como código aberto. Ao criar runtimes personalizados ou estender os existentes, você pode usar essas bibliotecas de código aberto para simplificar sua implementação. Os seguintes repositórios de código aberto do GitHub contêm o código-fonte dos RICs do Lambda:
+ [Clientes de interface de runtime do Node.js](https://github.com/aws/aws-lambda-nodejs-runtime-interface-client)
+ [Clientes de interface de runtime do Python](https://github.com/aws/aws-lambda-python-runtime-interface-client)
+ [Clientes de interface de runtime de Java](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-runtime-interface-client)
+ [Clientes de interface de runtime do Ruby](https://github.com/aws/aws-lambda-ruby-runtime-interface-client)
+ [Clientes de interface de runtime de .NET](https://github.com/aws/aws-lambda-dotnet)
+ [Clientes de interface de runtime de Rust](https://github.com/aws/aws-lambda-rust-runtime)
+ [Clientes de interface de runtime do Go](https://github.com/aws/aws-lambda-go)
+ [Cliente de interface de runtime de Swift](https://github.com/awslabs/swift-aws-lambda-runtime) (experimental)
+ [Cliente de interface de runtime de C\$1\$1](https://github.com/awslabs/aws-lambda-cpp) (experimental)
+ [Imagens base do Lambda](https://github.com/aws/aws-lambda-base-images)
Para obter mais informações sobre como usar esses clientes para criar runtimes personalizados, consulte [Criar um runtime personalizado para AWS Lambda](runtimes-custom.md).
## Bibliotecas de eventos
As bibliotecas de eventos do Lambda fornecem definições de tipo e utilitários auxiliares para processar eventos de vários serviços da AWS. Essas bibliotecas ajudam você a analisar e lidar com dados de eventos de maneira segura, facilitando o trabalho com eventos de serviços como Amazon S3, Amazon DynamoDB e Amazon API Gateway.
Para linguagens compiladas, a AWS fornece as seguintes bibliotecas de eventos:
+ [Biblioteca de eventos de Java](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-events)
+ [.Biblioteca de eventos de .NET](https://github.com/aws/aws-lambda-dotnet/tree/master/Libraries/src)
+ [Biblioteca de eventos de Go](https://github.com/aws/aws-lambda-go/tree/main/events)
+ [Biblioteca de eventos de Rust](https://github.com/awslabs/aws-lambda-rust-runtime)
Para linguagens interpretadas como Node.js, Python e Ruby, os eventos podem ser analisados diretamente como objetos JSON sem a necessidade de usar outra biblioteca. No entanto, os desenvolvedores que usam o Node.js e o Python podem aproveitar as Powertools para AWS Lambda, que fornecem esquemas integrados para eventos da AWS que oferecem dicas de tipo, validação de dados e funcionalidades semelhantes às fornecidas pelas bibliotecas de linguagens compiladas.
+ [Powertools para TypeScript](https://docs.powertools.aws.dev/lambda/typescript/latest/features/parser/#built-in-schemas)
+ [Powertools para Python](https://docs.powertools.aws.dev/lambda/python/latest/utilities/parser/#built-in-models)
## Imagens de base de contêiner
A AWS fornece imagens de base de contêiner de código aberto que você pode usar como ponto de partida para criar imagens de contêiner para suas funções do Lambda. Essas imagens de base incluem o cliente de interface de runtime e outros componentes necessários para executar suas funções no ambiente de execução do Lambda.
Para obter mais informações sobre as imagens base disponíveis e como usá-las, consulte o repositório de [AWS Lambda Base Images](https://github.com/aws/aws-lambda-base-images) e [Criar uma função do Lambda usando uma imagem de contêiner](images-create.md).
## Ferramentas de desenvolvimento
A AWS fornece ferramentas adicionais de desenvolvimento de código aberto para ajudar você a criar e otimizar suas funções do Lambda:
### Powertools para AWS Lambda
As Powertools para AWS Lambda simplificam o desenvolvimento de tecnologia sem servidor com utilitários essenciais para evitar processamento duplicado e processamento em lote para tratamento de vários registros e biblioteca de consumidores Kafka. Esses recursos ajudam a minimizar a complexidade do código e a sobrecarga operacional.
Também é possível aproveitar a validação integrada de esquema de eventos, o registro de log e o rastreamento estruturados e a integração do armazenamento de parâmetros, projetados para acelerar a criação de funções do Lambda prontas para produção e, ao mesmo tempo, seguir as práticas recomendadas de AWS Well-Architected.
Repositórios do GitHub:
+ [Python](https://github.com/aws-powertools/powertools-lambda-python)
+ [TypeScript](https://github.com/aws-powertools/powertools-lambda-typescript)
+ [Java](https://github.com/aws-powertools/powertools-lambda-java)
+ [.NET](https://github.com/aws-powertools/powertools-lambda-dotnet)
### Ferramentas de desenvolvimento de Java
+ [Java Profiler (experimental)](https://github.com/aws/aws-lambda-java-libs/tree/main/experimental/aws-lambda-java-profiler): uma ferramenta para criar perfis de funções do Java Lambda.
+ [Bibliotecas Java](https://github.com/aws/aws-lambda-java-libs): um repositório que contém uma coleção abrangente de bibliotecas e ferramentas Java para desenvolvimento em Lambda, incluindo projetos importantes, como utilitários de teste JUnit e ferramentas de criação de perfil.
+ [Contêiner Java de tecnologia sem servidor](https://github.com/aws/serverless-java-container): uma biblioteca que permite que você execute aplicações Java existentes no Lambda com o mínimo de alterações.
### Ferramentas de desenvolvimento .NET
O repositório de [AWS Lambda .NET](https://github.com/aws/aws-lambda-dotnet) fornece bibliotecas e ferramentas do .NET para o desenvolvimento do Lambda, incluindo projetos importantes, como ferramentas de AWS Lambda para a CLI do .NET e o servidor .NET Core para hospedar aplicações .NET Core.
## Projetos de amostra
Veja uma coleção abrangente de exemplos de projetos e aplicações de Lambda em [repositórios de Serverless Land](https://serverlessland.com/repos). Esses exemplos demonstram vários casos de uso, padrões de integração e melhores práticas do Lambda para ajudar você a começar a usar suas aplicações com tecnologia sem servidor.