Hébergement du plan Consommation Flex Azure Functions

Consommation flexible est un plan d’hébergement Azure Functions basé sur Linux qui s’appuie sur le modèle de facturation serverless de consommation avec paiement à l’utilisation. Il vous offre davantage de flexibilité et de personnalisation en introduisant la mise en réseau privée, le choix de taille de mémoire pour l’instance, et des fonctionnalités de mise à l'échelle rapides/étendues, tout en restant basé sur un modèle serveurless.

Vous pouvez consulter des exemples de bout en bout qui présentent le plan Flex Consumption dans le référentiel d’exemples de plan Flex Consumption.

Benefits

Le plan Consommation Flex s’appuie sur les points forts du plan Consommation serverless, qui incluent la mise à l’échelle dynamique et la facturation basée sur l’exécution. Avec le plan Consommation Flex, vous bénéficiez également ces fonctionnalités supplémentaires :

• Temps de démarrage à froid réduit : activez les instances toujours prêtes pour atteindre des temps de démarrage plus rapides par rapport au plan Consommation.
• Prise en charge du réseau virtuel : l’intégration de réseau virtuel permet à votre application serverless de s’exécuter dans un réseau virtuel.
• Mise à l'échelle par fonction : chaque fonction de votre application s'adapte indépendamment en fonction de sa charge de travail, ce qui peut entraîner une allocation de ressources plus efficace.
• Gestion améliorée de la concurrence : meilleur traitement des exécutions simultanées avec des paramètres de concurrence configurables par fonction.
• Configuration de la mémoire flexible : Flex Consumption offre plusieurs options de taille d’instance , ce qui vous permet d’optimiser vos besoins en charge de travail spécifiques.

Ce tableau vous aide à comparer directement les fonctionnalités de Consommation Flex avec le plan d’hébergement Consommation :

Feature	Consumption	Flex Consumption
Mettre à l’échelle vers zéro	✅ Oui	✅ Oui
Comportement de mise à l’échelle	Piloté par les événements	Piloté par les événements (rapide)
Réseaux virtuels	❌ Non pris en charge	✅ Pris en charge
Calcul dédié (atténuer les démarrages à froid)	❌ Aucun	✅ Instances toujours prêtes (facultatif)
Billing	Durée d’exécution uniquement	Durée d’exécution + instances toujours prêtes
Instances de scale-out (max)	200	1000

Pour obtenir une comparaison complète du plan Flex Consumption par rapport au plan Consommation et à tous les autres types de plan et d’hébergement, consultez les options d’hébergement et d’échelle de fonction.

Intégration du réseau virtuel

Flex Consumption s’étend sur les avantages traditionnels du plan Consommation en ajoutant la prise en charge de l’intégration de réseau virtuel. Lorsque vos applications s’exécutent dans un plan Consommation Flex, elles peuvent se connecter à d’autres services Azure sécurisés à l’intérieur d’un réseau virtuel. Par ailleurs, cela vous permet de tirer parti de la facturation et de la mise à l’échelle serverless, ainsi que des avantages de la mise à l’échelle et du débit du plan Consommation flexible. Pour plus d’informations, consultez Activer l’intégration de réseau virtuel.

Tailles d’instance

Lorsque vous créez votre application de fonction dans un plan Consommation Flex, vous pouvez sélectionner la taille de mémoire des instances sur lesquelles votre application s’exécute. Consultez Facturation pour savoir comment les tailles de mémoire d’instance affectent les coûts de votre application de fonction.

Actuellement, Flex Consumption offre ces options de taille d’instance :

Mémoire de l’instance (Mo)	Cœurs de processeur
512	0.25
2 048	1
4096	2

Note

Les valeurs de cœur du processeur indiquées sont des allocations classiques pour les instances avec la taille de mémoire spécifiée. Toutefois, les instances initiales peuvent recevoir des allocations de base légèrement différentes pour améliorer les performances. Chaque instance Flex Consumption inclut également 272 Mo supplémentaires de mémoire allouée par la plateforme en tant que mémoire tampon pour les processus système et hôte. Cette mémoire supplémentaire n’affecte pas la facturation et les instances sont facturées en fonction de la taille de mémoire de l’instance configurée indiquée dans le tableau ci-dessus.

Lorsque vous décidez de la taille de mémoire de l’instance à utiliser avec vos applications, voici quelques éléments à prendre en compte :

• La taille de mémoire de l’instance de 2 048 Mo est la valeur par défaut et il convient de l’utiliser pour la plupart des scénarios. Les tailles de mémoire d’instance de 512 Mo et de 4 096 Mo sont disponibles pour les scénarios qui conviennent le mieux aux exigences de concurrence ou de traitement de votre application. Pour plus d’informations, consultez Configurer la mémoire de l’instance.
• Vous pouvez changer la taille de mémoire de l’instance à tout moment. Pour plus d’informations, consultez Configurer la mémoire de l’instance.
• Les ressources d’instance sont partagées entre votre code de fonction et l’hôte Functions.
• Plus la taille de mémoire de l’instance est grande, plus chaque instance peut gérer jusqu’à des exécutions simultanées ou des charges de travail processeur ou mémoire plus intensives. Les décisions de mise à l'échelle spécifiques dépendent de la charge de travail.
• La concurrence par défaut des déclencheurs HTTP dépend de la taille de mémoire de l’instance. Pour plus d’informations, consultez la concurrence du déclencheur HTTP.
• Les processeurs disponibles et la bande passante réseau sont fournis proportionnellement à une taille d’instance spécifique.

Mise à l’échelle par fonction

La concurrence est un facteur clé qui détermine la mise à l’échelle des applications de fonction Flex Consumption. Pour améliorer les performances de mise à l’échelle des applications avec différents types de déclencheurs, le plan Consommation Flex offre un moyen plus déterministe de mettre à l’échelle votre application par fonction.

Ce comportement de mise à l’échelle par fonction fait partie de la plateforme d’hébergement. Vous n’avez donc pas besoin de configurer votre application ou de modifier le code. Pour plus d’informations, consultez la mise à l’échelle par fonction dans l’article sur la mise à l’échelle pilotée par les événements.

Dans la mise à l’échelle par fonction, les décisions sont prises pour certains déclencheurs de fonction selon les agrégations de groupe. Ce tableau montre le jeu défini de groupes de mise à l’échelle de fonction :

Groupes de mise à l’échelle	Déclencheurs dans le groupe	Valeur des paramètres
Déclencheurs HTTP	Déclencheur HTTP Déclencheur SignalR	http
Déclencheurs de Stockage Blob (Basé sur Event Grid)	Déclencheur de stockage Blob	blob
Durable Functions	Déclencheur d’orchestration Déclencheur d’activité Déclencheur d’entité	durable

Toutes les autres fonctions de l’application sont mises à l’échelle individuellement dans leur propre ensemble d’instances, qui sont référencées selon la convention function:<NAMED_FUNCTION>.

Instances toujours prêtes

Flex Consumption inclut une caractéristique toujours prête qui vous permet de choisir des instances qui sont toujours en cours d’exécution et affectées à chacun de vos groupes d'échelle par fonction ou de fonctions. Toujours prêt est une excellente option pour les scénarios où vous avez besoin d’un nombre minimal d’instances toujours prêtes pour gérer les demandes. Par exemple, pour réduire la latence de démarrage à froid de votre application. La valeur par défaut est 0 (zéro).

Par exemple, si vous définissez toujours la valeur 2 pour votre groupe de fonctions HTTP, la plateforme conserve deux instances toujours en cours d’exécution et attribuées à votre application pour vos fonctions HTTP dans l’application. Ces instances traitent vos exécutions de fonction, mais en fonction des paramètres d’accès concurrentiel, la plateforme met à l’échelle au-delà de ces deux instances avec des instances à la demande.

Pas moins de deux instances toujours prêtes peuvent être configurées par fonction ou groupe de fonctions pendant que la redondance de zone est activée.

Pour savoir comment configurer des instances toujours prêtes, consultez Définir le nombre d’instances toujours prêtes.

Concurrency

La concurrence fait référence au nombre d’exécutions parallèles d’une fonction sur une instance de votre application. Vous pouvez définir un nombre maximal d’exécutions simultanées que chaque instance doit gérer à tout moment. La concurrence a un effet direct sur la façon dont votre application est mise à l’échelle, car à des niveaux de concurrence inférieurs, vous avez besoin d’instances supplémentaires pour gérer la demande basée sur les événements pour une fonction. Bien que vous puissiez contrôler et affiner la concurrence, nous fournissons des valeurs par défaut qui fonctionnent pour la plupart des cas.

Pour savoir comment définir des limites de concurrence pour les fonctions de déclencheur HTTP, consultez Définir des limites de concurrence HTTP. Pour savoir comment définir des limites d’accès concurrentiel pour les fonctions de déclencheur non HTTP, consultez La mise à l’échelle de base cible.

Deployment

Les déploiements dans le plan Consommation flexible suivent un seul chemin et les paramètres d’application n’ont plus besoin d’influencer le comportement du déploiement. Une fois le code de votre projet généré et compressé dans un package d’application, il est déployé sur un conteneur de stockage blob. Au démarrage, votre application obtient le package et exécute votre code de fonction à partir de ce package. Par défaut, le même compte de stockage utilisé pour stocker les métadonnées d’hôte interne (AzureWebJobsStorage) est également utilisé comme conteneur de déploiement. Toutefois, vous pouvez utiliser un autre compte de stockage ou choisir votre méthode d’authentification préférée en configurant les paramètres de déploiement de votre application.

Déploiements sans temps d’arrêt

Note

Les déploiements sans temps d’arrêt avec mises à jour progressives sont actuellement en aperçu public.

Flex Consumption fournit des déploiements sans temps d’arrêt via des mises à jour propagées en tant que stratégie de mise à jour de site, ce qui permet aux déploiements de code et aux modifications de configuration d’être appliqués progressivement entre les instances sans interrompre l’exécution de la fonction. D’autres plans d’hébergement utilisent des emplacements de déploiement pour réduire les temps d’arrêt pendant les déploiements. Pour connaître les options de déploiement de tous les plans d’hébergement, consultez optimiser les déploiements.

Billing

Il existe deux modes permettant de déterminer vos coûts lors de l’exécution de vos applications dans le plan Consommation Flex. Chaque mode est déterminé par instance.

Mode de facturation	Description
À la demande	Lors de l’exécution en mode à la demande , vous êtes facturé uniquement pendant la durée pendant laquelle votre code de fonction s’exécute sur vos instances disponibles. En mode demande, aucun nombre minimal d’instances n’est requis. Vous êtes facturé pour : • Quantité totale de mémoire provisionnée alors que chaque instance à la demande exécute activement des fonctions (en Go-secondes), moins une allocation gratuite de Go-s par mois. • Le nombre total d’exécutions, moins un octroi gratuit (nombre) d’exécutions par mois.
Toujours prêt	Vous pouvez configurer une ou plusieurs instances affectées à des types de déclencheurs spécifiques (HTTP/Durable/Blob) et à des fonctions individuelles, qui sont toujours disponibles pour gérer les requêtes. Lorsque des instances toujours prêtes sont activées, vous êtes facturé pour : • Quantité totale de mémoire provisionnée sur toutes vos instances toujours prêtes, appelée base de référence (en Go-secondes). • Quantité totale de mémoire provisionnée pendant le temps où chaque instance toujours prête est en cours d’exécution active (en Go-secondes). • Le nombre total d'exécutions. Dans la facturation toujours prête, il n’y a pas d’octrois gratuits.

Pour obtenir les informations les plus récentes sur la tarification de l’exécution, les coûts de référence de « toujours prêtes » et les octrois gratuits pour les exécutions à la demande, consultez la page de tarification d’Azure Functions.

La période d’exécution facturable minimale pour les deux modes d’exécution est de 1 000 ms. Au-delà, la période d’activité facturable est arrondie à la plus proche de 100 ms. Vous trouverez des détails sur les compteurs de facturation du plan Flex Consumption dans la référence de surveillance.

Pour plus d’informations sur la façon dont les coûts sont calculés lorsque vous exécutez un plan Flex Consumption, y compris des exemples, consultez les coûts basés sur la consommation et l’affichage des données relatives aux coûts.

Versions de piles de langage prises en charge

Ce tableau présente les versions de la pile de langage actuellement prises en charge pour les applications Consommation flexible :

Ensemble de technologies linguistiques	Version requise
C# (modèle de travailleur isolé)1	.NET 8, .NET 9, .NET 10
Java	Java 11, Java 17, Java 21
Node.js	Node.js 20, Node.js 22
PowerShell	PowerShell 7.4
Python	Python 3.10, Python 3.11, Python 3.12

1. Le modèle in-process C# n’est pas pris en charge. Vous devez plutôt migrer votre projet .NET vers le modèle worker isolé.

Quotas de mémoire régionaux de l’abonnement

Le plan Flex Consumption dispose d’un quota basé sur la mémoire qui limite la quantité de calcul que toutes vos applications Flex Consumption peuvent utiliser en même temps dans une région et un abonnement spécifiques. Imaginez que vous disposez d’un compartiment de mémoire mesuré en Go ou en cœurs d’UC pour l’ensemble de votre abonnement dans une région. Toutes vos applications Flex Consumption de cette région partagent ce compartiment. Si vos applications Flex Consumption essaient d’utiliser plus que le quota autorisé, certaines exécutions peuvent être retardées ou limitées dans leur mise à l'échelle, mais vous ne serez pas empêché de créer ou déployer vos applications.

Actuellement, chaque région d’un abonnement donné dispose d’un quota par défaut du moindre de 512,000 MB ou 250 cœurs pour toutes les instances d’applications s’exécutant sur des plans Flex Consumption. Ces quotas signifient que, dans un abonnement et une région donnés, vous pouvez avoir n’importe quelle combinaison de tailles et de nombres de mémoire d’instance, tant qu’ils restent sous les limites de quota. Par exemple, dans chacun de ces scénarios, le quota est atteint et les applications de la région arrêtent la mise à l’échelle :

• Vous avez une application de 512 Mo mise à l’échelle vers 250 instances et une deuxième application de 512 Mo mise à l’échelle vers 750 instances.
• Vous disposez d’une application de 512 MB mise à l’échelle vers 1 000 instances.
• Vous avez une application de 2 048 Mo mise à l’échelle pour 100 instances et une deuxième application de 2 048 Mo mise à l’échelle pour 150 instances
• Vous disposez d’une application de 2 048 MB qui a été augmentée à 250 instances.
• Vous avez une application de 4 096 Mo qui a été mise à l’échelle à 125 instances
• Vous avez une application de 4 096 Mo mise à l’échelle à 100 et une application de 2 048 Mo mise à l’échelle à 50 instances

Les applications Consommation flexible mises à l’échelle à zéro, ou les instances marquées pour être mises à l’échelle et supprimées, ne sont pas comptabilisées dans le quota. Ce quota peut être augmenté pour permettre à vos applications Consommation flexible de continuer à se mettre à l’échelle, en fonction de vos besoins. Si vos applications nécessitent un quota plus important, créez un ticket de support.

Propriétés et paramètres déconseillés

Dans le plan Flex Consumption, la plupart des paramètres d’application standard et des propriétés de configuration de site sont déconseillés ou ont été déplacées et ne doivent pas être utilisées lors de l’automatisation de la création de ressources d’application de fonction. Pour plus d’informations, consultez Dépréciations du plan Consommation flexible.

Considerations

Gardez à l’esprit ces autres considérations lors de l’utilisation du plan Consommation Flex :

• Applications par plan : une seule application est autorisée par plan Flex Consumption.
• Hôte : Il existe un délai d’attente de 30 secondes pour l’initialisation des applications. Lorsque votre application de fonction prend plus de 30 secondes pour démarrer, vous pouvez voir les entrées System.TimeoutException liées à gRPC journalisées. Actuellement, vous ne pouvez pas configurer ce délai d’expiration. Pour plus d’informations, consultez cet élément de travail hôte.
• Durable Functions : Le stockage Azure est actuellement le seul fournisseur de stockage pris en charge pour Durable Functions lorsqu’il est hébergé dans le plan Flex Consumption. Consultez les recommandations lors de l’hébergement de Fonctions durables dans le plan Flex Consumption.
• Intégration de réseau virtuel Vérifiez que le Microsoft.App fournisseur de ressources Azure est activé pour votre abonnement en suivant ces instructions. La délégation de sous-réseau nécessaire pour les applications Consommation flexible est Microsoft.App/environments.
• Déclencheurs : bien que tous les déclencheurs soient entièrement pris en charge dans un plan Flex Consumption, le déclencheur de stockage Blob prend uniquement en charge la source Event Grid. Les applications de fonction non C# doivent utiliser la version [4.0.0, 5.0.0) du bundle d’extensions ou une version ultérieure.
• Régions : toutes les régions ne sont actuellement pas prises en charge. Pour en savoir plus, consultez Afficher les régions actuellement prises en charge.
• Déploiements : les emplacements de déploiement ne sont actuellement pas pris en charge. Pour les déploiements sans temps d’arrêt avec Flex Consumption, consultez les stratégies de mise à jour du site dans Flex Consumption.
• Stockage Azure en tant que partage local : les partages de fichiers NFS ne sont pas disponibles pour Flex Consumption. Seuls les blobs SMB et Azure (en lecture seule) sont pris en charge.
• Mise à l'échelle : le seuil maximal le plus bas est actuellement 40. La valeur la plus élevée actuellement prise en charge est 1000.
• Dépendances managées : les dépendances managées dans PowerShell ne sont pas prises en charge par Flex Consumption. Vous devez au lieu de cela charger des modules avec du contenu de l’application.
• Certificats : le chargement de certificats avec le paramètre d’application WEBSITE_LOAD_CERTIFICATES, les certificats managés, les certificats app service et d’autres fonctionnalités basées sur des certificats de plateforme comme endToEndEncryptionEnabled ne sont actuellement pas pris en charge.
• Fuseaux horaires : les paramètres WEBSITE_TIME_ZONE et TZ de l’application ne sont actuellement pas pris en charge lors de l’exécution sur le plan Flex Consumption.

Articles connexes

Options d’hébergement Azure FunctionsCréer et gérer des applications de fonction dans le plan Flex Consumption