← Retour aux ressources
// architecture · compute

EC2, ECS ou Lambda : comment je choisis

La question revient à chaque projet, et la mauvaise réponse coûte cher — en argent ou en nuits blanches. Voici l'arbre de décision que j'utilise, basé sur la charge, le budget et la taille de l'équipe, pas sur la mode.

Technique15 juil. 2026~8 min · intermédiaire
EC2ECS/FargateLambdaDockerauto-scaling
// sommaire
01Les trois modèles02L'arbre de décision03À quoi ça ressemble04Les pièges de coût05Lambda de près : cold starts, concurrence, 15 min06Fargate ou EC2 : où la courbe se croise99Sources & ressources
01

Les trois modèles

Ce sont trois niveaux d'abstraction. Plus tu montes, moins tu gères de serveur — mais moins tu contrôles, et le modèle de coût change du tout au tout.

EC2une machine à toi. Contrôle total, tu gères l’OS. Coût : à l’heure, allumée ou non.
ECS/Fargateton conteneur, sans machine à gérer. Coût : vCPU + RAM × durée.
Lambdajuste ta fonction. Zéro serveur, scale à zéro. Coût : à la milliseconde.
02

L'arbre de décision

Je me pose trois questions, dans cet ordre.

01
Le trafic est-il intermittent ?

Événementiel, en pics rares, ou proche de zéro la plupart du temps → Lambda. Tu ne paies rien quand ça dort.

02
Charge constante et conteneurisée ?

Une API qui tourne 24/7, déjà en Docker, plusieurs services → ECS/Fargate. Le juste milieu.

03
Besoin de contrôle fin ?

PHP historique, GPU, config système précise, ou tu veux le coût le plus bas à charge stable → EC2.

04
Petite équipe ?

Moins tu es nombreux, plus tu montes en abstraction : laisse AWS gérer les machines pour toi.

03

À quoi ça ressemble

Lambda — une fonction

handler.tscopier
// Lambda : le code, zero serveur a gerer
export async function handler(event) {
  return { statusCode: 200, body: "hello" };
}
// tu paies a la milliseconde d'execution. A l'arret : 0.

ECS/Fargate — un conteneur

Dockerfilecopier
# ECS/Fargate : ton conteneur, sans gerer de machine
FROM node:20-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]
# Fargate lance ce conteneur ; tu paies vCPU + RAM x duree
i

Pour EC2, le déploiement est celui de mes guides Langfuse et e-commerce : machine, reverse proxy, HTTPS, pm2 ou Docker.

04

Les pièges de coût

Lambda coûte cher quand…
le trafic devient constant et élevé
les fonctions sont longues (>1s)
les cold starts gênent la latence
EC2 coûte cher quand…
la machine tourne à vide la nuit
personne ne fait le rightsizing
le trafic est très irrégulier
!

Il n'y a pas de gagnant absolu : le bon choix dépend de ta courbe de trafic. En cas de doute sur une charge stable, ECS/Fargate est rarement un mauvais pari.

05

Lambda de près : cold starts, concurrence, 15 min

L'arbre plus haut dit « trafic intermittent → Lambda », mais avant de tout y mettre il faut connaître trois murs que je heurte régulièrement en production. Ce sont eux qui décident si Lambda tient la charge ou pas.

01
Le mur des 15 minutes

Une invocation ne peut pas dépasser 900 secondes, c'est un plafond dur non négociable, avec au maximum 10 240 MB de RAM ([quotas Lambda](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)). Un batch qui dépasse → tu découpes, tu passes en Step Functions, ou tu bascules la tâche sur Fargate.

02
Le mur de la concurrence

Par défaut, 1 000 exécutions simultanées pour tout ton compte dans une région, partagées entre toutes tes fonctions ([function scaling](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html)). Au-delà, throttling : les requêtes tombent. C'est augmentable, mais il faut le demander — et penser à la reserved concurrency pour protéger tes fonctions critiques.

03
Le mur du cold start

Quand aucun environnement chaud n'est dispo, Lambda en initialise un neuf : c'est le cold start, quelques centaines de ms à plusieurs secondes selon le runtime et tes dépendances. Gênant sur une API user-facing, invisible sur du batch.

Deux façons de tuer le cold start

SnapStart — gratuit

Java, Python 3.12+, .NET 8+

snapshot Firecracker de l'env initialisé, restauré à chaud
jusqu’à un démarrage sub-seconde, sans surcoût
attention à l'unicité d'état (seeds, connexions) — [doc SnapStart](https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html)
Provisioned concurrency — payant

tous les runtimes

N environnements pré-initialisés, réponse en ms
zéro cold start tant que tu restes sous le seuil
tu paies pour les garder chauds, même à vide
i

Ma règle : SnapStart d'abord quand le runtime le supporte (c'est gratuit), provisioned concurrency seulement si j'ai un SLA de latence strict que SnapStart ne tient pas. Et si les fonctions tournent longtemps ou en continu, je relis l'arbre — souvent c'est le signe qu'il faut passer sur ECS.

06

Fargate ou EC2 : où la courbe se croise

Une fois que tu as choisi les conteneurs, reste le sous-choix : Fargate (AWS gère les machines) ou launch type EC2 (tu gères ta flotte sous ECS). Ce n'est pas religieux, c'est une histoire de taux d'utilisation.

Fargatetu paies exactement le vCPU + RAM de chaque tâche, zéro machine à patcher. Gagnant à faible utilisation ou charge en dents de scie.
EC2 launch typetu bin-packes plusieurs tâches sur tes instances et tu appliques Savings Plans / Spot. Gagnant quand tes instances tournent bien remplies.

Le blog AWS Fargate vs EC2 chiffre le croisement : à faible taux de réservation, Fargate peut être jusqu'à ~87 % moins cher qu'une instance sous-utilisée ; à pleine charge, l'EC2 launch type repasse devant avec plus de 20 % d'économie. Le point de bascule, c'est ta capacité à remplir tes instances.

Le chemin que suivent la plupart des apps

Début : une Lambda ou une tâche Fargate. Zéro ops, tu paies ce que tu consommes, tu shippes.
Croissance : le trafic se stabilise, la facture Fargate monte — tu ajoutes des Savings Plans, toujours sans gérer de serveur.
Échelle : plusieurs services tournent 24/7 et bien remplis. Là seulement, l'EC2 launch type (ou EC2 nu pour du GPU / config fine) devient rentable, au prix de l'ops.
✓

Beaucoup d'équipes finissent en mixte : Fargate pour les services en pics ou peu utilisés, EC2 pour le cœur stable qui justifie un Savings Plan. Tu n'es jamais obligé de choisir un seul launch type pour tout le cluster.

99

Sources & ressources

Ne choisis pas par hype. Trafic intermittent → Lambda ; charge stable conteneurisée → ECS ; contrôle fin ou coût plancher → EC2. Et quel que soit le choix, surveille la facture : le mauvais modèle se voit d'abord là.