Opciones de hospedaje de Azure Functions

Artigo
05/21/2024

Cuando crea una aplicación de funciones en Azure, debe elegir una opción de hospedaje para su aplicación. Azure proporciona estas opciones de hospedaje para el código de función:

Opción de hospedaje	Service	Disponibilidad	Compatibilidad con los contenedores
Plan de consumo	Funciones de Azure	Disponible con carácter general	None
Plan de consumo flexible	Funciones de Azure	Vista previa	None
Plan Premium	Funciones de Azure	GA	Linux
Plan dedicado	Funciones de Azure	GA	Linux
Aplicaciones de contenedor	Azure Container Apps	GA	Linux

La infraestructura de Azure App Service facilita las opciones de hospedaje de Azure Functions en máquinas virtuales Linux y Windows. La opción de hospedaje que elija dicta 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.
Compatibilidad con contenedores de Linux.

El plan que elija también afecta a los costos de ejecutar el código de función. Para obtener más información, vea Facturación.

En este artículo se proporciona una comparación detallada entre las distintas opciones de hospedaje. Para más información sobre cómo ejecutar y administrar el código de función en contenedores de Linux, consulte Compatibilidad con contenedores de Linux en Azure Functions.

Información general sobre los planes

A continuación se muestra un resumen de las ventajas de las distintas opciones para el hospedaje de Azure Functions:

Opción	Ventajas
Plan de consumo	Pague por los recursos de proceso solo cuando las funciones se ejecutan (pago por uso) con escala automática. 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 que proporciona un hospedaje sin servidor verdadero. ✔ Pague solo cuando se ejecutan las funciones. ✔ Escala de forma automática, incluso durante períodos de carga elevada.
Plan de consumo flexible	Obtenga una alta escalabilidad con opciones de proceso, redes virtuales y facturación de pago por uso. En el plan de consumo flexible, las instancias del host de Functions se agregan y quitan dinámicamente en función de la simultaneidad configurada por instancia y el número de eventos entrantes. ✔ Reduzca los inicios en frío especificando una serie de instancias aprovisionadas previamente (siempre listas). ✔ Admite redes virtuales para mayor seguridad. ✔ Pague 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. ✔ Desea tener más control sobre las instancias y desea implementar varias aplicaciones de función en el mismo plan con escalado controlado por eventos. ✔ 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 proporcionan los planes de consumo. ✔ Su código debe ejecutarse durante más tiempo del máximo permitido en el plan de consumo. ✔ Necesita conectividad de 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 existentes e infrautilizadas que ya ejecutan otras instancias de App Service. ✔ Debe tener una facturación totalmente predecible o debe escalar manualmente las instancias. ✔ Quiere ejecutar varias aplicaciones web y aplicaciones de funciones en el mismo plan ✔ Necesita acceso a opciones de tamaño de proceso más grandes. ✔ Aislamiento de proceso completo y acceso seguro a la red proporcionado por una instancia de App Service Environment (ASE). ✔ Uso de memoria muy alto y gran escala (ASE).
Aplicaciones de contenedor	Cree e implemente aplicaciones de funciones en contenedor en un entorno totalmente administrado hospedado por Azure Container Apps. Use el modelo de programación de Azure Functions para crear aplicaciones de funciones nativas en la nube controladas por eventos, sin servidor. Ejecute las funciones junto con otros microservicios, API, sitios web y flujos de trabajo como programas hospedados en contenedores. Considere la posibilidad de hospedar las funciones en Container Apps en las situaciones siguientes: ✔ Quiere empaquetar bibliotecas personalizadas con el código de función para admitir aplicaciones de línea de negocio. ✔ Debe migrar la ejecución de código desde aplicaciones locales o heredadas a microservicios nativos en la nube que se ejecutan en contenedores. ✔ Si desea evitar la sobrecarga y la complejidad de administrar clústeres de Kubernetes y proceso dedicado. ✔ Las funciones necesitan potencia de procesamiento de gama alta proporcionada por recursos de proceso de GPU dedicados.

Las tablas restantes de este artículo comparan las opciones de hospedaje en función de varias características y comportamientos.

Compatibilidad con sistema operativo

En esta tabla se muestra la compatibilidad del sistema operativo con las opciones de hospedaje.

Hospedar aplicaciones de WPF	Implementación de Linux¹	Implementación de Windows²
Plan de consumo	✅ Solo código ❌ Contenedor (no compatible)	✅ Solo código
Plan de consumo flexible	✅ Solo código ❌ Contenedor (no compatible)	❌ No se admite
Plan Premium	✅ Solo código ✅ Contenedor	✅ Solo código
Plan dedicado	✅ Solo código ✅ Contenedor	✅ Solo código
Aplicaciones de contenedor	✅ Solo contenedor	❌ No se admite

¹ Linux es el único sistema operativo compatible con la pila del runtime de Python.
² Las implementaciones de Windows son de solo código. Functions no admite actualmente contenedores de Windows.

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 ¹
Plan de consumo	5	10
Plan de consumo flexible	30	Ilimitados³
Plan Premium	30²	Ilimitados³
Plan dedicado	30²	Ilimitados³

¹ 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.
² El tiempo de espera predeterminado para la versión 1.x del runtime de Functions es ilimitado.
³ Garantizado para un máximo de 60 minutos. El sistema operativo y aplicación de revisiones en el entorno de ejecución, la aplicación de revisiones a vulnerabilidades y el escalado de comportamientos todavía pueden cancelar las ejecuciones de funciones, por lo que asegúrese de escribir funciones sólidas. ⁴ En un plan de consumo flexible, el host no aplica un límite de tiempo de ejecución. Sin embargo, actualmente no hay ninguna garantía porque es posible que la plataforma tenga que finalizar las instancias durante el escalado horizontal, las implementaciones o aplicar actualizaciones.

Compatibilidad con idiomas

Para más información sobre la compatibilidad actual de la pila de lenguaje nativo en Functions, consulte Lenguajes admitidos en Azure Functions.

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. Escala horizontalmente de forma automática, incluso durante períodos de gran carga. La infraestructura de 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: 100¹
Plan de consumo flexible	Escalado por función. Las decisiones de escalado controladas por eventos se calculan por función, lo que proporciona una forma más determinista de escalar las funciones en la aplicación. A excepción de HTTP, Blob Storage (Event Grid) y Durable Functions, todos los demás tipos de desencadenadores de función de la aplicación se escalan en instancias independientes. Todos los desencadenadores HTTP de la aplicación se escalan conjuntamente como un grupo en las mismas instancias, como todos los desencadenadores de Blob Storage (Event Grid). Todos los desencadenadores de Durable Functions también comparten instancias y escalan juntas.	Limitado solo por el uso total de memoria de todas las instancias de una región determinada. Para obtener más información, consulte Memoria de instancia.
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 más instancias del host de Functions, según el número de eventos desencadenados por las funciones.	Windows: 100 Linux: 20-100²
Plan dedicado³	Escalabilidad automática o manual	10-30 100 (ASE)

¹ 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.
² 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.
³ 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 se pueden escalar a cero cuando están inactivas, lo que significa que algunas solicitudes pueden tener más latencia al iniciarse. 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 de consumo flexible	Admite instancias siempre preparadas para reducir el retraso al aprovisionar nuevas instancias.
Plan Premium	Admite instancias siempre preparadas para evitar los inicios en frío, ya que permite mantener una o varias instancias perpetuamente activas.
Plan dedicado	Cuando se ejecuta en un plan dedicado, el host de Functions se puede ejecutar continuamente en un número prescrito de instancias, lo que significa que el inicio en frío no es realmente un problema.

Límites de servicio

Recurso	Plan de consumo	Plan de consumo flexible¹²	Plan Premium	Plan dedicado/ASE
Duración de tiempo de espera predeterminada (min)	5	30	30	30¹
Duración máxima de tiempo de espera (min)	10	sin enlazar¹⁵	sin enlazar⁷	sin enlazar²
Número máximo de conexiones salientes (por instancia)	600 activas (1200 en total)	sin enlazar	sin enlazar	sin enlazar
Tamaño máximo de la solicitud (MB)³	100	100	100	100
Longitud máxima de la cadena de consulta³	4096	4096	4096	4096
Longitud máxima de URL de solicitud³	8192	8192	8192	8192
ACU por instancia	100	varía	210-840	100-840/210-250⁸
Memoria máxima (GB por instancia)	1.5	4¹³	3,5-14	1.75-14/3.5-14
Recuento de instancias máximo (Windows/Linux)	200/100	1000 ¹⁴	100/20	varía según la SKU/100⁹
Aplicaciones de funciones por plan¹¹	100	100	100	sin enlazar⁴
Planes de App Service	100 por región	N/D	100 por grupo de recursos	100 por grupo de recursos
Ranuras de implementación por aplicación¹⁰	2	N/D	3	1-20⁹
Almacenamiento⁵	5 GB	250 GB	250 GB	50-1000 GB
Dominios personalizados por aplicación	500⁶	500	500	500
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

Notas sobre los límites del servicio:

De manera predeterminada, el tiempo de expiración del runtime de Functions 1.x en un plan de App Service no está enlazado.
Requiere que el plan de App Service se establezca en Always On. Abonar según las tarifas estándar.
Estos límites se establecen en el host.
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.
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.
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.
Garantizado para un máximo de 60 minutos.
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.
Consulte los Límites de App Service para obtener más información.
Incluido el espacio de producción.
Actualmente hay un límite de 5000 aplicaciones de funciones en una suscripción determinada.
El Plan Flex Consumption está actualmente en versión preliminar.
Los tamaños de instancia del plan de consumo flexible se definen actualmente como 2048 MB o 4096 MB. Para obtener más información, consulte Memoria de instancia.
El plan de consumo flexible durante la versión preliminar tiene una cuota de suscripción regional que limita el uso total de memoria de todas las instancias de una región determinada. Para obtener más información, consulte Memoria de instancia.
En un plan de consumo flexible, el host no aplica un límite de tiempo de ejecución. Sin embargo, actualmente no hay ninguna garantía porque es posible que la plataforma tenga que finalizar las instancias durante el escalado horizontal, las implementaciones o aplicar actualizaciones.

Características de red

Característica	Plan de consumo	Plan de Consumo flexible	Plan Premium	Plan dedicado/ASE
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)	✅Sí (regional y puerta de enlace)
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 de consumo flexible	La facturación se basa en el número de ejecuciones, la memoria de las instancias cuando se ejecutan activamente las funciones, además del costo de cualquier instancia siempre preparada. Para obtener más información, consulte Facturación del plan Flex Consumption.
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. Para un ASE, hay una tarifa mensual plana que paga por la infraestructura y no cambia con el tamaño del entorno. 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. Para obtener más información, consulte el artículo de información general de ASE.

Para obtener una comparación directa de costos entre planes de hospedaje dinámicos (Consumo, Consumo flexible y Premium), consulte la página de precios de Azure Functions. Para obtener los precios de las diversas opciones del plan dedicado, vea la página Precios de App Service. Para obtener los precios del hospedaje de Container Apps, consulte Precios de Azure Container Apps.

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. Por ejemplo, las aplicaciones de consumo de Linux no se admiten en el mismo grupo de recursos que los planes Dedicados de Linux o Linux Premium.
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. Este error 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.

Compartir por