Le serverless est un excellent choix par défaut pour les nouvelles charges de travail. C'est aussi, régulièrement, le mauvais outil pour la tâche. Voici comment nous raisonnons pour trancher.
Les trois axes qui comptent
Ignorez l'idéologie. Décidez sur la forme de la charge, la courbe de coût et les compétences de l'équipe.
Axe 1 : la forme de la charge
- Trafic en rafales / imprévisible / faible en moyenne : Lambda gagne. Vous ne payez rien à l'arrêt et le scale-out est gratuit.
- Trafic stable, prévisible, soutenu : ECS Fargate ou EC2 revient en général 30 à 60 % moins cher par requête une fois passé environ 5 M d'invocations/jour avec des durées d'exécution et des allocations mémoire significatives.
- Jobs longs (>15 min) : Lambda est hors jeu. Utilisez ECS ou Step Functions pour piloter des tâches Fargate ou découper le travail en étapes Lambda.
- Charges gourmandes en mémoire (>10 Go) : Lambda plafonne à 10 240 Mo. ECS ou EC2.
- Stateful / sticky sessions : des serveurs, ou ré-architecturez en stateless et optez pour Lambda.
Axe 2 : la courbe de coût
Le pricing de Lambda est linéaire en invocations et en temps d'exécution. Celui des serveurs est en escalier : une seule petite instance Graviton (t4g ou m7g) encaisse des milliers de requêtes par seconde pour un coût mensuel fixe. Tracez les deux courbes et trouvez le point de croisement.
Règle empirique : si une fonction tourne moins d'environ 30 % du temps horloge, Lambda est moins cher. Si elle est occupée la plupart du temps, les serveurs gagnent.
Une charge occupée la plupart du temps peut coûter plusieurs fois plus cher sur Lambda que sur une paire de petites instances allumées en permanence. Tracez les deux courbes avant de vous engager sur l'une ou l'autre.
Axe 3 : les compétences de l'équipe
Le serverless est un modèle opérationnel différent. Cold starts, IAM par fonction, structure des logs CloudWatch, tracing distribué : tout cela est une seconde nature pour certaines équipes et complètement étranger à d'autres. Si votre équipe est plus productive sur un service Node/Python/Go traditionnel sur une machine Linux, ne lui imposez pas Lambda pour le principe.
À l'inverse, si votre équipe a adopté l'infrastructure-as-code, préfère les petites fonctions à responsabilité unique et vit déjà dans AWS, la simplicité opérationnelle de Lambda est un cadeau.
Là où Lambda gagne
- La glue événementielle (trigger S3 → transformation → DynamoDB).
- Les batchs planifiés type cron.
- Les outils internes et API d'admin à faible trafic.
- Les webhooks au trafic en rafales (Stripe, GitHub, Twilio).
- Les pipelines de traitement d'images et de documents.
Les cas où les serveurs gagnent
- Les API à fort débit et trafic stable (>100 req/s soutenues).
- Les serveurs WebSocket et les connexions temps réel.
- Les charges exigeant du tuning kernel spécifique ou des GPU.
- Les workers d'arrière-plan avec des jobs très longs.
- Les applications legacy non conçues pour une exécution stateless.
La voie médiane : Fargate
On oublie souvent cette option. ECS Fargate vous donne des conteneurs sans gestion d'EC2 : une exploitation proche du serverless, mais avec l'économie des serveurs traditionnels pour les charges stables. Pour beaucoup d'API de production, Fargate est la bonne réponse.
Une grille pragmatique
| Si votre charge est… | Commencez par |
|---|---|
| De la glue événementielle, sous 15 min | Lambda |
| Une API stable, >100 req/s | ECS Fargate |
| Du temps réel / WebSocket | ECS ou EC2 |
| Des webhooks en rafales | Lambda |
| Du GPU ou du matériel spécialisé | EC2 |
Vous hésitez entre Lambda, Fargate et EC2 pour votre prochaine charge ? Décrivez-la : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →L'essentiel
- Ignorez l'idéologie. Décidez sur la forme, le coût et l'équipe.
- Lambda gagne sur le travail en rafales, court, à faible duty cycle.
- Les serveurs gagnent sur le travail stable, long ou stateful.
- Fargate est souvent la bonne voie médiane.
- Tracez la courbe de coût ; ne devinez pas.