Intégrer Lambda aux services AWS

Applications serverless avec AWS Lambda

Claudio Canales

Senior DevOps Engineer

La boucle d'intégration

Événement entrant.
Logique du handler.
Appel SDK.

Événement -> handler -> boucle SDK

Déclencheurs vs appels SDK

Déclencheur

Décide quand Lambda s'exécute.

Appel SDK (dans le handler)

Lit et écrit dans des services comme DynamoDB et S3.

Déclencheur vs appel SDK

Un exemple concret

Un fichier arrive dans S3.
Lambda s'exécute.
Stocker un petit enregistrement dans DynamoDB.

Envoi S3 -> Lambda -> DynamoDB

Charge d'événement : trouvez l'essentiel

{
  "Records": [{
    "s3": {
      "bucket": {"name": "…"},
      "object": {"key": "…"}
    }
  }]
}

Annotations de la charge d'événement S3

Place du SDK AWS

Votre code appelle le SDK (boto3).
Le SDK appelle les API AWS.
IAM est le gardien.

Handler -> SDK -> API AWS

Rôle d'exécution = identifiants

Identifiants temporaires du rôle d'exécution.
Pas de clés d'accès dans le code.
Si le rôle ne peut pas appeler une API, l'appel SDK échoue.

Le rôle d'exécution fournit les identifiants

Moindre privilège : cibler actions + ressources

Réduit le rayon d'impact.
N'accorder que les actions et ressources nécessaires.
Éviter les jokers sauf besoin réel.

Principe du moindre privilège : actions et ressources

DynamoDB : choisir la bonne opération

PutItem écrit.
GetItem lit par clé.
Query trouve les éléments liés.
Préférez des opérations ciblées aux scans larges.

Opérations DynamoDB

S3 : travailler avec bucket + clé

Les objets sont définis par bucket + clé.
GetObject récupère le contenu.
PutObject écrit un fichier dérivé.

Bucket et clé S3

Placer la configuration en variables d'environnement

Coder en dur les noms de ressources est fragile.
Utilisez des variables d'environnement.
Déployez le même code en dev et en prod.

Configuration par variables d'env.

Code SDK : petit et testable

import boto3
ddb = boto3.client("dynamodb")
def handler(event, context):
    ddb.put_item(
        TableName="files",
        Item={"pk": {"S": "1"}},
    )

Valider les entrées, appeler le SDK, retourner.
Tester unitairement la logique pure.

Petit handler avec appel SDK

Gérer les erreurs SDK explicitement

Les erreurs de permissions sont courantes au début.
En cas d'échec, rendez la cause évidente.
De bons logs facilitent le débogage.

Chemins de réussite et d'échec

Si IAM est erroné, le code semble correct

AccessDeniedException
required action denied

Corrigez IAM d'abord, puis la logique du handler.

Accès refusé

Idempotence : reprises et doublons sans risque

Un même événement peut arriver deux fois.
Les clés d'idempotence évitent les doublons.
Les écritures conditionnelles rendent les répétitions sûres.

Modèle de clé d'idempotence

Assembler le tout (de bout en bout)

L'événement S3 fournit bucket et clé.
Le handler les analyse.
PutItem écrit les métadonnées dans DynamoDB.
CloudWatch Logs montrent ce qui s'est passé.

Résumé de l'intégration bout en bout

Points clés

Séparer déclencheurs et appels SDK.
Restreindre les permissions via le rôle d'exécution.
Rendre la config portable via les variables d'env.

Points clés de l'intégration

Passons à la pratique !

Applications serverless avec AWS Lambda