možnosti hostování Azure Functions

Když v Azure vytvoříte aplikaci funkcí, musíte zvolit možnost hostování aplikace. Azure poskytuje tyto možnosti hostování kódu funkce:

Možnost hostování	Služba	Dostupnost	Podpora kontejnerů
Plán flexibilní spotřeby	Azure Functions	Obecně dostupné (GA)	Žádné
Plán Premium	Azure Functions	GA	Operační systém Linux
Vyhrazený tarif	Azure Functions	GA	Operační systém Linux
Container Apps	Azure Container Apps	GA	Operační systém Linux
Plán spotřeby (starší verze)	Azure Functions	Windows – GA Linux – vyřazeno	Žádné

Důležité

Plán Consumption je starší plán hostování. Pro nové aplikace funkcí bez serveru použijte plán Flex Consumption. U existujících aplikací plánu Consumption migrujte do plánu Flex Consumption.

Infrastruktura Azure App Service na virtuálních počítačích s Linuxem i Windows usnadňuje možnosti hostování Azure Functions. Možnost hostování, kterou zvolíte, určuje následující chování:

• Jak se vaše funkční aplikace škáluje.
• Prostředky dostupné pro každou instanci aplikace funkcí.
• Podpora pokročilých funkcí, jako je připojení Azure Virtual Network
• Podpora kontejnerů Linuxu

Zvolený plán má také vliv na náklady na spuštění kódu funkce. Další informace najdete v tématu Fakturace.

Tento článek obsahuje podrobné porovnání různých možností hostování. Další informace o spouštění a správě kódu funkce v kontejnerech Linuxu najdete v tématu Podpora kontejnerůLinux v Azure Functions.

Přehled plánů

Následující tabulka shrnuje výhody různých možností hostování funkcí Azure.

Možnost	Zaměstnanecké výhody
Plán flexibilní spotřeby	Zažijte rychlé horizontální škálování s flexibilními možnostmi výpočetních prostředků, integrací virtuální sítě a fakturací průběžných plateb bez serveru. V plánu Flex Consumption se instance funkcí dynamicky škálují na více instancí (až 1 000) na základě nakonfigurované souběžnosti jednotlivých instancí, příchozích událostí a úloh pro jednotlivé funkce za účelem zajištění optimální efektivity. Zvažte plán Flex Consumption v následujících případech: ✔ Pro kód funkce potřebujete bezserverového hostitele, který platí jenom za provádění na vyžádání. ✔ Pro zabezpečený přístup k prostředkům Azure vyžadujete připojení k virtuální síti. ✔ Vaše úlohy jsou proměnlivé a můžou přecházet od žádné aktivity až po náročné rychlé škálování řízené událostmi. ✔ Chcete si přizpůsobit výpočet s velikostmi paměti (512 MB, 2 048 MB nebo 4 096 MB) a snížit počet studených startů prostřednictvím jedné nebo více instancí, které jsou předem připravené (vždy připravené).
Plán Premium	Automaticky škáluje na základě poptávky pomocí předem připravených pracovníků, které spouští aplikace bez zpoždění po nečinnosti, běží na výkonnějších instancích a připojuje se k virtuálním sítím. Vezměte v úvahu plán Azure Functions Premium v následujících situacích: ✔ Aplikace funkcí běží nepřetržitě nebo téměř nepřetržitě. ✔ Chcete mít větší kontrolu nad vašimi instancemi a chcete do stejného plánu nasadit více aplikací funkcí se škálováním řízeným událostmi. ✔ V plánu Consumption máte vysoký počet malých vykonání a vysoké faktury za provádění, ale nízké GB sekundy. ✔ Potřebujete více možností procesoru nebo paměti, než jaké poskytují spotřebitelské plány. ✔ Váš kód musí běžet déle, než je maximální doba provádění povolená v plánu Consumption. ✔ Pro zabezpečený přístup k prostředkům Azure vyžadujete připojení k virtuální síti. ✔ Chcete zadat vlastní image Linuxu, ve které chcete spouštět funkce.
Vyhrazený tarif	Spouštějte funkce v rámci plánu služby App Service za pravidelné sazby plánu služby App Service. Nejvhodnější pro dlouhotrvající scénáře, kdy se Durable Functions nedá použít. V následujících situacích zvažte plán služby App Service: ✔ Máte existující a nedostatečně využité virtuální počítače, na kterých už běží jiné instance služby App Service. ✔ Musíte mít plně předvídatelnou fakturaci nebo potřebujete ručně škálovat instance. ✔ Chcete spustit více webových aplikací a funkčních aplikací v rámci stejného plánu. ✔ Potřebujete přístup k většímu výběru velikosti výpočetní kapacity. ✔ Úplná izolace výpočetních prostředků a zabezpečený přístup k síti poskytovaný App Service Environment (ASE). ✔ Velmi vysoké využití paměti a vysoké škálování (ASE).
Container Apps	Vytváření a nasazování kontejnerizovaných aplikací funkcí v plně spravovaném prostředí hostovaného Azure Container Apps Pomocí programovacího modelu Azure Functions můžete vytvářet aplikace funkcí, které jsou řízené událostmi, bezserverové a nativní pro cloud. Funkce můžete spouštět společně s dalšími mikroslužbami, rozhraními API, weby a pracovními postupy jako programy hostované kontejnery. Zvažte hostování funkcí v Container Apps v následujících situacích: ✔ Chcete mít kontrolu nad imagí kontejneru a chcete s kódem funkce zabalit vlastní knihovny, které podporují obchodní aplikace. ✔ Potřebujete migrovat spouštění kódu z místních nebo starších aplikací do nativních cloudových mikroslužeb spuštěných v kontejnerech. ✔ Pokud se chcete vyhnout režii a složitosti správy clusterů Kubernetes a vyhrazených výpočetních prostředků. ✔ Vaše funkce potřebují vysoký výpočetní výkon poskytovaný vyhrazenými výpočetními prostředky GPU.
Plán spotřeby (starší verze)	Platíte za výpočetní prostředky jenom v případě, že vaše funkce běží (průběžné platby) s automatickým škálováním na Windows. V plánu Consumption se instance funkcí dynamicky přidávají a odebírají na základě počtu příchozích událostí. Zvažte plán Consumption v následujících případech: ✔ Máte závislost na Windows. Například pomocí modulu runtime v1, kompletního rozhraní .NET Framework nebo funkcí specifických pro Windows, jako jsou některé moduly PowerShellu. ✔ Chcete bezserverový fakturační model a platit jenom v případech, kdy jsou vaše funkce spuštěné. Pro nové aplikace funkcí bez serveru použijte místo toho plán Flex Consumption .

Zbývající tabulky v tomto článku porovnávají možnosti hostování na základě různých funkcí a chování.

Podpora operačního systému

Tato tabulka ukazuje podporu operačního systému pro možnosti hostování.

Hosting	Nasazení Linuxu1	Windows2 nasazení
Plán flexibilní spotřeby	✅ Pouze kód ❌ Kontejner (nepodporuje se)	❌ Nepodporováno
Plán Premium	✅ Pouze kód ✅ Kontejner	✅ Pouze kód
Vyhrazený tarif	✅ Pouze kód ✅ Kontejner	✅ Pouze kód
Container Apps	✅ Pouze kontejner	❌ Nepodporováno
Plán spotřeby	✅ Pouze kód (vyřazeno) ❌ Kontejner (nepodporuje se)	✅ Pouze kód (starší verze)

1. Linux je jediný podporovaný operační systém pro zásobník modulu runtime Python.
2. Nasazení Windows jsou pouze ve formě kódu. Azure Functions v současné době nepodporuje kontejnery Windows.

Důležité

Aplikace funkcí stále spouštějí modul runtime verze v3 s ukončenou podporou na Linuxu v plánu spotřeby přestanou běžet po 30. září 2026. Pokud se chcete vyhnout přerušení služeb, migrujte aplikaci do modulu runtime v4.

Možnost hostovat funkční aplikace na Linuxu v plánu Consumption bude vyřazena z provozu 30. září 2028. Plán spotřeby pro Linux již nedostává žádné nové funkce ani jazykové verze. Aplikace spuštěné na Windows v plánu Consumption nejsou aktuálně ovlivněné. Migrujte své aplikace do plánu Flex Consumption před datem vyřazení.

Doba trvání časového limitu aplikace funkcí

Vlastnost functionTimeout v souboru projektu host.json nastaví dobu časového limitu pro funkce v aplikaci funkcí. Tato vlastnost se vztahuje konkrétně na provádění funkcí. Jakmile trigger spustí spuštění funkce, musí se funkce vrátit nebo reagovat v době časového limitu. Pokud provádění tuto dobu překročí, dojde k chybě časového limitu a jazykový pracovní proces se restartuje. U aplikací v jazyce C# spuštěných v procesu se samotný hostitelský proces restartuje. Aby nedocházelo k vypršení časových limitů a následným restartováním procesů, je důležité napsat robustní funkce. Další informace najdete v tématu Zlepšit Azure Functions výkon a spolehlivost.

Následující tabulka uvádí výchozí a maximální hodnoty (v minutách) pro konkrétní plány:

Plánování	Výchozí	Maximálně1
Plán flexibilní spotřeby	30	Nevázané2
Plán Premium	304	Nevázané2
Vyhrazený tarif	304	Nevázané3
Container Apps	30	Neomezený5
Plán spotřeby	5	10

1. Bez ohledu na nastavení časového limitu aplikace funkcí je 230 sekund maximální doba, po kterou může funkce aktivovaná protokolem HTTP reagovat na požadavek. Tento limit existuje kvůli výchozí době nečinnosti Azure Load Balancer. V případě delší doby zpracování zvažte použití asynchronního vzoru Durable Functions nebo odložení skutečné práce a vrácení okamžité odpovědi.
2. Není vynucen žádný maximální časový limit pro spuštění. Období odkladu zadané pro provádění funkce je však během škálování pro plány Flex Consumption a Premium 60 minut a během aktualizací platformy se poskytuje období odkladu 10 minut.
3. Vyžaduje, aby plán služby App Service byl nastavený na AlwaysOn. Během aktualizací platformy se poskytuje období odkladu 10 minut.
4. Výchozí časový limit pro verzi 1.x modulu runtime hostitele Služby Functions je neomezený.
5. Pokud je minimální počet replik nastaven na nulu, výchozí časový limit závisí na konkrétních aktivačních událostech použitých v aplikaci.

Tyto hodnoty předpokládají, že se hostitelský proces Azure Functions správně spustí a běží. Je stanoven maximální časový limit 60 sekund pro spuštění jazykově specifického pracovního procesu. Časový limit spuštění pracovního procesu není momentálně konfigurovatelný.

Podpora jazyků

Podrobnosti o aktuální podpoře zásobníku nativních jazyků ve službě Functions najdete v tématu Supported languages in Azure Functions.

Škála

Následující tabulka porovnává chování škálování různých plánů hostování.
Maximální počet instancí se podává v aplikaci pro jednotlivé funkce (Consumption) nebo podle plánu (Premium/Dedicated), pokud není uvedeno jinak.

Plánování	Rozšíření kapacity	Maximální počet instancí #
Plán flexibilní spotřeby	Rychlá rozhodnutí o škálování řízená událostmi se počítají na základě jednotlivých funkcí, označovaných jako škálování jednotlivých funkcí, což poskytuje deterministický způsob škálování funkcí ve vaší aplikaci. Kromě protokolu HTTP, Blob Storage (Event Grid) a Durable Functions se všechny ostatní typy triggerů funkcí ve vaší aplikaci škálují na nezávislé instance. Všechny triggery HTTP ve vaší aplikaci se škálují společně jako skupina ve stejných instancích jako všechny triggery služby Blob Storage (Event Grid). Všechny triggery Durable Functions také sdílejí instance a škálují se společně.	10001
Plán Premium	Řízené událostmi. Automaticky rozšiřovat kapacitu, i během období vysokého zatížení. Azure Functions infrastruktura škáluje prostředky procesoru a paměti přidáním dalších instancí hostitele Functions na základě počtu událostí, na které se funkce aktivují.	Windows: 1006 Linux: 20-1002,6
Vyhrazený tarif	Ruční nebo automatické škálování	10-303 100 (ASE)
Container Apps	Řízené událostmi. Automaticky rozšiřovat kapacitu, i během období vysokého zatížení. Azure Functions infrastruktura škáluje prostředky procesoru a paměti přidáním dalších instancí hostitele Functions na základě počtu událostí, na které se funkce aktivují.	300-10004
Plán spotřeby	Řízené událostmi. Automatické škálování na základě zdroje událostí Infrastruktura functions škáluje prostředky přidáním dalších instancí hostitele funkce na základě počtu příchozích událostí triggeru.	Windows: 200 Linux: 1005

1. Plán Flex Consumption má kvótu místního předplatného, která omezuje celkové využití paměti všech instancí v dané oblasti. Další informace najdete v části Kvóty paměti regionálního předplatného. Plány Flex Consumption aktuálně podporují pouze Linux.
2. V některých oblastech se aplikace pro Linux v plánu Premium můžou škálovat na 100 instancí. Další informace najdete v článku o plánu Premium.
3. Konkrétní limity pro různé možnosti plánu služby App Service najdete v omezeních plánu služby App Service.
4. Ve službě Container Apps je výchozí 10 instancí, ale můžete nastavit maximální počet replik, které mají celkově maximálně 1 000. Toto nastavení se respektuje, pokud je k dispozici dostatek kvót jader. Další informace najdete v tématu Kvóty pro Azure Container Apps. Když vytvoříte aplikaci funkcí z portálu Azure, budete omezeni na 300 instancí.
5. Při škálování existuje v současné době limit 500 instancí na hodinu na jedno předplatné pro aplikace na Linuxu v plánu Consumption.
6. U HTTP triggerů s omezeným přístupem soukromého koncového bodu je škálování omezeno na maximálně 20 instancí.

Chování studeného startu

Plánování	Podrobnosti
Plán flexibilní spotřeby	Vylepšený studený start i při škálování na nulu. Podporuje vždy připravené instance pro další snížení zpoždění při zřizování nových instancí.
Plán Premium	Podporuje vždy připravené instance, abyste se vyhnuli studeným startům tím, že vám umožní udržovat jednu nebo více nepřetržitě teplých instancí.
Vyhrazený tarif	Pokud běží v režimu Dedicated, hostitel Functions může běžet nepřetržitě na předepsaném počtu instancí, což znamená, že problém studeného startu ve skutečnosti odpadá.
Container Apps	Závisí na minimálním počtu replik: • Při nastavení na nulu můžou aplikace při nečinnosti škálovat na nulu a některé požadavky můžou mít při spuštění vyšší latenci. • Pokud je nastaven na jednu či více hodnot, proces hostitele běží nepřetržitě, což znamená, že studený start nepředstavuje problém.
Plán spotřeby	Aplikace se můžou při nečinnosti škálovat na nulu, což znamená, že některé požadavky můžou mít při spuštění vyšší latenci. Plán Consumption má některé optimalizace, které pomáhají snížit čas studeného spuštění, včetně využívání předem připravených zástupných funkcí, kde už běží hostitelské a jazykové procesy.

Omezení služby

Prostředek	Plán flexibilní spotřeby	Plán Premium	Vyhrazený plán/ASE	Kontejnerové aplikace	Plán spotřeby
Výchozí časový limit (min)	30	30	301	3016	5
Maximální doba trvání časového limitu (min)	nevázaná9	nevázaná9	nevázané2	nevázaná17	10
Maximální počet odchozích připojení (na instanci)	neomezený	neomezený	zobrazení limitů služby App Service	neomezený	600 aktivních (celkem 1200)
Maximální velikost požadavku (MB)3	210	210	210	210	210
Maximální délkařetězce dotazu 3	4096	4096	4096	4096	4096
Maximální délka adresyURL požadavku 3	8192	8192	8192	8192	8192
ACU na instanci	210-840	100-840/210-25010	liší se	100	liší se
Maximální paměť (GB na instanci)	414	3.5-14	1.75-256/8-256	liší se	1.5
Maximální počet instancí (Windows | Linux)15	n/a | 1000	20-100	10–30 (100 ASE)11	300-100018	200 | 100
Aplikace funkcí na jeden plán13	1	100	nevázané4	nevázané4	100
Plány služby App Service	Není k dispozici	100 na skupinu prostředků	100 na skupinu prostředků	Není k dispozici	100 na oblast
Sloty nasazení na aplikaci12	Není k dispozici	3	1-2011	nepodporováno	2
Úložiště (dočasné)5	0,8 GB	21–140 GB	11–140 GB	Není k dispozici	0,5 GB
Úložiště (trvalé)	0 GB7	250 GB	10–1000 GB11	Není k dispozici	1 GB6,7
Vlastní domény pro aplikaci	258	500	500	nepodporováno	5008
Vlastní doména TSL/SSL podpora	Zahrnuté nevázané SSL SNI a jedno připojení SSL protokolu IP	Zahrnuté nevázané SSL SNI a jedno připojení SSL protokolu IP	Zahrnuté nevázané SSL SNI a jedno připojení SSL protokolu IP	nepodporováno	Zahrnuté nevázané připojení SSL SNI

Poznámky k limitům služeb:

1. Ve výchozím nastavení je časový limit modulu runtime Functions 1.x v plánu služby App Service nevázaný.
2. Vyžaduje, aby plán služby App Service byl nastavený na AlwaysOn. Platíte podle standardních sazeb. Během aktualizací platformy se poskytuje období odkladu 10 minut pro funkce aktivované protokolem HTTP, ale ne pro jiné triggery.
3. Tato omezení jsou nastavena v hostiteli.
4. Skutečný počet aplikací funkcí, které můžete hostovat, závisí na aktivitě aplikací, velikosti instancí počítačů a odpovídajícím využití prostředků.
5. Limit úložiště je celková velikost obsahu v dočasném úložišti napříč všemi aplikacemi ve stejném plánu služby App Service. V případě plánů Consumption v Linuxu je úložiště aktuálně 1,5 GB.
6. Plán Consumption využívá sdílenou složku Azure Files pro perzistentní úložiště. Když zadáte vlastní Azure Files sdílenou složku, konkrétní omezení velikosti sdílené složky závisí na účtu úložiště, který jste nastavili pro WEBSITE_CONTENTAZUREFILECONNECTIONSTRING.
7. V Linuxu musíte explicitně připojit vlastní sdílenou složku Azure Files.
8. Pokud je vaše aplikační funkce hostována v plánu Consumption, podporuje se pouze možnost CNAME. U aplikací funkcí v plánu Premium nebo plánu služby App Service můžete namapovat vlastní doménu pomocí CNAME nebo záznamu A.
9. Nevynucuje se žádná maximální doba časového omezení provádění. Období odkladu poskytnuté spuštěním funkce je však 60 minut během škálování a 10 minut během aktualizací platformy.
10. Pracovní role jsou hostiteli zákaznických aplikací. Pracovníci jsou k dispozici ve třech pevných velikostech: jeden vCPU/3,5 GB RAM; dva vCPU/7 GB RAM; čtyři vCPU/14 GB RAM.
11. Podrobnosti najdete v omezeních služby App Service.
12. Včetně produkčního slotu.
13. V daném předplatném je v současné době limit 5 000 funkčních aplikací.
14. Velikosti instancí plánů Flex Consumption jsou aktuálně definované jako 512 MB, 2 048 MB nebo 4 096 MB. Další informace naleznete v tématu Paměť instance.
15. Podrobnosti najdete v tématu Škálování v článku o porovnání hostování.
16. Pokud je minimální počet replik nastaven na nulu, výchozí časový limit závisí na konkrétních aktivačních událostech použitých v aplikaci.
17. Pokud je minimální počet replik nastaven na jeden nebo více.

Síťové funkce

Funkce	Plán flexibilní spotřeby	Plán spotřeby	Plán Premium	Vyhrazený plán/ASE	Container Apps1
Omezení příchozího přístupu	✅	✅	✅	✅	✅ 2
Koncové body (privátní, příchozí)	✅	❌	✅	✅	❌
Koncové body služby (příchozí)	✅	❌	✅	✅	✅
Integrace virtuální sítě (odchozí)	✅	❌	✅	✅ 3	✅
Hybridní připojení	❌	❌	✅ (jenom Windows)	✅ (jenom Windows)	✅ (jenom Windows)

1. Další informace najdete v tématu Síťování v prostředí Azure Container Apps.
2. Spravuje se prostřednictvím konfigurace příchozího přenosu dat prostředí Container Apps.
3. Plán Dedicated/ASE také podporuje integraci virtuální sítě vyžadované bránou.

Fakturace

Plánování	Podrobnosti
Plán flexibilní spotřeby	Fakturace vychází z počtu spuštění, paměti instancí při aktivním spouštění funkcí a nákladů na všechny instance, které jsou vždy připravené. Další informace najdete v tématu Fakturace plánu Flex Consumption.
Plán Premium	Plán Premium je založený na počtu sekund jádra a paměti využité napříč potřebnými a předem zahřátými instancemi. Nejméně jedna instance na plán musí být vždy v teple. Tento plán poskytuje nej předvídatelnější ceny.
Vyhrazený tarif	Platíte totéž za aplikace funkcí v plánu služby App Service jako u jiných prostředků služby App Service, jako jsou webové aplikace. U služby ASE existuje paušální měsíční sazba, která platí za infrastrukturu a nemění se s velikostí prostředí. Existují také náklady na virtuální procesor plánu služby App Service. Všechny aplikace hostované v ASE jsou v izolovaném cenovém modelu. Další informace najdete v článku s přehledem služby ASE.
Container Apps	Fakturace v Azure Container Apps je založená na typu vašeho plánu. Další informace najdete v tématu Billing in Azure Container Apps.
Plán spotřeby	Platíte jenom za čas, kdy vaše funkce běží. Fakturace vychází z počtu spuštění, doby spuštění a použité paměti.

Přímé porovnání nákladů mezi dynamickými plány hostování (Consumption, Flex Consumption a Premium) najdete na stránce s cenami Azure Functions. Ceny různých možností vyhrazeného plánu najdete na stránce s cenami služby App Service. Informace o cenách hostování Container Apps najdete v tématu Azure Container Apps ceny.

Omezení pro vytváření nových aplikací funkcí v existující skupině prostředků

V některých případech se při pokusu o vytvoření nového plánu hostování vaší aplikace funkcí ve stávající skupině prostředků může zobrazit jedna z následujících chyb:

• Cenová úroveň není v této skupině prostředků povolená.
• <Pracovníci >SKU_name nejsou dostupní ve skupině prostředků <resource_group_name>

K těmto chybám může dojít při splnění následujících podmínek:

• Aplikaci funkcí vytvoříte ve stávající skupině prostředků, která ještě obsahuje jinou aplikaci funkcí nebo webovou aplikaci. Například spotřební aplikace pro Linux nejsou podporovány ve stejné skupině prostředků jako dedikované nebo prémiové plány pro Linux.
• Nová aplikace funkcí se vytvoří ve stejné oblasti jako předchozí aplikace.
• Předchozí aplikace je nějakým způsobem nekompatibilní s novou aplikací. K této nekompatibilitě může dojít mezi verzemi, operačními systémy nebo je způsobená jinými funkcemi na úrovni platformy, jako je podpora zóny dostupnosti.

Funkční aplikace a plány webových aplikací jsou při vytvoření mapovány na různé fondy prostředků. Různé plány vyžadují jinou sadu funkcí infrastruktury. Když vytvoříte aplikaci ve skupině prostředků, tato skupina prostředků se namapuje a přiřadí ke konkrétnímu fondu prostředků. Pokud se pokusíte v této skupině prostředků vytvořit jiný plán a mapovaný fond nemá požadované prostředky, dojde k dříve uvedeným chybám.

Pokud k této situaci dojde, vytvořte aplikaci funkcí a plán hostování v nové skupině prostředků.

Další kroky

• Technologie nasazení v Azure Functions
• Azure Functions příručka pro vývojáře