Lambda pour les charges irrégulières, événementielles et courtes ; Fargate pour les services de longue durée à concurrence stable. Pour la plupart des workloads, cette phrase clôt le débat en une minute. Les cas difficiles vivent dans la zone grise : des API au trafic modéré mais constant, des jobs qui frôlent le plafond des 15 minutes, des fonctions devenues des monolithes sans que personne ne l'ait décidé. Cet article traite précisément de la frontière conteneur contre fonction ; pour la question plus large de quitter les serveurs, voyez notre guide Lambda contre serveurs.
Où Lambda gagne-t-il d'office ?
Lambda gagne quand le trafic est irrégulier ou imprévisible, quand le travail arrive sous forme d'événements discrets, quand chaque requête doit être isolée de ses voisines, et quand vous voulez une charge d'exploitation proche de zéro. Il passe de rien à des milliers d'exécutions concurrentes sans plan de capacité, et ne coûte rien au repos.
L'adéquation événementielle est structurelle, pas cosmétique. Dépôts S3, lots SQS, règles EventBridge et streams DynamoDB se branchent nativement sur des fonctions, avec relances et regroupement gérés par la plateforme. L'isolation par requête limite aussi le rayon d'impact : un message empoisonné ou une fuite mémoire emporte un environnement d'exécution, pas un processus partagé qui sert des centaines de connexions. Si votre charge est un ensemble de réactions courtes et indépendantes à des événements, Lambda n'est pas seulement moins cher à faible volume : c'est moins de code et moins de pièces mobiles à exploiter.
Où Fargate gagne-t-il d'office ?
Fargate gagne pour les processus de longue durée, la concurrence stable, les WebSockets et tout ce qui garde des connexions ouvertes, les jobs qui dépassent 15 minutes, et les gabarits de ressources que Lambda ne sait pas exprimer. Un conteneur qui exige beaucoup de vCPU avec peu de mémoire n'a qu'un seul foyer serverless : une tâche Fargate.
Lambda lie CPU et mémoire sur un seul curseur et plafonne l'exécution à 900 secondes, limites documentées dans la page des quotas Lambda. Fargate laisse choisir vCPU et mémoire indépendamment, aujourd'hui jusqu'à plus de dix vCPU et environ un ordre de grandeur de mémoire en plus que Lambda. La taille d'image est aussi plus libre : pas de jonglage de layers, juste un conteneur tiré de votre registre, comme décrit dans la documentation Fargate. Les pools de workers qui vident une file à rythme constant toute la journée sont le cas d'école.
À quoi ressemble une Lambda qui veut devenir un conteneur ?
Le signe annonciateur de migration : une fonction configurée avec un timeout de 900 secondes, une pile de layers qui se bat contre le modèle de packaging, et un routeur interne qui distribue des dizaines de routes dans un seul handler. C'est un runtime de conteneur réimplémenté au-dessus d'une plateforme de fonctions, et il hérite des contraintes des deux.
Autres symptômes que nous recherchons : de l'état passé en contrebande via /tmp entre invocations, une concurrence provisionnée montée si haut que la facture ressemble de toute façon à un serveur, et des acrobaties d'orchestration pour enchaîner des invocations au-delà de la limite de durée. Rien de tout cela n'est un bug : ce sont des signaux que la forme naturelle de la charge est un processus, pas une réaction. La déplacer dans un conteneur sur Fargate supprime généralement du code : le routeur, la gymnastique de timeout et la gestion des layers disparaissent.
Coincé dans la zone grise avec une Lambda qui bute sur ses limites ? Décrivez votre système : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →Comment les formes de coût se croisent-elles ?
Lambda facture à la requête plus une unité de mémoire-temps pendant que votre code s'exécute réellement, et rien au repos. Fargate facture au vCPU-heure et au Go-heure tant que la tâche existe, qu'elle serve du trafic ou non. Le point de bascule dépend donc de l'utilisation soutenue.
Une fonction occupée la majeure partie de chaque heure paie le tarif premium à la milliseconde de Lambda sur presque toute l'heure ; à ce stade, une tâche facturée selon la forme horaire de Fargate tend à l'emporter. Une charge inactive 95 % du temps inverse complètement la logique. L'endroit exact où passe la ligne dépend de la mémoire configurée, de la région, de l'architecture et des remises : nous refaisons le calcul par workload sur les pages officielles de tarification Lambda et de tarification Fargate plutôt que de nous fier à des règles toutes faites.
Démarrage à froid contre démarrage de tâche : quel écart ?
Environ un ordre de grandeur, et l'impact ne tombe pas au même endroit. Un démarrage à froid Lambda coûte typiquement entre quelques dizaines de millisecondes et quelques secondes, payées sur le chemin de la requête. Un démarrage de tâche Fargate, téléchargement d'image compris, prend couramment des dizaines de secondes, parfois des minutes.
La conséquence compte plus que les chiffres, qui varient selon le runtime, la taille d'image et la région. Lambda absorbe une rafale de trafic en quelques secondes mais fait attendre certaines requêtes ; la montée en charge de Fargate est trop lente pour courir après un pic, il faut donc garder de la marge, c'est-à-dire exactement la capacité permanente que vous vouliez éviter. Si les démarrages à froid sont votre principale objection à Lambda, ils se corrigent souvent avant de justifier une migration : notre guide pour garder vos fonctions Lambda chaudes passe les options en revue.
Le choix change-t-il votre porte d'entrée ?
Rarement, et cela vaut la peine d'en profiter. Fonctions Lambda et tâches Fargate s'enregistrent derrière le même Application Load Balancer comme target groups, consomment les mêmes files SQS et s'abonnent aux mêmes bus EventBridge. La couche de trafic n'est pas l'objet de cette décision.
Cette symétrie rend la zone grise moins intimidante. Gardez des handlers minces, gardez la logique métier dans des modules ordinaires, et le coût d'une erreur se réduit au packaging et au câblage de déploiement. Nous avons déplacé des charges dans les deux sens derrière une règle de listener ALB inchangée, sans que les appelants s'en aperçoivent. Traitez le choix de compute comme réversible et il cesse d'être un pari.
Fargate ou Lambda : le tableau récapitulatif
Le tableau ci-dessous condense la décision. Lisez d'abord la ligne « quand il gagne », puis confrontez les lignes de contraintes à votre workload : limites de durée, gabarit de ressources et utilisation soutenue sont les trois critères qui, le plus souvent, imposent la réponse à eux seuls, avant tout le reste.
| Lambda | Fargate | |
|---|---|---|
| Démarrage | À froid : de quelques millisecondes à quelques secondes | Tâche : de dizaines de secondes à quelques minutes |
| Limites de durée | Plafond strict de 15 minutes | Aucune : la tâche tourne aussi longtemps que nécessaire |
| Modèle de scaling | Par requête, depuis zéro, géré par la plateforme | Par tâche, via des politiques d'auto scaling de service |
| Forme de coût | À la requête plus mémoire-temps d'exécution | vCPU-heure et Go-heure tant que la tâche existe |
| Exploitation | Quasi nulle : ni image ni orchestrateur | Faible : images, task definitions, politiques de scaling |
| Quand il gagne | Trafic irrégulier, événementiel, exécutions courtes, isolation par requête | Longue durée, charge stable, WebSockets, gros gabarits CPU/mémoire |
La checklist de décision
Cinq questions tranchent la plupart des cas de zone grise :
- Une unité de travail dépasse-t-elle 15 minutes ? Fargate.
- La charge est-elle occupée la majorité de chaque heure ? Chiffrez la forme Fargate.
- Gardez-vous des connexions ouvertes (WebSockets, streaming) ? Fargate.
- Le trafic est-il irrégulier avec de vraies périodes creuses ? Lambda.
- Votre Lambda se bat-elle déjà contre les timeouts, les layers ou un routeur interne ? C'est votre signal de migration.