Décodage des prix sans serveur : un guide complet sur AWS, Azure et Google Cloud

Le Cloud computing a fondamentalement changé la façon dont les organisations architectent, déploient et écaillent les applications. Parmi les offres les plus transformatives, on trouve le calcul sans serveur, qui absorbe entièrement la gestion de l'infrastructure et ne facture que pour les ressources consommées pendant l'exécution. Ce modèle de paiement par usage peut réduire considérablement les coûts par rapport aux fournitures traditionnelles, mais seulement si vous comprenez les structures de tarification nuancées qui l'accompagnent.

Avant de plonger dans les spécificités du fournisseur, il est important de noter que le prix sans serveur est rarement un simple coût par invocation. Chaque fournisseur couche dans des dimensions telles que la durée d'exécution, l'allocation de mémoire, la concurrence fournie, l'évacuation du réseau, et même le nombre de ressources utilisées (comme le stockage ou les API).

AWS Lambda: Le leader du marché

AWS Lambda, lancé en 2014, a établi la norme pour les tarifs Function-as-a-Service (FaaS). Son modèle est simple à la surface, mais comprend des nuances critiques qui influent sur les factures du monde réel.

Composantes de base de la tarification

  • Demandes : Les frais de SAF par million de demandes. Les 1 millions de demandes par mois sont gratuites. Après cela, le taux est de 0,20 $ par million de demandes dans la plupart des régions.
  • Durée:[ C'est le plus gros facteur de coût pour de nombreuses charges de travail. La durée est mesurée en GB-secondes, qui multiplie la mémoire attribuée (en GB) par le temps d'exécution (en secondes), arrondi à la milliseconde la plus proche. Le prix typique est $0.0000166667 par GB-seconde pour l'architecture x86. Avec 128 MB (0,125 GB) de mémoire, un million de secondes de coûts d'exécution environ $2.08. Avec 1 Go de mémoire, la même durée coûte $16.67.
  • Concurrence prévue:[ Si vous devez préchauffer les fonctions pour éviter les démarrages à froid, vous payez pour la concordance prévue même lorsque la fonction est inactive. Ceci est facturé par seconde GB de capacité prévue, indépendamment de l'utilisation réelle, plus les frais standard de demande et de durée lorsque la fonction fonctionne.

Coûts supplémentaires souvent surestimés

  • Égrès réseau: Les données transférées hors du SFA vers Internet ou vers d'autres régions sont facturées à la norme EC2 taux de transfert de données (généralement 0,09 $ par GB pour les 10 premiers TB).
  • Stockage externe et API : Lambda travaille souvent en collaboration avec DynamoDB, S3 ou API Gateway. Chacun de ces services a ses propres prix (p. ex., unités de capacité de lecture/écriture DynamoDB, demandes S3 PUT/GET). API Gateway frais par appel API, avec des coûts allant de $1.00 à $3.50 par million de demandes selon la région et le cache.
  • Lambda@Edge: Lors de l'exécution des fonctions aux emplacements de bord de CloudFront, le prix diffère. Les demandes coûtent 0,60 $ par million, et la durée est de 0,00005001 $ par 128 Mo-seconde, ce qui représente environ trois fois le tarif standard de Lambda.

Pour une ventilation détaillée, consultez toujours la page de prix officielle AWS Lambda.

Fonctions Azure: Régimes de consommation et de primes

Azure Functions utilise un modèle similaire basé sur la consommation, mais ajoute un plan Premium qui élimine les démarrages à froid et offre des instances dédiées. Comprendre quel plan vous choisissez est essentiel à la précision des coûts.

Prix du plan de consommation

  • Compte d'exécution: Les premières 1 million d'exécutions par mois sont gratuites.
  • Ressource Consommation (GB-secondes):[ Le niveau gratuit comprend 400 000 Go-secondes par mois. Par-delà cela, le taux est $0.000016 par GB-seconde. Ceci est presque identique à la durée de prix d'AWS Lambda, mais notez que le temps d'exécution des tours Azure est de 100 millisecondes (pour des durées inférieures à 10 secondes) ou à la seconde la plus proche (pour des durées plus longues).

Prix du régime de primes

Azure Functions Premium est idéal pour les charges de travail qui nécessitent une latence prévisible, des instances plus puissantes, ou une connectivité réseau virtuelle.

  • Vous payez pour un nombre de base d'instances toujours prêtes (minimum 1) à un taux horaire fixe par vCPU et mémoire (environ 0,076 $ par vCPU-heure et 0,009 $ par GB-heure pour la première vCPU et 2 Go).
  • Les autres cas s'évaluent sur demande avec des prix de pointe supérieurs à la consommation mais inférieurs aux cas toujours en vigueur.
  • Le nombre et la durée de l'exécution sont également facturés, mais à des taux réduits (par exemple, 0,01 $ par million d'exécutions pour Premium).

Coûts cachés à surveiller

  • Storage et Bloc Triggers: Azure Functions utilisent souvent Blob Storage pour les déclencheurs. Chaque balayage de blob ajoute aux coûts de transaction de stockage, qui peuvent s'accumuler pour les flux d'événements à volume élevé.
  • Si vous hébergez vos fonctions sur un plan de service App (infrastructure dédiée), vous êtes facturé pour le calcul et la mémoire du plan, indépendamment de l'exécution de la fonction. Ce n'est pas vraiment sans serveur, mais il offre des coûts prévisibles.
  • Transfert de données:[ Comme AWS, les frais d'azur pour les transferts de données sortants. Les tarifs commencent à $0.087 par GB pour les 10 premiers To, mais peuvent varier selon la région.

Toujours se référer à la page de prix Azure Fonctions pour les tarifs courants.

Fonctions Google Cloud et Cloud Run: une approche conteneurisée

Google Cloud offre deux services de calcul primaire sans serveur : les fonctions Cloud (similaires aux fonctions Lambda et Azure) et Cloud Run (conteneurs sans serveur).

Fonctions Cloud (1er et 2e génération)

  • Invocations: Le niveau gratuit comprend 2 millions d'invocations par mois. Après cela, 0,40 $ par million d'invocations.
  • Temps de calcul (CPU-secondes et GB-secondes):[ Facturé séparément pour le CPU et la mémoire. Pour la 1ère génération, le taux est de 0,0000025 $ par seconde GHz et de 0,0000025 $ par seconde GB. Pour la 2ème génération, le prix est plus granulaire: 0,000016 $ par vCPU-seconde et 0,0000025 $ par seconde GB. Cela signifie qu'une fonction 1 vCPU, 2 Go fonctionnant pendant une seconde coûterait 0,000021 $ en temps de calcul seul (plus invocation).
  • Le réseau: Google Cloud comprend un généreux niveau gratuit pour l'évacuation du réseau (1 Go par mois pour toutes les destinations combinées). Après cela, l'évacuation vers Internet coûte 0,12 $ par Go pour les 10 premiers To, qui est plus élevé que AWS et Azure. Considérez cela si votre fonction sert des API externes avec des tailles de charge utile importantes.

Nuage (entièrement géré)

Cloud Run résume le temps d'exécution du conteneur et ne facture que les ressources consommées pendant le traitement des demandes, plus un petit prix pour les instances inactives qui sont conservées quelques minutes après la dernière demande (le prix basé sur la demande est de 0,000016 $ par vCPU-seconde et 0,0000025 $ par GB-seconde, identique aux fonctions Cloud 2nd gen). Notez que Cloud Run facture également le temps de démarrage du conteneur si un démarrage froid survient, ce qui n'est pas facturé pour les fonctions Cloud sauf si l'on utilise la concurrence.

Pièges à coûts communs

  • Mémoire Surdimensionnement:[ Google Cloud , prix est directement proportionnel à la mémoire et CPU. La sur-provisionnement de la mémoire pour des fonctions triviales peut doubler vos coûts de calcul.
  • Connecteur VPC:[ Si votre fonction sans serveur a besoin d'accéder aux ressources à l'intérieur d'un VPC, vous devez fournir un connecteur VPC qui coûte 0,026 $ l'heure plus les frais de traitement des données.
  • Cloud Scheduler & Pub/Sub: Le déclenchement d'une fonction via Cloud Scheduler ou Pub/Sub entraîne des coûts supplémentaires par exécution d'un travail et par message, respectivement.

Pour connaître les prix exacts, visitez Google Cloud Functions pricing[ et Cloud Run pricing[.

Comparaison des trois : Où les vraies différences se situent-elles?

Bien que les prix de base des trois fournisseurs soient remarquablement semblables – environ 0,20 $ par million de demandes et 0,000016 $ par seconde GB – les différences de coûts réels découlent de :

  • Généralité de niveau gratuit: Google Cloud offre 2 millions d'invocations par mois gratuitement, le double des 1 millions d'AWS et d'Azure. Pour les applications à faible trafic, Google Cloud peut être le moins cher.
  • Granularité de la facturation: AWS facture maintenant par milliseconde, Azure tourne à 100ms (ou 1s), et Google tourne à 100ms pour les fonctions Cloud mais par seconde pour les fonctions Cloud Run. Pour les fonctions qui fonctionnent pendant quelques millisecondes, AWS a un bord.
  • Coûts de concurrence prévus:[ Le prix de concurrence prévu par AWS est relativement élevé; le plan Azure Premium offre un taux horaire plus prévisible; Google Cloud="s Cloud Run permet des paramètres de min-instance sans frais supplémentaires pour la capacité de ralenti (bien que vous payez pour CPU/Mémory alloué même lorsque vous êtes inactif).
  • Prix d'entrée:[ Google Cloud est le plus cher pour les données sortantes (0,12 $/GB vs 0,09 $ pour AWS et 0,087 $ pour Azure). Si vos fonctions répondent fréquemment avec de grandes charges utiles, considérez AWS ou Azure.

Stratégies financières et architecturales pour le contrôle des coûts

Comprendre les prix n'est que la moitié de la bataille. Les tactiques suivantes vous aideront à garder les coûts sans serveur prévisible, surtout que votre application balance.

1. Profilez vos fonctions avec le traçage

Utilisez des outils de traçage distribués (AWS X-Ray, Azure Application Insights, Google Cloud Trace) pour identifier les fonctions à durées inattendues ou à usage excessif de la mémoire. Une seule fonction inefficace peut dominer votre facture. Une fois identifiée, optimiser le code (p. ex. utiliser le pooling de connexion, réduire le chargement de dépendance) ou augmenter la mémoire pour accélérer l'exécution – parfois une augmentation de mémoire réduit le coût total parce que la durée diminue de façon disproportionnée.

2. Mettre en œuvre l'élargissement sur demande avec soin

Les plates-formes sans serveur peuvent être à l'échelle automatique, mais une échelle non contrôlée peut entraîner des pics de coûts pendant les rafales de trafic. Définissez des limites de concurrence par fonction pour plafonner les invocations simultanées maximales. Pour AWS, utilisez la concurrence réservée; pour Azure, définissez des limites d'échelle d'application de fonction; pour Google Cloud, configurez des instances max par service.

3. Utilisez Pay-as-You-Go avec des rabais réservés ou des rabais d'engagement

AWS propose des plans d'épargne calcul qui s'appliquent à la durée de Lambda (à un rabais de 17 à 40 % en échange d'un engagement de 1 ou 3 ans). Azure offre des tarifs d'instance réservée aux fonctions de plan Premium, et Google Cloud a engagé des rabais pour l'utilisation de Cloud Run (si vous utilisez aussi GKE ou Calculer Engine).

4. Conception pour l'efficacité des lots

Si vous traitez de nombreux petits événements (par exemple, des messages provenant d'une file d'attente), vous pouvez les classer en moins d'invocations. Par exemple, AWS Lambda peut traiter des lots allant jusqu'à 10 000 messages SQS par invocation. Cela réduit le nombre de demandes, en économisant les frais par invocation, tandis que le coût de la durée n'augmente que légèrement.

5. Surveiller et alerter les anomalies

La plupart des fournisseurs de cloud vous permettent de fixer des seuils budgétaires mensuels et de déclencher des alertes lorsque les dépenses dépassent 50%, 80% ou 100% du budget. Utilisez des outils de surveillance cloud-native (AWS Cost Explorer, Azure Cost Management, Google Cloud Billing) pour suivre les dépenses sans serveur par fonction ou service.

Scénarios du monde réel : quand les prix sans serveur surprennent

Pour illustrer, considérez une fonction simple de redimensionnement d'images qui traite 10 millions d'images par mois. Sur AWS Lambda avec une mémoire de 1 Go et un temps d'exécution moyen de 200 ms:

  • Demandes : (10M – 1M gratuit) * 0,20 $/M = 1,80 $
  • Durée : 10M * 0,2s = 2M secondes. Go-secondes = 1 Go * 2M = 2M. Coût = 2M * 0,000016667 = 33,33 $
  • Calcul total : 35,13 $ par mois (plus les coûts S3 pour la source et la production).

Sur Google Cloud Fonctions avec les mêmes spécifications (2M invocations gratuites, durée de 2M secondes) :

  • Demandes : (10M – 2M) * 0,40 $/M = 3,20 $
  • Go-secondes : 2M * 0,0000025 = 5,00 $
  • CPU-secondes : supposons 1 GHz = 2M * 0,0000025 = 5,00 $
  • Calcul total : - 13,20 $

Google Cloud serait moins cher pour cette charge de travail. Mais si le traitement d'image implique le téléchargement d'un fichier de 5 Mo à partir d'une source externe, l'évacuation sur Google Cloud pourrait ajouter $6 par Go (5 MB * 10M = 50 000 Go? Attendre: 5 Mo par image * 10 millions = 50 téraoctets; ce serait astronomiquement élevé. Plus réaliste: fonction produit une vignette de 200 KB. Ensuite l'évacuation est de 2 To. Sur AWS egress: 1 TB $0.09/GB = 90, 1 TB $0.085 = 85, total $75. Sur Google: 1 TB gratuit? En fait, l'évacuation gratuite de Google est de 1 Go par mois pour toutes les destinations, vous payez $0.12/GB pour les 10 premiers TB = 240+.

Tout mettre en œuvre

L'informatique sans serveur offre d'énormes avantages sur les coûts de l'infrastructure traditionnelle lorsque les modèles s'alignent – un trafic faible et variable, des fonctions courtes et un code efficace. Mais les modèles de tarification ne sont pas monolithiques. AWS Lambda excelle avec une facturation fine et un écosystème mature. Azure Functions offre une flexibilité grâce à la consommation et des plans premium, avec une forte intégration dans l'écosystème Microsoft.

Pour faire un choix éclairé, modélisez votre utilisation prévue parmi les trois fournisseurs, y compris les services auxiliaires tels que le stockage, les bases de données et le transfert de données. Utilisez les calculateurs de prix officiels (chaque fournisseur en offre un) et testez avec des charges réelles dans un environnement de bac à sable. En comprenant ces modèles de prix à un niveau granulaire, vous pouvez concevoir une architecture sans serveur qui reste non seulement évolutive et réactive, mais également financièrement durable à mesure que votre entreprise grandit.