Options d’hébergement Azure Functions

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	Les fonctions Azure	Disponibilité générale (GA)	None
Plan Premium	Les fonctions Azure	GA	Linux
Plan Dedicated	Les fonctions Azure	GA	Linux
Container Apps	Azure Container Apps (Applications de Conteneur Azure)	GA	Linux
Plan de consommation	Les fonctions Azure	Windows - Disponibilité générale Linux - Retraité	None

Important

Après le 30 septembre 2028, l’option d’hébergement de votre application de fonction sur Linux dans un plan Consommation est supprimée. Pour éviter les interruptions, migrez vos applications de plan consommation existantes qui s’exécutent sur Linux vers le plan Flex Consumption avant cette date. Les applications s’exécutant sur Windows dans un plan Consommation ne sont pas affectées par cette modification. Pour plus d’informations, consultez l’avis de mise hors service du plan de consommation Linux.

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 :

Choix	Avantages
Plan Consommation flexible	Profitez d'une mise à l'échelle horizontale rapide, avec des options de calcul flexibles, l'intégration de réseau informatique virtuel et une facturation à l'utilisation sans serveur. Dans le plan Flex Consumption, les instances de fonction effectuent un scale-out dynamique (jusqu’à 1 000) en fonction de la concurrence configurée par instance, des événements entrants et des charges de travail par fonction pour une efficacité optimale. Tenez compte du plan Flex Consumption quand : ✔ Vous avez besoin d’un hôte serverless pour votre code de fonction, en payant uniquement pour les exécutions à la demande. ✔ Vous avez besoin d’une connectivité de réseau virtuel pour sécuriser l’accès aux ressources Azure. ✔ Vos charges de traitement sont variables et peuvent varier entre aucune activité et un besoin de mise à l'échelle rapide, déclenchée par les événements. ✔ Vous souhaitez personnaliser le calcul avec des tailles de mémoire (512 Mo, 2 048 Mo ou 4 096 Mo) et réduire les démarrages à froid via une ou plusieurs instances préprovisionnée (toujours prêtes).
Plan Premium	S'adapte automatiquement en fonction de la requête à l'aide de travailleurs préchauffés, qui exécutent les applications sans délai après avoir été inactifs, s'exécutent sur des instances plus puissantes et se connectent aux 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 pour sécuriser l’accès aux ressources Azure. ✔ Vous voulez fournir une image Linux personnalisée dans laquelle exécuter vos fonctions.
Plan Dedicated	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).
Container Apps	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 souhaitez contrôler l’image conteneur et souhaitez 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 de consommation	Payez les ressources de calcul uniquement lorsque vos fonctions s’exécutent (paiement à l’utilisation) avec une mise à l’échelle automatique sur Windows. Dans le plan Consommation, les instances de fonction sont ajoutées et supprimées dynamiquement en fonction du nombre d’événements entrants. Tenez compte du plan de consommation lorsque : ✔ Vous avez une dépendance sur Windows, par exemple, à l’aide du runtime v1, du .NET Framework complet ou des fonctionnalités spécifiques à Windows, comme certains modules PowerShell ✔ Vous souhaitez un modèle de facturation serverless et payer uniquement lorsque vos fonctions sont en cours d’exécution.

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.

Hosting	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 Dedicated	✅ Code uniquement ✅ Conteneur	✅ Code uniquement
Container Apps	✅ Conteneur uniquement	❌ Non pris en charge
Plan de consommation³	✅ Code uniquement (supprimé) ❌ 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.
La possibilité d’exécuter votre application sur Linux dans un plan Consommation est prévue pour être supprimée le 30 septembre 2028. Pour plus d’informations, consultez Plan Consommation.

Durée du délai d’expiration de l’application de fonction

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 a démarré l’exécution d’une fonction, la fonction doit retourner/répondre dans les limites 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	Par défaut	Maximum¹
Plan Consommation flexible	30	Illimité²
Plan Premium	30⁴	Illimité²
Plan Dedicated	30⁴	Illimité³
Container Apps	30	Illimité⁵
Plan de consommation	5	10

Quel que soit le paramètre de délai d’expiration de l’application de fonction, 230 secondes est le temps maximum que peut prendre une fonction déclenchée via HTTP pour répondre à une requête. 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.
Aucun délai maximal d’expiration d’exécution n’est 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 hôte 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.

Les valeurs de ce tableau supposent que le processus hôte Azure Functions a démarré et s’exécute correctement. Un délai d’expiration maximal de 60 secondes est autorisé pour que le processus Worker propre au langage démarre également. Le délai d’expiration du processus de travail n’est actuellement pas configurable.

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.

Échelle

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	Les décisions de mise à l’échelle rapides basées sur les événements sont calculées sur une base par fonction, appelée mise à l’échelle par fonction, qui fournit 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.	1000¹
Plan Premium	Basé sur les événements. Effectuer un scale-out automatique, même pendant les périodes de charge élevée L’infrastructure d’Azure Functions adapte automatiquement les ressources en processeur et en mémoire en déployant davantage d’instances de l’hôte Functions, en fonction du nombre d’événements déclenchant les fonctions.	Windows: 100⁶ Linux : 20-100^2,6
Plan Dedicated	Manuel/Mise à l’échelle automatique	10-30³ 100 (ASE)
Container Apps	Basé sur les événements. Effectuer un scale-out automatique, même pendant les périodes de charge élevée L’infrastructure d’Azure Functions adapte automatiquement les ressources en processeur et en mémoire en déployant davantage d’instances de l’hôte Functions, en fonction du nombre d’événements déclenchant les fonctions.	300 – 1 000⁴
Plan de consommation	Basé sur les événements. Mise à l’échelle automatique basée sur la source des événements. L’infrastructure Functions met à l’échelle les ressources en ajoutant d’autres instances de l’hôte de fonction, en fonction du nombre d’événements de déclencheur entrants.	Windows : 200 Linux : 100⁵

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 Quotas de mémoire d’abonnement régional. Les plans Flex Consumption prennent actuellement uniquement en charge Linux.
Dans certaines régions, les applications Linux sur un plan Premium peuvent être mises à l’échelle sur 100 instances. Pour plus d’informations, consultez l’article sur le plan Premium.
Pour connaître des limites spécifiques pour les différentes options de plan App Service, consultez les 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. Pour plus d’informations, consultez Quotas pour Azure Container Apps. Quand vous créez votre application de fonction depuis le portail Azure, vous êtes limité à 300 instances.
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.
Pour les déclencheurs http restreints aux points de terminaison privés, la mise à l'échelle est limitée à 20 instances au maximum.

Comportement du démarrage à froid

Plan	Détails
Plan Consommation flexible	Amélioration du démarrage à froid même lorsque la mise à l’échelle est réduite à zéro. Prend en charge les instances toujours prêtes pour réduire davantage 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 Dedicated	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.
Container Apps	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 de 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 Consommation Flex	Plan Premium	Plan dédié/ASE	Container Apps	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 max. (min)	illimité⁹	illimité⁹	illimité²	illimité¹⁷	10
Nbre max. de connexions sortantes (par instance)	unbounded	unbounded	unbounded	unbounded	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¹⁴	3,5-14	1,75–256/8–256	varie	1,5
Nombre maximal d’instances (Windows \| Linux)¹⁵	n/a \| 1000	20-100	10-30 (100 ASE)¹¹	300-1000¹⁸	200 \| 100
Applications de fonction par plan¹³	1	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	25⁸	500	500	non pris en charge	500⁸
Domaine personnalisé Prise en charge TLS/SSL	Connexions SNI SSL illimitées et une connexion IP SSL incluses	Connexions SNI SSL illimitées et une connexion IP SSL incluses	Connexions SNI SSL illimitées et une connexion IP SSL 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 pour les fonctions déclenchées par HTTP pendant les mises à jour de plateforme, mais pas pour d’autres déclencheurs.
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.
Aucun délai maximal d’expiration d’exécution n’est 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. Les travailleurs sont disponibles dans trois tailles fixes : une vCPU/3,5 Go de RAM. Deux vCPU/7 Go de RAM ; Quatre vCPU/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 5 000 applications de fonction dans un abonnement donné.
Les tailles d’instance du plan Flex Consumption sont actuellement définies comme 512 Mo, 2 048 Mo ou 4 096 Mo. Pour plus d’informations, consultez Mémoire des instances.
Pour plus d’informations, consultez la section Échelle dans l’article de comparaison de l’hébergement.
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.

Fonctionnalités réseau

Fonctionnalité	Plan Consommation Flex	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.
Lorsque vous travaillez avec des déclencheurs de réseau virtuel, vous devez prendre en compte certaines considérations particulières.
L’intégration des réseaux virtuels requis par la passerelle est uniquement possible dans le cadre de l’offre Dedicated/ASE.

Facturation

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 Dedicated	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.
Container Apps	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 de 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.

Étapes suivantes

Rétroaction

Cette page vous a-t-elle été utile ?

Last updated on 2025-09-26