Coûts Serverless en 2026 : AWS Lambda vs GCP Cloud Run Functions vs Azure Functions Flex

Mis à jour : 13 septembre 2026

Sur des charges de travail événementielles typiques (10 M d'invocations/mois, 512 Mo, 300 ms), Google Cloud Run Functions ressort le moins cher à ~4,10 $, suivi de AWS Lambda (Graviton) à ~4,80 $ et de Azure Functions Flex Consumption à ~6,90 $. Mais bon, le prix affiché ne raconte que la moitié de l'histoire : les cold starts, la concurrence provisionnée, l'egress et les frais annexes changent radicalement le classement. J'ai audité une bonne dizaine de stacks serverless cette année, et le vainqueur du tableur théorique perd presque toujours face à la réalité de production. Ce guide compare AWS Lambda, GCP Cloud Run Functions et Azure Functions en 2026, avec des tableaux côte à côte, du code d'optimisation prêt à l'emploi et un cadre de décision par type de workload.

• AWS Lambda facture 0,20 $ par million de requêtes + 0,0000166667 $ par Go-seconde (x86) ; passer à Graviton (arm64) économise 20 % sur le compute.
• Google Cloud Run Functions (2ᵉ génération) fusionne Cloud Functions et Cloud Run sous une seule facturation à 0,40 $ par million de requêtes + 0,0000024 $ par vCPU-seconde.
• Azure Functions Flex Consumption (GA en 2025) remplace le plan Premium pour les workloads exigeants et facture par instance actuellement provisionnée, pas par exécution.
• Un Compute Savings Plan AWS d'un an couvre Lambda et réduit la facture de 17 % (souvent oublié par les équipes qui pensent qu'il ne s'applique qu'à EC2).
• La règle du right-sizing mémoire : doubler la RAM peut diviser par deux la durée et donc laisser la facture inchangée, mais uniquement si le workload est CPU-bound.
• Le vrai gagnant dépend du profil : événementiel court → Cloud Run Functions ; API sensibles à la latence → Lambda + SnapStart ; workloads .NET et intégration Azure DevOps → Azure Functions.

Comment fonctionne la facturation serverless en 2026 ?

Les trois hyperscalers appliquent la même formule de base : coût = requêtes × prix unitaire + durée × mémoire × prix Go-seconde. La subtilité tient aux arrondis, aux offres pay-per-instance, et à la façon dont chaque provider comptabilise le CPU.

AWS Lambda facture la durée d'exécution par tranche de 1 ms, avec une mémoire configurable entre 128 Mo et 10 240 Mo. Le vCPU est alloué proportionnellement à la mémoire : à 1 769 Mo vous obtenez exactement 1 vCPU, à 3 538 Mo vous en avez 2. Vous ne pouvez pas dissocier CPU et RAM, ce qui pousse au surdimensionnement pour les workloads CPU-bound.

GCP Cloud Run Functions (issu de la fusion 2024–2025 entre Cloud Functions 2ᵉ génération et Cloud Run) permet de configurer CPU et mémoire indépendamment, jusqu'à 8 vCPU et 32 Gio. La facturation utilise deux compteurs distincts : vCPU-seconde et Gio-seconde, arrondis à 100 ms. C'est plus fin, et cela permet un vrai right-sizing sur les workloads déséquilibrés (beaucoup de mémoire mais peu de CPU, ou l'inverse).

Azure Functions propose désormais trois modèles : Consumption (pay-per-execution, gratuit sous 1 M d'exécutions/mois), Flex Consumption (GA en mai 2025, facturé à l'instance activement provisionnée en Go-seconde), et Premium (instances toujours chaudes avec VNet). Flex Consumption est la vraie nouveauté 2026 : elle offre les cold starts d'un Premium avec la facturation à la consommation d'un plan Consumption.

Tableau comparatif des prix : Lambda vs Cloud Run Functions vs Azure Functions

Tous les prix sont exprimés en USD dans la région us-east-1 / us-central1 / East US, hors free tier. Configuration de référence : 10 000 000 invocations/mois, 512 Mo, 300 ms d'exécution.

Dimension	AWS Lambda (x86)	AWS Lambda (Graviton)	GCP Cloud Run Functions	Azure Functions Flex
Prix par 1 M de requêtes	0,20 $	0,20 $	0,40 $	0,20 $
Prix par Go-seconde	0,0000166667 $	0,0000133334 $	0,0000025 $ (Gio-s) + vCPU	0,000016 $
Free tier mensuel	1 M req + 400 k Go-s	1 M req + 400 k Go-s	2 M req + 360 k vCPU-s	Aucun (Flex)
Cold start typique	200–800 ms	200–800 ms	150–600 ms	500–2 000 ms
Cold start avec instances chaudes	SnapStart : ~10 ms (Java/.NET/Python)	SnapStart : ~10 ms	Min instances : ~50 ms	Always Ready : ~100 ms
Durée max d'exécution	15 min	15 min	60 min (HTTP), illimité (event)	60 min (Flex)
Mémoire max	10 240 Mo	10 240 Mo	32 Gio	4 Go (Flex)
Coût du scénario type	~5,90 $	~4,80 $	~4,10 $	~6,90 $
Compute Savings Plan ?	Oui, jusqu'à 17 %	Oui, jusqu'à 17 %	CUDs 1 an sur Cloud Run : 17 %	Reserved Capacity Premium : 34 %

AWS Lambda : leviers d'optimisation 2026

Sur AWS Lambda, quatre leviers offrent le meilleur retour : ARM Graviton, right-sizing mémoire, SnapStart, et Compute Savings Plans. Franchement, j'ai vu des équipes économiser 45 % en combinant les trois premiers, sans toucher au code métier. Le plus surprenant, c'est à quel point ces optimisations restent sous-utilisées.

Migration vers Graviton (arm64)

Depuis 2024, la quasi-totalité des runtimes managés Lambda (Node.js, Python, Java 17/21, .NET 8, Ruby, Go) tournent nativement sur Graviton3. Le prix est 20 % inférieur au x86 pour la même mémoire, et les benchmarks internes que j'ai vus sur Node.js et Python indiquent une performance égale ou meilleure. Modifier une fonction existante prend une ligne de Terraform :

resource "aws_lambda_function" "api_handler" {
  function_name = "api-handler"
  runtime       = "nodejs20.x"
  architectures = ["arm64"]  # <-- passage à Graviton
  memory_size   = 512
  timeout       = 10
  handler       = "index.handler"
  role          = aws_iam_role.lambda_exec.arn
  filename      = "handler.zip"
}

Attention aux dépendances natives (bibliothèques compilées comme sharp, bcrypt, pillow) : elles doivent être empaquetées pour arm64. Utilisez docker buildx avec la plateforme linux/arm64 ou installez-les dans une couche Lambda construite sur une image ARM.

Right-sizing mémoire avec Lambda Power Tuning

La règle non-évidente : plus de RAM = plus de CPU = souvent moins cher. Lambda Power Tuning (outil open-source AWS basé sur Step Functions) lance votre fonction avec 128, 256, 512, 1024, 1536, 2048, 3008 Mo et trace la courbe coût/durée. Sur du traitement d'image ou de la transformation JSON lourde, le sweet spot est fréquemment 1 536 ou 3 008 Mo, pas les 128 Mo que « l'intuition » suggère.

# Déploiement via SAM
sam deploy --template-url https://s3.amazonaws.com/awslambda-reserved-us-east-1/aws-lambda-power-tuning.yaml

# Invocation via CLI
aws stepfunctions start-execution \
  --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:powerTuningStateMachine \
  --input '{
    "lambdaARN": "arn:aws:lambda:us-east-1:123456789012:function:api-handler",
    "powerValues": [128, 256, 512, 1024, 1536, 2048, 3008],
    "num": 50,
    "payload": {"userId": "test-123"},
    "strategy": "cost"
  }'

SnapStart pour éliminer les cold starts

SnapStart est disponible en 2026 pour Java, Python et .NET (aperçu en 2025 pour Node.js). Il snapshot la VM après init et démarre les invocations suivantes en ~10 ms au lieu de 200–800 ms. C'est gratuit sur Java et facturé 0,0000015046 $ par Go-seconde de « cached snapshot » sur Python et .NET, négligeable face au gain de latence et à la disparition du besoin de provisioned concurrency.

Compute Savings Plans couvrent Lambda

Point souvent ignoré : un Compute Savings Plan (engagement d'un ou trois ans sur un $/heure de compute) s'applique à Lambda comme à EC2, Fargate ou Batch. À l'engagement d'un an sans upfront, la réduction sur Lambda est de 17 % ; à trois ans avec upfront, on grimpe à 20+ %. Notre article sur Savings Plans vs Instances Réservées AWS en 2026 détaille la mécanique et le calcul du taux de couverture optimal.

GCP Cloud Run Functions : la fusion qui change tout

En août 2024, Google a annoncé la fusion de Cloud Functions et Cloud Run sous un seul produit : Cloud Run Functions. En 2026, l'ancienne API Cloud Functions 1ʳᵉ génération est officiellement dépréciée (fin de vie prévue janvier 2027) et toutes les nouvelles fonctions déployées utilisent le runtime Cloud Run. Voir la documentation officielle Cloud Run Functions.

Concrètement, cela change trois choses côté coût :

• Facturation CPU et mémoire dissociée. Vous pouvez configurer 1 vCPU + 256 Mio si votre workload est CPU-bound, ou 0,25 vCPU + 4 Gio pour une tâche mémoire-lourde. Impossible sur Lambda.
• Concurrence par instance jusqu'à 1 000 requêtes. Une seule instance peut traiter 1 000 requêtes HTTP simultanées. Sur un endpoint I/O-bound (appels API externes, requêtes DB), vous divisez la facture par un facteur proportionnel à la concurrence.
• Committed Use Discounts (CUDs) sur Cloud Run. Engagement d'un an = 17 % de réduction sur vCPU et mémoire, trois ans = 45 %. À comparer avec les Compute Savings Plans AWS.

Configuration Terraform typique

resource "google_cloudfunctions2_function" "api_handler" {
  name     = "api-handler"
  location = "us-central1"

  build_config {
    runtime     = "nodejs20"
    entry_point = "handler"
    source {
      storage_source {
        bucket = google_storage_bucket.functions.name
        object = google_storage_bucket_object.source.name
      }
    }
  }

  service_config {
    max_instance_count             = 100
    min_instance_count             = 0        # scale-to-zero
    available_memory               = "512Mi"
    available_cpu                  = "1"
    timeout_seconds                = 60
    max_instance_request_concurrency = 80     # 80 requêtes concurrentes par instance
    ingress_settings               = "ALLOW_ALL"
  }
}

Le paramètre max_instance_request_concurrency est le plus important pour les coûts : sur une API I/O-bound à 10 000 rps, passer de 1 à 80 divise la facture vCPU-seconde par un facteur proche de 80.

Économiser avec Committed Use Discounts

Les CUDs Cloud Run sont « resource-based » : vous vous engagez sur un nombre de vCPU-heures ou Gio-heures par région. Pour une fonction qui consomme en moyenne 2 vCPU actifs 24/7, l'engagement 1 an à 17 % rapporte ~1 500 $/an. Le calcul est direct depuis Cloud Billing → Commitments. Si vos workloads oscillent, préférez les CUDs flexibles (spend-based) qui couvrent Cloud Run, Compute Engine et GKE Autopilot.

Azure Functions : Flex Consumption vs Premium vs Consumption

Le portefeuille Azure Functions a été restructuré en 2025 avec l'arrivée en GA de Flex Consumption. Trois plans coexistent en 2026 :

• Consumption : historique, gratuit sous 1 M d'exécutions et 400 000 Go-s/mois. Cold starts marqués (jusqu'à 2 s sur .NET), pas de VNet integration native. Idéal pour du prototypage.
• Flex Consumption : nouveau, facturé à la mémoire d'instance active × durée (Go-seconde). Cold starts de ~500 ms, VNet integration incluse, « Always Ready instances » optionnelles pour éliminer les cold starts sur les endpoints critiques.
• Premium : instances pré-chauffées, VNet complet, jusqu'à 14 Go RAM. Facturation à l'instance heure, chère si mal dimensionnée, imbattable sur les workloads soutenus.

Quand Flex Consumption est-il le bon choix ?

Flex Consumption remplace Premium pour la majorité des cas. La règle empirique que j'applique : si votre fonction reçoit plus de 100 requêtes/minute en continu, activez 1 à 3 « Always Ready instances » et vous obtenez la latence Premium à ~40 % du prix. En dessous, la Consumption classique reste la moins chère.

# Provisionnement Flex Consumption via Azure CLI
az functionapp create \
  --resource-group rg-prod \
  --name api-handler \
  --storage-account stprodfunctions \
  --flexconsumption-location eastus \
  --runtime dotnet-isolated \
  --runtime-version 8.0 \
  --instance-memory 2048 \
  --maximum-instance-count 100

# Configurer Always Ready pour un endpoint critique
az functionapp scale config always-ready set \
  --name api-handler \
  --resource-group rg-prod \
  --settings http=2

Reserved Capacity sur Premium

Sur les workloads soutenus qui restent en Premium (VNet obligatoire pour compliance, hybride avec App Service Environment), Azure propose des Reserved Instances à 1 ou 3 ans, avec 34 à 55 % de réduction. C'est la seule offre de commitment discount comparable côté serverless. Lambda et Cloud Run n'atteignent pas ces niveaux.

Cold starts et coûts cachés : la vraie comparaison

Le prix affiché à l'exécution ne capture pas tout. Trois coûts cachés dominent en 2026 : cold starts, egress inter-régions, et surcoût des logs/traces.

Cold starts et concurrence provisionnée

Sur AWS Lambda, la Provisioned Concurrency coûte 0,0000041667 $ par Go-seconde en plus du prix d'exécution. Pour 10 instances de 1 024 Mo maintenues chaudes 24/7, cela ajoute ~110 $/mois. SnapStart, quand il est disponible pour votre runtime, est presque toujours préférable ; vous ne payez que la snapshot.

Sur GCP, min_instance_count = 1 coûte l'équivalent d'une instance 1 vCPU + 512 Mio tournant 24/7, soit environ 45 $/mois. Sur Azure Flex, les Always Ready instances sont facturées à leur mémoire allouée, 24/7. Le calcul : 2 048 Mo × 730 h × 0,000016 $ = ~24 $/mois par instance.

Egress : le tueur silencieux

Une fonction serverless qui appelle une base RDS/CloudSQL/Azure SQL dans une autre région, ou qui renvoie des payloads volumineux vers Internet, verra sa facture dominée par l'egress avant même les Go-seconde. J'ai vu ce piège tomber sur un client au mois de mars, un endpoint « pas cher » qui envoyait 350 Ko de JSON à chaque appel. Notre analyse détaillée dans les frais de transfert de données cloud en 2026 montre que sur un endpoint retournant 500 Ko × 10 M appels/mois, l'egress représente 450 $ chez AWS, 460 $ chez GCP et 490 $ chez Azure, plus que le compute serverless lui-même.

Logs, traces et métriques

CloudWatch Logs (Lambda), Cloud Logging (Cloud Run) et Application Insights (Azure) facturent l'ingestion et le stockage. Sur du serverless verbeux (une ligne de log par requête, DEBUG activé), attendez-vous à ce que les logs représentent 15 à 30 % de la facture totale. Réduisez le niveau à INFO, configurez une rétention agressive (7 à 30 jours), et échantillonnez les traces.

Quel provider serverless choisir selon le workload ?

Après avoir benchmarké ces trois plateformes sur des dizaines de workloads clients, voici mon cadre de décision honnête, celui que j'utilise avant chaque migration.

APIs synchrones à faible latence

Choisissez AWS Lambda + SnapStart (Java, Python, .NET) ou GCP Cloud Run Functions avec min_instances ≥ 1. Azure Functions Flex est acceptable mais le p99 reste supérieur. Coût cible : 0,20 à 0,50 $ par million de requêtes hors compute.

Traitements batch événementiels

GCP Cloud Run Functions gagne grâce à sa concurrence par instance élevée et à la facturation vCPU dissociée. Un job qui traite 10 000 messages Pub/Sub par instance en parallèle divise vraiment la facture.

ETL et transformations lourdes

Au-delà de 5 minutes d'exécution, Lambda devient limité (15 min max). Cloud Run Functions (60 min HTTP, illimité event-driven) ou Azure Durable Functions (orchestration long-running) sont plus adaptés. Le coût par Go-seconde importe moins que la capacité à finir le job sans partitionnement complexe.

Intégration écosystème existant

Si votre stack est majoritairement AWS (RDS, S3, SQS, EventBridge), Lambda gagne par les latences réseau intra-VPC et la gratuité des transferts intra-région. Idem pour Azure sur .NET, Cosmos DB et Service Bus. Sur du multi-cloud, privilégiez le provider qui héberge la donnée la plus volumineuse — l'egress paiera toujours plus cher que le compute. C'est la seule règle qui n'a jamais été prise en défaut chez mes clients.

Monitorer les coûts serverless : outils et pratiques

Sans monitoring dédié, une fonction mal réglée peut voir sa facture exploser en 24h (boucle infinie sur un event Kinesis, cold start sur DynamoDB non provisionnée, retry en cascade). Trois outils forment un stack solide en 2026 :

• AWS Cost Anomaly Detection + Lambda Insights : détection ML des dérives sur Lambda, avec drill-down par fonction. Gratuit hors Insights (~0,20 $ par fonction/mois).
• GCP Cloud Billing budgets + Cloud Monitoring : alertes email/Pub/Sub sur seuils absolus ou tendances, dashboards par service.
• Vantage, CloudZero, Finout : plateformes FinOps multi-cloud avec unit economics (coût par requête, par tenant, par feature).

Pour un cadre plus large de discipline financière multi-cloud, notre guide sur les Instances Spot AWS, Azure et GCP couvre les patterns de FinOps applicables également au serverless. Enfin, la FinOps Foundation Framework propose une matrice de maturité utile pour structurer une démarche organisationnelle.

Tagger toutes les fonctions

Sans tags de coût (environnement, équipe, produit, feature), la facturation serverless devient rapidement opaque, surtout à l'échelle de 500+ fonctions. Imposez un standard dès le déploiement :

# Exemple Terraform commun aux trois clouds
locals {
  common_tags = {
    Environment = "prod"
    Team        = "checkout"
    Product     = "cart-service"
    Feature     = "coupon-validation"
    CostCenter  = "CC-1042"
  }
}

# AWS Lambda
resource "aws_lambda_function" "handler" {
  # ... config
  tags = local.common_tags
}

# GCP Cloud Run Functions
resource "google_cloudfunctions2_function" "handler" {
  # ... config
  labels = local.common_tags
}

# Azure Functions
resource "azurerm_linux_function_app" "handler" {
  # ... config
  tags = local.common_tags
}

Questions fréquemment posées

AWS Lambda est-il vraiment moins cher que Cloud Functions ?

Pas systématiquement. Sur des invocations courtes (< 200 ms) et à volume élevé, GCP Cloud Run Functions est ~15 à 25 % moins cher que Lambda x86, essentiellement grâce à la concurrence par instance et au free tier plus généreux. Lambda Graviton (arm64) rétrécit l'écart à moins de 10 %. Au-delà, la comparaison dépend de l'egress et des services annexes.

Comment réduire les coûts de AWS Lambda rapidement ?

Trois actions à impact immédiat : migrer vers Graviton (arm64) pour 20 % d'économie sur le compute, exécuter Lambda Power Tuning pour trouver le sweet spot mémoire (souvent 3–4× la valeur intuitive), et souscrire un Compute Savings Plan couvrant vos heures Lambda garanties (17 % à 1 an). Ensemble, ces trois leviers ramènent typiquement la facture Lambda de 35 à 45 %.

Faut-il utiliser Azure Functions Flex Consumption ou Premium ?

Flex Consumption est le nouveau défaut en 2026 pour la plupart des workloads production. Elle offre VNet integration, cold starts réduits, et Always Ready instances à un prix inférieur à Premium. Restez sur Premium uniquement si vous avez besoin de RAM > 4 Go, d'App Service Environment, ou d'une durée d'exécution supérieure à 60 minutes.

Quel est le coût d'un cold start Lambda ?

Un cold start n'est pas facturé en tant que tel : vous payez uniquement les Go-secondes d'exécution. Mais la latence ajoutée (200 à 2 000 ms selon le runtime) peut vous pousser à surallouer la mémoire ou à activer Provisioned Concurrency, ce qui coûte 0,0000041667 $ par Go-s en plus. SnapStart, disponible en 2026 pour Java, Python et .NET, réduit les cold starts à ~10 ms sans surcoût significatif.

Peut-on utiliser des Savings Plans pour Cloud Run Functions ?

GCP n'offre pas de « Savings Plans » sous ce nom, mais les Committed Use Discounts (CUDs) Cloud Run s'appliquent aux Cloud Run Functions. Engagement 1 an = 17 %, 3 ans = 45 %. Vous vous engagez sur des vCPU-heures et Gio-heures par région, non transférables entre régions.