As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Funções do Lambda como destino
Você pode registrar suas funções Lambda como destinos e configurar uma regra de listener para encaminhar solicitações ao grupo de destino para sua função Lambda. Quando o load balancer encaminha a solicitação para um grupo de destino com uma função Lambda como um destino, ele invoca sua função Lambda e transmite o conteúdo da solicitação para a função Lambda, no formato JSON.
Limites
-
A função do Lambda e o grupo de destino devem estar na mesma conta e na mesma região.
-
O tamanho máximo do corpo da solicitação que você pode enviar para uma função Lambda é de 1 MB. Para limites de tamanho relacionados, consulte Limites de cabeçalho HTTP.
-
O tamanho máximo da resposta JSON que a função Lambda pode enviar é de 1 MB.
-
WebSockets não são suportados. Solicitações de atualização são rejeitadas com um código HTTP 400.
-
Não há compatibilidade com zonas locais.
-
Não há suporte para pesos alvo automáticos (ATW).
Conteúdo
Para uma demonstração, consulte Destino do Lambda no Application Load Balancer
Preparar a função do Lambda
As recomendações a seguir se aplicam se você estiver usando sua função do Lambda com um Application Load Balancer.
Permissões para invocar a função do Lambda
Se criar o grupo de destino e registrar a função Lambda usando o AWS Management Console, o console adicionará as permissões necessárias à sua política de função Lambda em seu nome. Caso contrário, depois de criar o grupo de destino e registrar a função usando a AWS CLI, você deverá usar o comando add-permission para permitir que o Elastic Load Balancing invoque sua função do Lambda. Recomendamos que você use as chaves de condição aws:SourceAccount e aws:SourceArn para restringir a invocação da função ao grupo de destino especificado. Para obter mais informações, consulte O problema de “confused deputy” no Guia do usuário do IAM.
aws lambda add-permission \ --function-namelambda-function-arn-with-alias-name\ --statement-idelb1\ --principal elasticloadbalancing.amazonaws.com \ --action lambda:InvokeFunction \ --source-arntarget-group-arn\ --source-accounttarget-group-account-id
Versionamento da função do Lambda
É possível registrar uma função Lambda por grupo de destino. Para garantir que você possa alterar sua função Lambda e que o load balancer sempre invoque a versão atual da função Lambda, crie um alias de função e inclua o alias no ARN da função ao registrar a função Lambda com o load balancer. Para obter mais informações, consulte Versionamento e aliases de função do AWS Lambda e Mudança de tráfego usando aliases no Guia do desenvolvedor do AWS Lambda.
Tempo-limite da função
O load balancer aguarda até que sua função Lambda responda ou expire. Recomendamos que você configure o tempo-limite da função Lambda com base no tempo de execução esperado. Para obter informações sobre o valor de tempo limite padrão e como alterá-lo, consulte Configuração básica de função do AWS Lambda. Para obter informações sobre o valor do tempo limite máximo que você pode configurar, consulte Limites do AWS Lambda.
Criar um grupo de destino para a função do Lambda
Crie um grupo de destino, que é usado no roteamento da solicitação. Se o conteúdo da solicitação corresponder a uma regra de listener com uma ação para encaminhá-la para esse grupo de destino, o load balancer invocará a função Lambda registrada.
Para criar um grupo de destino e registrar a função do Lambda usando a AWS CLI
Use os comandos create-target-groupe register-targets.
Receber eventos do balanceador de carga
O load balancer oferece suporte a invocações do Lambda para solicitações por protocolos HTTP e HTTPS. O load balancer envia um evento no formato JSON. O load balancer adiciona os seguintes cabeçalhos a todas as solicitações: X-Amzn-Trace-Id, X-Forwarded-For, X-Forwarded-Port e X-Forwarded-Proto.
Se o cabeçalho content-encoding estiver presente, o balanceador de carga Base64 codifica o corpo e define isBase64Encoded como true.
Se o cabeçalho content-encoding não estiver presente, a codificação Base64 dependerá do tipo de conteúdo. Para os tipos a seguir, o balanceador de carga envia o corpo como está e define isBase64Encoded como false: text/*, application/json, application/javascript e application/xml. Caso contrário, o balanceador de carga Base64 codificará o corpo e definirá isBase64Encoded como true.
O comando a seguir é um exemplo de evento.
{
"requestContext": {
"elb": {
"targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/my-target-group/6d0ecf831eec9f09"
}
},
"httpMethod": "GET",
"path": "/",
"queryStringParameters": {parameters},
"headers": {
"accept": "text/html,application/xhtml+xml",
"accept-language": "en-US,en;q=0.8",
"content-type": "text/plain",
"cookie": "cookies",
"host": "lambda-846800462-us-east-2.elb.amazonaws.com",
"user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6)",
"x-amzn-trace-id": "Root=1-5bdb40ca-556d8b0c50dc66f0511bf520",
"x-forwarded-for": "72.21.198.66",
"x-forwarded-port": "443",
"x-forwarded-proto": "https"
},
"isBase64Encoded": false,
"body": "request_body"
}
Responder ao balanceador de carga
A resposta da função do Lambda deve incluir o status de codificação Base64, o código do status e os cabeçalhos. É possível omitir o corpo.
Para incluir um conteúdo binário no corpo da resposta, você deve codificar o conteúdo em Base64 e definir isBase64Encoded como true. O load balancer decodifica o conteúdo para recuperar o conteúdo binário e o envia ao cliente no corpo da resposta HTTP.
O balanceador de carga não respeita hop-by-hop cabeçalhos, como Connection ou. Transfer-Encoding É possível omitir o cabeçalho Content-Length porque o load balancer o calcula antes de enviar respostas aos clientes.
Veja a seguir um exemplo de resposta de uma função do Lambda com base em nodejs.
{ "isBase64Encoded":false, "statusCode":200, "statusDescription": "200 OK", "headers": { "Set-cookie": "cookies", "Content-Type": "application/json" }, "body": "Hello from Lambda (optional)" }
Para modelos de função Lambda que funcionam com Application Load Balancers, consulte application-load-balancer-serverless-app
-
Alb-lambda-Target - S3 UploadFileto
-
Alb-lambda-Target- BinaryResponse
-
ALB-Lambda-Target - IP WhatisMy
Cabeçalhos de vários valores
Se as solicitações de um cliente ou respostas de uma função do Lambda contiverem cabeçalhos de vários valores ou contiverem o mesmo cabeçalho várias vezes, ou parâmetros de consulta com vários valores para a mesma chave, você poderá habilitar o suporte para a sintaxe de cabeçalho de vários valores. Após habilitar cabeçalhos de vários valores, os cabeçalhos e os parâmetros de consulta trocados entre o load balancer e a função do Lambda usam matrizes em vez de strings. Se você não habilitar a sintaxe de cabeçalho de vários valores e um cabeçalho ou um parâmetro de consulta tiver vários valores, o load balancer usará o último valor recebido.
Conteúdo
Solicitações com cabeçalhos de vários valores
Os nomes dos campos usados para cabeçalhos e parâmetros de string de consulta diferem dependendo da ativação de cabeçalhos de vários valores para o grupo de destino.
A solicitação de exemplo a seguir tem dois parâmetros de consulta com a mesma chave:
http://www.example.com?&myKey=val1&myKey=val2Com o formato padrão, o load balancer usa o último valor enviado pelo cliente e envia um evento que inclui parâmetros de string de consulta que usam queryStringParameters. Por exemplo: .
"queryStringParameters": { "myKey": "val2"},Se você ativar cabeçalhos de vários valores, o load balancer usará os dois valores de chave enviados pelo cliente e enviará um evento que inclui parâmetros de string de consulta usando multiValueQueryStringParameters. Por exemplo: .
"multiValueQueryStringParameters": { "myKey": ["val1", "val2"] },Da mesma forma, suponha que o cliente envie uma solicitação com dois cookies no cabeçalho:
"cookie": "name1=value1",
"cookie": "name2=value2",Com o formato padrão, o load balancer usa o último cookie enviado pelo cliente e envia um evento que inclui cabeçalhos que usam headers. Por exemplo: .
"headers": {
"cookie": "name2=value2",
...
},Se você ativar cabeçalhos de vários valores, o load balancer usará os dois cookies enviados pelo cliente e enviará um evento que inclui cabeçalhos que usam multiValueHeaders. Por exemplo: .
"multiValueHeaders": {
"cookie": ["name1=value1", "name2=value2"],
...
},Se os parâmetros de consulta forem codificados em URL, o load balancer não os decodificará. Decodifique-os na função do Lambda.
Respostas com cabeçalhos de vários valores
Os nomes dos campos usados para cabeçalhos diferem dependendo da ativação de cabeçalhos de vários valores para o grupo de destino. Você deve usar multiValueHeaders, se tiver ativado cabeçalhos de vários valores e headers de outra forma.
Com o formato padrão, é possível especificar um único cookie:
{
"headers": {
"Set-cookie": "cookie-name=cookie-value;Domain=myweb.com;Secure;HttpOnly",
"Content-Type": "application/json"
},
}Se você habilitar os cabeçalhos de vários valores, será necessário especificar vários cookies da seguinte maneira:
{
"multiValueHeaders": {
"Set-cookie": ["cookie-name=cookie-value;Domain=myweb.com;Secure;HttpOnly","cookie-name=cookie-value;Expires=May 8, 2019"],
"Content-Type": ["application/json"]
},
}O balanceador de carga pode enviar os cabeçalhos para o cliente em uma ordem diferente da ordem especificada na carga de resposta do Lambda. Portanto, não conte com o retorno dos cabeçalhos em uma ordem específica.
Habilitar cabeçalhos de vários valores
Você pode habilitar ou desabilitar cabeçalhos de vários valores para um grupo de destino com o tipo de destino lambda.
Para habilitar cabeçalhos de vários valores usando a AWS CLI
Use o modify-target-group-attributescomando com o lambda.multi_value_headers.enabled atributo.
Habilitar verificações de integridade
Por padrão, as verificações de integridade estão desabilitadas para grupos de destino do tipo lambda. Você pode habilitar as verificações de integridade para implementar o failover de DNS com o Amazon Route 53. A função Lambda pode verificar a integridade de um serviço de downstream antes de responder à solicitação de verificação de integridade. Se a resposta da função do Lambda indicar uma falha na verificação de integridade, essa falha será transmitida para o Route 53. É possível configurar o Route 53 para executar o failover para uma pilha de backup da aplicação.
Você será cobrado por verificações de integridade como por qualquer invocação da função Lambda.
A seguir, o formato do evento de verificação de integridade enviado à sua função Lambda. Para verificar se um evento é um evento de verificação de integridade, verifique o valor do campo do agente de usuário. O agente de usuário para verificações de integridade é ELB-HealthChecker/2.0.
{
"requestContext": {
"elb": {
"targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/my-target-group/6d0ecf831eec9f09"
}
},
"httpMethod": "GET",
"path": "/",
"queryStringParameters": {},
"headers": {
"user-agent": "ELB-HealthChecker/2.0"
},
"body": "",
"isBase64Encoded": false
}Para habilitar verificações de integridade para um grupo de destino usando a AWS CLI
Use o comando modify-target-group com a opção --health-check-enabled.
Cancelar o registro da função do Lambda
Se não precisar mais enviar tráfego para sua função Lambda, você poderá cancelar o registro. Depois de cancelar o registro de uma função Lambda, as solicitações em andamento falham com erros HTTP 5XX.
Para substituir uma função Lambda, recomendamos criar um grupo de destino, registrar a nova função com o novo grupo de destino e atualizar as regras do listener para usar o novo grupo de destino em vez do existente.
Para cancelar o registro da função Lambda usando a AWS CLI
Use o comando deregister-targets.
