Intégrer Lambda aux services AWS

Applications sans serveur avec AWS Lambda

Claudio Canales

Senior DevOps Engineer

La boucle d'intégration

Événement en entrée.
Logique du gestionnaire.
Appel au SDK.

Boucle Événement -> gestionnaire -> SDK

Déclencheurs vs appels SDK

Déclencheur

Décide quand Lambda s'exécute.

Appel SDK (dans le gestionnaire)

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.
Enregistrer un petit enregistrement dans DynamoDB.

Téléversement S3 -> Lambda -> DynamoDB

Charge utile d'événement : trouver ce qu'il faut

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

Indications sur la charge utile d'événement S3

Où s'insère l'AWS SDK

Votre code appelle le SDK (boto3).
Le SDK appelle les API AWS.
IAM contrôle l'accès.

Gestionnaire -> SDK -> API AWS

Rôle d'exécution = identifiants

Identifiants temporaires du rôle d'exécution.
Aucune clé 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 la portée des dommages.
N'accorder que les actions et ressources nécessaires.
Éviter les caractères génériques sauf besoin réel.

Moindre privilège : actions et ressources

DynamoDB : choisir la bonne opération

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

Opérations DynamoDB

S3 : travailler avec le seau et la clé

Les objets résident à l'emplacement « seau + clé ».
GetObject récupère le contenu.
PutObject écrit un fichier dérivé.

Seau S3 et clé

Placer la config dans des variables d'environnement

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

Configuration par variables d'environnement

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 gestionnaire avec appel SDK

Gérer les erreurs du SDK avec intention

Les erreurs d'autorisations sont fréquentes au début.
Quand un appel échoue, rendez-en la cause évidente.
De bons journaux facilitent le débogage.

Chemins de réussite et d'échec

Quand IAM est erroné, le code semble correct

AccessDeniedException
required action denied

Corriger IAM d'abord, puis la logique du gestionnaire.

Accès refusé

Idempotence : reprises et doublons sans risque

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

Patron de clé d'idempotence

Assembler le tout (de bout en bout)

L'événement S3 fournit le seau et la clé.
Le gestionnaire les analyse.
PutItem écrit les métadonnées dans DynamoDB.
CloudWatch Logs montre ce qui s'est passé.

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

Points clés à retenir

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

Points clés de l'intégration

Passons à la pratique !

Applications sans serveur avec AWS Lambda