Opciones de hospedaje de Azure Functions

Artículo
02/02/2025

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 flexible	Funciones de Azure	Disponible con carácter general	Ninguno
Plan Premium	Funciones de Azure	GA	Linux
Plan dedicado	Funciones de Azure	GA	Linux
Aplicaciones de contenedor	Azure Container Apps	GA	Linux
Plan de consumo	Funciones de Azure	GA	Ninguno

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 flexible	Obtenga un escalado horizontal rápido 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 o varias 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.
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.

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 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
Plan de consumo	✅ Solo código ❌ Contenedor (no compatible)	✅ Solo código

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 la aplicación de funciones

La duración del tiempo de espera de las funciones de una aplicación de funciones se define mediante la propiedad functionTimeout en el archivo de proyecto de 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 del tiempo de espera. Para evitar tiempos de espera, es importante escribir funciones sólidas. 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 flexible	30	Sin enlazar²
Plan Premium	30⁴	Sin enlazar²
Plan dedicado	30⁴	Sin enlazar³
Aplicaciones de contenedor	30	Sin enlazar⁵
Plan de consumo	5	10

Independientemente de la configuración de tiempo de espera de la aplicación de funciones, 230 segundos es la cantidad máxima de tiempo que una función desencadenada por HTTP puede tardar en responder a una solicitud. Esto se debe a que 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.
No se aplica la duración máxima del tiempo de espera de ejecución. Sin embargo, el período de gracia proporcionado a una ejecución de una función es de 60 minutos durante la reducción horizontal para los planes Flex Consumption y Premium, y se da un período de gracia de 10 minutos durante las actualizaciones de la plataforma.
Requiere que el plan de App Service se establezca en Always On. Se da un período de gracia de 10 minutos durante las actualizaciones de la plataforma.
El tiempo de espera predeterminado para la versión 1.x del entorno de ejecución del host de Functions se sin enlazar.
Cuando el número mínimo de réplicas se establece en cero, el tiempo de espera predeterminado depende de los desencadenadores específicos usados en la aplicación.

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 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.	1000⁵
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)
Aplicaciones de contenedor	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.	300-1000⁴
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¹

En el escalado horizontal hay un límite en la actualidad de 500 instancias por suscripción y hora para aplicaciones Linux en un plan de consumo.
En algunas regiones, las aplicaciones de Linux de un plan Premium se 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 del plan de App Service, consulte los límites del plan de App Service.
En Container Apps, el valor predeterminado es 10 instancias, pero puede establecer el número máximo de réplicas en 1000. Esta configuración se respeta siempre que haya suficiente cuota de núcleos disponible. Si crea la aplicación de funciones en Azure Portal, tendrá un límite de 300 instancias.
Las instancias totales de una región determinada están limitadas eficazmente por cuotas de memoria de suscripción regional.

Comportamiento del arranque en frío

Planear	Detalles
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.
Aplicaciones de contenedor	Depende del número mínimo de réplicas: • Cuando se establece en cero: las aplicaciones se pueden escalar a cero cuando están inactivas y algunas solicitudes pueden tener más latencias en el inicio. • Cuando se establece en uno o más: el proceso de host se ejecuta continuamente, lo que significa que el arranque en frío no es un problema.
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 y procesos de lenguaje.

Límites de servicio

Resource	Plan de Consumo flexible	Plan Premium	Plan dedicado/ASE	Aplicaciones de contenedor	Plan de consumo
Duración de tiempo de espera predeterminada (min)	30	30	30¹	30¹⁶	5
Máxduración del tiempo de espera (min)	sin enlazar⁹	sin enlazar⁹	sin enlazar²	¹⁷sin enlazar	10
Número máximo de conexiones salientes (por instancia)	sin enlazar	sin enlazar	sin enlazar	sin enlazar	600 activas (1200 en total)
Tamaño máximo de la solicitud (MB)³	210	210	210	210	210
Longitud máxima de la cadena de consulta³	4096	4096	4096	4096	4096
Longitud máxima de URL de solicitud³	8192	8192	8192	8192	8192
ACU por instancia	210-840	100-840/210-250¹⁰	varía	100	varía
Memoria máxima (GB por instancia)	4¹⁴	3,5-14	1.75-256/8-256	varía	1.5
Número máximo de instancias (Windows \| Linux)	n/a \| 1000¹⁵	varía según S KU \| 100¹¹	10-300¹⁸	200 \| 100	1 000
Aplicaciones de funciones por plan¹³	1	100	sin enlazar⁴	sin enlazar⁴	100
Planes de App Service	N/D	100 por grupo de recursos	100 por grupo de recursos	N/D	100 por región
Ranuras de implementación por aplicación¹²	N/D	3	1-20¹¹	no admitido	2
Almacenamiento (temporal)⁵	0.8 GB	21-140 GB	11-140 GB	N/D	0,5 GB
Almacenamiento (persistente)	0 GB⁷	250 GB	10-1000 GB¹¹	N/D	1 GB^6,7
Dominios personalizados por aplicación	500	500	500	no admitido	500⁷
Compatibilidad con TSL/SSLdominio personalizado	SSL de SNI sin enlazar y una conexión SSL de IP incluida	SSL de SNI sin enlazar y una conexión SSL de IP incluida	SSL de SNI sin enlazar y una conexión SSL de IP incluida	no admitido	conexión SNI SSL sin enlazar incluida

Notas sobre los límites del servicio:

De manera predeterminada, el tiempo de espera para el entorno de ejecución 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. Se da un período de gracia de 10 minutos durante las actualizaciones de la plataforma.
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. En el caso de los planes de Consumo en Linux, el almacenamiento es actualmente de 1,5 GB.
El plan de Consumo usa un recurso compartido de Azure Files para el almacenamiento persistente. Al proporcionar su propio recurso compartido de Azure Files, los límites de tamaño de recurso compartido específicos dependen de la cuenta de almacenamiento que establezca para WEBSITE_CONTENTAZUREFILECONNECTIONSTRING.
En Linux, debe montar explícitamente su propio recurso compartido de Azure Files.
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.
No se aplica ningún tiempo de espera de ejecución máximo. Sin embargo, el período de gracia proporcionado a una ejecución de función es de 60 minutos durante la reducción horizontal y de 10 minutos durante las actualizaciones de la plataforma.
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.
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 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.
Cuando el número mínimo de réplicas se establece en cero, el tiempo de espera predeterminado depende de los desencadenadores específicos usados en la aplicación.
Cuando el número mínimo de réplicas se establece en uno o varios.
En Container Apps, puede establecer el número máximo de réplicas, que se respeta siempre que haya suficiente cuota de núcleos disponibles.

Características de red

Característica	Plan de consumo flexible	Plan de consumo	Plan Premium	Plan dedicado/ASE	Container Apps¹
Restricciones de IP de entrada	✔	✔	✔	✔	✔
Puntos de conexión privados entrantes	✔		✔	✔
Integración de redes virtuales	✔		✔²	✔³	✔
Restricciones de IP de salida	✔		✔	✔	✔

Para más información, consulte Redes en el entorno de Azure Container Apps.
Hay consideraciones especiales al trabajar con desencadenadores de red virtual.
Solo el plan Dedicado/ASE admite la integración de red virtual necesaria para la puerta de enlace.

Facturación

Planear	Detalles
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.
Aplicaciones de contenedor	La facturación en Azure Container Apps se basa en el tipo de plan. Para más información, consulte Facturación en Azure Container Apps.
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.

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:

No se permite el plan de tarifa en este grupo de recursos
Los trabajadores 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 intenta crear otro plan en ese grupo de recursos y el grupo asignado 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 a través de