# 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
```