Hostingopties voor Azure Functions
Wanneer u een functie-app in Azure maakt, moet u een hostingoptie voor uw app kiezen. Azure biedt u de volgende hostingopties voor uw functiecode:
| Hostingoptie | Service | Beschikbaarheid | Ondersteuning voor containers |
|---|---|---|---|
| Flex Consumption-abonnement | Azure Functions | Algemeen beschikbaar | Geen |
| Premium-abonnement | Azure Functions | GA | Linux |
| Toegewezen abonnement | Azure Functions | GA | Linux |
| Container Apps | Azure Container Apps | GA | Linux |
| Verbruiksabonnement | Azure Functions | GA | Geen |
Azure Functions-hostingopties worden mogelijk gemaakt door Azure-app Service-infrastructuur op virtuele Linux- en Windows-machines. De hostingoptie die u kiest, bepaalt het volgende gedrag:
- Hoe uw functie-app wordt geschaald.
- De resources die beschikbaar zijn voor elk exemplaar van de functie-app.
- Ondersteuning voor geavanceerde functionaliteit, zoals Azure Virtual Network-connectiviteit.
- Ondersteuning voor Linux-containers.
Het plan dat u kiest, heeft ook invloed op de kosten voor het uitvoeren van uw functiecode. Zie Facturering voor meer informatie.
Dit artikel bevat een gedetailleerde vergelijking tussen de verschillende hostingopties. Zie de ondersteuning voor Linux-containers voor Linux-containers voor meer informatie over het uitvoeren en beheren van uw functiecode in Azure Functions.
Overzicht van plannen
Hier volgt een overzicht van de voordelen van de verschillende opties voor Het hosten van Azure Functions:
| Optie | Vergoedingen |
|---|---|
| Flex Consumption-abonnement | Snelle horizontale schaalaanpassing met rekenopties, virtuele netwerken en facturering per gebruik. In het Flex Consumption-abonnement worden exemplaren van de Functions-host dynamisch toegevoegd en verwijderd op basis van de geconfigureerde gelijktijdigheid per instantie en het aantal binnenkomende gebeurtenissen. ✔ Verminder koude start door een aantal vooraf ingerichte (altijd gereed) exemplaren op te geven. ✔ Ondersteunt virtuele netwerken voor extra beveiliging. ✔ Betalen wanneer uw functies worden uitgevoerd. ✔ Schaalt automatisch, zelfs tijdens perioden van hoge belasting. |
| Premium-abonnement | Schaalt automatisch op basis van vraag met behulp van vooraf opgewarmde werkrollen, die toepassingen zonder vertraging uitvoeren nadat ze inactief zijn, worden uitgevoerd op krachtigere exemplaren en verbinding maken met virtuele netwerken. Houd rekening met het Azure Functions Premium-abonnement in de volgende situaties: ✔ Uw functie-apps worden continu of bijna continu uitgevoerd. ✔ U wilt meer controle over uw exemplaren en meerdere functie-apps implementeren in hetzelfde plan met gebeurtenisgestuurd schalen. ✔ U hebt een groot aantal kleine uitvoeringen en een hoge uitvoeringsfactuur, maar lage GB seconden in het verbruiksabonnement. ✔ U hebt meer CPU- of geheugenopties nodig dan wordt geleverd door verbruiksabonnementen. ✔ Uw code moet langer worden uitgevoerd dan de maximale uitvoeringstijd die is toegestaan voor het verbruiksabonnement. ✔ U hebt een virtuele netwerkverbinding nodig. ✔ U wilt een aangepaste Linux-installatiekopieën opgeven waarin u uw functies kunt uitvoeren. |
| Toegewezen abonnement | Voer uw functies uit binnen een App Service-plan tegen normale tarieven voor Een App Service-plan. Het meest geschikt voor langdurige scenario's waarbij Durable Functions niet kan worden gebruikt. Overweeg een App Service-plan in de volgende situaties: ✔ U hebt bestaande en onderbenutte virtuele machines waarop al andere App Service-exemplaren worden uitgevoerd. ✔ U moet volledig voorspelbare facturering hebben of u moet exemplaren handmatig schalen. ✔ U wilt meerdere web-apps en functie-apps uitvoeren op hetzelfde abonnement ✔ U hebt toegang nodig tot grotere rekengrootten. ✔ Volledige rekenisolatie en beveiligde netwerktoegang die wordt geleverd door een App Service Environment (ASE). ✔ Zeer hoog geheugengebruik en hoge schaal (ASE). |
| Container Apps | In containers geplaatste functie-apps maken en implementeren in een volledig beheerde omgeving die wordt gehost door Azure Container Apps. Gebruik het Azure Functions-programmeermodel om gebeurtenisgestuurde, serverloze, cloudeigen functie-apps te bouwen. Voer uw functies uit naast andere microservices, API's, websites en werkstromen als door containers gehoste programma's. Overweeg in de volgende situaties uw functies op Container Apps te hosten: ✔ U wilt aangepaste bibliotheken verpakken met uw functiecode ter ondersteuning van Line-Of-Business-apps. ✔ U moet code-uitvoering migreren van on-premises of verouderde apps naar cloudeigen microservices die in containers worden uitgevoerd. ✔ Wanneer u de overhead en complexiteit van het beheren van Kubernetes-clusters en toegewezen rekenkracht wilt voorkomen. ✔ Uw functies hebben geavanceerde verwerkingskracht nodig die wordt geleverd door toegewezen GPU-rekenresources. |
| Verbruiksabonnement | Betaal alleen voor rekenresources wanneer uw functies worden uitgevoerd (betalen per gebruik) met automatische schaalaanpassing. Bij een verbruiksabonnement worden exemplaren van de Functions-host dynamisch toegevoegd en verwijderd op basis van het aantal binnenkomende gebeurtenissen. ✔ Standaardhostingabonnement dat echte serverloze hosting biedt. ✔ Betaal alleen wanneer uw functies worden uitgevoerd. ✔ Schaalt automatisch, zelfs tijdens perioden van hoge belasting. |
De resterende tabellen in dit artikel vergelijken hostingopties op basis van verschillende functies en gedragingen.
Ondersteuning van het besturingssysteem
In deze tabel ziet u besturingssysteemondersteuning voor de hostingopties.
| Hosting | Linux1-implementatie | Implementatie van Windows2 |
|---|---|---|
| Flex Consumption-abonnement | ✅ Alleen code ❌ Container (niet ondersteund) |
❌ Niet ondersteund |
| Premium-abonnement | ✅ Alleen code ✅ Container |
✅ Alleen code |
| Toegewezen abonnement | ✅ Alleen code ✅ Container |
✅ Alleen code |
| Container Apps | ✅ Alleen container | ❌ Niet ondersteund |
| Verbruiksabonnement | ✅ Alleen code ❌ Container (niet ondersteund) |
✅ Alleen code |
- Linux is het enige ondersteunde besturingssysteem voor de Python-runtimestack.
- Windows-implementaties zijn alleen code. Functions biedt momenteel geen ondersteuning voor Windows-containers.
Time-outduur voor Function-app
De time-outduur voor functies in een functie-app wordt gedefinieerd door de functionTimeout eigenschap in het host.json projectbestand. Deze eigenschap is specifiek van toepassing op functie-uitvoeringen. Nadat de trigger de uitvoering van de functie start, moet de functie binnen de time-outduur retourneren/reageren. Om time-outs te voorkomen, is het belangrijk om robuuste functies te schrijven. Zie Prestaties en betrouwbaarheid van Azure Functions verbeteren voor meer informatie.
In de volgende tabel ziet u de standaard- en maximumwaarden (in minuten) voor specifieke plannen:
| Plannen | Standaardinstelling | Maximum1 |
|---|---|---|
| Flex Consumption-abonnement | 30 | Niet-gebonden2 |
| Premium-abonnement | 304 | Niet-gebonden2 |
| Toegewezen abonnement | 304 | Niet-gebonden3 |
| Container Apps | 30 | Niet-gebonden5 |
| Verbruiksabonnement | 5 | 10 |
- Ongeacht de time-outinstelling van de Function-app is 230 seconden de maximale tijdsduur die een door HTTP geactiveerde functie heeft om te reageren op een aanvraag. Dit komt door de standaard time-out voor inactiviteit van Azure Load Balancer. Overweeg voor langere verwerkingstijden het asynchrone Durable Functions-patroon te gebruiken of stel het werk uit en stuur onmiddellijk een antwoord terug.
- Er is geen maximale time-outduur voor uitvoering afgedwongen. De respijtperiode die aan een functie-uitvoering wordt gegeven, is echter 60 minuten tijdens de inschaal voor de Flex Consumption- en Premium-abonnementen en er wordt een respijtperiode van 10 minuten gegeven tijdens platformupdates.
- Vereist dat het App Service-plan is ingesteld op AlwaysOn. Er wordt een respijtperiode van 10 minuten gegeven tijdens platformupdates.
- De standaardtime-out voor versie 1.x van de Functions-hostruntime is niet afhankelijk.
- Wanneer het minimale aantal replica's is ingesteld op nul, is de standaardtime-out afhankelijk van de specifieke triggers die in de app worden gebruikt.
Taalondersteuning
Schaal wijzigen
De volgende tabel vergelijkt het schaalgedrag van de verschillende hostingabonnementen.
Maximumaantal exemplaren worden gegeven per functie-app (Verbruik) of per abonnement (Premium/Dedicated), tenzij anders aangegeven.
| Plannen | Uitschalen | Maximaal aantal exemplaren |
|---|---|---|
| Flex Consumption-abonnement | Schaalaanpassing per functie. Gebeurtenisgestuurde schaalbeslissingen worden per functie berekend, wat een meer deterministische manier biedt om de functies in uw app te schalen. Met uitzondering van HTTP, Blob Storage (Event Grid) en Durable Functions, worden alle andere typen functietriggers in uw app geschaald op onafhankelijke instanties. Alle HTTP-triggers in uw app worden samen geschaald als een groep op dezelfde exemplaren, net als alle Blob Storage-triggers (Event Grid). Alle Durable Functions-triggers delen ook exemplaren en schalen. | Alleen beperkt door het totale geheugengebruik van alle exemplaren in een bepaalde regio. Zie Exemplaargeheugen voor meer informatie. |
| Premium-abonnement | Gebeurtenisgestuurd. Automatisch uitschalen, zelfs tijdens perioden met hoge belasting. De Infrastructuur van Azure Functions schaalt CPU- en geheugenresources door meer exemplaren van de Functions-host toe te voegen op basis van het aantal gebeurtenissen waarop de functies worden geactiveerd. | Windows: 100 Linux: 20-1002 |
| Toegewezen abonnement3 | Handmatige/automatische schaalaanpassing | 10-30 100 (ASE) |
| Container Apps | Gebeurtenisgestuurd. Automatisch uitschalen, zelfs tijdens perioden met hoge belasting. De Infrastructuur van Azure Functions schaalt CPU- en geheugenresources door meer exemplaren van de Functions-host toe te voegen op basis van het aantal gebeurtenissen waarop de functies worden geactiveerd. | 300-10004 |
| Verbruiksabonnement | Gebeurtenisgestuurd. Schaalt automatisch uit, zelfs tijdens perioden met hoge belasting. Met de functie-infrastructuur worden CPU- en geheugenresources geschaald door meer exemplaren van de Functions-host toe te voegen op basis van het aantal binnenkomende trigger gebeurtenissen. | Windows: 200 Linux: 1001 |
- Tijdens uitschalen geldt momenteel een limiet van 500 exemplaren per abonnement per uur voor Linux-apps in een verbruiksabonnement.
- In sommige regio's kunnen Linux-apps in een Premium-abonnement worden geschaald naar 100 exemplaren. Zie het artikel over het Premium-abonnement voor meer informatie.
- Zie de limieten van het App Service-plan voor specifieke limieten voor de verschillende opties voor het App Service-plan.
- In Container Apps is de standaardwaarde 10 exemplaren, maar u kunt het maximum aantal replica's instellen, met een totaal maximum van 1000. Deze instelling wordt gehonoreerd zolang er voldoende kerngeheugenquotum beschikbaar is. Wanneer u uw functie-app maakt vanuit Azure Portal, bent u beperkt tot 300 exemplaren.
Gedrag van koude start
| Plannen | DETAILS |
|---|---|
| Flex Consumption-abonnement | Ondersteunt altijd gereede instanties om de vertraging bij het inrichten van nieuwe exemplaren te verminderen. |
| Premium-abonnement | Ondersteunt altijd gereede exemplaren om koude start te voorkomen door u een of meer permanent warme exemplaren te laten onderhouden. |
| Toegewezen abonnement | Wanneer de Functions-host wordt uitgevoerd in een Dedicated-abonnement, kan deze continu worden uitgevoerd op een voorgeschreven aantal exemplaren, wat betekent dat koude start niet echt een probleem is. |
| Container Apps | Afhankelijk van het minimale aantal replica's: • Wanneer deze optie is ingesteld op nul: apps kunnen worden geschaald naar nul wanneer er niet-actieve aanvragen zijn en sommige aanvragen mogelijk meer latentie hebben bij het opstarten. • Wanneer dit is ingesteld op een of meer: het hostproces wordt continu uitgevoerd, wat betekent dat koude start geen probleem is. |
| Verbruiksabonnement | Apps kunnen worden geschaald naar nul wanneer ze niet actief zijn, wat betekent dat sommige aanvragen mogelijk meer latentie hebben bij het opstarten. Het verbruiksplan beschikt over enkele optimalisaties om de koude begintijd te verminderen, waaronder het ophalen van vooraf opgewarmde tijdelijke aanduidingenfuncties waarop de host- en taalprocessen al worden uitgevoerd. |
Servicelimieten
| Bron | Flex Consumption-abonnement | Premium-abonnement | As-omgeving van toegewezen abonnement/ | Container Apps | Verbruiksabonnement |
|---|---|---|---|---|---|
| Standaard time-outduur (min.) | 30 | 30 | 301 | 3016 | 5 |
| Maximale time-outduur (min.) | niet-gebonden9 | niet-gebonden9 | niet-gebonden2 | niet-gebonden17 | 10 |
| Maximumaantal uitgaande verbindingen (per exemplaar) | niet-gebonden | niet-gebonden | niet-gebonden | niet-gebonden | 600 actief (1.200 totaal) |
| Maximale aanvraaggrootte (MB)3 | 210 | 210 | 210 | 210 | 210 |
| Maximale tekenreekslengte voor query's3 | 4096 | 4096 | 4096 | 4096 | 4096 |
| Maximale lengte voor aanvraag-URL's3 | 8192 | 8192 | 8192 | 8192 | 8192 |
| ACU per exemplaar | 210-840 | 100-840/210-250 10 | Varieert | 100 | Varieert |
| Maximaal geheugen (GB per exemplaar) | 4<sup4 | 3,5-14 | 1.75-256/8-256 | Varieert | 1.5 |
| Maximumaantal exemplaren (Windows/Linux) | 100/20 | verschilt per SKU/10011 | 10-30018 | 200/100 | 1000 15 |
| Functie-apps per abonnement13 | 100 | 100 | niet-gebonden4 | niet-gebonden4 | 100 |
| App Service-abonnementen | n.v.t. | 100 per resourcegroep | 100 per resourcegroep | n.v.t. | 100 per regio |
| Implementatiesites per app12 | n.v.t. | 3 | 1-2011 | niet ondersteund | 2 |
| Opslag (tijdelijk)5 | 0,8 GB | 21-140 GB | 11-140 GB | n.v.t. | 0.5 GB |
| Opslag (persistent) | 0 GB7 | 250 GB | 10-1000 GB11 | n.v.t. | 1 GB6,7 |
| Aangepaste domeinen per app | 500 | 500 | 500 | niet ondersteund | 5007 |
| Aangepast domein voor SSL-ondersteuning | niet-gebonden SNI SSL- en 1 IP SSL-verbindingen inbegrepen | niet-gebonden SNI SSL- en 1 IP SSL-verbindingen inbegrepen | niet-gebonden SNI SSL- en 1 IP SSL-verbindingen inbegrepen | niet ondersteund | niet-gebonden SNI SSL-verbinding inbegrepen |
Opmerkingen over servicelimieten:
- De time-out voor de Functions 1.x-runtime in een App Service-plan is standaard niet gebonden.
- Vereist dat het App Service-plan is ingesteld op AlwaysOn. Tegen standaardtarieven. Er wordt een respijtperiode van 10 minuten gegeven tijdens platformupdates.
- Deze limieten worden ingesteld in de host.
- Het werkelijke aantal functie-apps dat u kunt hosten, is afhankelijk van de activiteit van de apps, de grootte van de machine-exemplaren en het bijbehorende resourcegebruik.
- De opslaglimiet is de totale inhoudsgrootte in tijdelijke opslag voor alle apps in hetzelfde App Service-plan. Voor verbruiksabonnementen op Linux is de opslag momenteel 1,5 GB.
- Verbruiksabonnement maakt gebruik van een Azure Files-share voor permanente opslag. Wanneer u uw eigen Azure Files-share opgeeft, zijn de limieten voor de specifieke sharegrootte afhankelijk van het opslagaccount dat u hebt ingesteld voor WEBSITE_CONTENTAZUREFILECONNECTIONSTRING.
- In Linux moet u uw eigen Azure Files-share expliciet koppelen.
- Wanneer uw functie-app wordt gehost in een verbruiksabonnement, wordt alleen de CNAME-optie ondersteund. Voor functie-apps in een Premium-abonnement of een App Service-abonnement kunt u een aangepast domein toewijzen met een CNAME- of A-record.
- Er is geen maximale time-outduur voor uitvoering afgedwongen. De respijtperiode die aan een functie-uitvoering wordt gegeven, is echter 60 minuten tijdens het inschalen en 10 minuten tijdens platformupdates.
- Werkrollen zijn rollen die klanten-apps hosten. Werkrollen zijn beschikbaar in drie vaste grootten: één vCPU/3,5 GB RAM; Twee vCPU/7 GB RAM; Vier vCPU/14 GB RAM.
- Zie App Service-limieten voor meer informatie.
- Inclusief de productiesite.
- Er is momenteel een limiet van 5000 functie-apps in een bepaald abonnement.
- De instantiegrootten van flexverbruiksabonnementen zijn momenteel gedefinieerd als 2048 MB of 4096 MB. Zie Exemplaargeheugen voor meer informatie.
- Flex Consumption-abonnement heeft een regionaal abonnementsquotum dat het totale geheugengebruik van alle exemplaren in een bepaalde regio beperkt. Zie Exemplaargeheugen voor meer informatie.
- Wanneer het minimale aantal replica's is ingesteld op nul, is de standaardtime-out afhankelijk van de specifieke triggers die in de app worden gebruikt.
- Wanneer het minimumaantal replica's is ingesteld op een of meer replica's .
- In Container Apps kunt u het maximum aantal replica's instellen, dat wordt gehonoreerd zolang er voldoende kerngeheugenquotum beschikbaar is.
Netwerkfuncties
| Functie | Flex Consumption-abonnement | Verbruiksabonnement | Premium-abonnement | As-omgeving van toegewezen abonnement/ | Container Apps1 |
|---|---|---|---|---|---|
| Binnenkomende IP-beperkingen | ✔ | ✔ | ✔ | ✔ | ✔ |
| Binnenkomende privé-eindpunten | ✔ | ✔ | ✔ | ||
| Integratie van virtueel netwerk | ✔ | ✔Arabisch cijfer | ✔3 | ✔ | |
| Uitgaande IP-beperkingen | ✔ | ✔ | ✔ | ✔ |
- Zie Netwerken in de Azure Container Apps-omgeving voor meer informatie.
- Er zijn speciale overwegingen bij het werken met triggers voor virtuele netwerken.
- Alleen het Toegewezen/ASE-plan biedt ondersteuning voor gateway-vereiste integratie van virtuele netwerken.
Billing
| Plannen | DETAILS |
|---|---|
| Flex Consumption-abonnement | Facturering is gebaseerd op het aantal uitvoeringen, het geheugen van exemplaren wanneer ze actief functies uitvoeren, plus de kosten van alle exemplaren die altijd gereed zijn. Zie Facturering voor Flex Consumption-abonnement voor meer informatie. |
| Premium-abonnement | Premium-abonnement is gebaseerd op het aantal kern seconden en het geheugen dat wordt gebruikt voor de benodigde en voorafwarmde exemplaren. Ten minste één exemplaar per abonnement moet altijd warm worden gehouden. Dit abonnement biedt de meest voorspelbare prijzen. |
| Toegewezen abonnement | U betaalt hetzelfde voor functie-apps in een App Service-plan als voor andere App Service-resources, zoals web-apps. Voor een ASE is er een vast maandelijks tarief dat betaalt voor de infrastructuur en niet verandert met de grootte van de omgeving. Er zijn ook kosten per App Service-plan vCPU. Alle apps die worden gehost in een AS-omgeving, vallen onder de Geïsoleerde prijs-SKU. Zie het overzichtsartikel over ASE voor meer informatie. |
| Container Apps | Facturering in Azure Container Apps is gebaseerd op uw abonnementstype. Zie Facturering in Azure Container Apps voor meer informatie. |
| Verbruiksabonnement | Betaal alleen voor de tijd dat uw functies worden uitgevoerd. De facturering is dan ook gebaseerd op het aantal uitvoeringen, de uitvoeringstijd en het gebruikte geheugen. |
Zie de pagina met prijzen van Azure Functions voor een directe kostenvergelijking tussen dynamische hostingabonnementen (Verbruik, Flex Consumption en Premium). Voor prijzen van de verschillende opties voor een Dedicated-abonnement raadpleegt u de pagina met prijzen van App Service. Zie De prijzen van Azure Container Apps voor het hosten van Container Apps.
Beperkingen voor het maken van nieuwe functie-apps in een bestaande resourcegroep
In sommige gevallen ontvangt u een van de volgende fouten wanneer u een nieuw hostingabonnement voor uw functie-app in een bestaande resourcegroep probeert te maken:
- De prijscategorie is niet toegestaan in deze resourcegroep
- <> SKU_name werknemers zijn niet beschikbaar in de resourcegroep <resource_group_name>
Dit kan gebeuren wanneer aan de volgende voorwaarden wordt voldaan:
- U maakt een functie-app in een bestaande resourcegroep die ooit een andere functie-app of web-app bevat. Linux Consumption-apps worden bijvoorbeeld niet ondersteund in dezelfde resourcegroep als Linux Dedicated- of Linux Premium-abonnementen.
- Uw nieuwe functie-app wordt gemaakt in dezelfde regio als de vorige app.
- De vorige app is op een of andere manier niet compatibel met uw nieuwe app. Deze fout kan optreden tussen SKU's, besturingssystemen of vanwege andere functies op platformniveau, zoals ondersteuning voor beschikbaarheidszones.
De reden hiervoor is dat functie-app- en web-app-plannen worden toegewezen aan verschillende groepen resources wanneer ze worden gemaakt. Voor verschillende SKU's is een andere set infrastructuurmogelijkheden vereist. Wanneer u een app in een resourcegroep maakt, wordt die resourcegroep toegewezen en toegewezen aan een specifieke groep resources. Als u een ander plan in die resourcegroep probeert te maken en de toegewezen pool niet over de vereiste resources beschikt, treedt deze fout op.
Wanneer deze fout optreedt, maakt u in plaats daarvan uw functie-app en hostingabonnement in een nieuwe resourcegroep.