🔥 AWS Lambda (Serverless Compute)

6.3. Concurrency Model (Modèle de Concurrence)

La concurrence définit le nombre de conteneurs (fonctions) qui peuvent s'exécuter simultanément pour votre compte/région (limite par défaut : 1000).

Burst Limits (Limites de Rafale)

C'est la vitesse à laquelle Lambda peut créer de nouveaux conteneurs (Cold Start) pour gérer un pic de trafic soudain (le rate limit de la scalabilité). AWS gère cette limite pour empêcher la saturation des autres services (comme l'API SSM ou la BDD). Si cette limite est dépassée, vous subissez également du Throttling (429).

6.4. Isolation et Sécurité via Micro-VM Firecracker

Cloud computing repose sur la mutualisation des ressources. Firecracker est la technologie qui garantit la sécurité et l'isolation entre les fonctions des différents clients sur le même serveur physique.

Firecracker : Le Micro-Hyperviseur

Firecracker est un **Virtual Machine Monitor (VMM)** ultra-léger basé sur KVM, développé par AWS.

• **Isolation Matérielle :** Chaque fonction (même de deux clients différents) est encapsulée dans sa propre **micro-VM**. Cela offre une isolation de sécurité de niveau Hyperviseur, supérieure à l'isolation par conteneur classique (Docker/Cgroups).
• **Minimalisme :** Firecracker est minimaliste (moins de code = moins de surface d'attaque). Il ne gère que le strict nécessaire (mémoire, vCPU, ENI virtuelle).
• **Performance :** Le temps de démarrage d'une micro-VM est très rapide (quelques centaines de millisecondes), minimisant l'impact de la latence du Cold Start (6.1).

5.2. Layers Lambda (Librairies Partagées)

Les **Layers** permettent d'isoler et de partager des dépendances (librairies) lourdes ou communes entre plusieurs fonctions Lambda. Le code de la fonction devient plus léger et le déploiement est plus rapide.

Avantages Clés

• **Réduction de la Taille du Package :** Le package ZIP de la fonction ne contient que le code métier, pas les dépendances (ex: Numpy, Pandas).
• **Standardisation :** Toutes les fonctions peuvent utiliser la même version d'une librairie (ex: Logger personnalisé).
• **Réutilisation :** Un Layer peut être attaché à **plusieurs** fonctions dans le même compte et région.
• **Patching Centralisé :** Mettre à jour la dépendance dans le Layer met à jour toutes les fonctions l'utilisant.

Structure du Layer (Python)

Le Layer doit respecter une structure de répertoire précise pour que Lambda le trouve au runtime.

                    # Structure du ZIP du Layer
                    mon_layer.zip
                    └── python/
                    ├── lib/
                    │   └── pythonX.X/
                    │       └── site-packages/
                    │           └── [votre librairie]
                    └── [votre librairie custom.py]
                

5.3. Gestion des Variables d’Environnement et Secrets

Les variables d'environnement (`Env Vars`) sont utilisées pour la configuration dynamique (ex: nom de la table DynamoDB, région).

Règles de Sécurité (Séparation des Secrets)

**Ne jamais stocker de secrets (mots de passe, clés API) directement en clair dans les variables d'environnement.**

Code d'Accès à un Secret (Python)

Récupération d'un secret depuis Secrets Manager :

                    import json
                    import boto3

                    def get_secret():
                    client = boto3.client('secretsmanager')
                    response = client.get_secret_value(SecretId='mon_secret_api')

                    # Le secret est renvoyé sous forme de string JSON
                    if 'SecretString' in response:
                    return json.loads(response['SecretString'])
                    return None
                

5.4. Versioning, Aliases et Déploiement Canari (CI/CD)

Le **Versioning** et les **Aliases** sont essentiels pour la gestion du cycle de vie des applications et le déploiement sans interruption (Zero Downtime).

Versioning et Aliases

• **Version (`$LATEST` et Nombres) :** Chaque déploiement (ZIP ou Container) crée une version immuable. `$LATEST` est la version en cours de développement.
• **Alias :** Un pointeur mutable vers une version spécifique (ou un mélange de versions). Ils sont utilisés pour séparer les environnements (DEV, STAGE, PROD).

Déploiement Canari (Traffic Shifting)

Un Alias peut pointer vers **deux versions différentes** avec une pondération de trafic. C'est la base du déploiement **Canari (Canary)** ou du **Blue/Green**.

                    # L'Alias "PROD" pointe vers :
                    # 90% du trafic -> Version: 15 (Ancienne)
                    # 10% du trafic -> Version: 16 (Nouvelle)
                    #
                    # Si la V16 est stable, on fait passer le trafic à 100% sur la V16.
                

Intégration CI/CD

Les outils de déploiement et d'orchestration modernes gèrent le Versioning/Alias automatiquement :

• **AWS CodeDeploy :** Gère la transition de trafic (Traffic Shifting) entre les versions d'Alias (Canary, Linear, AllAtOnce).
• **Serverless Framework (ou SAM) :** Frameworks qui simplifient la configuration du packaging (ZIP/Layers/Containers) et le déploiement (Mise à jour d'Alias).
• **GitHub Actions / CodePipeline :** Peuvent déclencher les commandes de Serverless/SAM après un Merge dans la branche `main`.

4.2. Contrôle d’Accès via Resource Policies

La **Resource Policy** est une politique IAM attachée **directement à la ressource Lambda** elle-même. Elle ne contrôle pas ce que la fonction fait (ça, c'est l'Execution Role), mais **qui** a le droit de l'invoquer (le Trigger).

Usage Principal : Le Filtre des Triggers

C'est cette politique qui permet à un service externe (API Gateway, S3, EventBridge) de "faire confiance" à la fonction Lambda pour l'invoquer (appelé `AddPermission` dans la console/CLI).

                    # Exemple de Resource Policy (Attachée à la fonction Lambda)
                    {
                    "Statement": [
                    {
                    "Sid": "AllowAPIGatewayInvocation",
                    "Effect": "Allow",
                    "Principal": {
                    "Service": "apigateway.amazonaws.com"
                    },
                    "Action": "lambda:InvokeFunction",
                    "Resource": "arn:aws:lambda:eu-west-3:1234567890:function:MaFonction",
                    "Condition": {
                    "ArnLike": {
                    "AWS:SourceArn": "arn:aws:execute-api:eu-west-3:1234567890:abcdef123/*/*"
                    }
                    }
                    }
                    ]
                    }
                

Dans cet exemple, seule l'instance **spécifique** d'API Gateway identifiée par son ARN est autorisée à appeler la fonction (empêchant un autre utilisateur AWS d'appeler cette Lambda via son propre API Gateway).

4.3. Encryption At Rest (Chiffrement au Repos - KMS)

Le chiffrement au repos protège les données stockées dans AWS lorsque la fonction n'est pas en cours d'exécution.

Qu'est-ce qui est chiffré ?

• **Code de la Fonction :** Le fichier `.zip` ou l'image conteneur (stockés dans S3 ou ECR managé par AWS) est chiffré.
• **Variables d'Environnement :** Les clés-valeurs stockées (ex: DB_HOST) sont chiffrées.
• **Système de Fichiers `/tmp` :** Les données temporaires (jusqu'à 10GB) dans l'environnement `/tmp` sont chiffrées.

Clés KMS (Key Management Service)

Vous avez le choix entre deux types de chiffrement pour les données au repos :

4.4. Encryption In Transit (Chiffrement en Transit - TLS)

Le chiffrement en transit protège les données lorsqu'elles se déplacent entre services (client-serveur ou serveur-serveur).

Entre le Client et Lambda (via API Gateway)

La communication (ex: navigateur -> API) est sécurisée par **TLS/SSL (HTTPS)**. Le certificat est généralement géré par **AWS Certificate Manager (ACM)** et installé sur l'**API Gateway** ou l'**ALB** qui expose la fonction.

Entre Lambda et les Services Cibles

Toutes les communications entre la fonction Lambda et les services AWS (S3, DynamoDB, SQS, KMS) se font **automatiquement via TLS (Port 443)** sur le réseau AWS.

Même si la fonction Lambda est dans un **VPC (Subnet Privé)** et utilise des **VPC Endpoints** pour accéder à S3/DynamoDB, la connexion est chiffrée de bout en bout sur le backbone AWS.

Audit et Exigences

• **Exigences Externes :** Pour les appels à des APIs externes (ex: Stripe), le code doit **appliquer TLS 1.2 ou supérieur** (si l'API cible l'exige).
• **Rotation Certificats :** Les certificats côté serveur (pour les appels AWS) sont gérés et rotatifs par AWS. Le développeur n'a pas à s'en soucier.

1.2. La Philosophie du “Serverless”

Le terme "Serverless" signifie que les tâches opérationnelles lourdes sont déplacées vers le fournisseur cloud (AWS), permettant aux développeurs de se concentrer sur la **logique métier (Business Logic)**.

• **Pas de Serveur à Provisionner :** AWS gère l'allocation des ressources de calcul au moment de l'invocation.
• **Zéro Maintenance Système :** Le patching de l'OS et des runtimes est la responsabilité d'AWS.
• **Pas de Scaling Manuel :** Le service s'adapte automatiquement à 1 ou 10 000 requêtes concurrentes (horizontal scaling).
• **Concentration sur le Code :** Le développeur s'occupe uniquement du code de la fonction et des configurations (mémoire, timeout).

Le Modèle d'Exécution (Event-Driven)

Lambda est un modèle piloté par les événements (Event-Driven). La fonction "dort" (coût zéro) et est réveillée par un **Trigger**.

                    # Représentation du Flux
                    (Événement/Trigger)  --->  (AWS Lambda Service)  --->  (Conteneur d'Exécution)
                    |
                    v
                    [ Votre Code ]
                

1.3. Les Langages (Runtimes) Supportés

Lambda fournit des **runtimes managés** pour les langages les plus populaires, ainsi que des options personnalisées pour les besoins spécifiques.

1.4. Cas d’Usage Typiques (Ubiquité de Lambda)

Lambda est la "colle" (Glue Code) du cloud AWS, utilisée pour lier les services entre eux ou pour créer des applications légères et scalables.

5.2. Gestion des Dépendances (Layers vs Bundling)

Comment gérer les "libs" (ex: pandas, numpy, Pillow) ?

Option 1 : Bundling / Packaging (ZIP)

C'est la méthode vue en 5.1. Vous "bundlez" (regroupez) le code ET les dépendances dans un seul fichier .zip.

• Limite : Le .zip décompressé ne doit pas dépasser 250 MB.
• Outils (IaC) : Des outils comme AWS SAM (sam build) ou Serverless Framework (sls package) automatisent ce "bundling" (le pip install -t ... et le zip) pour vous.

Option 2 : Lambda Layers (Couches)

(Recommandé pour les grosses libs) Une Layer est un .zip séparé (une "couche" du système de fichiers) que Lambda "monte" (attache) dans le dossier /opt de votre fonction au démarrage.

Structure (Python) : Votre .zip de Layer DOIT avoir cette arborescence :

                    (pandas_layer.zip)
                    └── python/
                    └── lib/
                    └── python3.12/
                    └── site-packages/
                    ├── pandas/
                    └── numpy/
                

Avantages :

• DRY (Don't Repeat Yourself) : Partagez une Layer (pandas-v1) entre 50 fonctions Lambda.
• Déploiement rapide : Votre code (app.py) ne pèse que 2KB (déploiement en 1s), même si la Layer pèse 200MB (car elle ne change pas).
• Versioning : Vous pouvez mettre à jour la Layer (pandas-v2) indépendamment du code de la fonction.

5.3. Variables d’Environnement

Permet de passer des configurations à votre code (os.environ.get('MA_VAR')) sans le "hardcoder".

• Usage (Paramétrage) : Idéal pour différencier les environnements.
  • Fonction (Dev) : TABLE_NAME = "users-dev"
  • Fonction (Staging) : TABLE_NAME = "users-staging"
  • Fonction (Prod) : TABLE_NAME = "users-prod"

Ne JAMAIS mettre de secrets (mots de passe) en clair !

Mauvaise Pratique : DB_PASSWORD = "Password123!". (Visible en clair par toute personne ayant accès "ReadOnly" à la console Lambda).

Bonne Pratique : Stocker les Secrets (SSM / Secrets Manager)

Stockez les secrets dans AWS Secrets Manager (pour les identifiants BDD/RDS) ou SSM Parameter Store (SecureString) (pour les clés d'API).

Flux de code (Bonne Pratique) :

1. Variable d'Env : SECRET_ARN = "arn:aws:secretsmanager:..."
2. Rôle IAM : Donnez à la Lambda la permission secretsmanager:GetSecretValue.
3. Code (Init) : Le code (Boto3) utilise le SECRET_ARN pour appeler l'API GetSecretValue et récupérer le mot de passe en mémoire au démarrage (Cold Start).

                    import boto3
                    import os

                    # (Phase INIT : Exécuté 1 fois au Cold Start)
                    SECRET_ARN = os.environ.get('SECRET_ARN')
                    client = boto3.client('secretsmanager')
                    response = client.get_secret_value(SecretId=SECRET_ARN)
                    DB_PASSWORD = response['SecretString'] # (Récupéré en mémoire)

                    def lambda_handler(event, context):
                    # (Phase INVOKE)
                    # Utilise DB_PASSWORD (déjà chargé) pour se connecter
                    conn = connect_to_db(DB_PASSWORD)
                    ...
                

5.4. Runtimes Gérés vs Images Conteneur

Ce sont les deux façons de packager (5.1) et d'exécuter (2.1) votre fonction.

Quand utiliser un Conteneur pour Lambda ?

Utilisez les Runtimes Gérés (.zip) par défaut. N'utilisez les Images Conteneur que si :

1. Votre package (Code + Dépendances) dépasse la limite de 250 MB.
2. Vous avez besoin de dépendances système (OS) (ex: apt-get, yum install) qui ne sont pas dans le runtime Amazon Linux 2 de base (ex: ffmpeg pour vidéo, tesseract pour OCR).
3. Vous avez un workload ML/IA (ex: PyTorch, TensorFlow) qui pèse plusieurs GB.
4. Vous voulez une consistance Dev/Prod absolue (l'image Docker locale est la même que sur AWS).

4.2. Invocations Directes (SDK / CLI)

Vous n'êtes pas obligé d'attendre un événement AWS. Vous pouvez appeler (invoquer) une fonction Lambda vous-même, depuis n'importe quel code (ex: Boto3) ou la CLI.

Invocation via SDK (Boto3 - Python)

Vous devez spécifier le InvocationType :

                    import boto3
                    import json

                    client = boto3.client('lambda')

                    # --- 1. Invocation SYNCHRONE (J'attends la réponse) ---
                    # (Bloquant, attend le 'return' de la fonction)
                    response_sync = client.invoke(
                    FunctionName='ma-fonction-prod',
                    InvocationType='RequestResponse', # (Défaut)
                    Payload=json.dumps({'key': 'value'})
                    )
                    print(json.loads(response_sync['Payload'].read()))
                    # Output: {'statusCode': 200, 'body': '...'}


                    # --- 2. Invocation ASYNCHRONE (Je n'attends pas) ---
                    # (Non-bloquant, "Fire-and-Forget")
                    response_async = client.invoke(
                    FunctionName='ma-fonction-batch',
                    InvocationType='Event',
                    Payload=json.dumps({'fichier': 'gros_fichier.csv'})
                    )
                    print(response_async['StatusCode'])
                    # Output: 202 (Accepted)
                

Invocation via AWS CLI

                    # Invoquer (Synchrone) et attendre la réponse (dans 'output.json')
                    aws lambda invoke \
                    --function-name ma-fonction-prod \
                    --payload '{"key": "value"}' \
                    output.json

                    # Invoquer (Asynchrone) et ne pas attendre
                    aws lambda invoke \
                    --function-name ma-fonction-batch \
                    --invocation-type Event \
                    --payload '{"fichier": "gros_fichier.csv"}' \
                    output.json
                    # (output.json sera vide, status 202)
                

4.3. Cas d'Usage par Déclencheur

1. S3 : Traitement de fichiers (Génération de vignettes)

L'architecture classique de traitement d'images (ou PDF, CSV, etc.).

• Trigger : s3:ObjectCreated:* sur le bucket uploads/.
• Rôle IAM : s3:GetObject (sur uploads/*), s3:PutObject (sur thumbnails/*).
• Code Lambda : (Python + Layer Pillow)
  1. Récupère le event['Records'][0]['s3']['object']['key'].
  2. Télécharge l'image (s3.download_file) vers /tmp/.
  3. Redimensionne l'image (Pillow.Image.thumbnail).
  4. Uploade le thumbnail (s3.upload_file) vers le bucket thumbnails/.

2. SQS : Worker Asynchrone (Découplage)

Idéal pour "découpler" une API (rapide) d'un traitement (lent) (ex: envoi d'email, génération de PDF).

                    (Client) -> [API GW] -> [Lambda (A) - Rapide] ---- (Envoi 1 message) ----> [📨 SQS Queue]
                    |
                    (Poll ESM)
                    |
                    [ 🔥 Lambda (B) - Lent ]
                    |
                    (Envoi Email SES)
                

Flux : Lambda (A) (API) ne fait que valider la donnée et l'envoyer à SQS (réponse en 50ms). Lambda (B) (le "Worker") prend le message de SQS (en batch) et prend (ex:) 5 secondes pour se connecter au SMTP (SES) et envoyer l'email. Le client (API) n'attend pas 5 secondes.

3. EventBridge (Scheduler) : Automatisation (Cron)

Remplace les "tâches cron" sur un serveur.

• Trigger : EventBridge Rule -> Schedule.
• Expression : cron(0 5 * * ? *) (Tous les jours à 5h00 UTC).
• Code Lambda : (Python + boto3)
  1. rds_client = boto3.client('rds')
  2. rds_client.create_db_snapshot(...) (Faire un backup de la BDD Prod).
  3. ec2_client = boto3.client('ec2')
  4. ec2_client.stop_instances(...) (Arrêter les EC2 de Dev pour la nuit).

4. API Gateway : Backend d'API / Microservice

Le pattern "Backend Serverless" (Full REST API).

• Trigger : API Gateway (HTTP API ou REST API).
• Route : GET /users/{id} -> Mappé (Intégration) vers Lambda:GetUserFunction.
• Code Lambda :
  1. Récupère l'ID : user_id = event['pathParameters']['id'].
  2. dynamo_client.get_item(Key={'PK': user_id}).
  3. return {'statusCode': 200, 'body': json.dumps(item)}.

3.2. Lambda + API Gateway (Backend API REST / HTTP)

C'est le pattern "Backend Serverless" le plus courant. Il remplace une architecture EC2 + Nginx + Django/Node.js.

                    (Client Web/Mobile)
                    |
                    (HTTP POST /users)
                    |
                    v
                    [ ☁️ API Gateway ]  --- (Route: "POST /users") ---> [ 🔥 Lambda (Fonction A) ]
                    |
                    (HTTP GET /users/123)
                    |
                    v
                    [ ☁️ API Gateway ]  --- (Route: "GET /users/{id}") --> [ 🔥 Lambda (Fonction B) ]
                

• API Gateway (Le "Routeur") : Gère les routes HTTP (/users, /products), le throttling (limitation de débit), les clés d'API, et (crucialement) l'authentification.
• Lambda (La "Logique Métier") : Gère une seule route (ex: create_user). Reçoit l'événement (HTTP JSON) et retourne une réponse (HTTP JSON).

Gestion de l'Authentification (par API GW)

• AWS Cognito : (Pour les clients/utilisateurs finaux) API GW vérifie le Token JWT (fourni par Cognito) avant de déclencher Lambda.
• AWS IAM : (Pour les services internes) API GW vérifie la Signature AWS (SigV4) (fournie par un autre service, ex: une EC2) avant de déclencher Lambda.
• Lambda Authorizer : (Custom) API GW appelle une 3ème Lambda (dédiée à l'auth) pour valider un token (ex: Auth0, OIDC custom) avant de déclencher la Lambda métier.

3.3. Lambda + S3 (Traitement Asynchrone)

Cas d'usage très fréquent pour le traitement de fichiers ("data processing"). L'invocation est asynchrone (S3 ne se soucie pas de si la Lambda réussit ou échoue).

Cas 1 : Traitement d'images (Thumbnails)

1. Trigger : s3:ObjectCreated:* sur Bucket-A (Filtre Préfixe: uploads/, Suffixe: .jpg).
2. Rôle IAM Lambda : Doit avoir s3:GetObject (sur Bucket-A) et s3:PutObject (sur Bucket-B).
3. Code Lambda (Python) :
   • Reçoit l'event (JSON) avec le nom du bucket/clé.
   • Utilise boto3.s3.download_file() (vers /tmp/).
   • Utilise une Layer (ex: Pillow) pour redimensionner l'image (image.thumbnail(...)).
   • Utilise boto3.s3.upload_file() (vers Bucket-B, clé thumbnails/image_thumb.jpg).

Cas 2 : Transcodage Vidéo / ETL

Une Lambda (max 15 min) est trop courte pour transcoder une vidéo de 2h ou un ETL de 3h.

Architecture (Orchestration) :

(S3 PUT video.mp4) -> (Trigger) -> [ 🔥 Lambda (A) ] -> (API Call) -> [ 🤖 AWS MediaConvert / AWS Glue (Job) ]

Ici, Lambda (A) ne fait que lancer (démarrer) le "gros" service (MediaConvert/Glue) qui, lui, va tourner 3h.

3.4. Lambda + DynamoDB / RDS (Couche Logique)

Lambda agissant comme la couche "software" (logique métier) devant la couche "données" (base de données).

Lambda en réaction à DynamoDB Streams

C'est le pattern "Change Data Capture (CDC)" ou "Chorégraphie de Microservices".

                    (Service A - Commande)
                    |
                    (Écrit dans Table "Orders")
                    |
                    (DynamoDB Stream) <-- (Un "journal" de tous les changements)
                    |
                    (Poll/Trigger ESM)
                    |
                    v
                    [ 🔥 Lambda (Service B - Notification) ]
                    |
                    v
                    [ ✉️ SES (Envoi Email Confirmation) ]
                    

Flux : Quand un item est INSERTED (Nouvelle commande) dans la table "Orders", le Stream (journal) capture cet événement. Le service Lambda (qui "écoute" ce stream) est invoqué et envoie l'email de confirmation. Le Service A (Commandes) est totalement découplé du Service B (Notifications).

Lambda + RDS (ex: PostgreSQL)

Le Piège du VPC : Une base RDS (ex: PostgreSQL) est (par bonne pratique) dans un Subnet Privé (sans accès Internet).

Pour que Lambda (ex: API GW) puisse parler à RDS, Lambda doit être "attachée" au même VPC (dans les Subnets Privés).

Conséquence : La Lambda (étant dans un Subnet Privé) perd son accès Internet par défaut. Si elle doit (aussi) appeler une API (ex: Stripe), elle aura besoin d'un NAT Gateway.

Le Piège des Connexions (RDS) : Si 1000 Lambdas (concurrentes) démarrent, elles tentent d'ouvrir 1000 connexions (psycopg2.connect()) à RDS, ce qui peut saturer (max_connections) la BDD.
Solution : Utiliser RDS Proxy (un "pooler" de connexion managé).

3.5. Orchestration (EventBridge & Step Functions)

Quand la logique devient complexe, Lambda seul ne suffit pas.

EventBridge (Le "Bus d'Événements" / Chorégraphie)

Permet un découplage "Many-to-Many". (Routage d'événements).

                    [Lambda (Service A)] -- (Événement "UserCreated") --> [ 🚌 EventBridge (Bus) ]
                    |
                    (Règle 1: source=User, detail=...)
                    |
                    v
                    [ 🔥 Lambda (Service B - Email) ]
                

Step Functions (L' "Orchestrateur" / Workflow)

Pour gérer des workflows longs (jusqu'à 1 an), avec état (stateful), retries, et logique complexe. (Évite le "Lambda Hell" : A->B->C).

Vous définissez le workflow en JSON (Amazon States Language) :

                    {
                    "StartAt": "ValiderCommande",
                    "States": {
                    "ValiderCommande": {
                    "Type": "Task",
                    "Resource": "arn:aws:lambda:...",
                    "Next": "ChoixPaiement"
                    },
                    "ChoixPaiement": {
                    "Type": "Choice",
                    "Choices": [
                    { "Variable": "$.type", "StringEquals": "CB", "Next": "PayerCB" },
                    { "Variable": "$.type", "StringEquals": "PayPal", "Next": "PayerPayPal" }
                    ]
                    },
                    "PayerCB": { ... (Appelle Lambda B) ... },
                    ...
                    }
                    }
                

Avantages : Gère l'état, les Try/Catch, les Retry (avec backoff) et les Wait (ex: "Attendre 3 jours") sans qu'une Lambda ne tourne (et ne soit facturée).

3.6. Patterns d'Architecture Fréquents

1. Fan-out (Éventail)

Un événement (Source) déclenche plusieurs traitements (Cibles) en parallèle.

Exemple (SNS Fan-out) :

                    [S3 (Upload Facture)]
                    |
                    v
                    [ 🔥 Lambda (A) - Analyse PDF ]
                    |
                    v
                    [ topic (SNS) "FactureAnalysée" ]
                    |
                    +--- (Subscription 1) ---> [ 🔥 Lambda (B) - Envoi Email Client ]
                    |
                    +--- (Subscription 2) ---> [ 🔥 Lambda (C) - Sauvegarde RDS (Compta) ]
                    |
                    +--- (Subscription 3) ---> [ 📨 SQS (File d'attente "Archivage") ]
                

2. Fan-in (Agrégation)

Opposé de Fan-out. Attendre que plusieurs traitements (parallèles) soient terminés avant de continuer (agréger).

Exemple (Step Functions) : C'est le pattern le plus complexe à gérer (état). Step Functions (3.5) le gère nativement avec l'état Parallel.

                    (Start)
                    |
                    (État "Parallel")
                    |
                    +--- (Branche A) ---> [ 🔥 Lambda (A) - Traite Vidéo 1080p ]
                    |
                    +--- (Branche B) ---> [ 🔥 Lambda (B) - Traite Vidéo 720p ]
                    |
                    +--- (Branche C) ---> [ 🔥 Lambda (C) - Traite Vidéo 360p ]
                    |
                    (Attend A, B, et C)
                    |
                    v
                    [ 🔥 Lambda (D) - Agréger & Notifier ]
                    |
                    (End)
                

3. Microservices "Serverless"

C'est la combinaison de tous ces patterns. Chaque "domaine métier" (ex: Commandes, Paiements, Utilisateurs) est un service indépendant, composé de :

• API (Interface) : API Gateway
• Logique (Métier) : Fonctions Lambda
• État (Base de données) : Table DynamoDB
• Communication (Événements) : EventBridge (Chorégraphie)

2.2. Le Modèle d'Invocation Événementielle

Une Lambda ne "tourne" pas. Elle est déclenchée (Triggered) par un Événement. Cet événement est un JSON (payload) qui est passé au paramètre event du handler.

Événements Déclencheurs (Triggers)

• API Gateway : (Expose la Lambda comme une API REST/HTTP).
• S3 : (ex: s3:ObjectCreated:* sur un bucket).
• SQS : (Traite les messages d'une file, en batch).
• EventBridge (Scheduler) : (ex: Un "Cron" tous les jours à 5h du matin).
• DynamoDB Streams : (ex: "Dès qu'un item est modifié dans cette table...").
• Kinesis, SNS, Cognito, ALB...

Invocation Synchrone vs Asynchrone

2.3. Le Contexte d'Exécution (Execution Context)

Le "Contexte d'Exécution" est le conteneur (basé sur Firecracker) que Lambda provisionne pour exécuter votre fonction. C'est cet environnement qui est "réchauffé" (Warm).

Phases (Init vs Invoke)

Comprendre ces deux phases est la clé pour optimiser les "Cold Starts" (2.4).

                    # (Code Python)

                    # -------- PHASE 1 : INIT (Démarrage à Froid) --------
                    # (Exécuté 1 SEULE FOIS, lors du Cold Start)
                    # (Facturation : Non facturé (max 10s))

                    import boto3
                    import pandas as pd

                    print("INIT: Démarrage du conteneur...")
                    # (Bonne pratique : Initialiser les clients/connexions ici)
                    s3_client = boto3.client('s3')
                    db_connection = ... # (Si hors VPC)

                    # --------------------------------------------------

                    # -------- PHASE 2 : INVOKE (Handler) --------
                    # (Exécuté À CHAQUE INVOCATION)
                    # (Facturation : Facturé à la milliseconde)

                    def lambda_handler(event, context):

                    # (Le 'context' est un objet AWS avec les métadonnées)
                    print(f"Request ID: {context.aws_request_id}")
                    print(f"Temps restant (ms): {context.get_remaining_time_in_millis()}")

                    # (Le code 'Init' (s3_client) est réutilisé ici)
                    response = s3_client.get_object(...)

                    return "OK"
                    # --------------------------------------------------
                

Réutilisation (Warm) : Si une 2ème invocation arrive rapidement, AWS réutilise ce conteneur. Il saute la phase "Init" (s3_client existe déjà) et exécute seulement la phase "Invoke" (lambda_handler).

2.4. Le "Cold Start" (Démarrage à Froid)

Définition : Un "Cold Start" est la latence (délai) subie lors de la première invocation, car AWS doit créer un Contexte d'Exécution (2.3) à partir de zéro.

Phases d'un Cold Start (Ce qui prend du temps)

1. (AWS) Allocation du conteneur Firecracker.
2. (AWS) Téléchargement du code (Image ECR ou .zip S3).
3. (AWS) Démarrage du Runtime (ex: Démarrage de la JVM pour Java, ou python3.12).
4. (Code Client) Exécution de la phase Init (2.3) (import pandas, boto3.client()...).
5. (Code Client) Exécution de la phase Invoke (lambda_handler).

Warm Start (Démarrage à Chaud)

Un "Warm Start" se produit si AWS réutilise un conteneur existant. Il saute les étapes 1 à 4 et exécute directement l'étape 5 (Invoke).

Impact sur la Latence (Varie énormément)

• Python / Node.js / Go : Cold Start très rapide (ex: 50ms - 300ms).
• Java / .NET (C#) : Cold Start très lent (ex: 2s - 10s) (à cause du démarrage de la JVM/CLR).
• Lambda dans un VPC (Avant 2019) : (Historique) Ajoutait 10-15 secondes (pour créer l'ENI). (Problème résolu par AWS Hyperplane).

Moyens de réduire les Cold Starts

• 1. Provisioned Concurrency (PC) : (La solution payante) Vous payez AWS (à l'heure) pour garder (ex:) 50 conteneurs "pré-chauffés" (Warm) 24/7, prêts à recevoir des requêtes (Invoke). (Pour API Web à faible latence).
• 2. Optimiser le code Init : Ne pas importer de librairies lourdes (pandas) si ce n'est pas nécessaire.
• 3. Augmenter la Mémoire : Plus de RAM = Plus de vCPU = Phase Init plus rapide. (Souvent, 2GB RAM est plus rapide que 512MB).
• 4. SnapStart (Java Uniquement) : AWS prend un "snapshot" (image) de la JVM (mémoire) après l'Init, permettant un redémarrage (Warm) quasi-instantané.

2.5. Limitations (Quotas) de Base

Lambda n'est pas fait pour tout (pas pour les calculs de 3 heures). Il a des limites (certaines "Hard", d'autres "Soft" (ajustables)).

AWS Lambda (Functions as a Service)

AWS Lambda est un service de calcul FaaS (Function-as-a-Service). Il exécute votre code (une "fonction") à la demande, en réponse à des événements (Triggers).

Modèle d'exécution (Stateless) :

1. La fonction "dort" (coût $0).
2. Un événement (Trigger) arrive (ex: un PUT sur S3, un appel API Gateway).
3. AWS "réveille" (ou crée) un conteneur d'exécution (c'est le Cold Start).
4. AWS exécute votre Handler (point d'entrée) en lui passant l'événement (JSON).
5. La fonction s'exécute (max 15 min).
6. La fonction retourne une réponse (ou pas).
7. Le conteneur "s'endort" (reste "Warm" quelques minutes) ou est détruit.

Stateless (Sans état) : Chaque invocation est (potentiellement) un nouveau conteneur. Vous ne devez jamais stocker d'état (ex: variables globales) entre deux invocations. L'état doit être persisté (ex: DynamoDB, S3, RDS).

Le "Handler" (Python)

C'est le point d'entrée de votre code. Il prend toujours 2 arguments :

                    # Fichier: app.py (Handler: "app.lambda_handler")

                    def lambda_handler(event, context):
                    """
                    :param event: (dict) Le JSON du Trigger (ex: infos S3, body API GW)
                    :param context: (object) Métadonnées d'exécution (Request ID, Log Group, Temps restant)
                    """

                    # 1. Log (va sur CloudWatch Logs)
                    print(f"Événement reçu: {event}")

                    # 2. Logique métier
                    message = "Traitement terminé."

                    # 3. Retour (crucial pour API GW, ignoré par S3)
                    return {
                    'statusCode': 200,
                    'body': message
                    }
                

Backend API (Web/Mobile)

C'est le cas d'usage le plus fréquent. Remplacer un serveur (EC2/Django/Node.js) par une API 100% serverless.

Architecture : (Client) -> (API Gateway) -> (Lambda) -> (DynamoDB/RDS)

Avantage : Scaling "infini" (gère 1 req/jour comme 1 million req/heure) et ne coûte rien (ou presque) si inutilisé.

Traitement de Données (Event-Driven)

Utiliser les événements AWS comme "déclencheurs" (Triggers).

• Traitement S3 (Images) : (Trigger: S3:ObjectCreated) -> Lambda se déclenche -> Crée un Thumbnail (Pillow) -> Sauvegarde sur S3 (autre bucket).
• Traitement S3 (Logs/CSV) : (Trigger: S3:ObjectCreated) -> Lambda se déclenche -> Lit le CSV (Pandas) -> Insère les lignes dans RDS/DynamoDB.
• File SQS (Découplage) : (Trigger: SQS Message) -> Lambda "dépile" les messages (un par un ou en batch) pour un traitement asynchrone (ex: envoi d'emails).
• EventBridge (Bus d'Événements) : (Trigger: EventBridge Rule) -> Déclencher une Lambda quand (par ex:) une instance EC2 change d'état (EC2 State Change).

Automatisation (Ops / DevOps)

Remplacer les scripts cron ou bash sur un serveur d'admin.

• "Cron" (Scheduler) : (Trigger: EventBridge Scheduler (Cron)) -> Lambda (tous les matins à 4h) -> Fait un Snapshot (boto3) des volumes EBS (backup).
• "Glue Code" : (Trigger: Alerte CloudWatch) -> Lambda se déclenche -> Envoie une notification (requests) sur Slack/Teams.