Opciones de hospedaje de Azure Functions

Cuando crea una aplicación de funciones en Azure, debe elegir un plan de hospedaje para su aplicación. Hay tres planes de hospedaje básico disponibles para Azure Functions: Plan de consumo, plan Premium y plan Dedicado (App Service). Todos los planes de hospedaje tienen disponibilidad general (GA) en máquinas virtuales Linux y Windows.

El plan de hospedaje que elija determina los comportamientos siguientes:

  • Cómo se escala la aplicación de funciones.
  • Los recursos disponibles para cada instancia de aplicación de funciones.
  • Compatibilidad con funcionalidad avanzada, como la conectividad con Azure Virtual Network.

En este artículo se proporciona una comparación detallada entre los distintos planes de hospedaje, además del hospedaje basado en Kubernetes.

Nota

Si decide hospedar las funciones en un clúster de Kubernetes, considere la posibilidad de usar un clúster de Kubernetes habilitado para Azure Arc. El hospedaje en un clúster de Kubernetes habilitado para Azure Arc está actualmente en versión preliminar. Para más información, consulte App Service, Functions y Logic Apps en Azure Arc.

Información general sobre los planes

A continuación se ofrece un resumen de las ventajas de los tres principales planes de hospedaje de Functions:

Planear Ventajas
Plan de consumo Escale de forma automática y pague los recursos de proceso solo cuando se ejecuten las funciones.

En el plan de consumo, las instancias del host de Functions se agregan y quitan de forma dinámica según el número de eventos de entrada.

✔ Plan de hospedaje predeterminado.
✔ Pague solo cuando se ejecutan las funciones.
✔ Escala de forma automática, incluso durante períodos de carga elevada.
Plan Premium Escala automáticamente en función de la demanda mediante trabajos preparados previamente que ejecutan aplicaciones sin ningún retraso después de estar inactivas, ejecuta en instancias más eficaces y se conecta a redes virtuales.

Considere la posibilidad de elegir el plan Premium de Azure Functions en las siguientes situaciones:

✔ La aplicación de funciones se ejecuta de forma continua, o casi continua.
✔ Tiene un gran número de ejecuciones pequeñas y una factura de ejecución elevada, pero pocos GB por segundo en el plan de consumo.
✔ Necesita más opciones de CPU o memoria de las que proporciona el plan de consumo.
✔ Su código debe ejecutarse durante más tiempo del máximo permitido en el plan de consumo.
✔ Necesita características que no están disponibles en el plan de consumo, como la conectividad con red virtual.
✔ Quiere proporcionar una imagen personalizada de Linux en la que ejecutar sus funciones.
Plan dedicado Ejecute las funciones en un plan de App Service a los Precios de App Service normales.

Mejor para escenarios de ejecución prolongada en los que no se puede usar Durable Functions. Considere el plan de App Service en las situaciones siguientes:

✔ Tiene máquinas virtuales infrautilizadas que ya ejecutan otras instancias de App Service.
✔ Se requieren escalado y costos predictivos.

En las tablas de comparación de este artículo también se incluyen las siguientes opciones de hospedaje, que proporcionan el mayor control y aislamiento posibles en los que ejecutar las aplicaciones de funciones.

Opción de hospedaje Detalles
ASE App Service Environment (ASE) es una característica de App Service que proporciona un entorno completamente aislado y dedicado para ejecutar de forma segura las aplicaciones de App Service a gran escala.

Las instancias de ASE son adecuadas para cargas de trabajo de aplicaciones que necesitan:

✔ Una gran escala.
✔ Aislamiento de proceso completo y acceso a redes seguro.
✔ Elevado uso de memoria.
Kubernetes
(Directo o
Azure Arc)
Kubernetes proporciona un entorno completamente aislado y dedicado que se ejecuta sobre la plataforma de Kubernetes.

Kubernetes resulta adecuado para cargas de trabajo de aplicaciones que necesitan:
✔ Requisitos de hardware personalizados.
✔ Aislamiento y acceso a redes seguro.
✔ Capacidad de ejecutarse en entornos híbridos o de varias nubes.
✔ Ejecutarse junto con aplicaciones y servicios de Kubernetes existentes.

En las tablas restantes de este artículo se comparan los planes con respecto a diversas características y comportamientos. Para obtener una comparación de costos entre los planes de hospedaje dinámicos (consumo y Premium), vea la página Precios de Azure Functions. Para obtener los precios de las diversas opciones del plan dedicado, vea la página Precios de App Service.

Sistema operativo o entorno de ejecución

En la tabla siguiente se muestran los sistemas operativos y la compatibilidad de lenguaje con los planes de hospedaje.

Linux1, 2
Solo código
Solo código de Windows Linux1,2,3
Contenedor de Docker
Plan de consumo C#
JavaScript
Java
Python
PowerShell Core
TypeScript
C#
JavaScript
Java
PowerShell Core
TypeScript
No se admite
Plan Premium C#
JavaScript
Java
Python
PowerShell Core
TypeScript
C#
JavaScript
Java
PowerShell Core
TypeScript
C#
JavaScript
Java
PowerShell Core
Python
TypeScript
Plan dedicado C#
JavaScript
Java
Python
TypeScript
C#
JavaScript
Java
PowerShell Core
TypeScript
C#
JavaScript
Java
PowerShell Core
Python
TypeScript
ASE C#
JavaScript
Java
Python
TypeScript
C#
JavaScript
Java
PowerShell Core
TypeScript
C#
JavaScript
Java
PowerShell Core
Python
TypeScript
Kubernetes (directo) N/D N/D C#
JavaScript
Java
PowerShell Core
Python
TypeScript
Azure Arc (versión preliminar) C#
JavaScript
Java
Python
TypeScript
N/D C#
JavaScript
Java
PowerShell Core
Python
TypeScript

1 Linux es el único sistema operativo compatible con la pila del runtime de Python.
2 La compatibilidad con PowerShell en Linux se encuentra actualmente en versión preliminar.
3 Linux es el único sistema operativo compatible con los contenedores de Docker.

Duración del tiempo de espera de una aplicación de función

La duración del tiempo de espera de las funciones en una aplicación de funciones se define mediante la propiedad functionTimeout en el archivo de proyecto host.json. Esta propiedad se aplica específicamente a las ejecuciones de funciones. Una vez que el desencadenador inicia la ejecución de la función, la función debe devolver o responder dentro de la duración del tiempo de espera. Para más información, consulte Mejorar el rendimiento y la confiabilidad de Azure Functions.

En la tabla siguiente se muestran los valores predeterminados y máximos (en minutos) para planes específicos:

Plan Valor predeterminado Máximo 1
Plan de consumo 5 10
Plan Premium 302 Sin límite
Plan dedicado 302 Sin límite

1 Independientemente de la configuración del tiempo de espera de la aplicación de función, 230 segundos es la cantidad de tiempo máxima que una función desencadenada por HTTP puede tardar en responder a una solicitud. Esto se debe al tiempo de espera de inactividad predeterminado de Azure Load Balancer. Para tiempos de procesamiento más largos, considere la posibilidad de usar el patrón asincrónico de Durable Functions o aplazar el trabajo real y devolver una respuesta inmediata.
2 El tiempo de espera predeterminado para la versión 1.x del runtime de Functions es ilimitado.

Escala

En la siguiente tabla se comparan los comportamientos de escalado de los distintos planes de hospedaje.
El número máximo de instancias se da en función de una aplicación por función (consumo) o por plan (Premium/Dedicado), a menos que se indique lo contrario.

Planear Escalado horizontal N.º máximo de instancias
Plan de consumo Controlado por eventos. Escale horizontalmente de forma automática, incluso durante períodos de gran carga. La infraestructura de Azure Functions escala los recursos de CPU y memoria mediante la incorporación de instancias adicionales del host de Functions, según el número de eventos de desencadenador entrantes. Windows: 200
Linux: 1001
Plan Premium Controlado por eventos. Escale horizontalmente de forma automática, incluso durante períodos de gran carga. La infraestructura de Azure Functions escala automáticamente los recursos de CPU y la memoria mediante la incorporación de instancias del host de Functions, según el número de eventos desencadenados por las funciones. Windows: 100
Linux: 20-1002
Plan dedicado3 Escalabilidad automática o manual 10-20
ASE3 Escalabilidad automática o manual 100
Kubernetes Escalado automático basado en eventos para los clústeres de Kubernetes mediante KEDA. Varía en función del clúster

1 Durante el escalado horizontal, actualmente hay un límite de 500 instancias por suscripción y hora para aplicaciones Linux en un plan de consumo.
2 En algunas regiones, las aplicaciones Linux de un plan Premium pueden escalar a 100 instancias. Para obtener más información, consulte el artículo Plan Premium.
3 Para conocer los límites específicos de las distintas opciones de plan de App Service, consulte Límites del plan de App Service.

Comportamiento del arranque en frío

Planear Detalles
Plan de consumo Las aplicaciones pueden escalar a cero si están inactivas, lo que significa que algunas solicitudes pueden tener una latencia adicional durante el arranque. El plan de consumo incluye algunas optimizaciones para reducir el tiempo de arranque en frío, incluida la extracción desde funciones de marcador de posición previamente preparadas que ya tienen en ejecución un host de función y procesos de lenguaje.
Plan Premium Instancias permanentemente preparadas para evitar cualquier arranque en frío.
Plan dedicado Cuando se ejecuta en un plan dedicado, el host de Functions se puede ejecutar de forma continua, lo que significa que el arranque en frío no es realmente un problema.
ASE Cuando se ejecuta en un plan dedicado, el host de Functions se puede ejecutar de forma continua, lo que significa que el arranque en frío no es realmente un problema.
Kubernetes En función de la configuración de KEDA, las aplicaciones se pueden configurar para evitar un arranque en frío. Si están configuradas para escalar a cero, se produce un arranque en frío de los nuevos eventos.

Límites de servicio

Recurso Plan de consumo Plan Premium Plan dedicado Azure App Service Environment Kubernetes
Duración de tiempo de espera predeterminada (min) 5 30 301 30 30
Duración máxima de tiempo de espera (min) 10 sin enlazar7 sin enlazar2 sin enlazar sin enlazar
Número máximo de conexiones salientes (por instancia) 600 activas (1200 en total) sin enlazar sin enlazar sin enlazar sin enlazar
Tamaño máximo de la solicitud (MB)3 100 100 100 100 Depende del clúster
Longitud máxima de la cadena de consulta3 4096 4096 4096 4096 Depende del clúster
Longitud máxima de URL de solicitud3 8192 8192 8192 8192 Depende del clúster
ACU por instancia 100 210-840 100-840 210-2508 Precios de AKS
Memoria máxima (GB por instancia) 1.5 3,5-14 1,75-14 3,5-14 Se admite cualquier nodo
Recuento de instancias máximo (Windows/Linux) 200/100 100/20 varía según la SKU9 1009 Depende del clúster
Aplicaciones de funciones por plan 100 100 sin enlazar4 sin enlazar sin enlazar
Planes de App Service 100 por región 100 por grupo de recursos 100 por grupo de recursos - -
Ranuras de implementación por aplicación10 2 3 1-209 20 N/D
Almacenamiento5 5 TB 250 GB 50-1000 GB 1 TB N/D
Dominios personalizados por aplicación 5006 500 500 500 N/D
Compatibilidad con dominio Compatibilidad con SSL conexión SNI SSL sin enlazar incluida conexiones SNI SSL ilimitadas y 1 conexión SSL de IP incluidas conexiones SNI SSL ilimitadas y 1 conexión SSL de IP incluidas conexiones SNI SSL ilimitadas y 1 conexión SSL de IP incluidas N/D

1 De manera predeterminada, el tiempo de expiración del runtime de Functions 1.x en un plan de App Service no está enlazado.
2 Requiere que el plan de App Service se establezca en Always On. Abonar según las tarifas estándar.
3 Estos límites se establecen en el host.
4 El número real de aplicaciones de funciones que puede hospedar depende de la actividad de las aplicaciones, el tamaño de las instancias de máquina y la utilización de recursos correspondiente.
5 El límite de almacenamiento es el tamaño total del almacenamiento temporal entre todas las aplicaciones en el mismo plan de App Service. El plan de consumo usa Azure Files para el almacenamiento temporal.
6 Cuando la aplicación de funciones se hospeda en un plan de consumo, solo se admite solo la opción CNAME. Para aplicaciones de funciones se hospedan en un plan Premium o en un plan de App Service, puede asignar un dominio personalizado mediante un CNAME o un registro A.
7 Garantizado para un máximo de 60 minutos.
8 Los trabajos son roles que hospedan las aplicaciones del cliente. Los trabajos están disponibles en tres tamaños fijos: Una CPU virtual/3,5 GB RAM; dos CPU virtuales/7 GB RAM; cuatro CPU virtuales/14 GB RAM.
9 Consulte los Límites de App Service para obtener más información.
10 Incluido el espacio de producción.

Limitaciones para crear nuevas aplicaciones de funciones en un grupo de recursos existente

En algunos casos, al intentar crear un nuevo plan de hospedaje para la aplicación de funciones en un grupo de recursos existente, puede recibir uno de los siguientes errores:

  • El plan de tarifa no está permitido en este grupo de recursos
  • Los trabajos de <SKU_name> no están disponibles en el grupo de recursos <resource_group_name>

Esto puede ocurrir cuando se dan las siguientes condiciones:

  • Cree una aplicación de funciones en un grupo de recursos existente que haya incluido alguna vez otra aplicación de funciones o aplicación web.
  • La nueva aplicación de funciones se crea en la misma región que la aplicación anterior.
  • La aplicación anterior es de alguna manera incompatible con la nueva aplicación. Esto puede ocurrir entre SKU, sistemas operativos o debido a otras características de nivel de plataforma, como la compatibilidad de zonas de disponibilidad.

El motivo por el que sucede esto se debe a cómo se asignan las aplicaciones de funciones y los planes de aplicación web a diferentes grupos de recursos cuando se crean. Las diferentes SKU requieren un conjunto diferente de funcionalidades de infraestructura. Al crear una aplicación en un grupo de recursos, este se asigna a un conjunto de recursos específico. Si crea otro plan en ese grupo de recursos y el grupo asociado no tiene los recursos necesarios, se produce este error.

Cuando se produce este error, cree la aplicación de funciones y el plan de hospedaje en un nuevo grupo de recursos.

Características de red

Característica Plan de consumo Plan Premium Plan dedicado Azure App Service Environment
Restricciones de IP de entrada ✅Sí ✅Sí ✅Sí ✅Sí
Puntos de conexión privados entrantes ❌No ✅Sí ✅Sí ✅Sí
Integración de redes virtuales ❌No ✅Sí (regional) ✅Sí (regional y puerta de enlace) ✅Sí
Desencadenadores de red virtual (no HTTP) ❌No ✅Sí ✅Sí ✅Sí
Conexiones híbridas (solo Windows) ❌No ✅Sí ✅Sí ✅Sí
Restricciones de IP de salida ❌No ✅Sí ✅Sí ✅Sí

Facturación

Planear Detalles
Plan de consumo Solo paga por el tiempo durante el que se ejecutan las funciones. La facturación se basa en el número de ejecuciones, el tiempo de ejecución y el uso de la memoria.
Plan Premium El plan Premium se basa en la cantidad de núcleos por segundo y en la memoria usada en las instancias necesarias y preparadas previamente. Al menos una instancia por plan se debe mantener preparada en todo momento. Este plan ofrece los precios más predecibles.
Plan dedicado Paga lo mismo por las aplicaciones de funciones en un plan de App Service que por otros recursos de App Service, como las aplicaciones web.
App Service Environment (ASE) Hay una tarifa plana mensual para las instancias de ASE en la que se paga por la infraestructura y que no varía según el tamaño de la instancia de ASE. Además, existe un costo por cada vCPU del plan de App Service. Todas las aplicaciones hospedadas en una instancia de ASE están en el SKU de precios Aislado.
Kubernetes Solo paga los costos del clúster de Kubernetes; no existe facturación adicional para Functions. La aplicación de funciones se ejecuta como una carga de trabajo de aplicación en el clúster, al igual que una aplicación normal.

Pasos siguientes