AWS : Lambda

AWS Lambda permet d'exécuter du code sans gérer de serveurs. Ce document décrit le déploiement d'une fonction qui restitue une page HTML via une Function URL, les méthodes de test applicables et les opérations de nettoyage des ressources associées.

AWS Lambda est un service d'exécution serverless orienté événements. Une fonction Lambda exécute du code en réponse à des déclencheurs (HTTP via Function URL ou API Gateway, événements S3, messages SNS/SQS, EventBridge, etc.). Le modèle de facturation repose sur le temps d'exécution et la mémoire allouée : il n'y a pas de coût pour des serveurs continus, seules les invocations et la durée d'exécution sont facturées.

L'exécution se fait dans des environnements éphémères isolés ; le démarrage initial peut entraîner un "cold start" pour certains runtimes. Les fonctions disposent de limites configurables (mémoire, timeout, taille du bundle) et peuvent utiliser des layers pour partager des dépendances. Les logs et métriques sont émis vers CloudWatch, et l'exécution requiert un rôle IAM avec permissions minimales (principle du least privilege) pour les actions nécessaires.

Cas d'usage courants : backends HTTP légers, transformations d'objets S3, tâches asynchrones, webhooks et prototypes rapides. Pour des charges statiques ou des assets lourds, l'utilisation de S3 + CloudFront reste préférable.

Créer la fonction

La création de la fonction peut s'effectuer depuis la console AWS Lambda.

La fonction peut être configurée avec des valeurs simples, par exemple runtime nodejs22.x, architecture x86_64 et un nommage tel que http-function-url-tutorial. Le rôle d'exécution peut être créé automatiquement et doit autoriser l'envoi de logs vers CloudWatch.

Le plan "Getting started with Lambda HTTP" fournit un index.html et un handler simple lisant ce fichier et renvoyant son contenu comme body HTML. La fonction traite une requête HTTP et retourne un document HTML.

Exemple de handler

Le handler renvoie simplement index.html. Exemple (ESM) :

// index.mjs
import fs from 'node:fs';

const html = fs.readFileSync('index.html', 'utf8');

export async function handler(event, context) {
    // `event` contient les données de la requête HTTP ou l'événement déclencheur.
    // `context` fournit des métadonnées d'exécution (requestId, timeout restant, etc.).
    return {
        statusCode: 200,
        headers: { 'Content-Type': 'text/html' },
        body: html,
    };
}

Le handler reçoit deux paramètres principaux : event et context. Pour une invocation HTTP, event inclut la méthode, les en-têtes et le corps de la requête. Le paramètre context fournit des informations sur l'exécution en cours (identifiant de la requête, temps restant avant timeout). Les messages envoyés via console.log apparaissent automatiquement dans CloudWatch Logs.

Le démarrage initial d'un environnement d'exécution peut entraîner un "cold start" qui augmente la latence pour la première invocation. Les cold starts sont plus perceptibles pour certains runtimes et lorsque la fonction a des dépendances lourdes. Les stratégies pour réduire l'impact comprennent le provisioned concurrency, le choix d'un runtime optimisé et la réduction de la taille du bundle.

Les variables d'environnement permettent de paramétrer le comportement sans modifier le code. Les layers servent à partager des dépendances entre fonctions et à réduire la taille des packages déployés. Pour des fichiers statiques ou des assets volumineux, héberger les ressources sur S3 et servir via CloudFront est généralement plus performant que de les embarquer dans le package Lambda.

Invoquer la Function URL

Pour vérifier le déploiement, l'onglet Code affiche le handler et le fichier index.html. L'ouverture de l'URL de Function (Configuration → Function URL) dans un navigateur déclenche l'invocation et retourne la page HTML.

Le test en ligne de commande s'effectue avec la commande suivante (remplacer <FUNCTION_URL> par l'URL fournie par la console) :

curl -i "https://<FUNCTION_URL>"

Vérifier les logs

Les logs CloudWatch fournissent les informations de diagnostic et les traces d'exécution. Les entrées START/END/REPORT et les erreurs JavaScript y sont visibles. Pour suivre les logs en temps réel, utiliser :

aws logs tail /aws/lambda/http-function-url-tutorial --follow --since 1h

La CLI AWS permet également d'invoquer la fonction directement sans passer par la Function URL :

aws lambda invoke --function-name http-function-url-tutorial out.txt

La différence principale est l'endpoint : aws lambda invoke appelle l'API Lambda en mode administré et ne reflète pas le comportement exact d'une invocation HTTP via Function URL (en-têtes, codes de statut). Pour une Function URL configurée en AWS_IAM, les requêtes HTTP doivent être signées (SigV4) ; les SDK AWS gèrent cette signature automatiquement.

Alternatives et bonnes pratiques

Pour un usage public statique, il est préférable d'héberger index.html sur S3 et d'utiliser CloudFront. Pour sécuriser l'accès à une fonction, il est recommandé d'utiliser AWS_IAM ou de placer un API Gateway avec des mécanismes d'authentification. Pour la performance, précompiler et bundler les assets et éviter les lectures synchrones à chaque invocation.

Exemple chaînage simple entre deux Lambdas

Un chaînage simple entre deux fonctions Lambda permet d'illustrer les concepts d'invocation et de permissions sans introduire d'infrastructure supplémentaire. Dans cet exemple, la fonction producer invoque de manière asynchrone la fonction consumer via l'API Lambda (Invoke avec InvocationType='Event').

Extrait du producer (Python) :

import os, json, boto3

lambda_client = boto3.client('lambda')
CONSUMER = os.environ.get('CONSUMER_FUNCTION_NAME', 'lambda-consumer')

def handler(event, context):
    payload = { 'message': 'Hello from producer', 'input': event }
    lambda_client.invoke(
        FunctionName=CONSUMER,
        InvocationType='Event',
        Payload=json.dumps(payload).encode()
    )
    return { 'statusCode': 202, 'body': json.dumps({'sent': True}) }

Comportement attendu du consumer : consigner le payload reçu dans les logs CloudWatch et exécuter le traitement asynchrone. Pour une invocation asynchrone, la réponse renvoyée par le consumer n'est pas retournée au caller.

Permissions minimales : le rôle d'exécution de la fonction producer doit inclure l'action lambda:InvokeFunction ciblant l'ARN de la fonction consumer (ex. arn:aws:lambda:REGION:ACCOUNT_ID:function:lambda-consumer).

Test rapide (CLI) :

aws lambda invoke --function-name lambda-producer --payload '{}' /tmp/out.json
cat /tmp/out.json
# Consulter les logs du consumer dans CloudWatch pour vérifier la réception

Remarques pratiques :

• Vérifier la taille du payload ; pour des objets volumineux, stocker sur S3 et transmettre un lien.
• Inclure des métadonnées (horodatage, requestId) facilite le traçage entre producer et consumer.
• Prévoir l'idempotence côté consumer si des duplications peuvent survenir.

Les fichiers d'exemple correspondants se trouvent dans examples/lambda-two/ du dépôt.

Nettoyage

La suppression des ressources commence par la suppression de la Function URL si elle n'est pas nécessaire, puis par la suppression de la fonction :

aws lambda delete-function --function-name http-function-url-tutorial

Après suppression de la fonction, supprimer le rôle IAM si celui-ci n'est plus utilisé.