Confiabilidad en Azure App Service

2025-06-22

En este artículo se describe el soporte de confiabilidad en Azure App Service, que abarca la resiliencia dentro de la región mediante zonas de disponibilidad y implementaciones multi-región.

La confiabilidad es una responsabilidad compartida entre usted y Microsoft. Puede usar esta guía para determinar qué opciones de confiabilidad cumplen sus objetivos empresariales específicos y objetivos de tiempo de actividad.

App Service es un servicio basado en HTTP para hospedar aplicaciones web, API REST y back-ends móviles. App Service se integra con Microsoft Azure para proporcionar seguridad, equilibrio de carga, escalado automático y administración automatizada para aplicaciones. Para explorar cómo App Service puede reforzar la confiabilidad y la resistencia de la carga de trabajo de la aplicación, consulte Introducción a App Service.

Al implementar App Service, puede aprovisionar varias instancias en un plan de App Service. Este plan representa los trabajos de proceso que ejecutan el código de la aplicación. La plataforma realiza un esfuerzo para implementar las instancias en distintos dominios de error, pero no distribuye automáticamente las instancias entre zonas de disponibilidad.

Recomendaciones de implementación de producción

Utiliza planes premium de "App Service" v3/v4.
Habilitación de la redundancia de zona. Para obtener información sobre los requisitos de redundancia de zona y cómo habilitarla, consulte la sección Compatibilidad con la zona de disponibilidad.

Habilite la redundancia de zona, lo que requiere que el plan de App Service use un mínimo de dos instancias.

Errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones controlen errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Los SDK proporcionados por Microsoft suelen controlar errores transitorios. Dado que hospeda sus propias aplicaciones en App Service, considere cómo evitar la causa de errores transitorios:

Implemente varias instancias en el plan. App Service realiza actualizaciones automatizadas y otras formas de mantenimiento en instancias del plan. Si una instancia se vuelve incorrecta, el servicio puede reemplazar automáticamente esa instancia por una nueva instancia correcta. Durante el proceso de reemplazo, puede haber un breve período cuando la instancia anterior no está disponible y una nueva instancia no está lista para atender el tráfico. Puede mitigar estos efectos mediante la implementación de varias instancias del plan de App Service.
Uso de ranuras de implementación. Las ranuras de implementación de App Service permiten implementaciones sin tiempo de inactividad de las aplicaciones. Use ranuras de implementación para minimizar el efecto de las implementaciones y los cambios de configuración para los usuarios. Las ranuras de implementación también reducen la probabilidad de que se reinicie la aplicación. Reiniciar la aplicación produce un error transitorio.
Evite escalar o reducir verticalmente. El escalado hacia arriba y hacia abajo requiere implementar cambios en la CPU, la memoria y otros recursos que se asignan a cada instancia. Las operaciones de ampliación y reducción pueden desencadenar un reinicio de la aplicación. En lugar de escalar hacia arriba o hacia abajo, seleccione un nivel y un tamaño de instancia que cumplan con sus requisitos de rendimiento bajo carga típica. Puede escalar horizontalmente y reducir horizontalmente agregando y quitando instancias dinámicamente para controlar los cambios en el volumen de tráfico.

Compatibilidad con zonas de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de cada región de Azure. Cuando se produce un error en una zona, los servicios pueden conmutar por error a una de las zonas restantes.

App Service se puede configurar como con redundancia de zona, lo que significa que los recursos se distribuyen entre varias zonas de disponibilidad. La distribución entre varias zonas ayuda a las cargas de trabajo de producción a lograr resistencia y confiabilidad. Al configurar la redundancia de zona en los planes de App Service, todas las aplicaciones que usan el plan se convierten en redundantes de zona.

La distribución de instancias en una implementación con redundancia de zona sigue reglas específicas. Estas reglas siguen siendo aplicables a medida que la aplicación escala hacia adentro y hacia afuera. Para obtener más información, consulte Consideraciones.

Soporte para regiones

Los planes de App Service con redundancia de zona se pueden implementar en cualquier región que admita zonas de disponibilidad.

Para ver qué regiones admiten zonas de disponibilidad para App Service Environment v3, consulte Regiones.

Requisitos

Debe usar los tipos de plan Premium v2-4. Para ver más información, asegúrese de seleccionar el nivel adecuado en la parte superior de esta página.

Debe usar los tipos de plan Premium v2-4 o Aislado v2 y tener un mínimo de dos instancias del plan.
Las zonas de disponibilidad solo se admiten en las unidades de escalado más recientes de App Service. Incluso si usa una de las regiones admitidas, si no se admiten zonas de disponibilidad para la unidad de escalado que usa, recibirá un error al crear un plan de App Service con redundancia de zona.

La unidad de escalado a la que está asignado se basa en el grupo de recursos en el que se implementa un plan de App Service. Para asegurarse de que las cargas de trabajo se encuentran en una unidad de escalado que admita zonas de disponibilidad, es posible que tenga que crear un nuevo grupo de recursos y crear un nuevo plan de App Service y una aplicación de App Service dentro del nuevo grupo de recursos.

Para ver si el plan de App Service está en una marca que admite zonas de disponibilidad, compruebe la maximumNumberOfZones propiedad del plan de App Service. Si el valor es mayor que uno, la marca admite zonas y puede habilitar la redundancia de zona en el plan. Si el valor es igual a uno, la unidad de escalado no admite zonas de disponibilidad y debe implementar un nuevo plan para habilitar la redundancia de zona.
```
az appservice plan show -n <app-service-plan-name> -g <resource-group-name> --query properties.maximumNumberOfZones
```
Debe implementar un mínimo de dos instancias en el plan.

Consideraciones

Durante una interrupción de zona de disponibilidad, es posible que algunos aspectos de Azure App Service se vean afectados, aunque la aplicación siga atendiendo el tráfico. Estos comportamientos incluyen el escalado del plan de App Service, la creación de aplicaciones, la configuración de la aplicación y la publicación de aplicaciones.

Al habilitar la redundancia de zona en el plan de App Service, también mejorará la resistencia a las actualizaciones que implementa la plataforma de App Service. Para más información, consulte Confiabilidad durante el mantenimiento del servicio.

La distribución de instancias en una implementación con redundancia de zona sigue reglas específicas. Estas reglas siguen siendo aplicables a medida que la aplicación se escala y reduce horizontalmente:

Instancias mínimas: El plan de App Service debe tener un mínimo de dos instancias para la redundancia de zona.
Zonas de disponibilidad máxima compatibles con el plan: Azure determina el número de zonas de disponibilidad que puede usar el plan. Para ver el número de zonas de disponibilidad que el plan puede usar, consulte la propiedad maximumNumberOfZones en el plan de App Service. Se trata de una propiedad de solo lectura. Si este valor es igual a 1, el plan de App Service no admite la redundancia de zona. Si el valor máximoNumberOfZones es mayor que 1, el plan de App Service se puede configurar para la redundancia de zona.
```
az appservice plan show -n <app-service-plan-name> -g <resource-group-name> --query properties.maximumNumberOfZones
```
Distribución de instancias: Cuando se habilita la redundancia de zona, las instancias de plan se distribuyen automáticamente entre varias zonas de disponibilidad. La distribución se basa en las reglas siguientes:
- Las instancias se distribuyen uniformemente si especifica una capacidad (número de instancias) mayor que maximumNumberOfZones y el número de instancias es divisible por maximumNumberOfZones.
- Las instancias restantes se distribuyen entre las zonas restantes.
- Cuando la plataforma de App Service asigna instancias para un plan de App Service con redundancia de zona, usa el equilibrio de zona de mejor esfuerzo que proporcionan los conjuntos de escalado de máquinas virtuales de Azure subyacentes. Un plan de App Service se equilibra si cada zona tiene el mismo número de máquinas virtuales o difiere en más una máquina virtual o menos una máquina virtual de todas las demás zonas. Para obtener más información, consulte Equilibrio de zona.
Ubicación de zona física: Puede ver la zona de disponibilidad física que se usa para cada una de las instancias del plan de App Service. Use la API REST, que devuelve el physicalZone valor de cada instancia.
```
az rest --method get --url https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/sites/{appName}/instances?api-version=2024-04-01
```

En el caso de los planes de App Service que no están configurados como redundantes de zona, las instancias de máquina virtual subyacentes no son resistentes a los errores de zona de disponibilidad. Pueden experimentar tiempo de inactividad durante una interrupción en cualquier zona de esa región.

Coste

Cuando se usan planes de App Service Premium v2-v4, no hay ningún costo adicional asociado a la habilitación de zonas de disponibilidad siempre que tenga dos o más instancias en el plan de App Service. Se le cobrará en función de la SKU del plan de App Service, la capacidad que especifique y las instancias a las que escale según los criterios de escalado automático.

Si habilita zonas de disponibilidad pero especifica una capacidad de menos de dos, la plataforma aplica un recuento mínimo de instancias de dos. La plataforma le cobra por esas dos instancias.

Al usar el plan aislado de App Service v2, no hay ningún costo adicional asociado a la habilitación de zonas de disponibilidad siempre que tenga dos o más instancias en el plan de App Service. Se le cobrará en función de la SKU del plan de App Service, la capacidad que especifique y las instancias a las que escale según los criterios de escalado automático.

Si habilita zonas de disponibilidad pero especifica una capacidad de menos de dos, la plataforma aplica un recuento mínimo de instancias de dos. La plataforma le cobra por esas dos instancias.

Configuración de la compatibilidad con zonas de disponibilidad

Para implementar un nuevo plan de App Service con redundancia de zona, debe usar los tipos de plan Premium v2-4. Para ver más información, asegúrese de seleccionar el nivel adecuado en la parte superior de esta página.

Cree un nuevo plan de App Service con redundancia de zona. Para implementar un nuevo plan de App Service con redundancia de zona, seleccione la opción Redundancia de zona al implementar el plan en Azure Portal o establezca la propiedad zoneRedundant del plan de App Service en true en el comando de la CLI de Azure, el comando de Azure PowerShell, el archivo Bicep o la plantilla de Azure Resource Manager:
- Azure CLI
- Bíceps
```
az appservice plan create -g MyResourceGroup -n MyPlan --zone-redundant --number-of-workers 2 --sku P1V3
```
Nota

Si usa la CLI de Azure para modificar la zone-redundant propiedad , debe especificar la --number-of-workers propiedad , que es el número de instancias y usar una capacidad mayor o igual que 2.
```
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
    name: appServicePlanName
    location: location
    sku: {
        name: sku
        capacity: 2
    }
    kind: 'linux'
    properties: {
        reserved: true
        zoneRedundant: true
    }
}
```
Migre un plan de App Service existente a la redundancia de zona. Si tiene un plan de App Service existente que admite redundancia de zona (la cantidad máxima de zonas disponibles es mayor que 1), puede habilitar la redundancia de zona estableciendo la propiedad zoneRedundant del plan de servicio de aplicaciones en la CLI de Azure, el archivo de Bicep o la plantilla de Resource Manager.
```
az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=true sku.capacity=2
```
Nota

Si usa la CLI de Azure para modificar la zoneRedundant propiedad , debe especificar la sku.capacity propiedad , que es el número de instancias y usar una capacidad mayor o igual que 2.

Si está en un plan o en una marca que no admite zonas de disponibilidad, debe crear un nuevo plan de App Service en un nuevo grupo de recursos para que se coloque en la superficie de App Service que admita zonas.

Nota

Cambiar el estado de redundancia de zona de un plan de App Service es casi instantáneo. No experimenta problemas de tiempo de inactividad ni rendimiento durante el proceso.
Desactivar la redundancia de zona. Para deshabilitar la redundancia de zona, establezca la propiedad plan zoneRedundant de App Service en false o use la CLI de Azure:
```
az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=false sku.capacity=1
```
Nota

Si usa la CLI de Azure para deshabilitar la zoneRedundant propiedad , debe especificar la sku.capacity propiedad ; de lo contrario, el valor predeterminado es 1.

Cree un nuevo plan de App Service con redundancia de zona.
1. Si no tiene una instancia de App Service Environment con redundancia de zona existente, implemente una nueva instancia de App Service Environment con redundancia de zona. Para más información sobre cómo crear una instancia de App Service Environment, consulte Creación de un entorno de App Service.
2. Para crear el plan de App Service en Azure Portal, seleccione Redundancia de zona. Para crear el plan mediante el comando de la CLI de Azure, el comando de Azure PowerShell, el archivo Bicep o la plantilla de Resource Manager, establezca la propiedad zoneRedundant del plan de App Service en true, como en el código de ejemplo siguiente:
- Azure CLI
- Bíceps
```
az appservice plan create -g MyResourceGroup -n MyPlan --app-service-environment MyAse --zone-redundant --number-of-workers 2 --sku I1V2
```
Nota

Si usa la CLI de Azure para modificar la zoneRedundant propiedad , debe especificar la number-of-workers propiedad , que es el número de instancias y usar una capacidad mayor o igual que 2.
```
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
    name: appServicePlanName
    location: location
    hostingEnvironmentProfile: {
        id: '...'
    }
    sku: {
        name: sku
        capacity: 2
    }
    kind: 'linux'
    properties: {
        reserved: true
        zoneRedundant: true
    }
}
```
Migrar un plan de App Service existente a la redundancia de zona Si tiene un plan de App Service Environment o de App Service Aislado v2 existente que admita redundancia de zona, puede habilitar la redundancia de zona en cualquier momento. Para habilitar la redundancia de zona en el App Service Environment, configure la propiedad zoneRedundant a true o use la CLI de Azure.
- Azure CLI
- Bíceps
```
az resource update --ids /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/hostingEnvironments/{aseName} --set properties.zoneRedundant=true
```
```
resource asev3 'Microsoft.Web/hostingEnvironments@2020-12-01' = {
    name: aseName
    location: location
    kind: 'ASEV3'
    dependsOn: [
        virtualnetwork
    ] 
    properties: {
        ...
        zoneRedundant: true
    }
}
```
Nota

Al cambiar el estado de redundancia de zona de App Service Environment, se inicia una actualización que tarda entre 12 y 24 horas en completarse. Durante el proceso de actualización, no experimenta ningún tiempo de inactividad ni problemas de rendimiento.

En el caso de los planes de App Service aislados v2, si App Service Environment es redundante de zona, los planes de App Service se pueden hacer redundantes de zona. Cada plan de App Service tiene su propia configuración de redundancia de zona, lo que significa que puede tener una combinación de planes con redundancia de zona y sin redundancia de zona en un entorno de App Service. Para habilitar la redundancia de zona en un plan de App Service aislado v2, establezca la zoneRedundantpropiedad del trueplan de App Service en o use la CLI de Azure.
- Azure CLI
- Bíceps
```
az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=true sku.capacity=2
```
Nota

Si usa la CLI de Azure para modificar la zoneRedundant propiedad , debe especificar la sku.capacity propiedad , que es el número de instancias y usar una capacidad mayor o igual que 2.
```
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
    name: appServicePlanName
    location: location
    hostingEnvironmentProfile: {
        id: '...'
    }
    sku: {
        name: sku
        capacity: 2
    }
    kind: 'linux'
    properties: {
        reserved: true
        zoneRedundant: true
    }
}
```
Desactivar la redundancia de zona. Para deshabilitar la redundancia de zona, puede establecer la propiedad App Service Plan o App Service Environment zoneRedundant en false o usar la CLI de Azure:
```
az resource update --ids /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/hostingEnvironments/{aseName} --set properties.zoneRedundant=false

az appservice plan update -g <resource group name> -n <app service plan name> --set zoneRedundant=false sku.capacity=1
```
Nota

Si usa la CLI de Azure para deshabilitar la zoneRedundant propiedad , debe especificar la sku.capacity propiedad ; de lo contrario, el valor predeterminado es 1.

Planeamiento y administración de capacidad

Para prepararse para errores de zona de disponibilidad, considere la posibilidad de sobreaprovisionar la capacidad del plan de App Service. El aprovisionamiento excesivo permite a la solución tolerar cierto grado de pérdida de capacidad y seguir funcionando sin degradar el rendimiento. Para más información, consulte Administración de la capacidad con sobreaprovisionamiento.

Operaciones normales

En la sección siguiente se describe qué esperar cuando los planes de App Service están configurados para la redundancia de zona y todas las zonas de disponibilidad están operativas:

Enrutamiento de tráfico entre zonas: Durante las operaciones normales, el tráfico se enruta entre todas las instancias de plan de App Service disponibles en todas las zonas de disponibilidad.
Replicación de datos entre zonas: Durante las operaciones normales, cualquier estado almacenado en el sistema de archivos de la aplicación se almacena en el almacenamiento con redundancia de zona y se replica sincrónicamente entre zonas de disponibilidad.

Experiencia de zona descendente

En la sección siguiente se describe qué esperar cuando los planes de App Service están configurados para la redundancia de zona y una o varias zonas de disponibilidad no están disponibles:

Detección y respuesta: La plataforma de App Service detecta automáticamente errores en una zona de disponibilidad e inicia una respuesta. No se requiere ninguna intervención manual para iniciar una conmutación por error de zona.
Solicitudes activas: Cuando una zona de disponibilidad no está disponible, se finalizan las solicitudes en curso conectadas a una instancia del plan de App Service en la zona de disponibilidad errónea. Deben reintentarse.
Reenrutamiento del tráfico: Cuando una zona no está disponible, App Service detecta las instancias perdidas de esa zona e intenta buscar automáticamente nuevas instancias de reemplazo. Una vez que encuentre reemplazos, distribuye el tráfico entre las nuevas instancias según sea necesario.

Si se configura el escalado automático y determina que se necesitan más instancias, emite una solicitud a App Service para agregar esas instancias. El comportamiento de escalado automático funciona independientemente del comportamiento de la plataforma de App Service, lo que significa que la especificación de recuento de instancias no necesita ser un múltiplo de dos. Para más información, consulte Escalado vertical de una aplicación en App Service y Información general sobre el escalado automático.

Importante

No hay ninguna garantía de que las solicitudes de más instancias en un escenario de zona inactiva se realicen correctamente. El relleno de las instancias perdidas se produce de la mejor manera posible. Si necesita capacidad garantizada cuando se pierde una zona de disponibilidad, debe crear y configurar los planes de App Service para tener en cuenta la pérdida de una zona. Para ello, puede sobreaprovisionar la capacidad del plan de App Service.
Comportamientos no en tiempo de ejecución: Las aplicaciones que se implementan en un plan de App Service con redundancia de zona siguen ejecutándose y atendiendo el tráfico incluso si una zona de disponibilidad experimenta una interrupción. Sin embargo, los comportamientos que no son de ejecución pueden verse afectados durante una interrupción de la zona de disponibilidad. Estos comportamientos incluyen el escalado del plan de App Service, la creación de aplicaciones, la configuración de la aplicación y la publicación de aplicaciones.

Conmutación por recuperación

Cuando se recupera la zona de disponibilidad, App Service crea automáticamente instancias en la zona de disponibilidad recuperada, quita las instancias temporales creadas en las otras zonas de disponibilidad y enruta el tráfico entre las instancias como de costumbre.

Pruebas de errores de zona

La plataforma de App Service administra el enrutamiento del tráfico, la conmutación por error y la conmutación por recuperación para planes de App Service con redundancia de zona. Dado que esta característica está totalmente administrada, no es necesario iniciar ni validar los procesos de error de zona de disponibilidad.

Compatibilidad con varias regiones

App Service es un servicio de una sola región. Si la región deja de estar disponible, la aplicación tampoco está disponible.

Enfoques alternativos de varias regiones

Para reducir el riesgo de un error de una sola región que afecte a la aplicación, implemente en varias regiones. Los pasos siguientes ayudan a reforzar la resistencia:

Implemente la aplicación en las instancias de cada región.
Configure directivas de equilibrio de carga y conmutación por error.
Replique los datos entre regiones para que pueda recuperar el último estado de la aplicación.

Los siguientes recursos están relacionados con este enfoque:

Para obtener un enfoque de ejemplo que ilustra esta arquitectura, consulte Implementación empresarial de alta disponibilidad mediante App Service Environment.

Copias de seguridad

Al usar el nivel Básico o superior, puede realizar una copia de seguridad de la aplicación de App Service en un archivo mediante las funcionalidades de copia de seguridad y restauración de App Service.

Esta característica es útil si es difícil volver a implementar el código o si almacena el estado en el disco. Para la mayoría de las soluciones, no debe confiar exclusivamente en copias de seguridad. En su lugar, utilice las otras capacidades descritas en esta guía para apoyar los requisitos de resiliencia. Sin embargo, las copias de seguridad protegen contra algunos riesgos que otros enfoques no. Para más información, consulte Copia de seguridad y restauración de la aplicación en App Service.

Confiabilidad durante el mantenimiento del servicio

Azure App Service realiza actualizaciones de servicio periódicas, así como otras formas de mantenimiento. Para asegurarse de que la capacidad esperada está disponible durante una actualización, la plataforma agrega automáticamente instancias adicionales del plan de App Service durante el proceso de actualización.

Habilitación de la redundancia de zona. Al habilitar la redundancia de zona en el plan de App Service, también mejorará la resistencia a las actualizaciones que implementa la plataforma de App Service. Los dominios de actualización constan de colecciones de máquinas virtuales (VM) que se desconectan en el momento de una actualización. Los dominios de actualización están vinculados a zonas de disponibilidad. La implementación de varias instancias en tu plan de App Service y la activación de la redundancia zonal para el plan agrega una capa adicional de resiliencia durante las actualizaciones si una instancia o zona no está en buen estado.

Para más información, consulte Mantenimiento planeado rutinario para Azure App Service.

Personalice el ciclo de actualización. Puede personalizar el ciclo de actualización de un entorno de App Service. Si necesita validar el efecto de las actualizaciones en la carga de trabajo, considere la posibilidad de habilitar las actualizaciones manuales para poder realizar la validación y las pruebas en una instancia de no producción antes de que el cambio se implemente en la instancia de producción.

Para más información sobre las preferencias de mantenimiento, consulte Preferencias de actualización para el mantenimiento planeado de App Service Environment.

Acuerdo de Nivel de Servicio (SLA)

El acuerdo de nivel de servicio (SLA) para App Service describe la disponibilidad esperada del servicio y las condiciones que se deben cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Al implementar un plan de App Service con redundancia de zona, aumenta el porcentaje de tiempo de actividad definido en el Acuerdo de Nivel de Servicio.

Confiabilidad en Azure