Options d’hébergement Azure Functions

Lorsque vous créez une Function App dans Azure, vous devez choisir un plan d’hébergement pour votre application. Trois plans d’hébergement De base sont disponibles pour Azure Functions : plan Consommation, plan Premium et plan dédié (App Service). Tous les plans d’hébergement sont en disponibilité générale sur les machines virtuelles Linux et Windows.

Le plan 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.

Cet article présente une comparaison détaillée entre les différents plans d’hébergement, ainsi que l’hébergement basé sur Kubernetes.

Notes

Si vous choisissez d’héberger vos fonctions dans un cluster Kubernetes, utilisez un cluster Kubernetes avec Azure Arc. L’hébergement sur un cluster Kubernetes avec Azure Arc est actuellement disponible en préversion. Pour en savoir plus, consultez App Service, Functions et Logic Apps sur Azure Arc.

Vue d’ensemble des plans

Voici un résumé des avantages des trois principaux plans d’hébergement pour Functions :

Plan Avantages
Plan de consommation Mettez à l’échelle automatiquement et ne payez les ressources de calcul que lorsque vos fonctions sont en cours d’exécution.

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.
✔ 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 Premium Mise à l’échelle automatique selon la demande à l’aide de Workers préparé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 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 mémoire ou de processeur que celles qui sont proposées dans le plan 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 de fonctionnalités qui ne sont pas disponibles dans le plan Consommation, notamment la connectivité de réseau virtuel.
✔ Vous souhaitez fournir une image Linux personnalisée sur 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 sous-utilisées qui exécutent déjà d’autres instances App Service.
✔ La prédiction de la mise à l’échelle et des coûts est requise.

Les tableaux de comparaison de cet article incluent également les options d’hébergement suivantes, qui fournissent la plus grande quantité de contrôle et d’isolation dans laquelle exécuter vos applications de fonction.

Option d’hébergement Détails
ASE App Service Environment(ASE) est une fonctionnalité d’App Service qui fournit un environnement totalement isolé et dédié pour l’exécution sécurisée de vos applications App Service à grande échelle.

Les environnements ASE conviennent aux charges de travail d’application qui nécessitent :

✔ Une très grande échelle.
✔ Une isolation totale du calcul et un accès réseau sécurisé.
✔ Utilisation élevée de la mémoire.
Kubernetes
(Direct ou
Azure Arc)
Kubernetes offre un environnement totalement isolé et dédié qui s’exécute sur la plateforme Kubernetes.

Kubernetes convient aux charges de travail d’application qui nécessitent :
✔ Des exigences matérielles personnalisées.
✔ Une isolation et un accès réseau sécurisé.
✔ Une possibilité d’exécution dans un environnement hybride ou multi-cloud.
✔ Une exécution en parallèle de services et d’applications Kubernetes existants.

Les autres tableaux de cet article comparent les plans sur des fonctionnalités et des comportements différents. Pour une comparaison des coûts entre les plans d’hébergement dynamique (Consommation et Premium), consultez la page de tarification d’Azure Functions. Pour obtenir la tarification des différentes options de plan Dedicated, consultez la page de tarification d’App Service.

Système d'exploitation/runtime

Le tableau suivant indique le système d'exploitation et la prise en charge des langages pour les plans d’hébergement.

Linux1,2
code-only
Windows code-only Linux1,2,3
Conteneur Docker
Plan de consommation C#
JavaScript
Java
Python
PowerShell Core
TypeScript
C#
JavaScript
Java
PowerShell Core
TypeScript
Aucune prise en charge
Plan Premium C#
JavaScript
Java
Python
PowerShell Core
TypeScript
C#
JavaScript
Java
PowerShell Core
TypeScript
C#
JavaScript
Java
PowerShell Core
Python
TypeScript
Plan dédié C#
JavaScript
Java
Python
TypeScript
C#
JavaScript
Java
PowerShell Core
TypeScript
C#
JavaScript
Java
PowerShell Core
Python
TypeScript
ASE C#
JavaScript
Java
Python
TypeScript
C#
JavaScript
Java
PowerShell Core
TypeScript
C#
JavaScript
Java
PowerShell Core
Python
TypeScript
Kubernetes (direct) n/a n/a C#
JavaScript
Java
PowerShell Core
Python
TypeScript
Azure Arc (préversion) C#
JavaScript
Java
Python
TypeScript
n/a C#
JavaScript
Java
PowerShell Core
Python
TypeScript

1 Linux est le seul système d’exploitation pris en charge pour votre pile d’exécution Python.
2 La prise en charge de PowerShell sur Linux est actuellement disponible en préversion.
3 Linux est le seul système d’exploitation pris en charge pour les conteneurs Docker.

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 Maximum1
Plan de consommation 5 10
Plan Premium 302 Illimité
Plan dédié 302 Illimité

1 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.
2 Le délai d’expiration par défaut pour la version 1.x du runtime Functions est illimité.

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 de consommation 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 automatiquement à 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 déclencheurs entrants. Windows: 200
Linux: 1001
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 automatiquement à l’échelle les ressources processeur et mémoire en ajoutant des instances de l’hôte Functions selon le nombre d’événements en fonction desquels ses fonctions sont déclenchées. Windows: 100
Linux: 20 à 1002
Plan dédié3 Manuel/Mise à l’échelle automatique 10-20
ASE3 Manuel/Mise à l’échelle automatique 100
Kubernetes Mise à l’échelle automatique basée sur les événements pour les clusters Kubernetes qui utilisent KEDA. Varie selon le cluster

1 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.
2 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.
3 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 jusqu’à zéro en cas d’inactivité, ce qui signifie que certaines requêtes peuvent présenter une latence supplémentaire 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éparées qui exécutent déjà les processus de langage et d’hôte de fonction.
Plan Premium Les instances perpétuellement chaudes permettent d’éviter les démarrages à froid.
Plan dédié En cas d’exécution dans un plan dédié, l’hôte Functions peut s’exécuter en continu, ce qui signifie que le démarrage à froid n’est pas vraiment un problème.
ASE En cas d’exécution dans un plan dédié, l’hôte Functions peut s’exécuter en continu, ce qui signifie que le démarrage à froid n’est pas vraiment un problème.
Kubernetes Selon la configuration de KEDA, les applications peuvent être configurées de manière à éviter un démarrage à froid. Si elles sont configurées pour être mises à l’échelle à zéro, les nouveaux événements font l’objet d’un démarrage à froid.

Limites du service

Ressource Plan Consommation Plan Premium Plan dédié ASE Kubernetes
Durée du délai d’expiration (min) par défaut 5 30 301 30 30
Durée du délai d’expiration maximum (min) 10 illimité7 illimité2 illimité illimité
Nbre max. de connexions sortantes (par instance) 600 actives (1 200 au total) illimité illimité illimité illimité
Taille de requête max. (Mo)3 100 100 100 100 Dépend du cluster
Longueur de chaîne de requête max.3 4096 4096 4096 4096 Dépend du cluster
Longueur d’URL de requête max.3 8 192 8 192 8 192 8 192 Dépend du cluster
ACU par instance 100 210-840 100-840 210-2508 Tarification d’AKS
Mémoire max. (en Go par instance) 1.5 3,5-14 1,75-14 3.5 - 14 Tous les nœuds sont pris en charge
Nombre d’instances maximal (Windows/Linux) 200/100 100/20 varie en fonction de la référence SKU9 1009 Dépend du cluster
Applications de fonction par plan 100 100 illimité4 illimité illimité
Plans App Service 100 par région 100 par groupe de ressources 100 par groupe de ressources - -
Emplacements de déploiement par application10 2 3 1-209 20 n/a
Stockage5 5 To 250 Go 50-1 000 Go 1 To n/a
Domaines personnalisés par application 5006 500 500 500 n/a
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 n/a

1 Par défaut, le délai d’attente du runtime de Functions 1.x dans un plan App Service est illimité.
2 Nécessite que le plan App Service soit défini sur Always On. Facturation aux tarifs standard.
3 Ces limites sont définies dans l’hôte.
4 Le nombre réel d’applications de fonction qui peuvent être hébergées dépend de l’activité des applications, de la taille des instances de machine et de l’utilisation de ressources correspondante.
5 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.
6 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.
7 Garanti pour une durée maximale de 60 minutes.
8Les 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.
9 Pour plus d’informations, consultez Limites App Service.
10, y compris l’emplacement de production.

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 plan d’hébergement pour votre application de fonction dans un groupe de ressources existant, vous pouvez 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.
  • 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. Ceci peut se produire entre des références SKU ou 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 de 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.

Fonctionnalités réseau

Fonctionnalité Plan Consommation Plan Premium Plan dédié ASE Kubernetes
Restrictions d’adresse IP entrantes ✅Oui ✅Oui ✅Oui ✅Oui ✅Oui
Points de terminaison privés entrants ❌Non ✅Oui ✅Oui ✅Oui ✅Oui
Intégration du réseau virtuel ❌Non ✅Oui (Zones géographiques) ✅Oui (Zones géographiques et Passerelle) ✅Oui ✅Oui
Déclencheurs de réseau virtuel (non HTTP) ❌Non ✅Oui ✅Oui ✅Oui ✅Oui
Connexions hybrides (Windows uniquement) ❌Non ✅Oui ✅Oui ✅Oui ✅Oui
Restrictions d’adresse IP sortantes ❌Non ✅Oui ✅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 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éparé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.
App Service Environment (ASE) Un tarif fixe mensuel couvre l’infrastructure d’un ASE et ne change pas avec la taille de l’environnement ASE. 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.
Kubernetes Vous ne payez que le coût de votre cluster Kubernetes et aucune facturation supplémentaire pour Functions. Votre application de fonction s’exécute comme une charge de travail d’application sur votre cluster, tout comme une application normale.

Étapes suivantes