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 | 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 Linux1 | Déploiement Windows2 |
|---|---|---|
| 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 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 | Maximum1 |
|---|---|---|
| Plan de consommation | 5 | 10 |
| Plan Consommation flexible | 30 | Illimité2 |
| Plan Premium | 304 | Illimité2 |
| Plan dédié | 304 | Illimité3 |
| Applications de conteneur | 30 | Illimité5 |
- 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 | 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: 1001 |
| 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 à 1002 |
| Plan dédié3 | 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 0004 |
- 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 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. |
| 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. |
Limites du service
| Ressource | Plan Consommation | Plan Consommation Flex13 | Plan Premium | Plan dédié/ASE | Applications de conteneur |
|---|---|---|---|---|---|
| Durée du délai d’expiration (min) par défaut | 5 | 30 | 30 | 301 | 3016 |
| Durée du délai d’expiration maximum (min) | 10 | illimité8 | illimité8 | illimité2 | illimité17 |
| 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 | 100 |
| Longueur de chaîne de requête max.3 | 4096 | 4096 | 4096 | 4096 | 4096 |
| Longueur d’URL de requête max.3 | 8 192 | 8 192 | 8 192 | 8 192 | 8 192 |
| ACU par instance | 100 | varie | 210-840 | 100-840/210-2509 | varie |
| Mémoire max. (en Go par instance) | 1.5 | 414 | 3,5-14 | 1,75-14/3,5-14 | varie |
| Nombre d’instances maximal (Windows/Linux) | 200/100 | 1000 15 | 100/20 | varie en fonction de la référence SKU/10010 | 10-30018 |
| Applications de fonction par plan12 | 100 | 100 | 100 | illimité4 | illimité4 |
| Plans App Service | 100 par région | n/a | 100 par groupe de ressources | 100 par groupe de ressources | n/a |
| Emplacements de déploiement par application11 | 2 | n/a | 3 | 1-2010 | non pris en charge |
| Stockage (temporaire)5 | 0,5 Go | 0,8 Go | 21-140 Go | 11-140 Go | n/a |
| Stockage (persistant) | 1 Go6 | 0 Go6 | 250 Go | 10-1000 Go10 | n/a |
| Domaines personnalisés par application | 5007 | 500 | 500 | 500 | non pris en charge |
| 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 | non pris en charge |
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. Sous Linux, vous devez monter explicitement votre propre partage Azure Files pour les plans Consommation Flex et Consommation.
- 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é.
- 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.
- 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 | Plan de consommation flexible | Plan Premium | Plan dédié/ASE | Applications de conteneur* |
|---|---|---|---|---|---|
| Restrictions d’adresse IP entrantes | ✅Oui | ✅Oui | ✅Oui | ✅Oui | ✅Oui |
| Points de terminaison privés entrants | ❌Non | ✅Oui | ✅Oui | ✅Oui | ❌Non |
| Intégration du réseau virtuel | ❌Non | ✅Oui (Zones géographiques) | ✅Oui (Zones géographiques) | ✅Oui (Zones géographiques et Passerelle) | ✅Oui |
| Déclencheurs de réseau virtuel (non HTTP) | ❌Non | ✅Oui | ✅Oui | ✅Oui | ✅Oui |
| Connexions hybrides (Windows uniquement) | ❌Non | ❌ Non | ✅Oui | ✅Oui | ❌Non |
| Restrictions d’adresse IP sortantes | ❌Non | ✅Oui | ✅Oui | ✅Oui | ✅Oui |
*Pour plus d’informations, consultez Mise en réseau dans un environnement Azure Container Apps.
Billing
| 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. |
| 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. |
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.