Simple Enough Blog logo
  • Home 
  • Projets 
  • Tags 

  •  Langage
    • English
    • Français
  1.   Blogs
  1. Accueil
  2. Blogs
  3. Introduction à AWS Lambda : le guide complet pour débutants et développeurs

Introduction à AWS Lambda : le guide complet pour débutants et développeurs

Posté le 23 mars 2026 • 6 min de lecture • 1 258 mots
CICD   Devops   Organisation   Helene  
CICD   Devops   Organisation   Helene  
Partager via
Simple Enough Blog
Lien copié dans le presse-papier

AWS Lambda est souvent l’un des premiers services que l’on découvre quand on s’intéresse au serverless sur AWS. Et pour cause : la promesse est très séduisante.

Sur cette page
I. C’est quoi AWS Lambda ?   II. Comment ça fonctionne ?   1. Le déclencheur (trigger)   2. La fonction   3. L’exécution   III. Schéma d’architecture   IV. Ton premier handler Lambda en Go   Prérequis   Structure d’un handler   Compilation et déploiement   Test de la fonction   V. Cas d’usage concrets   1. API REST légère   2. Traitement de fichiers à l’upload   3. Automatisation et tâches planifiées   4. Traitement de messages   5. Lambda@Edge   VI. Les limites à connaître   Le cold start   Lambda est adapté quand :   VII. Tarification : ce que on paie vraiment   Conclusion   🔗 Liens utiles  
Introduction à AWS Lambda : le guide complet pour débutants et développeurs
Photo par Helene Hemmerter

I. C’est quoi AWS Lambda ?  

AWS Lambda est un service de calcul serverless lancé par Amazon en 2014. L’idée est simple : on fournit une fonction (un morceau de code), et AWS l’exécute à la demande, sans qu’on aie à gérer le moindre serveur. Vous n’avez pas de serveur à provisionner, pas d’OS à maintenir, pas d’autoscaling à configurer à la main.

Le mot serverless peut prêter à confusion — des serveurs, il y en a bien sûr. Sauf qu’ils sont entièrement gérés par AWS. Nous ne voyons que le code.

Lambda supporte de nombreux langages : Go, Python, Node.js, Java, Ruby, .NET, et même des runtimes personnalisés via l’API Lambda Runtime.


II. Comment ça fonctionne ?  

Le modèle de fonctionnement de Lambda repose sur trois éléments :

1. Le déclencheur (trigger)  

Lambda ne tourne pas en permanence. Il est déclenché par un événement. Cet événement peut venir de nombreuses sources AWS :

SourceExemple
API GatewayUn appel HTTP GET /users
S3Un fichier uploadé dans un bucket
SQS / SNSUn message posté dans une queue
EventBridgeUn événement planifié (cron)
DynamoDB StreamsUne modification dans une table
CloudFrontLambda@Edge pour manipuler les requêtes

2. La fonction  

C’est le code. Il reçoit un événement (les données du déclencheur) et un contexte (les métadonnées d’exécution : ID de requête, timeout restant, etc.).

3. L’exécution  

AWS alloue un environnement d’exécution (CPU + RAM), exécute une fonction, puis libère les ressources. Si plusieurs requêtes arrivent en même temps, Lambda scale horizontalement et crée plusieurs instances en parallèle — automatiquement.


III. Schéma d’architecture  

Voici un exemple d’architecture classique : une API REST serverless avec Lambda au centre.

┌─────────────┐        ┌─────────────────┐        ┌──────────────┐
│   Client    │──────▶ │   API Gateway   │──────▶ │ AWS Lambda   │
│ (navigateur │  HTTPS │  (point d'entrée│  event │  (ta logique │
│  ou mobile) │        │   HTTP/REST)    │        │   métier)    │
└─────────────┘        └─────────────────┘        └──────┬───────┘
                                                         │
                              ┌──────────────────────────┤
                              │                          │
                     ┌────────▼──────┐        ┌─────────▼──────┐
                     │   DynamoDB    │        │      S3        │
                     │  (données)    │        │  (fichiers)    │
                     └───────────────┘        └────────────────┘

Ce pattern — API Gateway + Lambda + DynamoDB — est l’une des architectures serverless les plus répandues sur AWS. Elle est scalable, économique pour les workloads irréguliers, et ne nécessite aucun serveur à maintenir.


IV. Ton premier handler Lambda en Go  

Prérequis  

  • Go 1.21+
  • AWS CLI configuré
  • Le package github.com/aws/aws-lambda-go

Structure d’un handler  

package main

import (
    "context"
    "fmt"

    "github.com/aws/aws-lambda-go/lambda"
)

// Event représente la structure de l'événement entrant
type Event struct {
    Name string `json:"name"`
}

// Response est la structure retournée par la fonction
type Response struct {
    Message string `json:"message"`
}

// Handler est la fonction principale exécutée par Lambda
func Handler(ctx context.Context, event Event) (Response, error) {
    if event.Name == "" {
        event.Name = "monde"
    }
    return Response{
        Message: fmt.Sprintf("Bonjour, %s ! Tu es sur AWS Lambda.", event.Name),
    }, nil
}

func main() {
    lambda.Start(Handler)
}

Compilation et déploiement  

Lambda sur Go nécessite un binaire compilé pour Linux/amd64 (ou arm64 si on utilise Graviton) :

# Compilation pour Linux
GOOS=linux GOARCH=amd64 go build -o bootstrap main.go

# Création du zip de déploiement
zip function.zip bootstrap

# Déploiement via AWS CLI
aws lambda create-function \
  --function-name ma-premiere-lambda \
  --runtime provided.al2 \
  --handler bootstrap \
  --role arn:aws:iam::123456789012:role/lambda-role \
  --zip-file fileb://function.zip

Note : depuis Go 1.18, AWS recommande d’utiliser le runtime provided.al2 (Amazon Linux 2) avec un binaire nommé bootstrap.

Test de la fonction  

aws lambda invoke \
  --function-name ma-premiere-lambda \
  --payload '{"name": "Alice"}' \
  response.json

cat response.json
# {"message":"Bonjour, Alice ! Tu es sur AWS Lambda."}

V. Cas d’usage concrets  

1. API REST légère  

C’est l’usage le plus courant. Couplé à API Gateway, Lambda permet de créer des endpoints HTTP sans gérer de serveur web. Idéal pour les microservices ou les backends mobiles.

2. Traitement de fichiers à l’upload  

Un utilisateur uploade une image dans S3 → Lambda se déclenche automatiquement → redimensionne l’image → stocke les versions dans un autre bucket. Zéro polling, zéro serveur idle.

S3 (upload) ──▶ Lambda (resize) ──▶ S3 (versions)

3. Automatisation et tâches planifiées  

Avec EventBridge Scheduler, on déclenche une Lambda à intervalles réguliers : nettoyage de base de données, envoi de rapports, synchronisation de données. L’équivalent serverless d’un cron job.

4. Traitement de messages  

Couplé à SQS, Lambda consomme les messages d’une queue de façon asynchrone et scalable. Parfait pour les pipelines de traitement de données ou les systèmes d’événements.

5. Lambda@Edge  

Lambda@Edge est une extension d’AWS Lambda qui permet d’exécuter du code à proximité des utilisateurs finaux via le réseau de diffusion de contenu Amazon CloudFront. Lambda peut s’exécuter directement dans les Points of Presence CloudFront, au plus proche de l’utilisateur. Cas d’usage : redirection A/B testing, manipulation des headers HTTP, authentification à la périphérie.


VI. Les limites à connaître  

Lambda est puissant, mais il a des contraintes à anticiper dès la conception :

LimiteValeur
Durée maximale d’exécution15 minutes
Mémoire allouable128 MB à 10 240 MB
Taille du package de déploiement50 MB (zip), 250 MB (décompressé)
Espace disque temporaire (/tmp)512 MB (jusqu’à 10 GB configurable)
Concurrence par défaut1 000 exécutions simultanées par région

Le cold start  

Lorsque Lambda crée une nouvelle instance (après une période d’inactivité ou pour scaler), il y a un temps d’initialisation appelé cold start. En Go, ce cold start est particulièrement faible (< 100ms en général), ce qui en fait un excellent choix pour Lambda.

Pour les applications sensibles à la latence, tu peux utiliser les Provisioned Concurrency pour maintenir des instances “chaudes” en permanence.

Lambda est adapté quand :  

  • le traitement est piloté par événements
  • l’exécution est courte ou modérée
  • la charge est variable
  • on veut aller vite
  • on cherche à réduire l’exploitation serveur
  • on veut découpler une architecture

C’est aussi un très bon outil pour des petites briques très ciblées, même dans des architectures qui ne sont pas entièrement serverless.


VII. Tarification : ce que on paie vraiment  

Lambda facture sur deux dimensions :

  • Le nombre de requêtes : 0,20 $ par million d’invocations (les 1 premiers millions sont gratuits chaque mois)
  • La durée d’exécution : calculée en GB-secondes (mémoire allouée × temps d’exécution)

Exemple concret : une fonction de 128 MB qui s’exécute en 200ms, appelée 5 millions de fois par mois :

Requêtes : (5M - 1M gratuit) × 0,20$ / 1M = 0,80$
Durée    : 5M × 0,2s × 0,128 GB × 0,0000166667$/GB-s ≈ 2,13$
Total    : ~2,93$ / mois

Pour des workloads irréguliers ou faible volume, Lambda est souvent bien moins cher qu’une instance EC2 qui tourne 24h/24.


Conclusion  

AWS Lambda a changé la façon de concevoir les architectures cloud. En éliminant la gestion des serveurs, il permet de se concentrer sur la logique métier, de scaler sans effort, et de ne payer que ce qu’on consomme réellement.

Ce qu’on a vu dans cet article :

  • Lambda est déclenché par des événements provenant de nombreux services AWS
  • En Go, le cold start est minimal et les performances sont excellentes
  • L’architecture API Gateway + Lambda + DynamoDB est un pattern éprouvé
  • Lambda convient parfaitement aux workloads irréguliers, aux traitements asynchrones et aux APIs légères
  • Les limites (15 min max, cold start) orientent les choix d’architecture

Lambda n’est pas la solution universelle — pour des traitements longs, des applications avec état complexe, ou des workloads constants à forte charge, EC2 ou ECS/Fargate seront souvent plus adaptés. Mais pour démarrer vite, scaler facilement et garder les coûts sous contrôle, c’est un outil redoutable.


🔗 Liens utiles  

  • AWS lambda
 Nx n’est pas un outil JavaScript : c’est un orchestrateur de travail
Pourquoi le cache Docker est insuffisant pour un monorepo ? 
  • I. C’est quoi AWS Lambda ?  
  • II. Comment ça fonctionne ?  
  • III. Schéma d’architecture  
  • IV. Ton premier handler Lambda en Go  
  • V. Cas d’usage concrets  
  • VI. Les limites à connaître  
  • VII. Tarification : ce que on paie vraiment  
  • Conclusion  
  • 🔗 Liens utiles  
Suivez-nous

Nous travaillons avec vous !

   
Copyright © 2026 Simple Enough Blog Tous droits réservés. | Propulsé par Hinode.
Simple Enough Blog
Code copié dans le presse-papier