AWS Lambda vs ECS Fargate : guide de choix selon vos besoins

Deux approches "serverless", deux modèles radicalement différents

AWS Lambda et ECS Fargate sont tous deux qualifiés de "serverless" — vous ne gérez pas les serveurs sous-jacents. Mais leurs modèles d'exécution sont fondamentalement différents, et confondre les deux mène à des architectures sous-optimales, voire coûteuses. Ce guide vous donne les critères de décision que nous utilisons avec nos clients.

AWS Lambda : function-as-a-service

Lambda exécute votre code en réponse à des événements dans un environnement éphémère. Chaque invocation est indépendante. Les caractéristiques clés :

• Durée maximale : 15 minutes par invocation (hard limit, non modifiable)
• Mémoire : 128 MB à 10 GB (le CPU est alloué proportionnellement à la mémoire)
• Stockage éphémère : /tmp jusqu'à 10 GB (512 MB par défaut, augmentable payant)
• Cold starts : 50 ms à 2 s selon le runtime — Python/Node rapides, Java lent sans SnapStart
• Déclencheurs natifs : S3, SQS, SNS, DynamoDB Streams, API Gateway, EventBridge, Kinesis — Lambda est le cœur de l'architecture event-driven AWS
• Concurrence : 1 000 exécutions simultanées par défaut (augmentable à 10 000+)

ECS Fargate : container-as-a-service

Fargate exécute vos conteneurs Docker dans des environnements gérés sans que vous provisioniez d'instances EC2. La tâche démarre une fois et reste active pour servir de multiples requêtes :

• Durée : illimitée — les processus long-running (ML inference, WebSockets, traitement batch) sont natifs
• Ressources : 0,25 à 16 vCPU, 512 MB à 120 GB RAM par tâche
• Réseau : intégration native ALB/NLB, VPC complet, Security Groups, connexions persistantes à la base de données
• Runtime : n'importe quel langage, n'importe quelle bibliothèque système — total liberté
• Démarrage : 30 à 60 secondes pour démarrer une nouvelle tâche (vs quelques millisecondes pour Lambda)

Tableau comparatif — 10 critères

Critère	Lambda	ECS Fargate
Durée d'exécution	Max 15 min	Illimitée
Cold start	50ms–2s	30–60s (démarrage tâche)
Mémoire max	10 GB	120 GB
Réseau	VPC optionnel	VPC natif
Dev local	SAM CLI (complexe)	docker-compose (simple)
Modèle de coût	Par invocation	Par heure
Vitesse de scale-out	Immédiate (millisecondes)	30–90s (nouvelle tâche)
Connexions persistantes	Non (RDS Proxy requis)	Oui (natif)
Runtime personnalisé	Limité (layers)	Total (Docker)
Vendor lock-in	Élevé	Modéré (Docker standard)

Quand choisir Lambda

Lambda est le meilleur choix dans ces scénarios :

• Traitement événementiel : upload S3 → redimensionnement d'image, message SQS → traitement commande, EventBridge → orchestration de workflow
• Trafic variable ou sporadique : un webhook qui reçoit 0 requêtes la nuit et 500/seconde lors d'une campagne — Lambda scale de 0 à 500 instantanément
• Exécution courte : tâches inférieures à 5 minutes (validation, transformation, notification)
• Intégrations AWS natives : si votre application consomme intensément S3, DynamoDB, SQS, Kinesis — Lambda s'intègre nativement avec une configuration minimale
• Faible volume : moins de 3 millions de requêtes par mois à 512 MB — Lambda sera moins cher que n'importe quelle configuration Fargate

Quand choisir ECS Fargate

• Processus long-running : tâches batch de plusieurs heures, serveurs d'inférence ML actifs en permanence, jobs ETL volumineux
• WebSockets et gRPC : connexions longue durée incompatibles avec le modèle Lambda (timeout 15 min, pas de connexions persistantes)
• Mémoire supérieure à 10 GB : Lambda est limité à 10 GB ; Fargate monte à 120 GB par tâche
• Trafic continu prévisible : une API qui reçoit 50 req/s en permanence — Fargate avec Savings Plans sera plus économique que Lambda
• Images Docker existantes : si vous avez déjà une image Docker bien optimisée, Fargate vous évite de réécrire le code en fonctions Lambda

Analyse de coût : point d'inflexion

Pour un workload typique (512 MB de RAM, 500 ms de durée moyenne), le point d'inflexion où Fargate devient moins cher que Lambda se situe autour de 3 millions d'invocations par mois pour du trafic soutenu :

# Lambda (512 MB, 500ms, 3M invocations/mois)
Compute  : 3M × 0.5s × 0.0000000083 $/GB-s × 0.5 = 0.62 $
Requêtes : 3M × 0.0000002 $                       = 0.60 $
Total Lambda : ~1.22 $/mois

# Fargate (0.25 vCPU, 0.5 GB, 1 tâche 24h/24)
vCPU    : 0.25 × 0.04048 $/h × 730h = 7.39 $
Mémoire : 0.5  × 0.004445 $/h × 730h = 1.62 $
Total Fargate : ~9.01 $/mois

→ Lambda 7x moins cher pour 3M req/mois sporadiques

# Si le trafic est continu (3M req/mois = ~1.15 req/s en continu)
# Lambda reste moins cher jusqu'à ~30M req/mois à ce niveau de ressources
# Au-delà, Fargate Savings Plans (1 an) : -20% sur le compute
# Fargate devient compétitif à partir de ~50M req/mois

Lambda avec des images conteneurs : le meilleur des deux mondes

Depuis 2020, Lambda supporte les images de conteneurs ECR jusqu'à 10 GB. Cela permet de déployer des dépendances système complexes (ffmpeg, pandoc, bibliothèques ML) tout en conservant le modèle de facturation Lambda. C'est souvent la solution optimale pour les fonctions avec des dépendances lourdes :

# Dockerfile pour Lambda avec image conteneur
FROM public.ecr.aws/lambda/python:3.12

# Installer des dépendances système (impossible avec Lambda ZIP classique)
RUN dnf install -y ffmpeg     && dnf clean all

COPY requirements.txt .
RUN pip install -r requirements.txt --no-cache-dir

COPY src/ ${LAMBDA_TASK_ROOT}/

CMD ["handler.lambda_handler"]

# Build et push vers ECR
aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_URI
docker build -t my-lambda .
docker tag my-lambda:latest $ECR_URI/my-lambda:latest
docker push $ECR_URI/my-lambda:latest

Architecture pratique : Lambda + Fargate ensemble

Dans la plupart des architectures modernes, Lambda et Fargate jouent des rôles complémentaires :

# Architecture typique d'une application SaaS

API Gateway → ECS Fargate (API REST synchrone, 200 req/s)
              └── RDS PostgreSQL (connexions persistantes via pool)

S3 Events   → Lambda (traitement asynchrone des fichiers uploadés)
SQS Queue   → Lambda (traitement des jobs en file d'attente)
EventBridge → Lambda (orchestration cron et workflows)

ECS Fargate → tâches batch nocturnes (scheduled tasks, durée 2h+)
ECS Fargate → service WebSocket (chat temps réel, connexions longues)

Exemple Terraform : Lambda + ECS Task Definition

# Lambda function avec rôle IAM minimal
resource "aws_lambda_function" "order_processor" {
  function_name = "order-processor"
  runtime       = "python3.12"
  handler       = "handler.lambda_handler"
  filename      = "function.zip"
  timeout       = 300  # 5 minutes
  memory_size   = 512

  role = aws_iam_role.lambda_exec.arn

  environment {
    variables = {
      TABLE_NAME = aws_dynamodb_table.orders.name
      QUEUE_URL  = aws_sqs_queue.notifications.url
    }
  }
}

# ECS Task Definition pour l'API principale
resource "aws_ecs_task_definition" "api" {
  family                   = "api-production"
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu                      = "512"   # 0.5 vCPU
  memory                   = "1024"  # 1 GB

  execution_role_arn = aws_iam_role.ecs_execution.arn
  task_role_arn      = aws_iam_role.ecs_task.arn

  container_definitions = jsonencode([{
    name      = "api"
    image     = "${aws_ecr_repository.api.repository_url}:latest"
    essential = true
    portMappings = [{
      containerPort = 8080
      protocol      = "tcp"
    }]
    logConfiguration = {
      logDriver = "awslogs"
      options = {
        "awslogs-group"  = "/ecs/api-production"
        "awslogs-region" = "eu-west-1"
        "awslogs-stream-prefix" = "api"
      }
    }
  }])
}

Conclusion

Il n'existe pas de "meilleur" service entre Lambda et ECS Fargate — il existe le service adapté au contexte. Lambda pour les événements courts, sporadiques et les intégrations AWS natives. Fargate pour les processus longs, les connexions persistantes et les workloads à trafic soutenu. La grande majorité des architectures de production modernes utilisent les deux : Lambda gère les événements et les webhooks, Fargate porte les APIs synchrones critiques et les workers long-running. Adoptez cette complémentarité plutôt que de forcer un seul paradigme sur toute l'application.