Configurer les fonctions Lambda

Applications serverless avec AWS Lambda

Claudio Canales

Senior DevOps Engineer

Pourquoi la configuration compte

Le même code peut se comporter très différemment selon les réglages.
La configuration pilote performance, coût et sécurité.
Objectif : un comportement prévisible en dev et prod.

Même code, réglages différents

Code vs configuration

Package de code

Package de code
Logique du handler + dépendances.
Toute modification nécessite un déploiement.

Configuration de la fonction

Configuration de la fonction
Mémoire, délai, variables d'environnement.
Rôle d'exécution + layers.

Les leviers à votre disposition

Runtime + handler : quel code Lambda exécute.
Mémoire + délai : performance, coût, sécurité.
Variables d'environnement : config sans hard-coding.
Rôle d'exécution : autorisations pour les API AWS.
Layers : dépendances partagées entre fonctions.

Réglages de configuration Lambda

Bases du runtime et du handler

Runtime = environnement de langage (ex. Python).
Handler = point d'entrée appelé par Lambda.
Format du handler : file.function.
Exemple : lambda_function.lambda_handler.

Décomposition de la chaîne du handler

Chaîne du handler : sources d'erreurs

# lambda_function.py
def lambda_handler(event, context):
    return {"statusCode": 200}

Importer puis appeler le handler

Le rôle d'exécution (IAM)

IAM = Identity and Access Management (autorisations).
Le rôle d'exécution définit ce que la fonction peut faire.
Il contrôle quelles API AWS votre code peut appeler.

Rôle d'exécution comme badge d'accès

Qu'est-ce qu'une layer Lambda ?

Une layer est un ZIP attaché à une fonction.
Lambda rend ses fichiers disponibles au runtime sous /opt.
Utilisez-les pour des bibliothèques/ utilitaires communs.
Mettez-la à jour une fois ; plusieurs fonctions la réutilisent.

Layer montée sous /opt

Où apparaissent les layers au runtime

Votre code est monté sous /var/task.
Vos layers attachées sont montées sous /opt.
Lambda fournit aussi un dossier temporaire /tmp.

Dossiers runtime : /var/task, /opt, /tmp

La mémoire influe aussi sur le CPU

Plus de mémoire -> plus de CPU.
Réduit le temps d'exécution pour les tâches CPU-bound.
Le coût dépend de la durée et de la mémoire.

La mémoire augmente le CPU

Ajuster la mémoire par mesure

Commencez avec un défaut raisonnable (ex. 256 Mo).
Testez avec des événements réalistes.
Comparez durée et coût selon la mémoire.

Balayage mémoire : mesurer durée et coût

Timeouts et exécution sûre

Le délai d'expiration stoppe les exécutions folles.
Vérifiez le temps restant avant un long traitement.
Échouer vite et relancer si pertinent.

Timeout comme minuterie de sécurité

Pas à pas : vérifier le temps restant

def lambda_handler(event, context):
    time_left = context.get_remaining_time_in_millis()
    if time_left < 500:
        raise TimeoutError("Not enough time left")
    return {"statusCode": 200}

Garde avec compte à rebours du contexte

Variables d'environnement

Gardez la config hors du code.
Séparez les réglages dev/test/prod.
Utilisez Secrets Manager pour les valeurs sensibles.

Les variables d'environnement pilotent le comportement

Pas à pas : lire des variables d'environnement

import os

STAGE = os.getenv("STAGE", "dev")
LOG_LEVEL = os.getenv(
    "LOG_LEVEL", "INFO"
)

Des valeurs par défaut sécurisent les tests locaux

Importez os pour accéder aux variables d'environnement.
os.getenv renvoie la valeur ou le défaut.

Pièges courants de configuration

Valeurs d'étape en dur dans le code.
Timeout trop bas ou autorisations IAM manquantes.
Secrets en clair dans les variables d'environnement.

Pièges et règles pratiques

Passons à la pratique !

Applications serverless avec AWS Lambda