AWS Lambda vs Azure Functions vs Google Cloud Run : quelle plateforme serverless choisir en 2026 ?

AWS Lambda convient aux traitements déclenchés par des événements dans un écosystème AWS. Azure Functions, avec son plan Flex Consumption, convient aux équipes qui travaillent déjà avec .NET et Azure. Google Cloud Run convient aux API packagées en conteneurs, avec la meilleure portabilité. Aucune des trois AWS Lambda vs Azure Functions vs Cloud Run n’est la meilleure plateforme serverless en absolu. Le choix dépend de votre code existant, de la durée de vos traitements et de votre fournisseur cloud actuel.

Choisir une plateforme serverless engage votre architecture pour plusieurs années. Ce comparatif serverless 2026 évalue les trois leaders sur cinq critères : tarification, cold start, langages, limites et dépendance au fournisseur. AquilApp, agence de développement sur mesure à Nantes, propose de vérifier ces critères lors du cadrage d’une architecture back-end.

Quelle plateforme serverless choisir en 2026 : FaaS, containers et modèles hybrides

Le serverless est un modèle d’exécution. Dans ce cas, le fournisseur cloud gère les serveurs, la montée en charge et l’arrêt des ressources inactives. Vous payez l’usage réel, pas la capacité réservée. Ce modèle convient notamment aux charges irrégulières. En effet, aucune machine ne tourne sans raison.

Qu’est-ce que le FaaS ?

Le FaaS (Function as a Service) est un modèle où vous déployez de courtes fonctions. Elles sont déclenchées par un événement. 

Une requête HTTP, un message dans une file ou un fichier déposé peuvent lancer une fonction. AWS Lambda vs Azure Functions relèvent de ce modèle.

Où se place Google Cloud Run ?

D’un autre côté, Google Cloud Run est un service qui exécute des conteneurs. Il ajuste leur nombre selon la demande. Vous déployez une application complète, pas une fonction isolée. Google propose aussi Cloud Run functions. C’est le nouveau nom de Cloud Functions. Ces fonctions suivent la même grille tarifaire que Cloud Run.

Les frontières se brouillent : 

• Selon l’AWS Compute Blog, Lambda accepte l’empaquetage en image de conteneur. 
• Selon Microsoft Learn, Azure Functions peut aussi tourner sur Azure Container Apps.

Néanmoins, un changement côté Azure pèse sur votre choix. Microsoft retire le plan Consommation sous Linux le 30 septembre 2028. L’éditeur recommande le plan Flex Consumption pour tout nouveau projet serverless. Ce comparatif porte donc sur Flex Consumption.

Quels sont les modèles de pricing comparés et coûts réels ? 

Les trois plateformes facturent l’usage. Cependant, pas avec la même unité. Une Go-seconde correspond à 1 Go de mémoire utilisé pendant 1 seconde. 

• Lambda facture les requêtes et les Go-secondes. 
• Azure Flex Consumption facture les exécutions et la mémoire des instances actives. 
• Cloud Run facture les vCPU-secondes (processeurs virtuels) et les Gio-secondes, plus les requêtes en mode « à la requête ».

Selon la page tarifaire d’AWS, Lambda coûte 0,20 $ par million de requêtes et 0,0000166667 $ par Go-seconde sur architecture x86. L’offre gratuite couvre 1 million de requêtes et 400 000 Go-secondes par mois.

Selon Google Cloud, le mode à la requête facture 0,40 $ par million de requêtes au-delà de 2 millions gratuits. Le processeur actif coûte 0,000024 $ par vCPU-seconde dans les régions de niveau 1. Tel est le cas pour la Belgique, les Pays-Bas et Paris. Google arrondit la durée aux 100 ms supérieures. Le mode « à l’instance » facture toute la vie de l’instance, mais à 0,000018 $ par vCPU-seconde.

Selon Microsoft, le plan Flex Consumption inclut chaque mois 250 000 exécutions et 100 000 Go-secondes gratuites par abonnement. La durée minimale facturable est de 1 000 ms, puis l’arrondi se fait par tranche de 100 ms. Les tarifs unitaires varient selon la région. Consultez la page tarifaire Azure avant tout chiffrage.

Critère	AWS Lambda	Azure Functions (Flex Consumption)	Google Cloud Run
Unités facturées	Requêtes + Go-secondes	Exécutions + Go-secondes	vCPU-secondes + Gio-secondes + requêtes
Gratuité mensuelle	1 M de requêtes + 400 000 Go-s	250 000 exécutions + 100 000 Go-s	2 M de requêtes + 180 000 vCPU-s + 360 000 Gio-s
Capacité toujours prête	Provisioned Concurrency (0,000009722 $ par Go-s)	Instances Always Ready (mémoire facturée même au repos)	Instances minimales (0,0000025 $ par vCPU-s au repos)
Tarif de référence	0,20 $ / M de requêtes ; 0,0000166667 $ / Go-s	À consulter par région	0,40 $ / M de requêtes ; 0,000024 $ / vCPU-s actif

Sources : aws.amazon.com/lambda/pricing ; azure.microsoft.com/pricing/details/functions ; cloud.google.com/run/pricing. Tarifs en dollars américains, relevés en septembre 2026. Cloud Run : mode à la requête, régions de niveau 1.

Depuis le 1er août 2025, AWS facture aussi la phase d’initialisation de Lambda, appelée INIT. Cette phase correspond au cold start. Selon l’AWS Compute Blog, l’impact reste minime pour la plupart des clients. En effet, l’INIT concerne une très petite fraction des invocations. Une fonction rarement appelée et lente à initialiser subit un surcoût proportionnellement plus visible.

Les exemples de calcul officiels montrent l’effet de la concurrence sur une plateforme serverless. A savoir : 

• Chez AWS, 3 millions de requêtes par mois à 120 ms et 1 536 Mo coûtent 2,33 $ de calcul et 0,40 $ de requêtes. 
• Chez Google, le même service (10 millions de requêtes, 400 ms, 1 vCPU, 512 Mio) coûte 13,69 $ par mois avec 20 requêtes simultanées par instance. Il coûte 81,72 $ avec une seule requête par instance. 

Ces exemples reposent sur des hypothèses différentes et ne se comparent pas entre fournisseurs.

Retenez la règle suivante : le coût dépend autant du modèle de concurrence que du tarif unitaire de la plateforme serverless. Cloud Run partage une instance entre plusieurs requêtes. Azure Flex Consumption propose aussi une concurrence configurable par instance.

Quid du cold starts de votre plateforme serverless : les latences mesurées et les stratégies de mitigation

Un cold start (démarrage à froid) est le délai supplémentaire subi par la première requête lorsqu’aucune instance n’est prête. La plateforme doit alors : 

• Créer un environnement
• Charger le code 
• Et initialiser l’application.

Nous ne publions pas de benchmark maison. Les fournisseurs ne garantissent aucune latence de cold start. Les mesures tierces varient selon le runtime, la mémoire et la taille du paquet. 

Mesurez plutôt vos propres fonctions. Lambda affiche la durée d’initialisation dans chaque journal REPORT, par exemple « Init Duration: 100.77 ms » dans l’exemple de l’AWS Compute Blog.

Chaque plateforme serverless propose ses propres leviers :

• AWS Lambda : SnapStart prépare un instantané de l’environnement initialisé. Selon AWS, il offre un démarrage sous la seconde pour Java, Python 3.12 et suivants, et .NET 8 et suivants. Provisioned Concurrency maintient des environnements prêts en quelques dizaines de millisecondes, mais se facture même sans trafic.
• Azure Flex Consumption : les instances Always Ready restent actives pour chaque groupe de fonctions. Leur nombre par défaut est de zéro. Microsoft indique que Flex réduit les cold starts par rapport à l’ancien plan Consommation.
• Google Cloud Run : les instances minimales gardent des conteneurs démarrés. Google les facture au tarif « au repos » quand elles ne traitent aucune requête.

Appliquez trois règles pour limiter l’impact des cold starts :

1. Allégez le paquet : retirez les dépendances inutiles, car le temps d’initialisation croît avec la taille du code chargé.
2. Choisissez le runtime avec soin : Java et .NET initialisent plus lentement. SnapStart vise précisément les fonctions à initialisation longue, selon AWS.
3. Payez la capacité chaude uniquement où c’est utile : un traitement asynchrone tolère un cold start. Une API appelée par un utilisateur le tolère mal.

Quels sont les langages supportés et le runtime custom d’une bonne plateforme serverless ?

Un runtime est l’environnement d’exécution qui fait tourner votre code. Les trois plateformes ne l’exposent pas de la même façon.

Azure Flex Consumption prend en charge, selon Microsoft Learn, C# isolé (.NET 8, 9 et 10), Java (8 à 25), Node.js 22 et 24, Python 3.10 à 3.14, PowerShell et les gestionnaires personnalisés. Flex ne supporte pas les conteneurs. Pour déployer votre propre image, Microsoft oriente vers les plans Premium et Dedicated, ou vers Azure Container Apps.

AWS Lambda propose des runtimes gérés pour Node.js, Python, Java, .NET et Ruby. Il accepte aussi les runtimes personnalisés et les images de conteneur, selon la documentation AWS.

Enfin, Google Cloud Run exécute des conteneurs. La plateforme ne contraint donc pas le langage. Tout service qui écoute sur un port HTTP convient.

Votre choix de langage précède souvent celui de la plateforme. Votre équipe hésite entre Node.js et Python ? Notre comparatif Node.js vs Python backend détaille les critères. Pour structurer une API Node.js, lisez aussi Express.js vs NestJS.

Comparons les limites techniques de Lambda, Azure Functions ou Cloud Run : durée d’exécution, mémoire, concurrence

Les limites décident souvent du choix, avant même le prix. Le tableau ci-dessous reprend les valeurs par défaut des documentations officielles.

Limite	AWS Lambda	Azure Functions (Flex Consumption)	Google Cloud Run
Durée d’exécution	900 s (15 min), non modifiable	30 min par défaut, sans maximum imposé ; 230 s pour une réponse HTTP	5 min par défaut, 60 min maximum par requête ; jobs jusqu’à 168 h
Mémoire maximale	10 240 Mo	4 096 Mo par instance	32 Gio par instance
Processeur	Proportionnel à la mémoire (1 vCPU à 1 769 Mo)	0,25, 1 ou 2 cœurs	Jusqu’à 8 vCPU
Concurrence	1 000 exécutions simultanées par région (relevable)	Jusqu’à 1 000 instances	Jusqu’à 1 000 requêtes simultanées par instance
Taille de requête	6 Mo (appel synchrone)	210 Mo	32 Mio en HTTP/1

Sources : docs.aws.amazon.com/lambda (quotas) ; learn.microsoft.com/azure/azure-functions/functions-scale ; cloud.google.com/run/quotas. Valeurs relevées en septembre 2026.

Pour bien choisir votre plateforme serveless, faites notamment attention à trois points : 

• Traitements longs : Lambda plafonne à 15 minutes. Au-delà, découpez le travail en lots ou choisissez Cloud Run ou Azure.
• API synchrones : Azure coupe toute réponse HTTP après 230 secondes, quel que soit le délai configuré. Microsoft recommande alors un motif asynchrone.
• Pics de trafic : Azure limite aussi la capacité cumulée des applications Flex à 250 cœurs par région et par abonnement par défaut. Vérifiez ce quota avant un lancement.

Qu’en est-il de l’intégration cloud native et vendor lock-in de votre plateforme serverless?

Le vendor lock-in (dépendance à un fournisseur) désigne le coût de départ d’une plateforme. Tel est le cas de la réécriture du code, de la migration des données et de la refonte des déclencheurs.

Une fonction serverless vit rarement seule. Elle s’appuie sur les services voisins de son cloud. A savoir : 

• Chez AWS, ce sont par exemple S3, SQS et DynamoDB. 
• Chez Azure, Blob Storage, Event Grid et Durable Functions. Chez Google, Pub/Sub et Eventarc. 

Ces liens accélèrent le développement, mais ils ancrent votre code dans un fournisseur.

Nous évaluons la portabilité ainsi :

• Cloud Run : l’unité de déploiement est un conteneur standard. Le code se déplace vers un autre hébergeur de conteneurs avec peu de changements.
• AWS Lambda : les images de conteneur facilitent l’empaquetage. Les déclencheurs et les formats d’événements restent propres à AWS.
• Azure Flex Consumption : le code est déployé sans conteneur. Microsoft ne propose pas de migration sur place depuis l’ancien plan. Vous créez une nouvelle application Flex et redéployez.

Une bonne pratique réduit la dépendance quel que soit le fournisseur. Notre conseil : isolez la logique métier des déclencheurs. Le fournisseur n’appelle alors qu’une fine couche d’adaptation. Le réseau privé et les droits d’accès méritent la même rigueur. En effet, Flex prend en charge l’intégration à un réseau virtuel. Ils relèvent de la sécurité applicative, quelle que soit la plateforme.

Quand utiliser quoi : API, ETL, événementiel, cron jobs

Voici la plateforme que nous privilégions pour chaque usage.

1. API HTTP : Cloud Run convient si vous avez déjà une API Express, NestJS ou Django. Pour cause, elle tourne dans un conteneur et partage les instances entre requêtes. Lambda convient à un trafic faible dans un écosystème AWS. Azure Flex convient aux équipes .NET qui exigent un réseau virtuel.
2. ETL (Extract, Transform, Load) : ce traitement de données dure souvent plus de 15 minutes. Cloud Run jobs (jusqu’à 168 heures) ou Azure Flex (sans durée maximale imposée) conviennent mieux que Lambda.
3. Événementiel : lambda réagit nativement aux dépôts S3 et aux files SQS. Azure Functions se déclenche sur Blob Storage et Event Grid. Cloud Run s’appuie sur Eventarc et Pub/Sub.
4. Cron jobs : un traitement planifié coûte très peu. Google publie l’exemple d’un job horaire d’une minute (730 exécutions par mois, 1 vCPU, 512 Mio) à 0,00 $ avec l’offre gratuite, et 0,45 $ sans elle.

Ces usages coexistent dans la plupart des produits. Pour un logiciel en ligne (SaaS, Software as a Service), notre guide pour créer un SaaS détaille l’architecture d’ensemble.

Notre recommandation pour votre plateforme serveless chez AquilApp

Voici un tableau récapitulatif de comparatif serverless 2026 : 

Critère	AWS Lambda	Azure Functions (Flex Consumption)	Google Cloud Run
Modèle	Fonctions (FaaS)	Fonctions (FaaS)	Conteneurs
Durée maximale	15 min	Sans maximum imposé (HTTP : 230 s)	60 min par requête
Portabilité	Moyenne	Moyenne à faible	Élevée
Langages	Runtimes gérés, personnalisés, conteneurs	Runtimes gérés, gestionnaires personnalisés	Tout langage en conteneur
Point de vigilance	Limite de 15 min, INIT facturé	Pas de conteneur, quota régional de cœurs	Réglage de la concurrence et de la facturation
Profil adapté	Écosystème AWS, événementiel	Écosystème Microsoft, .NET	API existantes, portabilité

Sources : synthèse AquilApp à partir des documentations AWS, Microsoft Learn et Google Cloud citées plus haut, septembre 2026.

Notre position est la suivante :

• Startup ou PME sans cloud imposé : choisissez Cloud Run. La portabilité et le partage d’instances protègent votre budget.
• Organisation déjà sur AWS avec des flux événementiels : choisissez Lambda. L’intégration native avec S3 et SQS compense la limite de 15 minutes.
• Entreprise centrée sur Microsoft : choisissez Azure Functions en plan Flex Consumption. Il s’aligne sur .NET et sur votre réseau Azure.

Trois questions tranchent la plupart des cas :

1. Où se trouvent déjà vos données et vos identités ?
2. Vos traitements dépassent-ils 15 minutes ?
3. Votre code est-il déjà conteneurisé ?

Conclusion

Lambda vs Azure Functions vs Cloud Run répondent à trois besoins distincts : 

• Lambda excelle dans l’événementiel AWS. 
• Azure Flex Consumption sert les équipes .NET. 
• Cloud Run offre la meilleure portabilité pour les API. 

Ce comparatif de plateforme serverless vous donne les critères pour trancher : coûts, cold starts, limites et dépendance.

Vous voulez valider votre choix sur votre projet ? Découvrez notre offre de développement logiciel sur mesure ou lisez notre guide sur la sécurité applicative pour aborder la mise en production.