Exposer une fonction Lambda avec une API HTTP

Introduction

Une page de statut a besoin d'un point de terminaison HTTP indiquant si une application est saine. Vous allez relier un gestionnaire Lambda fourni à une API HTTP, envoyer des requêtes, diagnostiquer sa permission d'invocation et retirer vos ressources.

Terminez Exécuter une fonction Lambda avec un événement JSON et Configurer et diagnostiquer une fonction Lambda, y compris leurs prérequis sur les rôles et journaux. Ce nouvel environnement fournit le gestionnaire et le rôle d'exécution.

Lien avec les certifications

Ce laboratoire propose une pratique des sujets d’examen suivants.

Solutions Architect – Associate (SAA-C03) · Tâche 2.1: Routes HTTP API, intégration Lambda et autorisations d’invocation.
Developer – Associate (DVA-C02) · Tâche 1.1, Tâche 1.2: Routes HTTP API, intégration Lambda et autorisations d’invocation.
DevOps Engineer – Professional (DOP-C02) · Tâche 3.2: Pratique des fondamentaux : Routes HTTP API, intégration Lambda et autorisations d’invocation.

Déployer la fonction de santé

Dans cette étape, vous allez empaqueter le gestionnaire de santé fourni et déployer une fonction capable de répondre à un événement HTTP.

Accédez à l'espace de travail préparé :

cd /home/labex/project

Ouvrez AWS View à côté de Terminal pour suivre le même état de fonction, d'API et de journaux que vos commandes. Au départ, seuls des journaux de référence sans rapport existent ; conservez-les.

Lisez l'application fournie avant de l'empaqueter :

cat app.py

Le gestionnaire reçoit un événement, journalise cette entrée et renvoie une réponse proxy avec statusCode, headers et une chaîne JSON dans body. Le format de charge utile HTTP 2.0 place les paramètres de requête de l'URL dans queryStringParameters. Le paramètre facultatif name modifie le message de bienvenue. RELEASE_LABEL est un paramètre d'environnement renvoyé à ses côtés.

Utilisez zip pour placer app.py à la racine de l'archive de déploiement :

zip health.zip app.py

Lisez l'ARN du rôle préparé dans une variable du shell. --query sélectionne un champ de réponse et --output text le rend utilisable par la commande suivante :

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

Déployez app.handler avec Python 3.12 et le rôle d'exécution préparé. fileb:// charge les octets du Zip. La table JSON Variables utilise le même format que le laboratoire de configuration Lambda. Sa valeur de chaîne marque la première publication :

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}'

La réponse doit identifier labex-a01-health, app.handler et python3.12. Ouvrez AWS View et inspectez la carte Function. Une fonction déployée seule ne fournit pas encore de route HTTP ; la carte HTTP APIs reste vide.

Relier la route HTTP et envoyer une requête

Dans cette étape, vous allez relier une requête HTTP à votre fonction déployée. Amazon API Gateway fournit l'entrée HTTP. Une route sélectionne une intégration vers le backend pour une méthode et un chemin, comme GET /health.

Créez une API HTTP et enregistrez son identifiant généré dans une variable du shell. La substitution de commande $(...) capture l'identifiant d'API sélectionné au lieu de l'afficher :

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

Enregistrez cet identifiant pour votre inventaire de ressources. La redirection > écrit la valeur dans un fichier :

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

Un stage est l'entrée de déploiement de l'API. Le stage $default n'a pas de segment de nom de stage dans l'URL. --auto-deploy applique automatiquement les changements. Les guillemets simples conservent le signe dollar littéral :

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

Lisez l'ARN de la fonction déployée, puis créez une intégration AWS_PROXY. Les intégrations Lambda utilisent POST pour invoquer le backend, même si la route cliente entrante ci-dessous utilise GET. Le format de charge utile 2.0 correspond au gestionnaire fourni :

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)

Une clé de route combine la méthode HTTP du client et le chemin. Sa cible pointe vers l'intégration que vous venez de créer :

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

Cette route publique de santé utilise NONE ; la connexion à l'application sera introduite plus tard. Le rôle d'exécution contrôle ce que le code de la fonction peut faire, tandis que la politique de ressource de la fonction contrôle qui peut l'invoquer. API Gateway a encore besoin d'une autorisation d'invocation précise.

Lisez l'identifiant du compte sélectionné et construisez l'ARN source pour la route GET /health du stage par défaut de cette API. Le signe dollar échappé conserve $default littéralement dans la chaîne développée :

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"

Accordez uniquement à cette route d'API la permission d'invoquer la fonction :

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

Pour les requêtes HTTP dans cet espace de travail, utilisez l'adresse d'API préparée avec votre identifiant généré. Il s'agit de l'entrée d'API de l'espace de travail, pas d'un nom d'hôte public AWS :

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

La console officielle affiche le même identifiant d'API, le stage $default et le paramètre Auto deploy. Son Invoke URL est un point de terminaison AWS ; poursuivez avec l'API_URL de votre espace de travail ci-dessus pour ce laboratoire.

Console officielle API Gateway affichant les détails de l'API et l'URL d'invocation du stage par défaut

Source : AWS API Gateway.

curl -i affiche les en-têtes HTTP et le corps de réponse. Le paramètre de requête de l'URL fait partie de l'événement Lambda réel :

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

Attendez-vous à obtenir HTTP 200 et ce corps JSON :

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

Retournez dans AWS View. La carte HTTP APIs doit afficher GET /health, NONE et $default · AutoDeploy true. La carte CloudWatch Logs doit afficher la route, le statut et la réponse réels. Cliquez sur Show logs et trouvez queryStringParameters avec name: Maya. Cette observation manuelle relie la requête HTTP à l'entrée de la fonction déployée ; la vérification contrôle la configuration distante et l'exécution réelle.

Route HTTP de santé et sa réponse Lambda dans AWS View

Cet exemple montre la route configurée et sa réponse réussie Maya / initial. Votre identifiant d'API généré et l'empreinte du code seront différents.

La route de santé sélectionne l'intégration Lambda pour la requête.

Diagnostiquer la permission d'invocation et diffuser une nouvelle publication

Dans cette étape, vous allez observer une rupture de l'autorisation d'invocation, rétablir l'autorisation précise et tester un paramètre de fonction modifié.

Retirez l'instruction par son identifiant. Cela laisse l'API, l'intégration et le rôle d'exécution en place :

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

Envoyez une autre requête pendant l'absence d'autorisation :

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

Attendez-vous à obtenir HTTP 502 avec Invocation permission denied. Le déploiement de l'API et la configuration de route n'accordent pas eux-mêmes la permission d'invoquer Lambda. Dans AWS View, l'invocation réussie existante reste présente ; cette requête rejetée n'a pas exécuté le gestionnaire. Comparez manuellement les journaux avant et après la requête. Le contrôle automatique ne déduit pas un rejet historique de la politique finale rétablie.

Rétablissez la même autorisation limitée au compte et à la route :

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

Modifiez l'environnement de la fonction pour marquer la publication ready. Le gestionnaire lit ce paramètre lors de son exécution :

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

La route pointe toujours vers la même fonction. Envoyez une requête avec une valeur de paramètre différente :

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

Attendez-vous à obtenir HTTP 200 et une réponse calculée à partir du nouveau paramètre et de l'environnement :

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

Dans AWS View, inspectez la dernière réponse et développez ses journaux. Confirmez que l'entrée indique Noah et que le corps indique ready. La réponse antérieure Maya doit rester disponible. Ces résultats différents démontrent que l'intégration exécute la fonction déployée plutôt que de renvoyer un seul message de santé fixe.

Supprimer votre API et votre fonction

Dans cette étape, vous allez retirer les ressources créées et prouver que les journaux de référence sans rapport subsistent.

Votre inventaire comprend l'identifiant d'API dans api-id.txt, labex-a01-health et /aws/lambda/labex-a01-health. L'API possède sa route, son intégration et son stage par défaut. Supprimez d'abord l'API pour qu'elle ne puisse plus recevoir de requêtes :

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

Retirez la fonction et sa politique d'invocation de l'exercice :

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

Les groupes de journaux Lambda ont leur propre cycle de vie. Supprimez uniquement le groupe de cette fonction :

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

Lisez les inventaires natifs avec succès ; les erreurs de requête ne prouvent pas la suppression :

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

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

Les deux listes doivent être vides. Lisez les groupes de journaux restants :

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

Seul /labex/labex-a01-reference doit rester. Conservez-le ainsi que le rôle d'exécution préparé. Dans AWS View, confirmez que les cartes API, Function et d'invocation sont vides, tandis que Reference logs affiche toujours INFO platform reference keep unchanged.

Résumé

Vous avez déployé un gestionnaire Python de santé, relié une route d'API HTTP par une intégration payload 2.0 et activé son stage par défaut. Vous avez limité l'autorisation d'invocation Lambda de l'API, diagnostiqué son retrait et observé différentes réponses issues de vrais paramètres de requête et de fonction. Enfin, vous avez retiré votre API, votre fonction et votre groupe de journaux en conservant les ressources sans rapport.