Exponha uma Função Lambda com uma HTTP API

Introdução

Uma página de status precisa de um endpoint HTTP que informe se uma aplicação está saudável. Você conectará um manipulador Lambda fornecido a uma HTTP API, enviará solicitações, diagnosticará sua permissão de invocação e removerá seus recursos.

Conclua Execute uma Função Lambda com um Evento JSON e Configure e Diagnostique uma Função Lambda, incluindo seus pré-requisitos de funções IAM e logs. Este ambiente novo fornece o manipulador e a função de execução.

Relação com as certificações

Este laboratório oferece prática nos seguintes tópicos de exame.

Solutions Architect – Associate (SAA-C03) · Tarefa 2.1: Rotas HTTP API, integração Lambda e permissões de invocação.
Developer – Associate (DVA-C02) · Tarefa 1.1, Tarefa 1.2: Rotas HTTP API, integração Lambda e permissões de invocação.
DevOps Engineer – Professional (DOP-C02) · Tarefa 3.2: Prática dos fundamentos: Rotas HTTP API, integração Lambda e permissões de invocação.

Implante a Função de Saúde

Nesta etapa, você empacotará o manipulador de saúde fornecido e implantará uma função capaz de responder a um evento HTTP.

Entre no diretório de trabalho preparado:

cd /home/labex/project

Abra AWS View ao lado do Terminal para acompanhar o mesmo estado de função, API e logs dos seus comandos. Inicialmente, existem apenas logs de referência não relacionados; preserve-os.

Leia a aplicação fornecida antes de empacotá-la:

cat app.py

O manipulador recebe um evento, registra essa entrada nos logs e retorna uma resposta proxy com statusCode, headers e uma string JSON em body. O formato de payload HTTP 2.0 coloca os parâmetros de consulta da URL em queryStringParameters. O parâmetro opcional name altera a saudação. RELEASE_LABEL é uma configuração de ambiente retornada junto com ela.

Use zip para colocar app.py na raiz do arquivo de implantação:

zip health.zip app.py

Leia o ARN da função IAM preparada em uma variável do shell. --query seleciona um campo da resposta, e --output text o torna utilizável pelo próximo comando:

ROLE_ARN=$(aws iam get-role --role-name labex-a01-execution --query 'Role.Arn' --output text)

Implante app.handler usando Python 3.12 e a função de execução preparada. fileb:// envia os bytes do Zip. O mapa JSON Variables usa o mesmo formato do laboratório de configuração Lambda. Seu valor de string marca o primeiro lançamento:

aws lambda create-function \
  --function-name labex-a01-health \
  --runtime python3.12 \
  --role "$ROLE_ARN" \
  --handler app.handler \
  --timeout 5 \
  --environment '{"Variables":{"RELEASE_LABEL":"initial"}}' \
  --zip-file fileb://health.zip \
  --query '{Name:FunctionName,Handler:Handler,Runtime:Runtime}'

A resposta deve identificar labex-a01-health, app.handler e python3.12. Abra o AWS View e inspecione o cartão Function. Uma função implantada sozinha ainda não fornece uma rota HTTP; o cartão HTTP APIs permanece vazio.

Conecte a Rota HTTP e Envie uma Solicitação

Nesta etapa, você conectará uma solicitação HTTP à sua função implantada. O Amazon API Gateway fornece a entrada HTTP. Uma rota seleciona uma integração de backend para um método e caminho, como GET /health.

Crie uma HTTP API e salve seu ID gerado em uma variável do shell. A substituição de comando, $(...), captura o ID selecionado da API em vez de exibi-lo:

API_ID=$(aws apigatewayv2 create-api --name labex-a01 --protocol-type HTTP --query ApiId --output text)

Registre esse ID para seu inventário de recursos. O redirecionamento, >, grava o valor em um arquivo:

printf '%s\n' "$API_ID" > api-id.txt

Um estágio é a entrada de implantação da API. O estágio $default não tem um segmento de nome de estágio na URL. --auto-deploy aplica alterações automaticamente. As aspas simples preservam o sinal de dólar literal:

aws apigatewayv2 create-stage --api-id "$API_ID" --stage-name '$default' --auto-deploy --query '{Stage:StageName,AutoDeploy:AutoDeploy}'

Leia o ARN da função implantada e crie uma integração AWS_PROXY. Integrações Lambda usam POST para invocar o backend, embora a rota de entrada do cliente abaixo use GET. O formato de payload 2.0 corresponde ao manipulador fornecido:

FUNCTION_ARN=$(aws lambda get-function-configuration --function-name labex-a01-health --query FunctionArn --output text)

INTEGRATION_ID=$(aws apigatewayv2 create-integration --api-id "$API_ID" --integration-type AWS_PROXY --integration-method POST --integration-uri "$FUNCTION_ARN" --payload-format-version 2.0 --query IntegrationId --output text)

Uma chave de rota combina o método HTTP do cliente com o caminho. Seu destino aponta para a integração que você acabou de criar:

aws apigatewayv2 create-route \
  --api-id "$API_ID" \
  --route-key 'GET /health' \
  --target "integrations/$INTEGRATION_ID" \
  --authorization-type NONE \
  --query '{Route:RouteKey,Authorization:AuthorizationType}'

Esta rota pública de saúde usa NONE; o login da aplicação será apresentado depois. A função de execução controla o que o código da função pode fazer, enquanto a política de recurso da função controla quem pode invocá-la. O API Gateway ainda precisa de uma concessão precisa de invocação.

Leia o ID da conta selecionada e construa o ARN de origem para a rota GET /health do estágio padrão desta API. O sinal de dólar escapado mantém $default literal dentro da string expandida:

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

SOURCE_ARN="arn:aws:execute-api:us-east-1:$ACCOUNT_ID:$API_ID/\$default/GET/health"

Conceda permissão apenas a esta rota da API para invocar a função:

aws lambda add-permission \
  --function-name labex-a01-health \
  --statement-id ApiHealth \
  --action lambda:InvokeFunction \
  --principal apigateway.amazonaws.com \
  --source-account "$ACCOUNT_ID" \
  --source-arn "$SOURCE_ARN" \
  --query Statement \
  --output text

Para solicitações HTTP neste diretório de trabalho, use o endereço preparado da API com seu ID gerado. Esta é a entrada da API do ambiente de trabalho, não um hostname público da AWS:

API_URL="http://127.0.0.1:8081/api/$API_ID"

O Console oficial mostra o mesmo ID de API, estágio $default e configuração Auto deploy. Seu Invoke URL é um endpoint da AWS; continue com o API_URL do seu ambiente de trabalho acima neste laboratório.

Console oficial do API Gateway mostrando detalhes da API e a URL de invocação do estágio padrão

Fonte: AWS API Gateway.

curl -i mostra tanto os cabeçalhos HTTP quanto o corpo da resposta. O parâmetro de consulta da URL torna-se parte do evento real do Lambda:

curl -i "$API_URL/health?name=Maya"

Espere HTTP 200 e este corpo JSON:

{"healthy": true, "message": "Hello, Maya", "release": "initial"}

Volte ao AWS View. O cartão HTTP APIs deve mostrar GET /health, NONE e $default · AutoDeploy true. O cartão CloudWatch Logs deve mostrar a rota, o status e a resposta reais. Clique em Show logs e encontre queryStringParameters com name: Maya. Esta observação manual conecta a solicitação HTTP à entrada da função implantada; a verificação confere a configuração remota e a execução real.

Rota HTTP de saúde e sua resposta Lambda no AWS View

Este exemplo mostra a rota configurada e sua resposta bem-sucedida Maya / initial. Seu ID gerado da API e a impressão digital do código serão diferentes.

A rota de saúde seleciona a integração Lambda para a solicitação.

Diagnostique a Permissão de Invocação e Publique um Novo Lançamento

Nesta etapa, você observará um limite de invocação interrompido, restaurará a concessão precisa e testará uma configuração alterada da função.

Remova a declaração pelo seu ID. Isso mantém a API, a integração e a função de execução no lugar:

aws lambda remove-permission --function-name labex-a01-health --statement-id ApiHealth

Envie outra solicitação enquanto a concessão está ausente:

curl -i "$API_URL/health?name=Noah"

Espere HTTP 502 com Invocation permission denied. A implantação da API e a configuração da rota não concedem, por si só, permissão de invocação Lambda. No AWS View, a invocação bem-sucedida existente permanece; esta solicitação rejeitada não executou o manipulador. Compare manualmente os logs antes e depois da solicitação. A verificação automática não infere uma rejeição histórica a partir da política final restaurada.

Restaure a mesma concessão restrita à conta e à rota:

aws lambda add-permission \
  --function-name labex-a01-health \
  --statement-id ApiHealth \
  --action lambda:InvokeFunction \
  --principal apigateway.amazonaws.com \
  --source-account "$ACCOUNT_ID" \
  --source-arn "$SOURCE_ARN" \
  --query Statement \
  --output text

Altere o ambiente da função para marcar o lançamento ready. O manipulador lê essa configuração quando executa:

aws lambda update-function-configuration --function-name labex-a01-health --environment '{"Variables":{"RELEASE_LABEL":"ready"}}' --query 'Environment.Variables'

A rota ainda aponta para a mesma função. Envie uma solicitação usando um valor de consulta diferente:

curl -i "$API_URL/health?name=Noah"

Espere HTTP 200 e uma resposta calculada a partir da nova consulta e do novo ambiente:

{"healthy": true, "message": "Hello, Noah", "release": "ready"}

No AWS View, inspecione a resposta mais recente e expanda seus logs. Confirme que a entrada diz Noah e o corpo diz ready. A resposta anterior Maya deve permanecer disponível. Esses resultados diferentes demonstram que a integração executa a função implantada, em vez de retornar uma única mensagem fixa de saúde.

Exclua Sua API e Função

Nesta etapa, você removerá os recursos que criou e comprovará que os logs de referência não relacionados permanecem.

Seu inventário consiste no ID de API em api-id.txt, em labex-a01-health e em /aws/lambda/labex-a01-health. A API possui sua rota, integração e estágio padrão. Exclua a API primeiro para que ela não receba mais solicitações:

aws apigatewayv2 delete-api --api-id "$API_ID"

Remova a função e sua política de invocação:

aws lambda delete-function --function-name labex-a01-health

Grupos de logs Lambda têm seu próprio ciclo de vida. Exclua apenas o grupo desta função:

aws logs delete-log-group --log-group-name /aws/lambda/labex-a01-health

Leia os inventários nativos com sucesso; erros nas solicitações não comprovam a exclusão:

aws apigatewayv2 get-apis --query 'Items[].Name'

aws lambda list-functions --query 'Functions[].FunctionName'

Ambas as listas devem estar vazias. Leia os grupos de logs restantes:

aws logs describe-log-groups --query 'logGroups[].logGroupName'

Somente /labex/labex-a01-reference deve permanecer. Preserve-o e a função de execução preparada. No AWS View, confirme que os cartões API, Function e de invocação estão vazios, enquanto Reference logs ainda mostra INFO platform reference keep unchanged.

Resumo

Você implantou um manipulador Python de saúde, conectou uma rota de HTTP API por meio de uma integração de payload 2.0 e habilitou seu estágio padrão. Você restringiu a concessão de invocação Lambda da API, diagnosticou sua remoção e observou respostas diferentes a partir de valores reais de consulta e configurações da função. Por fim, removeu sua API, função e grupo de logs, preservando os recursos não relacionados.