Options d’hébergement Azure Functions

Article
05/21/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	Azure Functions	Disponibilité générale (GA)	Aucun
Plan Consommation flexible	Azure Functions	Aperçu	Aucun
Plan Premium	Azure Functions	GA	Linux
Plan dédié	Azure Functions	GA	Linux
Applications de conteneur	Azure Container Apps	GA	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 :

Option	Avantages
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.
Plan Consommation flexible	Bénéficiez d’une scalabilité élevée des choix de calcul, de la mise en réseau virtuel et du paiement à 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.

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	✅ Code uniquement ❌ Conteneur (non pris en charge)	✅ Code uniquement
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

¹ Linux est le seul système d’exploitation pris en charge pour votre pile d’exécution Python.
² Les déploiements Windows sont en 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 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 de consommation	5	10
Plan Consommation flexible	30	Illimité³
Plan Premium	30²	Illimité³
Plan dédié	30²	Illimité³

¹ 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.
² Le délai d’expiration par défaut pour la version 1.x du runtime Functions est illimité.
³ Garanti pour une durée maximale de 60 minutes. La mise à jour corrective du système d’exploitation et du runtime, la mise à jour corrective des vulnérabilités et la mise à l’échelle des comportements peuvent toujours annuler les exécutions de fonctions. Veillez bien à écrire des fonctions robustes. ⁴ Dans un plan Consommation flexible, l’hôte n’applique pas de limite de temps d’exécution. Toutefois, il n’existe actuellement aucune garantie, car la plateforme peut avoir besoin de mettre fin à vos instances pendant la mise à l’échelle, les déploiements ou l’application de mises à jour.

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	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¹
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)

¹ 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 sur 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 les limites du plan App Service.

Comportement du démarrage à froid

Plan	Détails
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 de consommation offre des optimisations pour réduire le temps de démarrage à froid, notamment en extrayant à partir de fonctions d’espace réservé préchauffées qui exécutent déjà les processus de fonction de langage et d’hôte.
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.

Limites du service

Ressource	Plan Consommation	Plan Consommation Flex¹²	Plan Premium	Plan dédié/ASE
Durée du délai d’expiration (min) par défaut	5	30	30	30¹
Durée du délai d’expiration maximum (min)	10	illimité¹⁵	illimité⁷	illimité²
Nbre max. de connexions sortantes (par instance)	600 actives (1 200 au total)	illimité	illimité	illimité
Taille de requête max. (Mo)³	100	100	100	100
Longueur de chaîne de requête max.³	4096	4096	4096	4096
Longueur d’URL de requête max.³	8 192	8 192	8 192	8 192
ACU par instance	100	varie	210-840	100-840/210-250⁸
Mémoire max. (en Go par instance)	1.5	4¹³	3,5-14	1,75-14/3,5-14
Nombre d’instances maximal (Windows/Linux)	200/100	1000 ¹⁴	100/20	varie en fonction de la référence SKU/100⁹
Applications de fonction par plan¹¹	100	100	100	illimité⁴
Plans App Service	100 par région	n/a	100 par groupe de ressources	100 par groupe de ressources
Emplacements de déploiement par application¹⁰	2	n/a	3	1-20⁹
Stockage⁵	5 Go	250 Go	250 Go	50-1 000 Go
Domaines personnalisés par application	500⁶	500	500	500
domaines personnalisés Prise en charge SSL	connexion SNI SSL illimitée incluse	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

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.
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. Le plan Consommation utilise Azure Files pour le stockage temporaire.
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.
Garanti pour une durée maximale de 60 minutes.
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é.
Le plan Consommation flexible est actuellement en préversion.
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 Flex pendant la période de la préversion a un quota d’abonnement régional qui limite l’utilisation totale de la mémoire de toutes les instances dans une région donnée. Pour plus d’informations, consultez Mémoire d’instance.
Dans un plan Consommation Flex, l’hôte n’applique pas de limite de temps d’exécution. Toutefois, il n’existe actuellement aucune garantie, car la plateforme peut avoir besoin de mettre fin à vos instances pendant la mise à l’échelle, les déploiements ou l’application de mises à jour.

Fonctionnalités réseau

Fonctionnalité	Plan Consommation	Plan de consommation flexible	Plan Premium	Plan dédié/ASE
Restrictions d’adresse IP entrantes	✅Oui	✅Oui	✅Oui	✅Oui
Points de terminaison privés entrants	❌Non	✅Oui	✅Oui	✅Oui
Intégration du réseau virtuel	❌Non	✅Oui (Zones géographiques)	✅Oui (Zones géographiques)	✅Oui (Zones géographiques et Passerelle)
Déclencheurs de réseau virtuel (non HTTP)	❌Non	✅Oui	✅Oui	✅Oui
Connexions hybrides (Windows uniquement)	❌Non	✅Oui	✅Oui	✅Oui
Restrictions d’adresse IP sortantes	❌Non	✅Oui	✅Oui	✅Oui

Facturation

Plan	Détails
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.
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.

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