Värdalternativ för Azure Functions

2025-05-09

När du skapar en funktionsapp i Azure måste du välja ett värdalternativ för din app. Azure tillhandahåller följande värdalternativ för din funktionskod:

Värdtjänstalternativ	Tjänst	Tillgänglighet	Stöd för containrar
Flex-förbrukningsplan	Azure-funktioner	Allmänt tillgängliga (GA)	Ingen
Premium-plan	Azure-funktioner	Allmän tillgänglighet (GA)	Linux
Dedikerad plan	Azure-funktioner	Allmän tillgänglighet (GA)	Linux
Container Apps	Azure Container-applikationer	Allmän tillgänglighet (GA)	Linux
Förbrukningsplan	Azure-funktioner	Allmän tillgänglighet (GA)	Ingen

Värdalternativ för Azure Functions underlättas av Azure App Service-infrastrukturen på både virtuella Linux- och Windows-datorer. Det värdalternativ som du väljer avgör följande beteenden:

Hur din funktionsapplikation blir skalad.
De resurser som är tillgängliga för varje funktionsappinstans.
Stöd för avancerade funktioner, till exempel Azure Virtual Network-anslutning.
Stöd för Linux-containrar.

Den plan du väljer påverkar också kostnaderna för att köra funktionskoden. Mer information finns i Fakturering.

Den här artikeln innehåller en detaljerad jämförelse mellan de olika värdalternativen. Mer information om hur du kör och hanterar din funktionskod i Linux-containrar finns i Stöd för Linux-container i Azure Functions.

Översikt över planer

Följande är en sammanfattning av fördelarna med de olika alternativen för Azure Functions-värdtjänster:

Alternativ	Förmåner
Flex-förbrukningsplan	Få snabb horisontell skalning med beräkningsalternativ, virtuella nätverk och betala per användning-fakturering. I Flex Consumption-planen läggs instanser av hubb för funktioner dynamiskt till och tas bort baserat på den konfigurerade samtidigheter per instans och antalet inkommande händelser. ✔ Minska kallstarter genom att ange en eller flera förprovisionerade (alltid redo) instanser. ✔ Stöder virtuella nätverk för ökad säkerhet. ✔ Betala när funktionerna körs. ✔ Skalas automatiskt, även under perioder med hög belastning.
Premium-plan	Skalar automatiskt baserat på efterfrågan med hjälp av förvärmda arbetare, som kör program utan fördröjning efter inaktivitet, körs på kraftfullare instanser och ansluter till virtuella nätverk. Överväg Azure Functions Premium-planen i följande situationer: ✔ Dina funktionsappar körs kontinuerligt eller nästan kontinuerligt. ✔ Du vill ha mer kontroll över dina instanser och vill distribuera flera funktionsappar på samma plan med händelsedriven skalning. ✔ Du har ett stort antal små körningar och en hög körningsfaktura, men låga GB-sekunder i förbrukningsplanen. ✔ Du behöver fler processor- eller minnesalternativ än vad som anges i förbrukningsplanerna. ✔ Koden måste köras längre än den maximala körningstiden som tillåts i förbrukningsplanen. ✔ Du behöver anslutning till virtuella nätverk. ✔ Du vill ange en anpassad Linux-avbildning där du kan köra dina funktioner.
Dedikerad plan	Kör dina funktioner i en App Service-plan till vanliga App Service-planpriser. Bäst för långvariga scenarier där Durable Functions inte kan användas. Överväg en App Service-plan i följande situationer: ✔ Du har befintliga och underutnytttagna virtuella datorer som redan kör andra App Service-instanser. ✔ Du måste ha en helt förutsägbar fakturering, eller så måste du skala instanser manuellt. ✔ Du vill köra flera webbappar och funktionsappar på samma plan ✔ Du behöver åtkomst till större val av beräkningsstorlek. ✔ Fullständig beräkningsisolering och säker nätverksåtkomst som tillhandahålls av en App Service-miljön (ASE). ✔ Mycket hög minnesanvändning och hög skalning (ASE).
Container Apps	Skapa och distribuera containerbaserade funktionsappar i en fullständigt hanterad miljö som hanteras av Azure Container Apps. Använd Azure Functions-programmeringsmodellen för att skapa händelsedrivna, serverlösa, molnbaserade funktionsappar. Kör dina funktioner tillsammans med andra mikrotjänster, API:er, webbplatser och arbetsflöden som värdbaserade program för containrar. Överväg att vara värd för dina funktioner i Container Apps i följande situationer: ✔ Du vill paketera anpassade bibliotek med din funktionskod för att stödja verksamhetsspecifika appar. ✔ Du måste migrera kodkörning från lokala eller äldre appar till molnbaserade mikrotjänster som körs i containrar. ✔ När du vill undvika omkostnaderna och komplexiteten i att hantera Kubernetes-kluster och dedikerad beräkning. ✔ Dina funktioner behöver avancerad bearbetningskraft som tillhandahålls av dedikerade GPU-beräkningsresurser.
Förbrukningsplan	Betala endast för beräkningsresurser när dina funktioner körs (betala per användning) med automatisk skalning. I en konsumtionsplan läggs instanser av Functions-värden till och tas bort dynamiskt baserat på antalet inkommande händelser. ✔ Standardvärdplan som tillhandahåller sann serverlös värd. ✔ Betala endast när dina funktioner körs. ✔ Skalas automatiskt, även under perioder med hög belastning.

De återstående tabellerna i den här artikeln jämför värdalternativ baserat på olika funktioner och beteenden.

Stöd för operativsystem

Den här tabellen visar operativsystemsstöd för värdalternativen.

Webbhotell	Linux^{1-distribution}	Windows^{2-driftsättning}
Flex-förbrukningsplan	✅ Endast kod ❌ Container (stöds inte)	❌ Stöds inte
Premium-plan	✅ Endast kod ✅ Behållare	✅ Endast kod
Dedikerad plan	✅ Endast kod ✅ Behållare	✅ Endast kod
Container Apps	✅ Endast container	❌ Stöds inte
Förbrukningsplan	✅ Endast kod ❌ Container (stöds inte)	✅ Endast kod

Linux är det enda operativsystem som stöds för Python-körningsstacken.
Windows-utplaceringar består endast av kod. Functions stöder för närvarande inte Windows-containrar.

Tidsgränsvaraktighet för funktionsapp

Tidsgränsen för funktioner i en funktionsapp definieras av functionTimeout egenskapen i host.json-projektfilen . Den här egenskapen gäller specifikt för funktionskörningar. När utlösaren startar funktionskörningen måste funktionen returnera/svara inom tidsgränsen. För att undvika tidsgränser är det viktigt att skriva robusta funktioner. Mer information finns i Förbättra Prestanda och tillförlitlighet för Azure Functions.

I följande tabell visas standardvärdena och maxvärdena (i minuter) för specifika planer:

Strategi	Standardvärde	Maximalt¹
Flex-förbrukningsplan	30	Obundna²
Premium-plan	30⁴	Obundna²
Dedikerad plan	30⁴	Obundna³
Container Apps	30	Obunden⁵
Förbrukningsplan	5	10

Oavsett tidsgränsinställningen för funktionsappen är 230 sekunder den maximala tid som en HTTP-utlöst funktion kan ta för att svara på en begäran. Detta beror på den inaktiva tidsgränsen som är standard för Azure Load Balancer. För längre bearbetningstider bör du överväga att använda mönstret Durable Functions-asynkronisering eller skjuta upp det faktiska arbetet och returnera ett omedelbart svar.
Det finns ingen maximal tidsgräns för körningen som tillämpas. Respitperioden som ges för en funktionskörning är dock 60 minuter under nedskalning för Flex Consumption- och Premium-planerna, och en respitperiod för 10 minuter ges under plattformsuppdateringar.
Kräver att App Service-planen är inställd på AlwaysOn. En respitperiod på 10 minuter ges under plattformsuppdateringar.
Standardtidsgränsen för version 1.x av Functions-värdkörningen är obegränsad.
När det minsta antalet repliker är inställt på noll beror standardtidsgränsen på de specifika utlösare som används i appen.

Språkstöd

Mer information om aktuellt stöd för interna språkstackar i Functions finns i Språk som stöds i Azure Functions.

Skala

I följande tabell jämförs skalningsbeteendena för de olika värdplanerna.
Maximalt antal instanser ges per funktionsapp (Förbrukning) eller per plan (Premium/Dedikerad) om inget annat anges.

Strategi	Skala ut	Maximalt antal instanser
Flex-förbrukningsplan	Skalning per funktion. Händelsedrivna skalningsbeslut beräknas per funktion, vilket ger ett mer deterministiskt sätt att skala funktionerna i din app. Med undantag för HTTP, Blob Storage (Event Grid) och Durable Functions skalas alla andra funktionsutlösartyper i din app på oberoende instanser. Alla HTTP-utlösare i din app skalas tillsammans som en grupp på samma instanser, liksom alla Blob Storage-utlösare (Event Grid). Alla Durable Functions-utlösare delar också instanser och skalar tillsammans.	1000¹
Premium-plan	Händelsedriven. Skala ut automatiskt, även under perioder med hög belastning. Azure Functions-infrastrukturen skalar CPU- och minnesresurser genom att lägga till fler instanser av funktionernas värd, baserat på antalet händelser som dess funktioner utlöses av.	Windows: 100⁶ Linux: 20–100^2,6
Dedikerad plan	Manuell/autoskalering	10-30³ 100 (ASE)
Container Apps	Händelsedriven. Skala ut automatiskt, även under perioder med hög belastning. Azure Functions-infrastrukturen skalar CPU- och minnesresurser genom att lägga till fler instanser av funktionernas värd, baserat på antalet händelser som dess funktioner utlöses av.	300-1000⁴
Förbrukningsplan	Händelsedriven. Skalas ut automatiskt, även under perioder med hög belastning. Funktionernas infrastruktur skalar CPU- och minnesresurser genom att lägga till fler instanser av funktionernas värd, baserat på antalet inkommande utlösarhändelser.	Windows: 200 Linux: 100⁵

Flex Consumption Plan har en regional prenumerationskvot som begränsar den totala minnesanvändningen för alla instanser i en viss region. Mer information finns i Regionala minneskvoter för prenumeration. Flex Consumption-planer stöder för närvarande endast Linux.
I vissa regioner kan Linux-appar på en Premium-plan skalas till 100 instanser. Mer information finns i artikeln premiumplan.
Specifika gränser för de olika App Service-planalternativen finns i Gränserna för App Service-planen.
I Container Apps är standardvärdet 10 instanser, men du kan ange det maximala antalet repliker, som totalt har högst 1 000. Den här inställningen respekteras så länge det finns tillräckligt med kvoter för kärnor tillgängliga. Mer information finns i Kvoter för Azure Container Apps. När du skapar din funktionsapp från Azure Portal är du begränsad till 300 instanser.
Vid utskalning finns det för närvarande en gräns på 500 instanser per prenumeration per timme för Linux-appar i en konsumtionsplan.
För privata slutpunktsbegränsade http-utlösare är utskalning begränsad till högst 20 instanser.

Beteende för kallstart

Strategi	Detaljer
Flex-förbrukningsplan	Stöder alltid redo instanser för att minska fördröjningen vid etablering av nya instanser.
Premium-plan	Stöder alltid redo instanser för att undvika kallstarter genom att du kan underhålla en eller flera ständigt varma instanser.
Dedikerad plan	När den körs i en dedikerad plan kan Functions-värden köras kontinuerligt på ett föreskrivet antal instanser, vilket innebär att kallstart egentligen inte är ett problem.
Container Apps	Beror på det minsta antalet repliker: • När värdet är noll: appar kan skalas till noll när de är inaktiva och vissa begäranden kan ha fler svarstider vid start. • När värdet är inställt på en eller flera: värdprocessen körs kontinuerligt, vilket innebär att kallstart inte är ett problem.
Förbrukningsplan	Appar kan skalas till noll när de är inaktiva, vilket innebär att vissa begäranden kan ha fler svarstider vid start. Förbrukningsplanen har vissa optimeringar för att minska kallstartstiden, inklusive att hämta från förvärmda platshållarfunktioner som redan har värd- och språkprocesserna igång.

Tjänstbegränsningar

Resurs	Flex-förbrukningsplan	Premium-plan	Dedikerad plan/ASE	Appar för containrar	Förbrukningsplan
Standard timeoutperiod (min)	30	30	30¹	30¹⁶	5
Maximal timeout-tidsgräns (min)	obunden⁹	obunden⁹	obegränsad²	obunden¹⁷	10
Maximalt antal utgående anslutningar (per instans)	Obegränsad	Obegränsad	Obegränsad	Obegränsad	600 aktiva (totalt 1 200)
Maximal storlek på begäran (MB)³	210	210	210	210	210
Maximal frågesträngslängd³	4096	4096	4096	4096	4096
Maximal url-längd^{för begäran 3}	8192	8192	8192	8192	8192
ACU per instans	210-840	100-840/210-250¹⁰	Varierar	100	Varierar
Maximalt minne (GB per instans)	4¹⁴	3.5-14	1.75-256/8-256	Varierar	1.5
Maximalt antal instanser (Windows \| Linux)¹⁵	n/a \| 1000	20-100	10–30 (100 ASE)¹¹	300-1000¹⁸	200 \| 100
Funktionsappar per plan¹³	1	100	obunden⁴	obunden⁴	100
App Service-planer	Inte tillämpligt	100 per resursgrupp	100 per resursgrupp	Inte tillämpligt	100 per region
Distribueringsplatser per app¹²	Inte tillämpligt	3	1-20¹¹	stöds inte	2
Lagring (tillfälligt)⁵	0,8 GB	21–140 GB	11–140 GB	Inte tillämpligt	0,5 GB
Lagring (beständiga)	0 GB⁷	250 GB	10–1 000 GB¹¹	Inte tillämpligt	1 GB^6,7
Anpassade domäner per app	500	500	500	stöds inte	500⁷
Stöd för TSL/SSL för anpassad domän	Obegränsade SNI SSL och en IP-baserad SSL-anslutning ingår	Obegränsade SNI SSL och en IP-baserad SSL-anslutning ingår	Obegränsade SNI SSL och en IP-baserad SSL-anslutning ingår	stöds inte	Obundna SNI SSL-anslutningar ingår

Anmärkningar om tjänstbegränsningar:

Som standardinställning är tidsgränsen för körning av Functions 1.x i en App Service-plan obegränsad.
Kräver att App Service-planen är inställd på AlwaysOn. Betala till standardpriser. En respitperiod på 10 minuter ges under plattformsuppdateringar.
Dessa gränser anges i värddatorn.
Det faktiska antalet funktionsappar som du kan vara värd för beror på apparnas aktivitet, storleken på datorinstanserna och motsvarande resursanvändning.
Lagringsgränsen är den totala innehållsstorleken i tillfällig lagring för alla appar i samma App Service-plan. För förbrukningsplaner i Linux är lagringen för närvarande 1,5 GB.
Förbrukningsplanen använder en Azure Files-resurs för sparad lagring. När du anger en egen Azure Files-resurs beror de specifika storleksgränserna för resursen på det lagringskonto som du har angett för WEBSITE_CONTENTAZUREFILECONNECTIONSTRING.
I Linux måste du uttryckligen montera din egen Azure Files-resurs.
När din funktionsapp finns i en förbrukningsplan stöds endast CNAME-alternativet. För funktionsappar i en Premium-plan eller en App Service-plan kan du mappa en anpassad domän med antingen en CNAME- eller A-post.
Tidsgränsen för maximal körning har inte tillämpats. Respitperioden som ges till en funktionskörning är dock 60 minuter under skalning på och 10 minuter under plattformsuppdateringar.
Arbetare är roller som är värdar för kundappar. Arbetare är tillgängliga i tre fasta storlekar: En vCPU/3,5 GB RAM-minne; Två vCPU/7 GB RAM-minne; Fyra vCPU/14 GB RAM-minne.
Mer information finns i Begränsningar för App Service.
Inklusive produktionsplatsen.
Det finns för närvarande en gräns på 5 000 funktionsappar i en viss prenumeration.
Instansstorlekar för Flex Consumption Plan definieras för närvarande som 512 MB, 2 048 MB eller 4 096 MB. Mer information finns i Instansminne.
Mer information finns i artikeln Skala i Jämförelse av värd.
När det minsta antalet repliker är inställt på noll beror standardtidsgränsen på de specifika utlösare som används i appen.
När det minsta antalet repliker är inställt på en eller flera.

Nätverksfunktioner

Egenskap	Flex-förbrukningsplan	Förbrukningsplan	Premium-plan	Dedikerad plan/ASE	Container Apps¹
Inkommande IP-begränsningar	✔	✔	✔	✔	✔
Inkommande privata slutpunkter	✔		✔	✔
Integrering med virtuellt nätverk	✔		✔²	✔³	✔
Utgående IP-begränsningar	✔		✔	✔	✔

Mer information finns i Nätverk i Azure Container Apps-miljön.
Det finns särskilda överväganden när du arbetar med utlösare för virtuella nätverk.
Endast den Dedikerade/ASE-planen stödjer integration med virtuella nätverk som kräver gateway.

Fakturering

Strategi	Detaljer
Flex-förbrukningsplan	Faktureringen baseras på antalet körningar, minnet av instanser när de aktivt kör funktioner, plus kostnaden för alla alltid redo instanser. Mer information finns i Fakturering av flexförbrukningsplan.
Premium-plan	Premium-planen baseras på antalet kärnsekunder och minne som används i de nödvändiga och förvärmda instanserna. Minst en instans per plan måste alltid hållas varm. Den här planen ger den mest förutsägbara prissättningen.
Dedikerad plan	Du betalar samma för funktionsappar i en App Service-plan som för andra App Service-resurser, till exempel webbappar. För en ASE finns det en fast månadskostnad som betalar för infrastrukturen och som inte ändras med miljöns storlek. Det finns också en kostnad per App Service-plan vCPU. Alla appar som har en ASE som värd finns i SKU med isolerad prissättning. Mer information finns i ase-översiktsartikeln.
Container Apps	Faktureringen i Azure Container Apps baseras på din plantyp. Mer information finns i Fakturering i Azure Container Apps.
Förbrukningsplan	Betala bara för den tid som dina funktioner körs. Fakturering baseras på antalet körningar, körningstid och använt minne.

En direkt kostnadsjämförelse mellan dynamiska värdplaner (Förbrukning, Flexförbrukning och Premium) finns på prissättningssidan för Azure Functions. Priser för de olika alternativen för dedikerade abonnemang finns på prissidan för App Service. Information om hur du prissätter Värdtjänster för Container Apps finns i Prissättning för Azure Container Apps.

Begränsningar för att skapa nya funktionsappar i en befintlig resursgrupp

I vissa fall kan du få något av följande fel när du försöker skapa en ny värdplan för funktionsappen i en befintlig resursgrupp:

Prisnivån är inte tillåten i den här resursgruppen
<SKU_name>-arbetare är inte tillgängliga i resursgruppen <resource_group_name>

Detta kan inträffa när följande villkor uppfylls:

Du skapar en funktionsapp i en befintlig resursgrupp som någonsin har innehållit en annan funktionsapp eller webbapp. Till exempel stöds inte Linux-förbrukningsappar i samma resursgrupp som Linux Dedicated- eller Linux Premium-abonnemang.
Den nya funktionsappen skapas i samma region som föregående app.
Den tidigare appen är på något sätt inte kompatibel med din nya app. Det här felet kan inträffa mellan SKU:er, operativsystem eller andra funktioner på plattformsnivå, till exempel stöd för tillgänglighetszoner.

Orsaken till detta beror på hur funktionsapps- och webbappsplaner mappas till olika resurspooler när de skapas. Olika SKU:er kräver en annan uppsättning infrastrukturfunktioner. När du skapar en app i en resursgrupp mappas och tilldelas den resursgruppen till en specifik resurspool. Om du försöker skapa en annan plan i resursgruppen och den mappade poolen inte har de resurser som krävs uppstår det här felet.

När det här felet inträffar skapar du i stället din funktionsapp och värdplan i en ny resursgrupp.

Dela via