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á.
Usar funções do Lambda como destino de um Application Load Balancer
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.
O balanceador de carga invoca a função Lambda diretamente em vez de usar uma conexão de rede. Portanto, não há requisitos para as regras de saída dos grupos de segurança do Network Load Balancer.
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 ponderações de destinos 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-alvo e registrar a função usando o AWS CLI, você deverá usar o comando add-permission para conceder permissão ao Elastic Load Balancing para invocar sua função 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 aliases de AWS Lambda funções no Guia do AWS Lambda desenvolvedor.
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 Configurar o tempo limite da função Lambda. Para obter informações sobre o valor máximo de tempo limite que você pode configurar, consulte AWS Lambda cotas.
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.
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 seguintes tipos, o balanceador de carga envia o corpo como está e define isBase64Encoded comofalse: text/*,. application/json, application/javascript, and 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.
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
}Registre a função Lambda
Você só pode registrar uma função do Lambda com cada grupo de destino. Para substituir uma função Lambda, recomendamos que você crie um novo grupo-alvo, registre a nova função com o novo grupo-alvo e atualize as regras do ouvinte para usar o novo grupo-alvo.
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 que você crie um novo grupo-alvo, registre a nova função com o novo grupo-alvo e atualize as regras do ouvinte para usar o novo grupo-alvo.
