Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Ao criar um aplicativo de funções no Azure, você deve escolher uma opção de hospedagem para o aplicativo. O Azure oferece estas opções de hospedagem para seu código de função:
| Opção de hospedagem | Serviço | Disponibilidade | Suporte a contêiner |
|---|---|---|---|
| Plano de Consumo Flexível | Azure Functions | GA (em disponibilidade geral) | Nenhum |
| Plano Premium | Azure Functions | GA | Linux |
| Plano dedicado | Azure Functions | GA | Linux |
| Aplicativos de Contêiner | Aplicativos de Contêiner do Azure | GA | Linux |
| Plano de consumo | Azure Functions | Windows – GA Linux – Aposentado |
Nenhum |
Importante
Após 30 de setembro de 2028, a opção de hospedar seu aplicativo de funções no Linux em um plano de consumo será desativada. Para evitar interrupções, migre seus aplicativos de plano de consumo existentes que são executados no Linux para o plano de consumo flex antes dessa data. Os aplicativos em execução no Windows em um plano de consumo não são afetados por essa alteração. Para obter mais informações, consulte o aviso de desativação do plano de consumo do Linux.
As opções de hospedagem do Azure Functions são facilitadas pela infraestrutura do Serviço de Aplicativo do Azure em máquinas virtuais do Linux e do Windows. A opção de hospedagem escolhida determina os seguintes comportamentos:
- Como o aplicativo de funções é dimensionado.
- Os recursos disponíveis para cada instância do aplicativo de funções.
- Suporte para funcionalidades avançadas, como conectividade à Rede Virtual do Azure.
- Suporte para contêineres do Linux.
O plano escolhido também afeta os custos para executar seu código de função. Para mais informações, consulte Faturamento.
Este artigo mostra uma comparação detalhada entre as várias opções de hospedagem. Para saber mais sobre como executar e gerenciar seu código de função em contêineres do Linux, confira Suporte a contêineres do Linux no Azure Functions.
Visão geral dos planos
Veja a seguir um resumo dos benefícios das várias opções de hospedagem do Azure Functions:
| Opção | Benefícios |
|---|---|
| Plano de Consumo Flexível | Experimente o dimensionamento horizontal rápido, com opções de computação flexíveis, integração de rede virtual e cobrança paga conforme o uso sem servidor. No plano de Consumo Flex, as instâncias de função são escalonadas dinamicamente (até 1.000) com base na simultaneidade configurada por instância, eventos de entrada e cargas de trabalho por função para obter a eficiência ideal. Considere o plano de Consumo Flex quando: ✔ Você precisa de um host sem servidor para seu código de função, pagando apenas por execuções sob demanda. ✔ Você precisa de conectividade de rede virtual para acesso seguro aos recursos do Azure. ✔ As suas cargas de trabalho são variáveis e podem passar da inatividade para o dimensionamento rápido e baseado em eventos. ✔ Você deseja personalizar a computação com tamanhos de memória (512 MB, 2.048 GB ou 4.096 GB) e reduzir as inicializações a frio por meio de uma ou mais instâncias pré-provisionadas (sempre prontas). |
| Plano Premium | Escala automaticamente com base na demanda usando trabalhos pré-ativados, que executam aplicativos sem atraso após ficarem ociosos, são executados em instâncias mais potentes e se conectam a redes virtuais. Considere o plano Azure Functions Premium nas seguintes situações: ✔ Os aplicativos de funções executam continuamente ou quase continuamente. ✔ Você deseja ter mais controle sobre suas instâncias e implantar vários aplicativos de funções no mesmo plano com escala orientada por eventos. ✔ Você tem um número alto de execuções pequenas e uma fatura de execução alta, mas com poucos GB por segundo no plano de Consumo. ✔ Você precisa de mais opções de CPU ou memória do que são fornecidas pelos planos de consumo. ✔ O código precisa executar por mais tempo do que o tempo de execução máximo permitido no plano de Consumo. ✔ Você precisa de conectividade de rede virtual para acesso seguro aos recursos do Azure. ✔ Você quer fornecer uma imagem do Linux personalizada na qual suas funções serão executadas. |
| Plano dedicado | Execute suas funções em um plano do Serviço de Aplicativo com taxas regulares do Plano do Serviço de Aplicativo. Melhor para cenários de execução longa em que o Durable Functions não pode ser usado. Considere um Plano do Serviço de Aplicativo nas seguintes situações: ✔ Você tem máquinas virtuais existentes e subutilizadas que já estão executando outras instâncias do Serviço de Aplicativo. ✔ Você precisa ter uma cobrança totalmente previsível ou escalonar manualmente as instâncias. ✔ Você quer executar vários aplicativos Web e aplicativos de funções no mesmo plano ✔ Você precisa de acesso a opções maiores de tamanho da computação. ✔ Isolamento de computação completo e acesso seguro à rede fornecidos por um ASE (Ambiente do Serviço de Aplicativo). ✔ Muito uso de memória e alta escala (ASE). |
| Aplicativos de Contêiner | Crie e implante aplicativos de funções em contêineres em um ambiente totalmente gerenciado hospedado pelos Aplicativos de Contêiner do Azure. Use o modelo de programação do Azure Functions para criar aplicativos de funções nativos da nuvem, sem servidor e controlados por eventos de build. Execute suas funções junto com outros microsserviços, APIs, sites e fluxos de trabalho como programas hospedados em contêiner. Considere a possibilidade de hospedar suas funções em Aplicativos de Contêiner nas seguintes situações: ✔ Você deseja controlar a imagem de contêiner e deseja empacotar bibliotecas personalizadas com seu código de função para dar suporte a aplicativos de linha de negócios. ✔ Você precisa migrar a execução de código de aplicativos locais ou legados para microsserviços nativos da nuvem executados em contêineres. ✔ Quando quiser evitar a sobrecarga e a complexidade do gerenciamento de clusters do Kubernetes e da computação dedicada. ✔ Suas funções precisam de potência de processamento de última geração fornecida por recursos de computação de GPU dedicados. |
| Plano de consumo | Pague por recursos de computação somente quando suas funções estiverem em execução (paga conforme o uso) com escala automática no Windows. No plano Consumo, as instâncias de função são adicionadas e removidas dinamicamente com base no número de eventos recebidos. Considere o plano de consumo quando: ✔ Você tem uma dependência do Windows, por exemplo, usando o runtime v1, o .NET Framework completo ou recursos específicos do Windows, como determinados módulos do PowerShell ✔ Você deseja um modelo de cobrança sem servidor e pagar somente quando suas funções estiverem em execução. |
As tabelas restantes deste artigo comparam as opções de hospedagem com base em vários recursos e comportamentos.
Suporte do sistema operacional
Esta tabela mostra o suporte do sistema operacional para as opções de hospedagem.
| Hosting | Implantação do Linux1 | Implantação do Windows2 |
|---|---|---|
| Plano de Consumo Flexível |
✅ Somente código ❌ Contêiner (sem suporte) |
❌ Sem suporte |
| Plano Premium |
✅ Somente código ✅ Contêiner |
✅ Somente código |
| Plano dedicado |
✅ Somente código ✅ Contêiner |
✅ Somente código |
| Aplicativos de Contêiner | ✅ Somente contêiner | ❌ Sem suporte |
| Plano de consumo3 |
✅ Somente código (Desativado) ❌ Contêiner (sem suporte) |
✅ Somente código |
- O Linux é o único sistema operacional compatível com a pilha de runtime do Python.
- As implantações do Windows são de somente código. No momento, o Functions não dá suporte a contêineres do Windows.
- A capacidade de executar seu aplicativo no Linux em um plano de consumo está prevista para ser desativada em 30 de setembro de 2028. Para obter mais informações, consulte o plano de consumo.
Duração do tempo limite do aplicativo de funções
A duração do tempo limite das funções em um aplicativo de funções é definida pela propriedade functionTimeout no arquivo de projeto host.json. Essa propriedade se aplica especificamente a execuções de função. Depois que o gatilho inicia a execução da função, a função precisa retornar/responder durante a duração do tempo limite. Para evitar tempos limite, é importante escrever funções robustas. Para saber mais, confira Melhorar o desempenho e a confiabilidade do Azure Functions.
A seguinte tabela mostra os valores padrão e máximo (em minutos) para planos específicos:
| Plano | Padrão | Máximo1 |
|---|---|---|
| Plano de Consumo Flexível | 30 | Não associado2 |
| Plano Premium | 304 | Não associado2 |
| Plano dedicado | 304 | Não associado3 |
| Aplicativos de Contêiner | 30 | Desassociado5 |
| Plano de consumo | 5 | 10 |
- Independentemente da configuração do tempo limite do aplicativo de funções, 230 segundos é a quantidade máxima de tempo que uma função disparada por HTTP pode levar para responder a uma solicitação. Isso ocorre devido ao tempo limite ocioso padrão do Azure Load Balancer. Para tempos de processamento mais longos, considere usar o padrão assíncrono das Durable Functions ou adiar o trabalho real e retornar uma resposta imediata.
- Não há uma duração máxima de tempo limite de execução imposta. No entanto, o período de cortesia dado a uma execução de função é de 60 minutos durante a redução horizontal para os planos Flex Consumo e Premium, e um período de cortesia de 10 minutos é dado durante as atualizações da plataforma.
- Exige que o plano do Serviço de Aplicativo seja definido como Always On. Um período de cortesia de 10 minutos é dado durante as atualizações da plataforma.
- O tempo limite padrão da versão 1.x do runtime do host do Functions é não associado.
- Quando o número mínimo de réplicas for definido como zero, o tempo limite padrão dependerá dos gatilhos específicos usados no aplicativo.
Os valores nesta tabela pressupõem que o processo de host do Azure Functions foi iniciado e está sendo executado corretamente. Há um tempo limite máximo de 60 segundos permitido para que o processo de trabalho específico do idioma também seja iniciado. O tempo limite de inicialização do processo de trabalho não é configurável no momento.
Suporte ao idioma
Para obter detalhes sobre o suporte à atual pilha de linguagens nativas do Functions, confira Linguagens com suporte no Azure Functions.
Escala
A tabela a seguir compara os comportamentos de dimensionamento dos vários planos de hospedagem.
As instâncias máximas são fornecidas por aplicativo por função (Consumo) ou por plano (Premium/Dedicado), a menos que indicado de outra forma.
| Plano | Escalar horizontalmente | Número máximo de instâncias |
|---|---|---|
| Plano de Consumo Flexível | As decisões de dimensionamento rápidas orientadas a eventos são calculadas por função, chamadas de dimensionamento por função, o que fornece uma maneira mais determinística de dimensionar as funções em seu aplicativo. Com exceção do HTTP, do Armazenamento de Blobs (Grade de Eventos) e do Durable Functions, todos os outros tipos de gatilho de função no aplicativo são escalados em instâncias independentes. Todos os gatilhos HTTP no aplicativo são escalados juntos como um grupo nas mesmas instâncias, assim como todos os gatilhos do Armazenamento de Blobs (Grade de Eventos). Todos os gatilhos do Durable Functions também compartilham instâncias e são escalados juntos. | 10001 |
| Plano Premium | Controlado por evento. Escale horizontalmente de forma automática, mesmo durante períodos de carga alta. A infraestrutura do Azure Functions dimensiona recursos de CPU e memória adicionando mais instâncias do host do Functions, com base no número de eventos nos quais suas funções são disparadas. |
Windows: 1006 Linux: 20-1002,6 |
| Plano dedicado | Dimensionamento manual/automático | 10-303 100 (ASE) |
| Aplicativos de Contêiner | Controlado por evento. Escale horizontalmente de forma automática, mesmo durante períodos de carga alta. A infraestrutura do Azure Functions dimensiona recursos de CPU e memória adicionando mais instâncias do host do Functions, com base no número de eventos nos quais suas funções são disparadas. | 300-10004 |
| Plano de consumo | Controlado por evento. Escala automática com base na origem dos eventos. A infraestrutura do Functions dimensiona os recursos adicionando mais instâncias do host de função, com base no número de eventos de gatilho de entrada. |
Windows: 200 Linux: 1005 |
- O plano de Consumo Flexível tem uma cota de assinatura regional que limita o uso total de memória de todas as instâncias em uma determinada região. Para obter mais informações, consulte cotas de memória de assinatura regionais. Atualmente, os planos de consumo flex dão suporte apenas ao Linux.
- Em algumas regiões, os aplicativos Linux em um plano Premium podem ser escalados para 100 instâncias. Para mais informações, confira o artigo do plano Premium.
- Para obter limites específicos para as várias opções de plano do Serviço de Aplicativo, confira os limites do plano do Serviço de Aplicativo.
- Em Aplicativos de Contêiner, o padrão é 10 instâncias, mas você pode definir o número máximo de réplicas, que tem um máximo geral de 1000. Essa configuração é respeitada desde que haja cota de núcleos suficiente disponível. Para obter mais informações, consulte Cotas para os Aplicativos de Contêiner do Azure. Ao criar seu aplicativo de funções no portal do Azure, você está limitado a 300 instâncias.
- Durante a expansão, atualmente há um limite de 500 instâncias por assinatura por hora para aplicativos Linux em um plano de Consumo.
- Para gatilhos http restritos do ponto de extremidade privado, o dimensionamento é limitado a no máximo 20 instâncias.
Comportamento de inicialização a frio
| Plano | Detalhes |
|---|---|
| Plano de Consumo Flexível | Início frio aprimorado mesmo quando dimensionado para zero. Dá suporte a instâncias sempre prontas para reduzir ainda mais o atraso ao provisionar novas instâncias. |
| Plano Premium | Dá suporte a instâncias sempre prontas para evitar inicializações a frio, permitindo que você mantenha uma ou mais instâncias permanentemente ativas. |
| Plano dedicado | Quando executado em um plano Dedicado, o host do Functions pode ser executado continuamente em um número prescrito de instâncias, o que significa que a inicialização a frio não é realmente um problema. |
| Aplicativos de Contêiner | Depende do número mínimo de réplicas: • Quando definido como zero: os aplicativos podem ser escalados para zero quando ociosos e algumas solicitações podem ter mais latência na inicialização. • Quando definido como um ou mais: o processo de host é executado continuamente, o que significa que o início frio não é um problema. |
| Plano de consumo | Os aplicativos podem ser escalados para zero quando ociosos, o que significa que algumas solicitações podem ter mais latências na inicialização. O plano de consumo tem algumas otimizações para ajudar a diminuir o tempo de inicialização a frio, incluindo a extração de funções de espaço reservado pré-ativadas que já têm o host e os processos de linguagem em execução. |
Limites de serviço
| Recurso | Plano de Consumo Flexível | Plano Premium | Plano Dedicado/ASE | Aplicativos de Contêiner | Plano de Consumo |
|---|---|---|---|---|---|
| Duração de tempo limite padrão (min) | 30 | 30 | 301 | 3016 | 5 |
| Duração do tempo limite máximo (min.) | não associado9 | não associado9 | não associado2 | não associado17 | 10 |
| Máximo de conexões de saída (por instância) | não associado | não associado | não associado | não associado | 600 ativos (1.200 no total) |
| Tamanho máximo da solicitação (MB)3 | 210 | 210 | 210 | 210 | 210 |
| Comprimento máximo da cadeia de caracteres de consulta3 | 4096 | 4096 | 4096 | 4096 | 4096 |
| Comprimento máximo da URL de solicitação3 | 8192 | 8192 | 8192 | 8192 | 8192 |
| ACU por instância | 210-840 | 100-840/210-25010 | varia | 100 | varia |
| Memória máxima (GB por instância) | 414 | 3,5-14 | 1.75-256/8-256 | varia | 1.5 |
| Contagem máxima de instâncias (Windows | Linux)15 | n/a | 1000 | 20-100 | 10-30 (100 ASE)11 | 300-100018 | 200 | 100 |
| Aplicativos de função por plano13 | 1 | 100 | não associado4 | não associado4 | 100 |
| Planos do Serviço de Aplicativo | n/d | 100 por grupo de recursos | 100 por grupo de recursos | n/d | 100 por região |
| Slots de implantação por aplicativo12 | n/d | 3 | 1-2011 | sem suporte | 2 |
| Armazenamento (temporário)5 | 0,8 GB | 21 a 140 GB | 11 a 140 GB | n/d | 0,5 GB |
| Armazenamento (persistente) | 0 GB7 | 250 GB | 10-1000 GB11 | n/d | 1 GB6,7 |
| Domínios personalizados por aplicativo | 258 | 500 | 500 | sem suporte | 5008 |
| Suporte a TSL/SSL de domínio personalizado | SSL SNI não associado e uma conexão IP SSL incluída | SSL SNI não associado e uma conexão IP SSL incluída | SSL SNI não associado e uma conexão IP SSL incluída | sem suporte | conexão SSL SNI não associada incluída |
Observações sobre os limites do serviço:
- Por padrão, o tempo limite do runtime do Functions 1.x em um plano do Serviço de Aplicativo é desassociado.
- Exige que o plano do Serviço de Aplicativo seja definido como Always On. Pagamento com taxas padrão. Um período de cortesia de 10 minutos é dado durante as atualizações da plataforma.
- Esses limites são definidos no host.
- O número real de aplicativos de funções que você pode hospedar depende da atividade dos aplicativos, do tamanho das instâncias do computador e da utilização de recursos correspondente.
- O limite de armazenamento é o tamanho total do conteúdo no armazenamento temporário em todos os aplicativos no mesmo plano do Serviço de Aplicativo. Para planos de consumo no Linux, o armazenamento atual é de 1,5 GB.
- O plano de consumo usa um compartilhamento dos Arquivos do Azure para armazenamento persistente. Ao fornecer o próprio compartilhamento dos Arquivos do Azure, os limites de tamanho do compartilhamento específicos dependem da conta de armazenamento definida para WEBSITE_CONTENTAZUREFILECONNECTIONSTRING.
- No Linux, você deve montar explicitamente seu próprio compartilhamento de Arquivos do Azure.
- Quando seu aplicativo de funções estiver hospedado em um Plano de consumo, somente a opção CNAME será compatível. Para obter aplicativos de funções em um plano Premium ou plano do Serviço de Aplicativo, você poderá mapear um domínio personalizado usando um CNAME ou registro A.
- Não há duração máxima de tempo limite de execução imposta. No entanto, o período de cortesia dado a uma execução de função é de 60 minutos durante a redução horizontal e de 10 minutos durante as atualizações de plataforma.
- As funções de trabalho são funções que hospedam aplicativos cliente. As funções de trabalho estão disponíveis em três tamanhos fixos: uma vCPU/3.5 GB de RAM; Duas vCPU/7 GB de RAM; Quatro vCPU/14 GB de RAM.
- Confira Limites do Serviço de Aplicativo para saber detalhes.
- Incluindo o slot de produção.
- Atualmente, há um limite de 5.000 aplicativos de funções em uma determinada assinatura.
- Atualmente, os tamanhos da instância do plano de consumo flex são definidos como 512 MB, 2.048 MB ou 4.096 MB. Para obter mais informações, confira Memória da instância.
- Para obter detalhes, consulte Escala no artigo de comparação de hospedagem.
- Quando o número mínimo de réplicas for definido como zero, o tempo limite padrão dependerá dos gatilhos específicos usados no aplicativo.
- Quando o número mínimo de réplicas for definido como um ou mais.
Recursos de rede
- Para obter mais informações, consulteRede no ambiente de Aplicativos de Contêiner do Azure.
- Há considerações especiais ao trabalhar com gatilhos de rede virtual.
- Somente o plano Dedicado/ASE dá suporte à integração de rede virtual necessária para o gateway.
Cobrança
| Plano | Detalhes |
|---|---|
| Plano de Consumo Flexível | A cobrança é baseada no número de execuções, na memória das instâncias quando elas estão executando funções ativamente, além do custo das instâncias sempre prontas. Para obter mais informações, confira Cobrança do plano de Consumo Flexível. |
| Plano Premium | O plano Premium é baseado no número de núcleos por segundo e na memória usada nas instâncias necessárias e pré-ativadas. Pelo menos uma instância por plano deve ser mantida aquecida em todos os momentos. Esse plano fornece o preço mais previsível. |
| Plano dedicado | Você paga o mesmo por aplicativos de funções em um plano do Serviço de Aplicativo que pagaria por outros recursos do Serviço de Aplicativo, como aplicativos Web. Existe uma taxa mensal fixa para um ASE que paga pela infraestrutura e não se altera com o tamanho do ambiente. Também há um custo por vCPU do plano do Serviço de Aplicativo. Todos os aplicativos hospedados no ASE estão em um SKU de preços Isolado. Para saber mais, confira o artigo de visão geral do ASE. |
| Aplicativos de Contêiner | A cobrança nos Aplicativos de Contêiner do Azure baseia-se no tipo de plano. Para saber mais, confira Cobrança em Aplicativos de Contêiner do Azure. |
| Plano de consumo | Você paga apenas pelo tempo durante o qual suas funções são executadas. A cobrança baseia-se no número de execuções, no tempo de execução e na memória usada. |
Para uma comparação de custo entre planos de hospedagem dinâmicos (Consumo, Consumo Flexível e Premium), confira a página de preços do Azure Functions. Para ver os preços das várias opções de plano Dedicado, confira a página de preços do Serviço de Aplicativo. Para ver os preços de hospedagem dos Aplicativos de Contêiner, confira Preços dos Aplicativos de Contêiner do Azure.
Limitações para criar aplicativos de funções em um grupo de recursos existente
Em alguns casos, ao tentar criar um plano de hospedagem para o aplicativo de funções em um grupo de recursos existente, você pode receber um dos seguintes erros:
- O tipo de preço não é permitido neste grupo de recursos
- <SKU_name> os trabalhadores não estão disponíveis no grupo de recursos <resource_group_name>
Isso pode acontecer quando as seguintes condições são atendidas:
- Você cria um aplicativo de funções em um grupo de recursos existente que já contém outro aplicativo de funções ou aplicativo Web. Por exemplo, não há suporte para os aplicativos de Consumo em Linux no mesmo grupo de recursos dos planos Dedicado em Linux ou Premium em Linux.
- O novo aplicativo de funções é criado na mesma região que o aplicativo anterior.
- O aplicativo anterior é incompatível com o novo aplicativo em algum aspecto. Esse erro pode ocorrer entre SKUs, sistemas operacionais ou devido a outros recursos de nível da plataforma, como o suporte à zona de disponibilidade.
O motivo disso é a forma como os planos de aplicativos Web e de aplicativos de funções são mapeados para diferentes pools de recursos ao serem criados. SKUs diferentes exigem um conjunto diferente de funcionalidades de infraestrutura. Quando você cria um aplicativo em um grupo de recursos, esse grupo de recursos é mapeado e atribuído a um pool de recursos específico. Se você criar outro plano nesse grupo de recursos e o pool mapeado não tiver os recursos necessários, esse erro ocorrerá.
Quando esse erro ocorrer, crie o aplicativo de funções e o plano de hospedagem em um novo grupo de recursos.