Lambda vs Azure Functions vs Cloud Run : 2x d'Écart [2026]

Trois mille fonctions déployées, zéro serveur à administrer, et pourtant une facture qui peut varier du simple au double selon la plateforme choisie. En octobre 2026, le choix entre AWS Lambda, Azure Functions et Google Cloud Run functions ne se limite plus à une question de préférence pour un fournisseur. Les trois géants du cloud ont publié cette année des mises à jour qui changent concrètement les règles du jeu : Lambda Managed Instances a étendu le délai d’exécution asynchrone à 90 minutes, Azure a généralisé son plan Flex Consumption, et Google a fusionné Cloud Functions dans Cloud Run pour simplifier son offre serverless de seconde génération.

Pour une équipe technique basée à Paris, Lyon ou Bruxelles qui doit choisir où héberger sa prochaine API événementielle, chaque détail compte : le prix par million de requêtes, la mémoire maximale allouable, le délai de démarrage à froid, ou encore la compatibilité avec une stack Kubernetes existante. Ce comparatif détaille les trois plateformes avec des chiffres vérifiés, des exemples d’entreprises qui les utilisent en production, et un guide pratique pour migrer de l’une à l’autre sans mauvaise surprise sur la facture.

Google · Sources préférées

Ne manquez aucune actu tech sur Google

Ajoutez TrendinTech France une seule fois dans l'app Google pour retrouver nos articles dans vos suggestions.

Ajouter

Le serverless en 2026 : où en sont AWS, Microsoft et Google

Le modèle serverless a dépassé le stade de la curiosité technique. Les trois fournisseurs historiques se livrent désormais une bataille sur des terrains très spécifiques : la latence de démarrage, la durée d’exécution maximale et la flexibilité réseau. AWS Lambda reste la référence historique, lancée en 2014, mais Azure Functions et Google Cloud Run functions ont rattrapé une bonne partie de leur retard fonctionnel au cours des deux dernières années.

La bascule la plus notable de 2026 concerne Google. L’entreprise a regroupé Cloud Functions sous la bannière Cloud Run functions, unifiant son modèle de facturation et de déploiement autour du moteur Cloud Run. Résultat : les développeurs qui écrivent une fonction HTTP bénéficient désormais des mêmes capacités de scaling, de mise en réseau et de sécurité que les conteneurs Cloud Run classiques, avec jusqu’à 32 Gio de mémoire disponible en seconde génération, un chiffre très supérieur aux 10 240 Mo plafonnés chez AWS Lambda.

Chez Microsoft, le plan Flex Consumption est devenu l’option recommandée pour les nouvelles charges de travail. Il combine mise à l’échelle élastique, réseau privé (VNET), instances toujours prêtes pour limiter les démarrages à froid, et une concurrence configurable par instance, selon la documentation officielle sur le plan Flex Consumption d’Azure Functions. AWS, de son côté, a ouvert cette année l’accès anticipé à Node.js 26 et Python 3.15 sur Lambda, tout en élargissant SnapStart aux fonctions packagées en image de conteneur pour réduire les démarrages à froid à moins d’une seconde.

Pour une entreprise européenne, ces évolutions ne sont pas anecdotiques. Le choix d’une plateforme serverless structure l’architecture pour plusieurs années, impacte les coûts d’infrastructure de façon directe, et conditionne la vitesse à laquelle une équipe peut livrer de nouvelles fonctionnalités. D’où l’intérêt de comparer AWS Lambda, Azure Functions et Google Cloud Run sur des critères concrets plutôt que sur la réputation de marque.

AWS Lambda en 2026 : architecture et nouveautés

AWS Lambda demeure le service serverless le plus mature du marché, avec l’écosystème d’intégrations le plus large (plus de 200 services AWS peuvent déclencher ou être appelés par une fonction Lambda). La nouveauté la plus structurante de 2026 est l’arrivée des Lambda Managed Instances, qui portent le délai d’exécution maximal à 5 400 secondes, soit 90 minutes, pour les invocations asynchrones et celles déclenchées via un event source mapping. Les invocations synchrones classiques restent, elles, plafonnées à 900 secondes (15 minutes), une limite inchangée depuis plusieurs années, selon la documentation officielle des quotas Lambda.

Sur le plan du réseau, AWS a également amélioré la bande passante disponible pour les fonctions configurées avec au moins 2 048 Mo de mémoire et exécutées hors VPC : le débit grimpe désormais de 625 Mbps jusqu’à 3 000 Mbps pour les fonctions allouées à 10 240 Mo, la configuration maximale. Cette évolution cible directement les charges de travail qui déplacent de gros volumes de données, comme le traitement vidéo ou les pipelines ETL.

Côté démarrage à froid, SnapStart, la technologie qui capture un instantané de la mémoire après l’initialisation d’une fonction, prend désormais en charge les fonctions packagées en image de conteneur et non plus seulement les archives ZIP. AWS annonce des démarrages inférieurs à la seconde pour les runtimes compatibles, un gain important pour les applications Java historiquement pénalisées par la lenteur de la JVM au démarrage. Autre nouveauté : l’accès anticipé (preview publique) à Node.js 26 et Python 3.15, permettant aux équipes de tester leurs fonctions sur ces runtimes avant la disponibilité générale.

Sur la tarification, AWS Lambda facture 0,20 dollar par million de requêtes après le quota gratuit, et 0,0000166667 dollar par Go-seconde pour les fonctions en architecture x86. Les fonctions tournant sur processeurs Arm (Graviton) bénéficient d’un tarif réduit à environ 0,0000133334 dollar par Go-seconde, soit une économie de 20 % par rapport à x86, un détail que beaucoup d’équipes ignorent encore. Le quota gratuit permanent reste fixé à 1 million de requêtes et 400 000 Go-secondes de calcul par mois, selon la page de tarification officielle d’AWS Lambda.

Azure Functions en 2026 : le pari du plan Flex Consumption

Microsoft a construit sa stratégie serverless autour d’un point fort difficile à copier : l’intégration native avec l’écosystème Azure Active Directory, Microsoft Entra ID, et les outils de gouvernance déjà déployés dans la majorité des grandes entreprises européennes. Azure Functions propose plusieurs modèles d’hébergement (Consumption, Premium, Dedicated, Flex Consumption), ce qui complique la comparaison directe avec AWS Lambda, mais offre aussi plus de flexibilité pour ajuster coût et performance selon la charge de travail.

Le plan Flex Consumption, généralisé cette année, cible explicitement les limites historiques du plan Consumption classique. Il introduit des instances toujours prêtes (always ready instances) pour réduire la fréquence des démarrages à froid, une intégration réseau privée via VNET sans les contraintes du plan Premium, et une concurrence par instance que les développeurs peuvent configurer finement selon le profil de la charge, d’après la documentation Microsoft Learn sur le plan Flex Consumption.

Sur la facturation, Azure Functions en mode Consumption applique un tarif proche de celui d’AWS : environ 0,20 dollar par million d’exécutions après le quota gratuit, avec un quota permanent d’environ 1 million d’exécutions et 400 000 Go-secondes par mois. La différence se joue surtout sur les plans Premium et Dedicated, où le délai d’exécution maximal devient pratiquement illimité, soumis uniquement à des périodes de grâce opérationnelles, contre un plafond strict de 900 secondes en Consumption. La mémoire maximale grimpe jusqu’à 14 Go sur le plan Premium, contre une allocation dépendante du plan en Consumption.

Pour une entreprise déjà engagée dans l’écosystème Microsoft 365 et Azure Active Directory, cette intégration réduit considérablement la charge d’administration liée à la sécurité et aux identités. C’est souvent l’argument décisif qui l’emporte sur de simples écarts de prix, en particulier dans les secteurs régulés comme la banque ou l’assurance, où la conformité prime sur l’optimisation marginale des coûts.

Google Cloud Run functions : la fusion qui change la donne

Google a pris une direction différente de ses deux concurrents en fusionnant Cloud Functions dans Cloud Run. Les fonctions dites de seconde génération (2nd gen) héritent directement du moteur Cloud Run, ce qui leur donne accès à des capacités largement supérieures en mémoire : jusqu’à 32 Gio, contre 10 240 Mo chez Lambda et 14 Go au maximum chez Azure Functions Premium. Cette architecture repose sur des conteneurs gérés automatiquement, ce qui simplifie le passage d’une fonction event-driven à un microservice complet sans réécrire le code depuis zéro.

Les délais d’exécution varient selon le type de déclencheur : jusqu’à 60 minutes pour les fonctions déclenchées en HTTP, 30 minutes pour les tâches planifiées ou mises en file d’attente, et 9 minutes pour les fonctions purement event-driven. Cette granularité par type de déclencheur n’a pas d’équivalent direct chez AWS ou Microsoft, où la limite s’applique généralement de façon uniforme selon le plan choisi.

Sur le plan tarifaire, Google applique un tarif de base plus élevé que ses concurrents : environ 0,40 dollar par million de requêtes, soit le double du tarif pratiqué par AWS et Microsoft. Le quota gratuit est en revanche nettement plus généreux, avec 2 millions de requêtes, 180 000 vCPU-secondes et 360 000 Gio-secondes offerts chaque mois, selon la page de tarification officielle de Cloud Run. Pour les petits projets et les prototypes, ce quota gratuit élargi peut largement compenser un tarif unitaire plus élevé une fois la facturation déclenchée.

L’autre avantage de Cloud Run functions tient à sa compatibilité native avec les conteneurs Docker standards. Une équipe peut développer localement avec le même conteneur qui tournera en production, sans les contraintes de packaging spécifiques imposées par les runtimes Lambda ou Azure Functions. Cette portabilité séduit particulièrement les équipes qui veulent garder la possibilité de migrer vers une infrastructure Kubernetes si leurs besoins évoluent.

Tableau comparatif technique complet

Voici une synthèse des caractéristiques techniques des trois plateformes, basée sur les spécifications officiellement publiées par chaque fournisseur en octobre 2026.

Caractéristique	AWS Lambda	Azure Functions	Google Cloud Run functions
Mémoire maximale	10 240 Mo	Jusqu’à 14 Go (Premium)	32 Gio (2e génération)
Délai d’exécution standard	900 s (15 min)	900 s (15 min, Consumption)	9 à 60 min selon déclencheur
Délai d’exécution étendu	5 400 s (90 min, Managed Instances, async)	Illimité (Premium/Dedicated)	60 min max (HTTP)
Concurrence par défaut	1 000 exécutions simultanées par région	Dépend du plan et du déclencheur	Élastique, géré par Cloud Run
Démarrage à froid optimisé	SnapStart (image conteneur incluse), sub-seconde	Instances « always ready » (Flex Consumption)	Instances minimales configurables
Réseau privé (VPC/VNET)	Oui, avec bande passante jusqu’à 3 000 Mbps	Oui, natif en Flex Consumption	Oui, via VPC Connector
Runtimes récents (preview)	Node.js 26, Python 3.15	Dépend du runtime hôte (.NET, Node, Python, Java)	Support conteneur Docker natif
Modèle de déploiement	ZIP ou image de conteneur	Code ou conteneur (plans Premium/Dedicated)	Conteneur Docker natif
Intégration identité cloud	IAM	Microsoft Entra ID	Google Cloud IAM
Facturation à la requête	0,20 $/million	~0,20 $/million	~0,40 $/million
Quota gratuit mensuel (requêtes)	1 million	~1 million	2 millions
Année de lancement du service	2014	2016	2017 (fusion Cloud Run en 2026)

Ce tableau met en évidence un arbitrage clé : Google Cloud Run functions domine sur la mémoire disponible et la flexibilité des délais d’exécution, mais facture un tarif de base deux fois plus élevé qu’AWS ou Microsoft par million de requêtes. AWS Lambda reste la référence pour les très hauts volumes de requêtes courtes grâce à son tarif compétitif et son quota gratuit généreux en calcul. Azure Functions, enfin, se distingue surtout par son intégration à l’écosystème Microsoft plutôt que par des chiffres bruts supérieurs.

Comparatif des tarifs détaillé

Le prix reste souvent le critère décisif pour les équipes techniques qui arbitrent entre plusieurs plateformes serverless. Voici une ventilation plus fine des coûts, utile pour estimer une facture mensuelle réaliste.

Poste de coût	AWS Lambda	Azure Functions	Google Cloud Run functions
Prix par million de requêtes	0,20 $	~0,20 $	~0,40 $
Prix par Go-seconde (x86/standard)	0,0000166667 $	Variable selon plan	Variable selon vCPU/mémoire
Prix par Go-seconde (Arm/Graviton)	0,0000133334 $ (-20 %)	Non applicable	Non applicable
Quota gratuit requêtes/mois	1 000 000	~1 000 000	2 000 000
Quota gratuit calcul/mois	400 000 Go-s	~400 000 Go-s	180 000 vCPU-s + 360 000 Gio-s
Surcoût instances « toujours prêtes »	Non disponible en Consumption classique	Oui, Flex Consumption	Oui, instances minimales Cloud Run
Facturation réseau sortant	Standard AWS (par Go transféré)	Standard Azure (par Go transféré)	Standard GCP (par Go transféré)
Remises à l’engagement	Savings Plans AWS	Réservations Azure	Committed Use Discounts GCP
Facturation à la milliseconde	Oui	Oui	Oui
Modèle le plus avantageux pour	Très hauts volumes, courtes durées	Clients déjà sur Microsoft 365/Entra ID	Petits volumes, besoins mémoire élevés

Un exemple chiffré permet de visualiser l’écart réel. Pour une application qui traite 10 millions de requêtes par mois avec une consommation moyenne de 128 Mo et 200 millisecondes d’exécution, le coût brut en requêtes serait d’environ 2 dollars sur AWS Lambda et Azure Functions, contre environ 4 dollars sur Google Cloud Run functions, avant même de compter le calcul. Sur des volumes bien plus importants, typiques d’une API grand public, cet écart de facturation à la requête peut représenter plusieurs centaines d’euros par mois, d’où l’intérêt de bien dimensionner son choix de plateforme dès la conception.

Démarrage à froid et performance : ce que montrent les documentations officielles

Le démarrage à froid, ce délai supplémentaire subi par une fonction serverless quand elle n’a pas été invoquée récemment, reste le critère de performance le plus scruté par les équipes techniques. Les chiffres précis varient énormément selon le runtime, la taille du package, la région et la mémoire allouée, ce qui rend les benchmarks indépendants difficiles à généraliser. Trois sources permettent cependant de dégager des tendances solides.

Premièrement, la documentation officielle d’AWS sur SnapStart confirme que cette technologie ramène les démarrages à froid des runtimes compatibles, y compris désormais les fonctions packagées en image de conteneur, à moins d’une seconde, contre plusieurs secondes pour un démarrage classique sur des runtimes lourds comme Java. Deuxièmement, la documentation Microsoft Learn sur le plan Flex Consumption décrit explicitement les instances « always ready » comme un mécanisme pour réduire la fréquence des démarrages à froid en maintenant un nombre configurable d’instances pré-chauffées en permanence. Troisièmement, le site de référence français LeMagIt, propriété du groupe TechTarget, souligne dans son analyse comparative que le choix du runtime et la taille du package de déploiement pèsent souvent plus lourd sur la latence perçue que le fournisseur cloud lui-même.

La leçon pratique est simple : plutôt que de choisir une plateforme uniquement sur la base d’un chiffre de latence marketing, une équipe doit tester ses propres fonctions, avec son propre code et ses propres dépendances, sur les trois environnements. Les écarts entre runtimes (Node.js contre Java, par exemple) sont souvent plus importants que les écarts entre fournisseurs pour un même runtime.

Kubernetes et conteneurs : le contexte cloud-native en 2026

Le choix d’une plateforme serverless ne se fait pas en vase clos. De nombreuses équipes font cohabiter fonctions serverless et clusters Kubernetes managés pour les charges de travail qui nécessitent un contrôle plus fin. Kubernetes 1.34 est la version stable la plus récente au moment de la rédaction, avec un dernier correctif, la version 1.34.12, publié le 15 septembre 2026. Cette branche est entrée en mode maintenance le 27 août 2026, et sa fin de support amont (end-of-life) est fixée au 27 octobre 2026, selon le calendrier publié sur kubernetes.io.

Côté offres managées, Amazon EKS a rendu Kubernetes 1.34 disponible en version générale dès le 2 octobre 2025, avec une période de support standard qui s’étend jusqu’au 2 décembre 2026, d’après la documentation des versions Kubernetes sur Amazon EKS. Microsoft Azure Kubernetes Service (AKS) a de son côté généralisé Kubernetes 1.34 en novembre 2025, avec une fin de support prévue en novembre 2026, selon la documentation officielle AKS sur les versions supportées.

Service Kubernetes managé	Version 1.34 disponible depuis	Fin de support standard	Fournisseur
Amazon EKS	2 octobre 2025	2 décembre 2026	AWS
Azure Kubernetes Service (AKS)	Novembre 2025	Novembre 2026	Microsoft
Google Kubernetes Engine (GKE)	Suivi via les notes de version GKE	Variable selon canal de version	Google
Kubernetes upstream 1.34	Dernier correctif 1.34.12 (15 sept. 2026)	27 octobre 2026 (fin de vie amont)	CNCF / communauté open source

Pourquoi ce détour par Kubernetes dans un comparatif serverless ? Parce que les trois fournisseurs positionnent explicitement leurs fonctions serverless comme un complément, et non un substitut, à leurs offres Kubernetes managées. Google l’illustre le mieux avec Cloud Run functions, construit directement sur le moteur Cloud Run, lui-même conçu pour cohabiter avec GKE. Une architecture hybride, fonctions serverless pour les tâches événementielles et cluster Kubernetes pour les services avec état, reste le choix par défaut pour la majorité des plateformes d’ingénierie en 2026.

Cas d’usage réels en entreprise

Au-delà des spécifications techniques, la meilleure façon de juger une plateforme serverless reste d’observer comment des entreprises l’utilisent réellement en production. Voici huit exemples documentés publiquement.

Autodesk utilise AWS Lambda dans le moteur de simulation de son produit Autodesk Forma, pour exécuter des calculs de bâtiment à la demande et livrer des résultats quasi en temps réel aux architectes et concepteurs, d’après le cas client publié par AWS.
Alcon, spécialiste des dispositifs médicaux ophtalmiques, a reconstruit son application Custom Pak Designer en application serverless déployée mondialement, avec AWS Lambda au cœur de la logique métier, selon le cas client Alcon.
Prezzee, plateforme de cartes-cadeaux numériques, fait tourner l’ensemble de ses systèmes métier (e-commerce, facturation, inventaire, service client) sur une infrastructure serverless AWS incluant Lambda, d’après le cas client Prezzee.
Haufe-Lexware exploite AWS Lambda pour exécuter du code en réponse à des événements dans son produit SaaS de comptabilité lexoffice, ce qui lui permet d’absorber les pics d’utilisation et de réduire les temps de réponse, selon le cas client Haufe-Lexware.
Inlitix, plateforme de business intelligence, combine Azure Functions et Azure Data Factory pour orchestrer l’ingestion et le traitement de données serverless, une transition qui a divisé par dix les coûts de ses environnements de développement et de test, d’après le témoignage client publié par Microsoft.
KAUCHE, marketplace japonaise, a adopté Google Cloud Run pour développer des applications conteneurisées capables de suivre la croissance rapide du volume de transactions, selon le cas client Google Cloud.
Credit OK exécute son module de scoring de crédit sur Google Cloud Functions pour traiter les données clients et calculer les scores, puis déploie l’application environnante sur Cloud Run via des pipelines CI/CD, d’après le cas client Credit OK.
ChatAndBuild utilise Cloud Run et Cloud Functions pour démarrer automatiquement des microservices sans état lors des pics de trafic, avec un équilibrage de charge Cloud Load Balancing pour garantir des réponses à faible latence, selon le cas client ChatAndBuild.

Ce panorama montre une tendance claire : AWS Lambda domine encore chez les grandes entreprises établies avec des contraintes de conformité globales, Azure Functions séduit les organisations déjà intégrées à l’écosystème Microsoft, et Google Cloud Run attire les équipes qui veulent garder la portabilité des conteneurs tout en bénéficiant d’un modèle de facturation à l’usage.

Avantages et inconvénients d’AWS Lambda

AWS Lambda profite de dix ans de maturité et d’un catalogue d’intégrations natives difficile à égaler. Son principal atout reste l’écosystème : CloudWatch pour le monitoring, EventBridge pour l’orchestration événementielle, Step Functions pour les workflows complexes, et une communauté de développeurs considérable qui produit une documentation tierce abondante. Le tarif par Go-seconde réduit sur Graviton (Arm) constitue également un avantage concret pour les équipes qui optimisent leurs coûts à grande échelle.

Avantages : écosystème le plus riche, tarif Graviton réduit de 20 %, SnapStart pour les démarrages à froid, 90 minutes d’exécution asynchrone avec Managed Instances, communauté et documentation abondantes.
Inconvénients : mémoire maximale plus basse que Cloud Run (10 240 Mo contre 32 Gio), délai d’exécution synchrone limité à 15 minutes, complexité de configuration IAM pour les équipes débutantes, verrouillage fort à l’écosystème AWS.

Avantages et inconvénients d’Azure Functions

Azure Functions tire sa force de l’intégration avec Microsoft Entra ID, Azure DevOps et l’ensemble de la suite Microsoft 365, un avantage décisif pour les grandes organisations déjà sous contrat Microsoft. Le plan Flex Consumption comble une bonne partie du retard historique sur les démarrages à froid, tout en conservant la flexibilité de passer à un plan Premium pour des besoins de calcul plus intenses.

Avantages : intégration identité et conformité la plus poussée pour les entreprises sous écosystème Microsoft, délai d’exécution illimité sur Premium/Dedicated, instances « always ready » du plan Flex Consumption, support multi-runtime (.NET, Node.js, Python, Java, PowerShell).
Inconvénients : multiplicité des plans d’hébergement qui complique les choix d’architecture, mémoire plus limitée en Consumption que chez les deux concurrents, documentation parfois fragmentée entre plans.

Avantages et inconvénients de Google Cloud Run functions

Cloud Run functions se distingue par sa générosité en mémoire et sa portabilité conteneur native. La fusion avec Cloud Run permet à une équipe de faire évoluer une simple fonction event-driven vers un microservice complet sans migration de plateforme, un argument fort pour les startups qui anticipent une croissance rapide de la complexité de leur architecture.

Avantages : mémoire maximale la plus élevée (32 Gio), quota gratuit mensuel le plus généreux (2 millions de requêtes), portabilité Docker native, délais d’exécution flexibles selon le déclencheur (jusqu’à 60 minutes en HTTP).
Inconvénients : tarif par requête environ deux fois plus élevé qu’AWS ou Azure, écosystème d’intégrations tierces plus restreint, documentation parfois moins détaillée en français que celle d’AWS.

Guide de migration entre plateformes serverless

Migrer une application serverless d’une plateforme à une autre demande de traduire des concepts qui portent des noms différents mais remplissent des rôles équivalents. Voici une table de correspondance utile pour planifier une migration.

Concept	AWS Lambda	Azure Functions	Google Cloud Run functions
Déclencheur HTTP	API Gateway / Function URL	HTTP Trigger	Déclencheur HTTP natif Cloud Run
Déclencheur événementiel	EventBridge, SQS, SNS	Event Grid, Service Bus	Eventarc
Orchestration de workflows	Step Functions	Durable Functions	Workflows
Gestion des secrets	Secrets Manager	Key Vault	Secret Manager
Observabilité	CloudWatch	Application Insights	Cloud Monitoring
Infrastructure as code	CloudFormation, SAM, CDK	Bicep, ARM Templates	Terraform, gcloud
Identité et accès	IAM	Microsoft Entra ID	Cloud IAM
Packaging	ZIP ou image conteneur	Code ou conteneur (Premium)	Image conteneur Docker

Sur le plan pratique, voici un exemple simplifié de fonction HTTP équivalente en Node.js pour chaque plateforme, afin d’illustrer les différences de syntaxe à anticiper lors d’une migration.

// AWS Lambda (Node.js)
exports.handler = async (event) => {
  return {
    statusCode: 200,
    body: JSON.stringify({ message: "Bonjour depuis Lambda" }),
  };
};

// Azure Functions (Node.js, modèle v4)
app.http('bonjour', {
  methods: ['GET'],
  authLevel: 'anonymous',
  handler: async (request, context) => {
    return { body: JSON.stringify({ message: "Bonjour depuis Azure Functions" }) };
  }
});

// Google Cloud Run functions (Node.js)
const functions = require('@google-cloud/functions-framework');
functions.http('bonjour', (req, res) => {
  res.status(200).json({ message: "Bonjour depuis Cloud Run functions" });
});

La migration la plus simple reste généralement AWS Lambda vers Google Cloud Run functions, grâce à la compatibilité conteneur native des deux côtés. La migration vers Azure Functions demande en revanche un travail d’adaptation plus important sur la gestion des identités et des déclencheurs, surtout si l’application s’appuie fortement sur EventBridge ou Step Functions côté AWS, des services sans équivalent strictement identique chez Microsoft.

Avant toute migration en production, il reste indispensable de rejouer l’ensemble des tests de charge sur la nouvelle plateforme. Les limites de concurrence, les comportements de mise à l’échelle et les délais de démarrage à froid diffèrent suffisamment pour justifier une phase de validation complète plutôt qu’un simple portage de code.

Quelle plateforme choisir selon votre cas d’usage

Le choix optimal dépend moins d’un classement général que du profil précis de la charge de travail. Voici une matrice de recommandation basée sur les scénarios les plus fréquents rencontrés par les équipes d’ingénierie européennes.

Cas d’usage	Plateforme recommandée	Raison principale
API publique à très fort volume de requêtes courtes	AWS Lambda	Tarif par requête compétitif, écosystème API Gateway mature
Entreprise déjà sous contrat Microsoft 365/Azure AD	Azure Functions	Intégration identité et conformité native
Traitement de données volumineuses (vidéo, ML)	Google Cloud Run functions	Mémoire maximale la plus élevée (32 Gio)
Startup qui anticipe une montée en complexité	Google Cloud Run functions	Portabilité conteneur, migration facile vers microservices
Workflows longs et orchestration complexe	AWS Lambda (Step Functions) ou Azure (Durable Functions)	Outils d’orchestration natifs les plus matures
Projet avec budget très serré et faible trafic	Google Cloud Run functions	Quota gratuit mensuel le plus généreux
Secteur régulé (banque, assurance, santé)	Azure Functions	Certifications de conformité et gouvernance intégrée

Ces recommandations restent des points de départ, pas des règles absolues. Une équipe qui utilise déjà intensivement Terraform et des conteneurs Docker trouvera souvent plus de cohérence architecturale avec Google Cloud Run functions, même pour un cas d’usage qui favoriserait théoriquement AWS Lambda sur le papier. La cohérence avec l’infrastructure existante pèse souvent plus lourd que l’écart de prix brut entre fournisseurs.

FinOps et maîtrise des coûts serverless

Le modèle de facturation à l’usage du serverless présente un piège classique : sans surveillance active, les coûts peuvent dériver rapidement avec la croissance du trafic, sans qu’aucune alerte ne se déclenche automatiquement. Les trois fournisseurs proposent des outils natifs de suivi budgétaire (AWS Cost Explorer, Azure Cost Management, Google Cloud Billing), mais leur granularité par fonction reste parfois insuffisante pour isoler précisément quelle route API génère le plus de dépenses.

Les équipes FinOps les plus avancées appliquent trois pratiques communes, quelle que soit la plateforme retenue. Premièrement, le tagging systématique des fonctions par équipe et par projet pour permettre une ventilation budgétaire fine. Deuxièmement, l’ajustement régulier de la mémoire allouée : une fonction surdimensionnée en mémoire consomme plus de Go-secondes sans gain de performance proportionnel. Troisièmement, l’usage des remises à l’engagement (Savings Plans chez AWS, réservations chez Azure, Committed Use Discounts chez Google) pour les charges de travail prévisibles, qui peuvent réduire la facture de 20 à 30 % sur les volumes stables.

L’architecture Arm/Graviton d’AWS mérite une mention particulière pour les équipes orientées coûts : migrer une fonction x86 vers Graviton ne demande généralement qu’une recompilation, sans changement de code applicatif pour la majorité des runtimes gérés, pour une économie directe de 20 % sur la facture de calcul.

Sécurité et conformité : des approches différentes

La sécurité serverless déplace une partie de la responsabilité vers le fournisseur cloud, mais ne l’élimine pas pour l’équipe applicative. Les trois plateformes appliquent le modèle de responsabilité partagée : le fournisseur sécurise l’infrastructure sous-jacente, l’équipe reste responsable de la configuration des permissions, de la gestion des secrets et de la sécurité du code applicatif.

AWS IAM impose un modèle de permissions granulaire mais réputé complexe à maîtriser pour les nouvelles équipes, avec un risque réel de sur-permissionnement par excès de prudence. Microsoft Entra ID, par contraste, profite d’une courbe d’apprentissage plus douce pour les organisations déjà familières avec Active Directory classique. Google Cloud IAM se situe entre les deux, avec une structure de rôles prédéfinis qui simplifie les cas d’usage courants sans sacrifier la granularité pour les besoins avancés.

Pour les entreprises européennes, la question de la localisation des données reste centrale. Les trois fournisseurs opèrent des régions cloud en France et dans l’Union européenne, mais les équipes doivent vérifier explicitement la configuration de leurs fonctions pour s’assurer qu’aucune donnée ne transite par une région hors UE, en particulier pour les secteurs soumis au RGPD de façon stricte.

Verdict : quelle plateforme l’emporte en 2026

Aucune des trois plateformes ne domine sur tous les critères, et c’est précisément ce qui rend ce comparatif utile plutôt que tranché d’avance. AWS Lambda reste le choix le plus sûr pour les équipes qui veulent l’écosystème d’intégrations le plus large et un tarif compétitif à très grande échelle, en particulier avec l’option Graviton. Azure Functions s’impose naturellement pour les organisations déjà engagées dans l’écosystème Microsoft, où l’intégration identité et conformité justifie à elle seule le choix de la plateforme. Google Cloud Run functions, enfin, séduit par sa générosité en mémoire (32 Gio contre 10 240 Mo chez Lambda) et son quota gratuit étendu, au prix d’un tarif par requête deux fois plus élevé que ses deux concurrents.

Si une seule recommandation devait ressortir de ce comparatif : partez de votre infrastructure existante plutôt que des chiffres bruts. Une équipe déjà sur AWS gagnera rarement à migrer vers Azure pour un gain marginal de 20 % sur certains postes de coût, alors que les frais de migration et la courbe d’apprentissage annuleront probablement ce bénéfice sur douze à dix-huit mois. En revanche, pour un nouveau projet sans historique cloud, les critères de ce tableau, mémoire nécessaire, volume de requêtes attendu, et contraintes de conformité, doivent guider le choix final.

Questions fréquentes

AWS Lambda, Azure Functions ou Google Cloud Run : lequel est le moins cher ?
Sur le tarif unitaire par requête, AWS Lambda et Azure Functions se valent à environ 0,20 dollar par million de requêtes, contre environ 0,40 dollar chez Google Cloud Run functions. Mais le quota gratuit de Google (2 millions de requêtes par mois) est plus généreux, ce qui peut rendre Cloud Run plus économique pour les projets à faible trafic.

Quelle plateforme serverless offre le plus de mémoire ?
Google Cloud Run functions permet d’allouer jusqu’à 32 Gio de mémoire en seconde génération, contre un maximum de 10 240 Mo chez AWS Lambda et jusqu’à 14 Go sur le plan Premium d’Azure Functions.

Peut-on exécuter une fonction serverless plus de 15 minutes ?
Oui, mais pas de façon uniforme. AWS Lambda Managed Instances autorise jusqu’à 90 minutes pour les invocations asynchrones. Azure Functions sur les plans Premium ou Dedicated n’impose pas de plafond strict. Google Cloud Run functions autorise jusqu’à 60 minutes pour les déclencheurs HTTP.

Le démarrage à froid est-il un vrai problème en 2026 ?
Il reste mesurable mais s’atténue grâce à des technologies comme SnapStart chez AWS ou les instances « always ready » du plan Flex Consumption d’Azure. L’impact réel dépend surtout du runtime utilisé : Node.js et Python démarrent généralement plus vite que Java ou .NET sur une architecture serverless classique.

Faut-il choisir une seule plateforme serverless ou en combiner plusieurs ?
De nombreuses entreprises adoptent une approche multi-cloud par nécessité (acquisitions, contraintes clients) plutôt que par choix stratégique. Techniquement rien n’empêche de combiner les trois, mais la complexité opérationnelle et les coûts de formation des équipes augmentent fortement avec chaque plateforme supplémentaire à maîtriser.

Google Cloud Functions existe-t-il encore séparément de Cloud Run ?
Les nouvelles fonctions de seconde génération sont désormais regroupées sous le nom Cloud Run functions, qui s’appuie directement sur le moteur Cloud Run. Les fonctions historiques de première génération restent supportées mais Google oriente les nouveaux projets vers la seconde génération.

Quelle plateforme s’intègre le mieux avec Kubernetes ?
Google Cloud Run functions, de par sa parenté technique avec Cloud Run, s’intègre le plus naturellement dans un environnement cloud-native déjà construit autour de GKE. AWS et Azure proposent toutefois des passerelles solides entre leurs fonctions serverless et leurs services Kubernetes managés respectifs, EKS et AKS.

Quel runtime choisir pour minimiser les démarrages à froid ?
Sur les trois plateformes, les runtimes interprétés légers comme Node.js et Python affichent généralement des démarrages à froid plus courts que les runtimes qui nécessitent le chargement d’une machine virtuelle complète, comme Java ou .NET, sauf lorsque des technologies dédiées comme SnapStart sont activées.

Lambda vs Azure Functions vs Cloud Run : 2x d’Écart [2026]