Options d’hébergement Azure Functions

Article
11/04/2024

Lorsque vous créez une application de fonction dans Azure, vous devez choisir un plan d’hébergement pour votre application. Azure vous fournit ces options d’hébergement pour votre code de fonction :

Option d’hébergement	Service	Disponibilité	Support pour les conteneurs
Plan Consommation flexible	Azure Functions	Aperçu	Aucun
Plan Premium	Azure Functions	Disponibilité générale (GA)	Linux
Plan dédié	Azure Functions	GA	Linux
Applications de conteneur	Azure Container Apps	GA	Linux
Plan Consommation	Azure Functions	GA	Aucune

Les options d’hébergement Azure Functions sont facilitées par l’infrastructure Azure App Service, sur les machines virtuelles Linux comme Windows. L’option d’hébergement que vous choisissez détermine les comportements suivants :

La mise à l’échelle de votre Function App.
Les ressources disponibles pour chaque instance de Function App.
La prise en charge des fonctionnalités avancées, notamment la connectivité du réseau virtuel Azure.
Prise en charge des conteneurs Linux.

Le plan que vous choisissez a également un impact sur les coûts d’exécution de votre code de fonction. Pour plus d'informations, consultez Facturation.

Cet article fournit une comparaison détaillée entre les différentes options d’hébergement. Pour en savoir plus sur l’exécution et la gestion de votre code de fonction dans les conteneurs Linux, consultez Prise en charge des conteneurs Linux dans Azure Functions.

Vue d’ensemble des plans

Voici un résumé des avantages des différentes options proposées pour votre hébergement Azure Functions :

Option	Avantages
Plan Consommation flexible	Bénéficiez d'une mise à l'échelle horizontale rapide avec des choix de calcul, une mise en réseau virtuelle et une facturation à l'utilisation. Dans le plan Consommation Flex, les instances de l’hôte Functions sont ajoutées et supprimées dynamiquement en fonction de la concurrence par instance configurée et du nombre d’évènements entrants. ✔ Réduisez les démarrages à froid en spécifiant un certain nombre d’instances pré-approvisionnées (toujours prêtes). ✔ Prend en charge la mise en réseau virtuel pour renforcer la sécurité. ✔ Payez uniquement lorsque vos fonctions s’exécutent. ✔ Mise à l’échelle automatique, même pendant les périodes de charge élevée.
Plan Premium	Mise à l’échelle automatique selon la demande à l’aide de Workers préchauffés qui exécutent des applications sans délai après leur inactivité, exécution sur des instances plus puissantes et connexion à des réseaux virtuels. Envisagez le plan Premium d’Azure Functions dans les situations suivantes : ✔Vos applications de fonction s’exécutent en continu ou presque. ✔ Vous voulez plus de contrôle de vos instances et voulez déployer plusieurs applications de fonction sur le même plan avec une mise à l’échelle pilotée par les évènements. ✔ Vous disposez d’un grand nombre d’exécutions de petite taille et d’une facture d’exécution élevée, mais de peu de Go par seconde dans le plan Consommation. ✔ Vous avez besoin de plus d’options de processeur ou de mémoire que celles fournies par les plans de consommation. ✔Votre code exige une durée d’exécution supérieure à celle qui est autorisée dans le plan de consommation. ✔ Vous avez besoin d’une connectivité de réseau virtuel. ✔ Vous voulez fournir une image Linux personnalisée dans laquelle exécuter vos fonctions.
Plan dédié	Exécutez vos fonctions au sein d’un plan App Service aux tarifs habituels du plan App Service. Idéal pour les scénarios de longue durée où l’extension Durable Functions ne peut pas être utilisée. Envisagez un plan App Service dans les situations suivantes : ✔ Vous disposez de machines virtuelles existantes et sous-utilisées qui exécutent déjà d’autres instances App Service. ✔ Vous devez avoir une facturation entièrement prévisible, ou vous devez mettre à l’échelle manuellement des instances. ✔ Vous voulez exécuter plusieurs applications web et applications de fonction sur le même plan ✔ Vous avez besoin d’accéder à des choix de taille de calcul plus importants. ✔ Isolation de calcul complète et accès réseau sécurisé fourni par un App Service Environment (ASE). ✔ Utilisation très élevée de la mémoire et mise à l’échelle élevée (ASE).
Applications de conteneur	Créez et déployez des applications de fonction conteneurisées dans un environnement entièrement managé hébergé par Azure Container Apps. Utilisez le modèle de programmation Azure Functions pour créer des applications de fonction natives cloud, basées sur les évènements et serverless. Exécutez vos fonctions en même temps que d’autres microservices, API, sites web et flux de travail en tant que programmes hébergés par des conteneurs. Envisagez d’héberger vos fonctions sur Container Apps dans les situations suivantes : ✔ Vous voulez empaqueter des bibliothèques personnalisées avec votre code de fonction pour prendre en charge les applications métier. ✔ Vous devez migrer l’exécution du code depuis des applications locales ou héritées vers des microservices natifs cloud s’exécutant dans des conteneurs. ✔ Lorsque vous voulez éviter la surcharge et la complexité de la gestion des clusters Kubernetes et du calcul dédié. ✔ Vos fonctions ont besoin d’une puissance de traitement haut de gamme fournie par des ressources de calcul GPU dédiées.
Plan Consommation	Payez des ressources de calcul uniquement lorsque vos fonctions s’exécutent (paiement à l’utilisation) avec une mise à l’échelle automatique. Dans le plan de consommation, les instances de l’hôte Functions sont ajoutées et supprimées de façon dynamique en fonction du nombre d’événements entrants. ✔ Plan d’hébergement par défaut qui fournit un véritable hébergement serverless. ✔ Paiement uniquement en cas d’exécution de vos fonctions. ✔ Mise à l’échelle automatique, même pendant les périodes de charge élevée.

Les tableaux restants de cet article comparent les options d’hébergement en fonction de différentes fonctionnalités et comportements.

Prise en charge du système d’exploitation

Ce tableau présente la prise en charge des systèmes d’exploitation pour les options d’hébergement.

Hébergement	Déploiement Linux¹	Déploiement Windows²
Plan Consommation flexible	✅ Code uniquement ❌ Conteneur (non pris en charge)	❌ Non pris en charge
Plan Premium	✅ Code uniquement ✅ Conteneur	✅ Code uniquement
Plan dédié	✅ Code uniquement ✅ Conteneur	✅ Code uniquement
Applications de conteneur	✅ Conteneur uniquement	❌ Non pris en charge
Plan Consommation	✅ Code uniquement ❌ Conteneur (non pris en charge)	✅ Code uniquement

Linux est le seul système d’exploitation pris en charge pour la pile d’exécution Python.
Les déploiements Windows sont du code uniquement. Functions ne prend actuellement pas en charge les conteneurs Windows.

Durée du délai d’expiration du conteneur de fonctions

La durée du délai d’expiration pour les fonctions d’une application de fonction est définie par la propriété functionTimeout dans le fichier projet host.json. Cette propriété s’applique spécifiquement aux exécutions de fonction. Une fois que le déclencheur démarre l’exécution d’une fonction, la fonction doit retourner/répondre dans la durée du délai d’expiration. Pour éviter les délais d’expiration, il est important d’écrire des fonctions robustes. Pour plus d’informations, consultez Améliorer les performances et la fiabilité d’Azure Functions.

Le tableau suivant indique les valeurs par défaut et maximales (en minutes) pour des plans spécifiques :

Plan	Default	Maximum¹
Plan Consommation flexible	30	Illimité²
Plan Premium	30⁴	Illimité²
Plan dédié	30⁴	Illimité³
Applications de conteneur	30	Illimité⁵
Plan Consommation	5	10

Quel que soit le paramètre de délai d’expiration du conteneur de fonctions, 230 secondes est le temps maximum que peut prendre une fonction déclenchée via HTTP pour répondre à une demande. Cela est dû au délai d’inactivité par défaut d’Azure Load Balancer. Pour des temps de traitement plus longs, pensez à utiliser un modèle asynchrone Durable Functions ou différez le travail actuel et renvoyez une réponse immédiate.
Il n’existe aucun délai maximal d’expiration d’exécution appliqué. Toutefois, la période de grâce donnée à une exécution de fonction est de 60 minutes pendant le scale-in pour les plans Consommation flexible et Premium, et une période de grâce de 10 minutes est donnée pendant les mises à jour de la plateforme.
Nécessite que le plan App Service soit défini sur Always On. Une période de grâce de 10 minutes est donnée pendant les mises à jour de la plateforme.
Le délai d’expiration par défaut pour la version 1.x du runtime Functions est illimité.
Lorsque le nombre minimal de réplicas est défini sur zéro, le délai d’expiration par défaut dépend des déclencheurs spécifiques utilisés dans l’application.

Support multilingue

Pour plus d’informations sur la prise en charge actuelle de la pile de langues natives dans Functions, consultez Langues prises en charge dans Azure Functions.

Scale

Le tableau suivant compare les comportements de mise à l’échelle des différents plans d’hébergement.
Le nombre maximal d’instances est donné sur une base d’application par fonction (Consommation) ou par plan (Premium/Dédié), sauf indication contraire.

Plan	Scale-out	Nombre maximal d’instances
Plan Consommation flexible	Mise à l’échelle par fonction. Les décisions de mise à l’échelle basées sur les évènements sont calculées par fonction, ce qui offre un moyen plus déterministe de mettre à l’échelle les fonctions dans votre application. À l’exception de HTTP, stockage Blob (Event Grid) et Durable Functions, tous les autres types de déclencheurs de fonction dans votre application sont mis à l’échelle sur des instances indépendantes. Tous les déclencheurs HTTP de votre application sont mis à l’échelle en tant que groupe sur les mêmes instances, ainsi que tous les déclencheurs de stockage d’objets blob (Event Grid). Tous les déclencheurs Durable Functions partagent également des instances et sont mis à l’échelle ensemble.	Limité uniquement par l’utilisation totale de la mémoire de toutes les instances d’une région donnée. Pour plus d’informations, consultez Mémoire d’instance.
Plan Premium	Basé sur les événements. Effectuer un scale-out automatique, même pendant les périodes de charge élevée L’infrastructure Azure Functions met à l’échelle les ressources de processeur et de mémoire en ajoutant des instances de l’hôte Functions selon le nombre d’événements qui déclenchent ses fonctions.	Windows: 100 Linux: 20 à 100²
Plan dédié³	Manuel/Mise à l’échelle automatique	10-30 100 (ASE)
Applications de conteneur	Basé sur les événements. Effectuer un scale-out automatique, même pendant les périodes de charge élevée L’infrastructure Azure Functions met à l’échelle les ressources de processeur et de mémoire en ajoutant des instances de l’hôte Functions selon le nombre d’événements qui déclenchent ses fonctions.	300 – 1 000⁴
Plan Consommation	Basé sur les événements. Effectue un scale-out automatique, même pendant les périodes de charge élevée. L’infrastructure Functions met à l’échelle les ressources de processeur et de mémoire en ajoutant davantage d’instances de l’hôte Functions, en fonction du nombre d’évènements déclencheurs entrants.	Windows: 200 Linux: 100¹

Pendant le scale-out, il existe actuellement une limite de 500 instances par abonnement et par heure pour les applications Linux sur un plan Consommation.
Dans certaines régions, les applications Linux sur un plan Premium peuvent être mises à l’échelle vers 100 instances. Pour plus d’informations, consultez l’article sur le plan Premium.
Pour connaître les limites spécifiques des différentes options du plan App Service, consultez Limites du plan App Service.
Sur Container Apps, la valeur par défaut est de 10 instances, mais vous pouvez définir le nombre maximal de réplicas, qui a un maximum global de 1 000. Ce paramètre est respecté tant qu’il y a suffisamment de quota de cœurs disponibles. Quand vous créez votre application de fonction depuis le portail Azure, vous êtes limité à 300 instances.

Comportement du démarrage à froid

Plan	Détails
Plan Consommation flexible	Prend en charge les instances toujours prêtes pour réduire le délai lors de l’approvisionnement de nouvelles instances.
Plan Premium	Prend en charge les instances toujours prêtes pour éviter les démarrages à froid en vous permettant de conserver une ou plusieurs instances perpétuellement chaudes.
Plan dédié	Lors d’une exécution dans un plan Dedicated, l’hôte Functions peut s’exécuter en continu sur un nombre prescrit d’instances, ce qui signifie que le démarrage à froid n’est pas vraiment un problème.
Applications de conteneur	Dépend du nombre minimal de réplicas : • Quand il est défini sur 0 : les applications peuvent être mises à l’échelle à 0 quand elles sont inactives, ce qui signifie que certaines requêtes peuvent avoir plus de latence au démarrage. • Quand il est défini sur 1 ou plus : le processus hôte s’exécute en continu, ce qui signifie que le démarrage à froid n’est pas un problème.
Plan Consommation	Les applications peuvent être mises à l’échelle à zéro lorsqu’elles sont inactives, ce qui signifie que certaines requêtes peuvent avoir plus de latence au démarrage. Le plan Consommation comprend des optimisations pour réduire le temps de démarrage à froid, notamment en extrayant auprès de fonctions d’espace réservé préparées pour lesquelles les processus d’hôte et de langage sont déjà en cours d’exécution.

Limites du service

Ressource	Plan de consommation flexible	Plan Premium	Plan dédié/ASE	Applications de conteneur	Plan Consommation
Durée du délai d’expiration (min) par défaut	30	30	30¹	30¹⁶	5
Durée du délai d’expiration maximum (min)	illimité⁹	illimité⁹	illimité²	illimité¹⁷	10
Nbre max. de connexions sortantes (par instance)	illimité	illimité	illimité	illimité	600 actives (1 200 au total)
Taille de requête max. (Mo)³	210	210	210	210	210
Longueur de chaîne de requête max.³	4096	4096	4096	4096	4096
Longueur d’URL de requête max.³	8 192	8 192	8 192	8 192	8 192
ACU par instance	210-840	100–840/210–250¹⁰	varie	100	varie
Mémoire max. (en Go par instance)	4<sup4	3,5-14	1,75–256/8–256	varie	1.5
Nombre d’instances maximal (Windows/Linux)	100/20	varie selon la référence SKU/100¹¹	10-300¹⁸	200/100	1000 ¹⁵
Applications de fonction par plan¹³	100	100	illimité⁴	illimité⁴	100
Plans App Service	n/a	100 par groupe de ressources	100 par groupe de ressources	n/a	100 par région
Emplacements de déploiement par application¹²	n/a	3	1–20¹¹	non pris en charge	2
Stockage (temporaire)⁵	0,8 Go	21-140 Go	11-140 Go	n/a	0,5 Go
Stockage (persistant)	0 Go⁷	250 Go	10–1 000 Go¹¹	n/a	1 Go^{6, 7}
Domaines personnalisés par application	500	500	500	non pris en charge	500⁷
domaines personnalisés Prise en charge SSL	connexions 1 IP SSL et SNI SSL illimitées incluses	connexions 1 IP SSL et SNI SSL illimitées incluses	connexions 1 IP SSL et SNI SSL illimitées incluses	non pris en charge	connexion SNI SSL illimitée incluse

Remarques sur les limites de service :

Par défaut, le délai d’expiration du runtime de Functions 1.x dans un plan App Service est illimité.
Nécessite que le plan App Service soit défini sur Always On. Facturation aux tarifs standard. Une période de grâce de 10 minutes est donnée pendant les mises à jour de la plateforme.
Ces limites sont définies dans l’hôte.
Le nombre réel d’applications de fonction que vous pouvez héberger dépend de l’activité des applications, de la taille des instances de machine et de l’utilisation de ressources correspondante.
La limite de stockage est la taille totale du contenu dans le stockage temporaire de toutes les applications du même plan App Service. Pour les plans Consommation sur Linux, le stockage est actuellement de 1,5 Go.
Le plan de Consommation utilise un partage Azure Files pour le stockage persistant. Lorsque vous fournissez votre propre partage Azure Files, les limites de taille de partage spécifiques dépendent du compte de stockage que vous définissez pour WEBSITE_CONTENTAZUREFILECONNECTIONSTRING.
Sur Linux, vous devez monter explicitement votre propre partage Azure Files.
Lorsque votre application de fonction est hébergée dans un Plan Consommation, seule l’option CNAME est prise en charge. Pour les applications de fonction présentes dans un plan Premium ou un plan App Service, vous pouvez mapper un domaine personnalisé en utilisant l’un ou l’autre des enregistrements : CNAME ou A.
Il n’existe aucun délai maximal d’expiration d’exécution appliqué. Cependant, la période de grâce donnée à l’exécution d’une fonction est de 60 minutes pendant un scale-in et de 10 minutes pendant les mises à jour de la plateforme.
Les workers sont des rôles qui hébergent des applications clientes. Ils sont disponibles dans trois tailles fixes : Un processeur virtuel/3,5 Go de RAM ; Deux processeurs virtuels/7 Go de RAM ; Quatre processeurs virtuels/14 Go de RAM.
Consultez Limites d’App Service pour plus d’informations.
Y compris l’emplacement de production.
Il existe actuellement une limite de 5000 applications de fonction dans un abonnement donné.
Les tailles d’instance du plan Consommation Flex sont actuellement définies comme étant soit 2048 Mo, soit 4096 Mo. Pour plus d’informations, consultez Mémoire d’instance.
Le plan Consommation flexible a un quota d’abonnements régionaux qui limite l’utilisation de la mémoire totale de toutes les instances dans une région donnée. Pour plus d’informations, consultez Mémoire d’instance.
Lorsque le nombre minimal de réplicas est défini sur zéro, le délai d’expiration par défaut dépend des déclencheurs spécifiques utilisés dans l’application.
Lorsque le nombre minimal de réplicas est défini sur un ou plusieurs.
Sur Container Apps, vous pouvez définir le nombre maximal de réplicas, qui est respecté tant que le quota de cœurs disponibles est suffisant.

Fonctionnalités réseau

Fonctionnalité	Plan Consommation flexible	Plan Consommation	Plan Premium	Plan dédié/ASE	Container Apps¹
Restrictions d’adresse IP entrantes	✔	✔	✔	✔	✔
Points de terminaison privés entrants	✔		✔	✔
Intégration du réseau virtuel	✔		✔²	✔³	✔
Restrictions d’adresse IP sortantes	✔		✔	✔	✔

Pour plus d’informations, consultez Réseaux dans un environnement Azure Container Apps.
Il existe des points particuliers à prendre en compte quand vous utilisez des déclencheurs de réseau virtuel.
Seul le plan Dédié/ASE prend en charge l’intégration au réseau virtuel nécessitant une passerelle.

Billing

Plan	Détails
Plan Consommation flexible	La facturation est basée sur le nombre d’exécutions, la mémoire des instances lorsqu’elles exécutent activement des fonctions, ainsi que le coût des instances toujours prêtes. Pour plus d’informations, consultez facturation du plan Consommation Flex.
Plan Premium	Le plan Premium se base sur le nombre de cœurs-seconde et la mémoire utilisée sur les instances nécessaires et préchauffées. Au moins une instance par plan doit être chaude en permanence. Ce plan offre la tarification la plus prévisible.
Plan dédié	Le coût des Function App dans un plan App Service est le même que pour d’autres ressources App Service, par exemple les applications web. Pour un ASE, il existe un taux mensuel fixe qui rémunère l’infrastructure et ne change pas avec la taille de l’environnement. Chaque processeur virtuel de plan App Service présente aussi un coût. Toutes les applications hébergées dans un environnement App Service sont dans la référence (SKU) de prix Isolée. Pour plus d’informations, consultez l’article de présentation des ASE.
Applications de conteneur	La facturation dans Azure Container Apps est basée sur votre type de plan. Pour plus d’informations, consultez Facturation dans Azure Container Apps.
Plan Consommation	Ne payez que la durée d’exécution de vos fonctions. La facturation est basée sur le nombre d’exécutions, la durée d’exécution et la mémoire utilisée.

Pour une comparaison des coûts entre les plans d’hébergement dynamique (Consommation, Consommation Flex et Premium), consultez la page de tarification Azure Functions. Pour obtenir la tarification des différentes options de plan Dedicated, consultez la page de tarification d’App Service. Pour la tarification de l’hébergement Container Apps, consultez Tarification Azure Container Apps.

Limitations pour la création d’applications de fonction dans un groupe de ressources existant

Dans certains cas, quand vous essayez de créer un nouveau plan d’hébergement pour votre application de fonction dans un groupe de ressources existant, vous pourriez recevoir une des erreurs suivantes :

Le niveau tarifaire n’est pas autorisé dans ce groupe de ressources
Les Workers <nom_référence_SKU> ne sont pas disponibles dans le groupe de ressources <nom_groupe_ressources>

Ceci peut se produire quand les conditions suivantes sont rencontrées :

Vous créez une application de fonction dans un groupe de ressources existant qui contient une autre application de fonction ou une autre application web. Par exemple, les applications de consommation Linux ne sont pas prises en charge dans le même groupe de ressources que les plans Linux Dedicated ou Linux Premium.
Votre nouvelle application de fonction est créée dans la même région que l’application précédente.
L’application précédente présente une incompatibilité avec votre nouvelle application. Cette erreur peut se produire entre des références SKU, des systèmes d’exploitation, ou en raison d’autres fonctionnalités au niveau de la plateforme, comme la prise en charge des zones de disponibilité.

La raison pour laquelle cela se produit est due à la façon dont les plans d’application de fonction et d’application web sont mappés à des pools de ressources différents lors de la création. Les différentes références SKU nécessitent un ensemble différent de fonctionnalités d’infrastructure. Quand vous créez une application dans un groupe de ressources, ce groupe de ressources est mappé et affecté à un pool de ressources spécifique. Si vous essayez de créer un autre plan dans ce groupe de ressources et que le pool mappé n’a pas les ressources requises, cette erreur se produit.

Quand cette erreur se produit, créez à la place votre application de fonction et votre plan d’hébergement dans un nouveau groupe de ressources.

Partage via