Tutorial: Creación de una aplicación de varias regiones de alta disponibilidad en Azure App Service

En una solución bien diseñada, dos de los componentes clave son la alta disponibilidad y la tolerancia a errores. Una configuración sólida incluye un plan de emergencia para errores inesperados, para reducir el tiempo de inactividad y mantener los sistemas en ejecución automáticamente.

Al implementar una aplicación en la nube, elija una región en esa nube para la base de infraestructura de la aplicación. Si implementa una aplicación solo en una sola región y esa región deja de estar disponible, la aplicación tampoco está disponible. La falta de disponibilidad puede ser inaceptable en virtud de los términos del acuerdo de nivel de servicio (SLA) de la aplicación. Para garantizar la disponibilidad, implemente la aplicación y sus servicios en varias regiones de la nube.

En este tutorial se describe cómo implementar una aplicación web de varias regiones de alta disponibilidad. El procedimiento implementa un escenario sencillo que consta de una aplicación web y Azure Front Door. Puede expandir los conceptos para admitir otros patrones de infraestructura. Por ejemplo, si tu aplicación se conecta a una oferta de base de datos de Azure o a una cuenta de almacenamiento, consulta Replicación geográfica activa para bases de datos SQL y redundancia de Azure Storage. Para obtener una arquitectura de referencia para un escenario más detallado, consulte el patrón de aplicación web Reliable para .NET.

En este tutorial, usted hará lo siguiente:

• Creación de aplicaciones de App Service idénticas en regiones independientes
• Creación de Azure Front Door con restricciones de acceso para bloquear el acceso público a App Service

Requisitos previos

Si no tiene una cuenta de Azure, cree una cuenta free antes de comenzar.

Para completar este tutorial:

• Use el entorno de Bash en Azure Cloud Shell. Para obtener más información, consulte Get started with Azure Cloud Shell.

  

• Si prefiere ejecutar comandos de referencia de la CLI localmente, instale la CLI de Azure. Si se ejecuta en Windows o macOS, considere la posibilidad de ejecutar CLI de Azure en un contenedor de Docker. Para obtener más información, consulte Cómo ejecutar el CLI de Azure en un contenedor de Docker.

  • Si usa una instalación local, inicie sesión en el CLI de Azure mediante el comando az login. Siga los pasos que se muestran en el terminal para completar el proceso de autenticación. Para ver otras opciones de inicio de sesión, consulte Authenticate para Azure con CLI de Azure.

  • Cuando se le solicite, instale la extensión CLI de Azure en el primer uso. Para obtener más información sobre las extensiones, consulte Use y administre extensiones con el CLI de Azure.

  • Ejecute az version para buscar cuál es la versión y las bibliotecas dependientes que están instaladas. Para realizar la actualización a la versión más reciente, ejecute az upgrade.

Revisión de la arquitectura del escenario

En el diagrama de arquitectura siguiente se muestra la infraestructura que se crea en este tutorial. Consta de dos aplicaciones de App Service idénticas en regiones independientes. La primera aplicación web está en la región activa. Es la aplicación principal responsable del procesamiento del tráfico entrante. La segunda aplicación está en la región en espera y espera a la disponibilidad de la aplicación principal. Azure Front Door intenta enrutar el tráfico a la aplicación web principal. Cuando la región primaria no está disponible, el tráfico se enruta al servidor en espera. En el diagrama, la línea de puntos representa el enrutamiento del tráfico en función del estado de la región. Las restricciones de acceso se configuran para bloquear el acceso directo a las aplicaciones desde Internet.

Azure proporciona varias opciones para el equilibrio de carga y el enrutamiento del tráfico. Azure Front Door se selecciona para este tutorial porque implica aplicaciones web accesibles desde Internet hospedadas en Azure App Service implementadas en varias regiones. Si la configuración difiere del ejemplo de este tutorial, consulte Elección de una solución de equilibrio de carga para su escenario.

El escenario de este tutorial proporciona el siguiente comportamiento:

• Se implementan aplicaciones de App Service idénticas en dos regiones distintas.
• El tráfico público enviado directamente a las aplicaciones web está bloqueado.
• Azure Front Door enruta el tráfico a la aplicación activa en la región primaria.
• La aplicación en espera de la región secundaria está disponible para atender el tráfico, según sea necesario.

Creación de un grupo de recursos

Necesita dos instancias de una aplicación web que se ejecuten en regiones de Azure diferentes para este tutorial.

1. Revise los pares de regiones disponibles y seleccione dos regiones emparejadas para las aplicaciones web.

   En este tutorial, las dos regiones se conocen como (<primary-region>eastus) y <standby-region> (westus).

2. Cree un grupo de recursos para todos los recursos que configure en este tutorial. En este tutorial se crea el grupo de recursos en la <primary-region> ubicación.

   az group create --name <resource-group> --location <primary-region>
   

   Cambie los valores de los parámetros siguientes <placeholder> por la información de sus propios recursos.

   Parámetro	Value	Descripción	Ejemplo
   --name	<resource-group>	Grupo de recursos que contiene los recursos creados en este tutorial.	zava-resource-group
   --location	<primary-region>	Ubicación de la región del grupo de recursos. En este tutorial se usa la misma ubicación de región para el grupo de recursos y la aplicación web principal.	eastus

   En una implementación real, use grupos de recursos independientes para cada región o recurso. La separación permite el aislamiento de los recursos en una situación de recuperación ante desastres.

   Para obtener más información, consulte la referencia de comandos az group create .

Creación de dos planes de App Service

Cree dos planes de App Service, uno para cada aplicación web. Cree cada plan en la ubicación de la región donde espera crear la aplicación correspondiente.

Para este comando, usará el par de regiones que seleccionó anteriormente. Use la región activa para la aplicación web principal y la región pasiva para la aplicación web en espera.

Ejecute el siguiente comando para crear el plan de App Service para la aplicación web principal y vuelva a ejecutar el comando para crear el plan de la aplicación en espera.

az appservice plan create --name <app-service-plan> --resource-group <resource-group> --is-linux --location `<region>`

Cambie los valores de los parámetros siguientes <placeholder> por la información de sus propios recursos.

Parámetro	Value	Descripción	Ejemplo
--name	<app-service-plan>	Nombre del plan de servicio de aplicaciones para aplicación web. Cada instancia de plan debe tener un nombre único.	zava-primary-plan zava-standby-plan
--resource-group	<resource-group>	Grupo de recursos que contiene los recursos creados en este tutorial.	zava-resource-group
--location	<region>	Ubicación de la región de la aplicación web.	- Aplicación web principal, región activa eastus - Aplicación web en espera, región pasiva westus

Para obtener más información, consulte la referencia del comando az appservice plan create.

Creación de dos aplicaciones

Cree dos aplicaciones web de App Service. Coloque cada aplicación en una ubicación de región y plan de App Service correspondiente.

1. Identifique la versión del --runtime idioma de las aplicaciones web.

   Puede ejecutar el siguiente comando para obtener la lista de entornos de ejecución disponibles:

   az webapp list-runtimes
   

   Si planea usar la aplicación de ejemplo de Node.js descrita en este tutorial, establezca el valor en <language-version>.

2. Crear dos aplicaciones web. Ejecute el siguiente comando para crear la aplicación web principal y vuelva a ejecutar el comando para crear la aplicación en espera.

   az webapp create --name <web-app-name> --resource-group <resource-group> --plan <app-service-plan> --runtime <language-version>
   

   Cambie los valores de los parámetros siguientes <placeholder> por la información de sus propios recursos.

   Parámetro	Value	Descripción	Ejemplo
   --name	<web-app-name>	el nombre de la aplicación web. Cada aplicación debe tener un nombre único global. Los caracteres válidos son a-z, 0-9y -.	zava-primary-app zava-standby-app
   --resource-group	<resource-group>	Grupo de recursos que contiene los recursos creados en este tutorial.	zava-resource-group
   --name	<app-service-plan>	Nombre del plan de servicio de aplicaciones para aplicación web.	zava-primary-plan zava-standby-plan
   --runtime	<language-version>	La versión del lenguaje en tiempo de ejecución de la aplicación web.	NODE:24-lts

   Para obtener más información, consulte la referencia del comando az webapp create .

3. Identifique el defaultHostName valor de cada aplicación web. El formato del nombre de host es <web-app-name>.azurewebsites.net.

   Examine la salida del comando para cada aplicación web y busque el valor o ejecute el siguiente comando para cada aplicación web:

   az webapp show --name <web-app-name> --resource-group <resource-group> --query "hostNames"
   

   Cambie los valores de los parámetros siguientes <placeholder> por la información de sus propios recursos.

   Parámetro	Value	Descripción	Ejemplo
   --name	<web-app-name>	el nombre de la aplicación web.	zava-primary-app zava-standby-app
   --resource-group	<resource-group>	Grupo de recursos que contiene los recursos creados en este tutorial.	zava-resource-group

   En el portal Azure, el nombre de host de cada aplicación está visible en la página Overview.

   Registre los valores de nombre de host para más adelante. Usa los nombres de host para definir las direcciones de backend para la implementación de Azure Front Door.

4. Confirme que puede acceder a las nuevas aplicaciones web.

   1. En un explorador, escriba el nombre de host de la aplicación web principal, como zava-primary-app.azurewebsites.net.

      Cuando la conexión se realiza correctamente, verá el siguiente mensaje:

      

   2. Repita la prueba con el nombre de host de la aplicación web de respaldo.

Configuración de Azure Front Door

Una implementación de varias regiones puede usar una configuración activa-activa o activa-pasiva . La región primaria está activa y la región en espera es pasiva.

• Una configuración activa-activa distribuye las solicitudes entre varias regiones activas.
• Una configuración activa-pasiva sigue ejecutando instancias en la región en espera (pasiva), pero no envía tráfico allí a menos que se produzca un error en la región principal (activa).

Azure Front Door permite habilitar ambas configuraciones. Para obtener más información sobre el diseño de aplicaciones para alta disponibilidad y tolerancia a errores, consulte Lista de comprobación de revisión de diseño para obtener confiabilidad.

Creación de un perfil

Cree una instancia de Azure Front Door Premium para enrutar el tráfico a las aplicaciones web.

1. Revise la comparación de niveles Azure Front Door y seleccione el nivel de la implementación.

   En este tutorial se usa Azure Front Door Premium (Premium_AzureFrontDoor).

   Si prefiere implementar Azure Front Door Estándar, tenga en cuenta que el nivel Estándar no admite la implementación de reglas administradas en la política de WAF.

2. Ejecute el siguiente comando para crear el perfil:

   az afd profile create --profile-name <front-door-profile> --resource-group <resource-group> --sku <front-door-tier>
   

   Cambie los valores de los parámetros siguientes <placeholder> por la información de sus propios recursos.

   Parámetro	Value	Descripción	Ejemplo
   --profile-name	<front-door-profile>	Nombre del perfil de Azure Front Door. El nombre debe ser único dentro del grupo de recursos.	zava-profile
   --resource-group	<resource-group>	Grupo de recursos que contiene los recursos creados en este tutorial.	zava-resource-group
   --sku	<front-door-tier>	SKU de nivel de Azure Front Door para la implementación.	Premium_AzureFrontDoor (recomendado) Standard_AzureFrontDoor

   Para obtener más información, consulte la referencia del comando az afd profile create .

Agregación de un extremo

Cree un endpoint en tu perfil. Después de crear el primer punto de conexión, puede crear varios puntos de conexión en el perfil.

az afd endpoint create --resource-group <resource-group> --endpoint-name <front-door-endpoint> --profile-name <front-door-profile> --enabled-state Enabled

Cambie los valores de los parámetros siguientes <placeholder> por la información de sus propios recursos.

Parámetro	Value	Descripción	Ejemplo
--resource-group	<resource-group>	Grupo de recursos que contiene los recursos creados en este tutorial.	zava-resource-group
--endpoint-name	<front-door-endpoint>	Nombre del punto de conexión en el perfil de Azure Front Door. El nombre debe ser único globalmente.	zava-endpoint
--profile-name	<front-door-profile>	Nombre del perfil de Azure Front Door.	zava-profile

Para obtener más información, consulte la referencia del comando az afd endpoint create .

Creación de un grupo de origen

Al implementar en Azure Front Door, necesita un origen para que actúe como punto de conexión para el back-end de la aplicación web. Para obtener más información, vea Orígenes y grupos de origen en Azure Front Door. Los orígenes se almacenan en un grupo de origen.

Cree un grupo de origen en el perfil de Azure Front Door para contener orígenes para las dos aplicaciones web.

az afd origin-group create --resource-group <resource-group> --origin-group-name <front-door-origin-group> --profile-name <front-door-profile> \
   --probe-request-type <probe-request> \
   --probe-protocol <probe-protocol> \
   --probe-interval-in-seconds <probe-interval> \
   --probe-path <probe-path> \
   --sample-size <sample-size> \
   --successful-samples-required <required-samples> \
   --additional-latency-in-milliseconds <extra-latency>

Cambie los valores de los parámetros siguientes <placeholder> por la información de sus propios recursos.

Parámetro	Value	Descripción	Ejemplo
--resource-group	<resource-group>	Grupo de recursos que contiene los recursos creados en este tutorial.	zava-resource-group
--origin-group-name	<front-door-origin-group>	El nombre del grupo de origen de Azure Front Door. El nombre debe ser único globalmente.	zava-origin-group
--profile-name	<front-door-profile>	Nombre del perfil de Azure Front Door.	zava-profile
--probe-request-type	<probe-request>	Tipo de solicitud de sondeo de estado.	GET
--probe-protocol	<probe-protocol>	Protocolo que se va a usar para el sondeo de salud.	Http
--probe-interval-in-seconds	<probe-interval>	Número de segundos entre sondeos de estado.	60
--probe-path	<probe-path>	La ruta de acceso relativa al origen, que se utiliza para evaluar la integridad del origen.	/ (barra diagonal inversa)
--sample-size	<sample-size>	Número de muestras para tener en cuenta para las decisiones de equilibrio de carga.	4
--successful-samples-required	<required-samples>	El número de muestras dentro del período de muestreo que deben realizarse correctamente.	3
--additional-latency-in-milliseconds	<extra-latency>	Latencia adicional en milisegundos para que los sondeos se ubiquen en el cubo de latencia más bajo.	50

Para obtener más información, consulte la referencia del comando az afd origin-group create .

Agregar orígenes al grupo de orígenes

Agregue un origen para cada una de las aplicaciones web al grupo de origen de Azure Front Door.

1. Agregue un origen para la aplicación web principal . Establezca el parámetro --priority en 1, que informa Azure Front Door de que esta aplicación es el receptor principal del tráfico.

   az afd origin create --resource-group <resource-group> --host-name <web-app-name>.azurewebsites.net --profile-name <front-door-profile> \
      --origin-group-name <front-door-origin-group> \
      --origin-name <web-app-origin-name> \
      --origin-host-header <web-app-name>.azurewebsites.net \
      --priority <origin-priority> --weight <origin-weight> --enabled-state <origin-state> \
      --http-port <origin-port> --https-port <origin-secure-port>
   

   Cambie los valores de los parámetros siguientes <placeholder> por la información de sus propios recursos.

   Parámetro	Value	Descripción	Ejemplo
   --resource-group	<resource-group>	Grupo de recursos que contiene los recursos creados en este tutorial.	zava-resource-group
   --host-name	<web-app-name>.azurewebsites.net	Nombre de host de la aplicación web principal . El nombre de host combina el nombre de la aplicación web, como zava-primary-app con el identificador de host, azurewebsites.net.	zava-primary-app.azurewebsites.net
   --profile-name	<front-door-profile>	Nombre del perfil de Azure Front Door.	zava-profile
   --origin-group-name	<front-door-origin-group>	El nombre del grupo de origen de Azure Front Door.	zava-origin-group
   --origin-name	<web-app-origin-name>	Nombre del origen de la aplicación web principal . El nombre debe ser único dentro del grupo de origen.	primary-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	La cabecera del host que se enviará para las solicitudes al origen de la aplicación web principal. Si no especifica un valor, el nombre de host de la solicitud determina este valor. Azure CDN orígenes, como Web Apps, Blob Storage y Cloud Services requieren este valor de encabezado de host para que coincida con el nombre de host de origen de forma predeterminada.	zava-primary-app.azurewebsites.net
   --priority	<origin-priority>	Prioridad de este origen dentro del grupo de origen. Para la aplicación web principal , establezca la prioridad en 1. Azure Front Door usa los valores de prioridad para el equilibrio de carga entre orígenes y regiones activas. El valor debe estar comprendido entre 1 y 5.	1
   --weight	<origin-weight>	Peso del origen dentro del grupo de origen para el equilibrio de carga. El valor debe estar comprendido entre 1 y 1000.	1 000
   --enabled-state	<origin-state>	Indica si se debe habilitar este origen para recibir tráfico.	Enabled
   --http-port	<origin-port>	El puerto usado para las solicitudes HTTP al origen.	80
   --https-port	<origin-secure-port>	Puerto usado para solicitudes HTTPS seguras al origen.	443

   Para obtener más información, consulte la referencia del comando az afd origin create .

2. Vuelva a ejecutar el comando y agregue un origen para la aplicación web en espera . El comando usa los mismos parámetros, pero con los siguientes valores de parámetro únicos:

   Parámetro	Value	Descripción	Ejemplo
   --host-name	<web-app-name>.azurewebsites.net	Nombre de host de la aplicación web en espera .	zava-standby-app.azurewebsites.net
   --origin-name	<web-app-origin-name>	Nombre del origen de la aplicación web en espera .	standby-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	Encabezado de host para enviar las solicitudes al origen de la aplicación web standby.	zava-standby-app.azurewebsites.net
   --priority	<origin-priority>	Prioridad de este origen dentro del grupo de origen. Para la aplicación web en espera , establezca la prioridad en 2. Azure Front Door intenta dirigir todo el tráfico al origen principal. Cuando el origen principal no está disponible, el tráfico se enruta al origen en espera.	2

Adición de una regla de ruta

Agregue una regla de enrutamiento para asignar el punto de conexión de Azure Front Door al grupo de origen. La ruta reenvía las solicitudes del punto de conexión al grupo de origen.

1. Cree una regla de ruta para asignar el punto de conexión de Azure Front Door al grupo de origen:

   az afd route create --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> `
      --forwarding-protocol <protocol-type> --route-name <route-rule-name> --https-redirect <secure-redirect> `
      --origin-group <front-door-origin-group> --supported-protocols <protocol-list> --link-to-default-domain <domain-link> 
   

   Cambie los valores de los parámetros siguientes <placeholder> por la información de sus propios recursos.

   Parámetro	Value	Descripción	Ejemplo
   --resource-group	<resource-group>	Grupo de recursos que contiene los recursos creados en este tutorial.	zava-resource-group
   --profile-name	<front-door-profile>	Nombre del perfil de Azure Front Door.	zava-profile
   --endpoint-name	<front-door-endpoint>	Nombre del punto de conexión en el perfil de Azure Front Door.	zava-endpoint
   --forwarding-protocol	<protocol-type>	El protocolo usado por esta regla de ruta al reenviar el tráfico a las aplicaciones de back-end.	MatchRequest
   --route-name	<route-rule-name>	Nombre de la regla de ruta. Debe ser único en el perfil de Azure Front Door.	zava-route-rule
   --https-redirect	<secure-redirect>	Indica si se redirigirá automáticamente el tráfico HTTP al tráfico HTTPS.	Enabled
   --origin-group-name	<front-door-origin-group>	El nombre del grupo de origen de Azure Front Door.	zava-origin-group
   --supported-protocols	<protocol-list>	Lista de protocolos admitidos para esta regla de ruta. Use un espacio para separar los tipos de protocolo.	Http Https
   --link-to-default-domain	<domain-link>	Indique si esta ruta está vinculada al dominio de punto de conexión predeterminado.	Enabled

   Para obtener más información, consulte la referencia del comando az afd route create .

2. Espere unos 15 minutos para que se complete la implementación. Los cambios pueden tardar algún tiempo en propagarse globalmente.

Restringir el acceso solo a través de Azure Front Door

Actualmente puede acceder a las aplicaciones web directamente escribiendo sus nombres de host en un explorador. Si establece restricciones de acceso en las aplicaciones, puede asegurarse de que el tráfico llega a las aplicaciones solo a través de Azure Front Door.

Las características de Azure Front Door funcionan mejor cuando el tráfico circula exclusivamente a través del servicio. Se recomienda configurar los orígenes de la aplicación web para bloquear el tráfico que no se envía a través de Azure Front Door. De lo contrario, el tráfico podría omitir el firewall de aplicaciones web de Azure Front Door, la protección contra DDoS y otras características de seguridad.

El tráfico de Azure Front Door a las aplicaciones se origina en un conjunto conocido de intervalos IP definidos en la etiqueta de servicio AzureFrontDoor.Backend. Mediante una regla de restricción de etiquetas de servicio, puede restringir el tráfico para que solo se origine desde Azure Front Door.

1. Obtenga el identificador del perfil de Azure Front Door.

   Necesita el ID de perfil para asegurarse de que el tráfico se origina únicamente en su instancia específica de Azure Front Door. La restricción de acceso filtra aún más las solicitudes entrantes en función del encabezado HTTP único enviado desde el perfil de Azure Front Door.

   az afd profile show --resource-group <resource-group> --profile-name <front-door-profile> --query "frontDoorId"
   

   Cambie los valores de los parámetros siguientes <placeholder> por la información de sus propios recursos.

   Parámetro	Value	Descripción	Ejemplo
   --resource-group	<resource-group>	Grupo de recursos que contiene los recursos creados en este tutorial.	zava-resource-group
   --profile-name	<front-door-profile>	Nombre del perfil de Azure Front Door.	zava-profile

   La salida del comando muestra el identificador de perfil (valor alfanumérico de 32 dígitos):

   "0000aaaa-1b1b-2c2c-3d3d-444444eeeeee"
   

   En el paso siguiente, usará el identificador de perfil para el valor de <profile-identifier>.

2. Ejecute el siguiente comando para establecer restricciones de acceso en la aplicación web principal y vuelva a ejecutar el comando para establecer restricciones en la aplicación en espera.

   az webapp config access-restriction add --resource-group <resource-group> --name <web-app-name> `
      --priority <access-priority> --service-tag <tag-name> --http-header x-azure-fdid=<front-door-id>
   

   Cambie los valores de los parámetros siguientes <placeholder> por la información de sus propios recursos.

   Parámetro	Value	Descripción	Ejemplo
   --resource-group	<resource-group>	Grupo de recursos que contiene los recursos creados en este tutorial.	zava-resource-group
   --name	<web-app-name>	Nombre de la aplicación web para la que está estableciendo restricciones de acceso.	zava-primary-app zava-standby-app
   --priority	<access-priority>	Especifique la prioridad de la regla de restricción de acceso en todas las reglas definidas para el perfil. Un valor inferior equivale a una prioridad más alta.	100
   --service-tag	<tag-name>	Nombre de etiqueta de servicio reconocido por Azure Front Door. Las restricciones de acceso se aplican al intervalo IP indicado por la etiqueta de servicio.	AzureFrontDoor.Backend
   --http-header	x-azure-fdid=<profile-identifier>	Especifique uno o varios encabezados HTTP únicos para el filtrado adicional del tráfico entrante. Las restricciones de acceso filtran las solicitudes entrantes en función del encabezado HTTP único enviado desde el perfil de Azure Front Door. El encabezado combina el prefijo Azure Front Door y el identificador de perfil de la instancia de Azure Front Door.	x-azure-fdid=0000aaaa-1b1b-2c2c-3d3d-444444eeeeee

   Para obtener más información, consulte la referencia del comando az webapp config access-restriction add .

Restricciones de acceso de prueba

Confirme que las restricciones de acceso impiden el acceso directo a las aplicaciones.

1. En un explorador, escriba el nombre de host de la aplicación web principal, como zava-primary-app.azurewebsites.net.

   La conexión debería fallar con el siguiente mensaje:

   

2. Repita la prueba con el nombre de host de la aplicación web en espera, como zava-standby-app.azurewebsites.net.

Prueba de la implementación de Azure Front Door

Al crear el perfil de Azure Front Door Estándar o Premium, la configuración puede tardar algún tiempo en implementarse globalmente. Una vez completada la implementación, puede acceder al host de front-end.

1. Obtenga el nombre de host del punto de conexión de Azure Front Door:

   az afd endpoint show --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> --query "hostName"
   

   Cambie los valores de los parámetros siguientes <placeholder> por la información de sus propios recursos.

   Parámetro	Value	Descripción	Ejemplo
   --resource-group	<resource-group>	Grupo de recursos que contiene los recursos creados en este tutorial.	zava-resource-group
   --profile-name	<front-door-profile>	Nombre del perfil de Azure Front Door.	zava-profile
   --endpoint-name	<front-door-endpoint>	Nombre del punto de conexión en el perfil de Azure Front Door.	zava-endpoint

   La salida del comando muestra el nombre de host del punto de conexión:

   "zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net"
   

   El nombre de host consta del nombre del punto de conexión, un hash alfanumérico único, un identificador y el sufijo Azure Front Door. En el paso siguiente, usará el nombre de host del punto de conexión.

   Para obtener más información, consulte la referencia del comando az afd endpoint show .

2. En un explorador, escriba el nombre de host del punto de conexión, como zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

   La solicitud debe enrutarse automáticamente a la aplicación principal en la región activa.

   Cuando la conexión se realiza correctamente, verá el siguiente mensaje:

   

3. Pruebe una conmutación por error global instantánea entre las aplicaciones de las regiones emparejadas.

   1. En un explorador, escriba el nombre de host del punto de conexión, como zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

   2. Detenga la aplicación principal ejecutando el comando az webapp stop .

      Cambie los valores de los parámetros siguientes <placeholder> por la información de sus propios recursos.

      az webapp stop --name <primary-web-app> --resource-group <resource-group>
      

   3. Actualice el explorador.

      Si el tráfico redirige correctamente a la aplicación en espera en la otra región, deberías ver la misma página y mensaje.

      Sugerencia

      Es posible que tenga que actualizar la página varias veces para que se complete la conmutación por error.

      Puede confirmar que Azure Front Door redirige a la aplicación en espera comprobando el estado de las aplicaciones web en el portal de Azure. En la página Información general de la aplicación web principal, la opción Inicio debe estar disponible (no desactivada). En la página Información general de la aplicación web en espera, la opción Iniciar no debe estar disponible (atenuada).

   4. Vuelva a ejecutar el az webapp stop comando y detenga la aplicación en espera .

      Cambie los valores de los parámetros siguientes <placeholder> por la información de sus propios recursos.

      az webapp stop --name <standby-web-app> --resource-group <resource-group>
      

   5. Vuelva a actualizar el explorador.

      Si la aplicación en espera también se detiene, todo el enrutamiento del tráfico debe detenerse. Esta vez, debería ver un mensaje de error:

      

   6. Ejecute el az webapp start comando y reinicie su aplicación en modo de espera.

      Cambie los valores de los parámetros siguientes <placeholder> por la información de sus propios recursos.

      az webapp start --name <standby-web-app> --resource-group <resource-group>
      

   7. Actualice el explorador y debería ver una conexión exitosa de la aplicación.

La validación confirma que ahora puede acceder a sus aplicaciones a través de Azure Front Door y que las funciones de conmutación por error funcionan según lo previsto.

Si ha terminado con las pruebas de conmutación por error, reinicie la aplicación principal.

Limpieza de recursos

En los pasos anteriores, creó recursos de Azure en un grupo de recursos. Si no espera necesitar estos recursos en el futuro, elimine el grupo de recursos ejecutando el comando siguiente en el Cloud Shell.

Reemplace el valor del <placeholder> parámetro por la información de su propio recurso:

az group delete --name <resource-group>

Este comando puede tardar unos minutos en ejecutarse.

Implementación desde ARM o Bicep

Los recursos que creó en este tutorial se pueden implementar mediante una plantilla de Azure Resource Manager (plantilla de ARM) o una plantilla de Bicep. Puede empezar con el archivo Bicep para aplicaciones web altamente disponibles y multirregionales en GitHub. Esta plantilla le ayuda a crear una solución de un extremo a otro seguro, de alta disponibilidad y de varias regiones con dos aplicaciones web en diferentes regiones detrás de Azure Front Door.

Para obtener información sobre cómo implementar plantillas de ARM y Bicep, consulte Deploy Bicep archivos con el CLI de Azure.

Preguntas más frecuentes

En este tutorial, ha implementado una infraestructura de línea base para habilitar una aplicación web de varias regiones. App Service proporciona características que pueden ayudarle a asegurarse de que ejecuta aplicaciones que siguen los procedimientos recomendados y las recomendaciones de seguridad.

Esta sección contiene respuestas a las preguntas más frecuentes que pueden ayudarle a proteger aún más las aplicaciones e implementar y administrar los recursos según los procedimientos recomendados.

Administración e implementación de recursos de infraestructura y Azure

En este tutorial, ha usado el CLI de Azure para implementar los recursos de infraestructura. Considere la posibilidad de configurar un mecanismo de implementación continua para administrar la infraestructura de la aplicación. Dado que va a implementar recursos en diferentes regiones, debe administrar de forma independiente esos recursos en las regiones. Para asegurarse de que los recursos son idénticos en cada región, infraestructura como código (IaC), como una plantilla de ARM o Terraform debe usarse con canalizaciones de implementación como Azure Pipelines o Acciones de GitHub. Al configurar esta configuración correctamente, cualquier cambio en los recursos desencadena actualizaciones en todas las regiones de implementación. Para obtener más información, consulte Configurar la implementación continua en Azure App Service.

Utiliza entornos de ensayo para una implementación segura en producción

No se recomienda implementar código de aplicación directamente en aplicaciones y entornos de producción. Es importante tener un lugar seguro para probar las aplicaciones y validar los cambios antes de insertar en producción. Use una combinación de ranuras de ensayo y intercambio de ranuras para mover código del entorno de prueba a producción.

En este tutorial, ha creado la infraestructura de línea base que admite el uso de ranuras de ensayo. Puede crear ranuras de implementación para cada instancia de la aplicación web y configurar la implementación continua en estas ranuras de ensayo con Acciones de GitHub. Al igual que con la administración de infraestructuras, también se recomienda configurar la implementación continua para el código fuente de la aplicación para asegurarse de que los cambios entre regiones permanecen sincronizados. Si no configura la implementación continua, debe actualizar manualmente cada aplicación de cada región cada vez que haya un cambio de código.

Para usar espacios de ensayo, siga este procedimiento:

1. Para este procedimiento, necesita una aplicación que esté lista para implementarla en la aplicación de App Service.

   Si completó el tutorial, puede usar su aplicación web principal y su aplicación web de respaldo. Sin embargo, necesita un plan de App Service que admita suficientes espacios de implementación. Para obtener más información, consulte Azure límites de suscripción y servicio, cuotas y restricciones.

   Si no tiene una aplicación, puede empezar con la aplicación de ejemplo Node.js Hola mundo. Bifurque el repositorio de GitHub para que tenga su propia copia para realizar cambios.

2. Configura las opciones de la pila de App Service para tus aplicaciones web.

   La configuración del entorno de ejecución se refiere a la versión del lenguaje o al runtime utilizado para tu aplicación.

   Puede configurar los valores en el portal de Azure o usar el comando az webapp config set. Si usa el ejemplo de Node.js, establezca la configuración de la pila en Node 24 LTS.

   1. En el portal Azure, vaya a su aplicación web principal.

   2. En el menú de la izquierda, seleccione Configuración de configuración>.

   3. En la pestaña Configuración de pila , configure las opciones siguientes:

      1. Seleccione el valor Stack, como Node.

      2. Seleccione el valor Versión , como Node 24 LTS.

      3. Seleccione Aplicar.

   4. Repita el proceso para configurar la configuración de la pila de App Service para la aplicación web en espera .

3. Configure la implementación continua en el portal de Azure. Para obtener instrucciones detalladas sobre cómo configurar la implementación continua con proveedores como Acciones de GitHub, consulte Configurar la implementación continua en Azure App Service.

4. Ejecute el comando siguiente para crear una ranura de ensayo denominada stage para la aplicación web principal .

   az webapp deployment slot create --resource-group <resource-group> --name <web-app-name> --slot stage --configuration-source <web-app-name>
   

5. Vuelva a ejecutar el az webapp deployment slot create comando y cree una ranura de ensayo denominada stage para la aplicación web en espera .

6. Configura la implementación continua con Acciones de GitHub para cada slot de ensayo.

   1. En el portal Azure, vaya a su aplicación web principal.

   2. En el menú izquierdo, seleccione Ranuras de implementación>.

   3. Busque la ranura de fase en la lista y seleccione la ranura para abrir el panel de detalles.

   4. En el menú izquierdo, seleccione Centro de implementación>.

   5. En la pestaña Settings, establezca la opción Source en GitHub:

      

   6. Si va a implementar desde GitHub por primera vez, seleccione Authorize y siga las indicaciones de autorización. Si quiere realizar la implementación desde un repositorio de usuario diferente, seleccione Cambiar cuenta.

   7. Después de autorizar tu cuenta de Azure con GitHub, selecciona configurar el Organization, el Repository y el Branch para CI/CD. Si no encuentra una organización o repositorio, es posible que tenga que habilitar más permisos en GitHub. Para obtener más información, consulte Administración del acceso de los usuarios a los repositorios de la organización.

      Si va a usar la aplicación de ejemplo de Node.js, utilice la siguiente configuración.

      Configuración	Value
      Organización	<your-GitHub-organization>
      Repositorio	nodejs-docs-hello-world
      Rama	main (principal)

   8. Seleccione Guardar.

Las nuevas confirmaciones del repositorio y la rama seleccionados ahora se implementan continuamente en la ranura de la aplicación de App Service. Puede hacer el seguimiento de las confirmaciones y las implementaciones en la pestaña Registros.

Se agrega un archivo de flujo de trabajo predeterminado que usa un perfil de publicación para autenticarse en App Service al repositorio de GitHub. Para ver este archivo, vaya al directorio <repo-name>/.github/workflows/.

Deshabilitación de la autenticación básica en App Service

Puede limitar el acceso a los puntos de conexión FTP y SCM a los usuarios respaldados por Microsoft Entra ID deshabilitando la autenticación básica.

Si usa una herramienta de implementación continua para implementar el código fuente de la aplicación, deshabilitar la autenticación básica requiere pasos adicionales para configurar la implementación continua. Por ejemplo, no puede usar un perfil de publicación porque no usa Microsoft Entra credenciales. En su lugar, debe usar un principal de servicio o una credencial de OpenID Connect.

Los siguientes comandos deshabilitan la autenticación básica para la aplicación web principal y el entorno de ensayo de App Service, así como para la aplicación web secundaria y el entorno de ensayo. Reemplaza los valores del parámetro <placeholder> siguientes con la información de tus propios recursos.

1. Deshabilite el acceso FTP para los sitios de producción y los entornos de prueba de su aplicación web principal.

   az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
      --parent sites/<web-app-name> --set properties.allow=false
   
   az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
      --parent sites/<web-app-name>/slots/stage --set properties.allow=false
   

2. Vuelva a ejecutar los comandos para la aplicación web en espera .

3. Deshabilite el acceso de autenticación básica al puerto WebDeploy y al sitio de SCM para los sitios de producción y las ranuras de ensayo de la aplicación web principal :

   az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
      --parent sites/<primary-web-app> --set properties.allow=false
   
   az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
      --parent sites/<primary-web-app>/slots/stage --set properties.allow=false
   

4. Vuelva a ejecutar los comandos para la aplicación web en espera .

Para obtener más información sobre cómo deshabilitar la autenticación básica, incluido cómo probar y supervisar inicios de sesión, consulte Deshabilitación de la autenticación básica en implementaciones de App Service.

Uso de la implementación continua cuando la autenticación básica está deshabilitada

Si decide permitir la autenticación básica en las aplicaciones de App Service, puede usar cualquiera de los métodos de implementación disponibles en App Service. Por ejemplo, puede usar el perfil de publicación que configuró en la sección ranuras de ensayo .

Si deshabilita la autenticación básica para las aplicaciones de App Service, la implementación continua requiere un principal de servicio o OpenID Connect para la autenticación. Si usa Acciones de GitHub como repositorio de código, consulte Deploy para Azure App Service mediante Acciones de GitHub. En el tutorial se proporcionan instrucciones paso a paso para crear un principal de servicio o OpenID Connect para implementar en App Service mediante Acciones de GitHub. También puede completar el proceso siguiendo el procedimiento de la sección siguiente.

Crea el principal de servicio y credenciales con Acciones de GitHub

Configurar la implementación continua con Acciones de GitHub y una entidad de servicio:

1. Cree la entidad de servicio para la aplicación web principal y la aplicación web de respaldo:

   Reemplaza los valores del parámetro <placeholder> siguientes con la información de tus propios recursos.

   az ad sp create-for-rbac --name <service-principal-name> --role contributor --scopes \
      /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<primary-web-app> \
      /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<standby-web-app>
   

   La salida es un objeto JSON con las credenciales de asignación de roles que proporcionan acceso a las aplicaciones de App Service.

   {
     "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
     "clientSecret": "ffffffff-5a5a-6b6b-7c7c-888888888888",
     "subscriptionId": "cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a",
     "tenantId": "aaaabbbb-6666-cccc-7777-dddd8888eeee",
     "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
     "resourceManagerEndpointUrl": "https://management.azure.com/",
     "activeDirectoryGraphResourceId": "https://graph.windows.net/",
     "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
     "galleryEndpointUrl": "https://gallery.azure.com/",
     "managementEndpointUrl": "https://management.core.windows.net/"
   }
   

   El json incluye el secreto de cliente, que solo está visible en este momento.

   Sugerencia

   Se recomienda conceder acceso mínimo. En este ejemplo, el ámbito se limita solo a las aplicaciones, no a todo el grupo de recursos.

2. Copie el objeto JSON para que tenga un registro del secreto de cliente.

3. Proporcione las credenciales del principal de servicio a la operación de inicio de sesión de Azure como parte del flujo de trabajo de GitHub Action.

   Puede proporcionar los valores directamente en el flujo de trabajo, o bien almacenarlos como secretos de GitHub a los que se hará referencia allí. Guardar los valores como GitHub secretos es la opción más segura.

   1. Abra el repositorio de GitHub para la aplicación.

   2. Vaya a Configuración>Seguridad>Secretos y variables>Acciones.

   3. Seleccione Nuevo secreto de repositorio y cree un secreto para cada una de las siguientes opciones de configuración. Use los valores de la salida JSON.

      Configuración	Value	Ejemplo
      AZURE_APP_ID	<application/client-id>	00001111-aaaa-2222-bbbb-3333cccc4444
      AZURE_PASSWORD	<client-secret>	ffffffff-5a5a-6b6b-7c7c-888888888888
      AZURE_TENANT_ID	<tenant-id>	aaaabbbb-6666-cccc-7777-dddd8888eeee
      AZURE_SUBSCRIPTION_ID	<subscription-id>	cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a

Creación de un flujo de trabajo de Acciones de GitHub

Una vez que tenga un principal de servicio que pueda acceder a sus aplicaciones de App Service, edite los flujos de trabajo predeterminados de sus aplicaciones. Estos flujos de trabajo se generan automáticamente al configurar la implementación continua.

La autenticación debe realizarse mediante el principal de servicio en lugar del perfil de publicación. Para ver flujos de trabajo de ejemplo, consulte la pestaña Service principal en Agregar el archivo de flujo de trabajo al repositorio de GitHub. El siguiente flujo de trabajo de ejemplo se puede usar para la aplicación de ejemploNode.js.

1. Abra el repositorio de GitHub para la aplicación.

2. Vaya al directorio <repo-name>/.github/workflows/. Debería ver los flujos de trabajo generados automáticamente.

3. Para cada archivo de flujo de trabajo, seleccione Editar (lápiz).

4. Reemplace el contenido del archivo de flujo de trabajo por el siguiente contenido. El código supone que ya ha creado los secretos de GitHub para tus credenciales.

   En la env sección , configure los valores siguientes:

   • AZURE_WEBAPP_NAME: reemplace el <web-app-name> marcador de posición por el nombre de la aplicación web.
   • NODE_VERSION: especifique la versión del nodo que se va a usar. Para el ejemplo de Node.js, el valor es '24.x'.
   • AZURE_WEBAPP_PACKAGE_PATH: especifique la ruta de acceso al proyecto de aplicación web. El valor predeterminado es la raíz del repositorio, '.'.
   • AZURE_WEBAPP_SLOT_NAME: Especifique el nombre del slot de aplicación. El nombre común es stage.

   
    name: Build and deploy Node.js app to Azure Web App
   
    on:
      push:
        branches:
          - main
      workflow_dispatch:
   
    env:
      AZURE_WEBAPP_NAME: <web-app-name>   # Your application name
      NODE_VERSION: '24.x'                # Node version to use
      AZURE_WEBAPP_PACKAGE_PATH: '.'      # Path to your web app project
      AZURE_WEBAPP_SLOT_NAME: stage       # Application slot name
   
    jobs:
      build:
        runs-on: ubuntu-latest
   
        steps:
          - uses: actions/checkout@v4
   
          - name: Set up Node.js version
            uses: actions/setup-node@v4
            with:
              node-version: ${{ env.NODE_VERSION }}
   
          - name: npm install, build
            run: |
              npm install
              npm run build --if-present
   
          - name: Upload artifact for deployment job
            uses: actions/upload-artifact@v4
            with:
              name: node-app
              path: .
   
      deploy:
        runs-on: ubuntu-latest
        needs: build
        environment:
          name: 'stage'
          url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
   
        steps:
          - name: Download artifact from build job
            uses: actions/download-artifact@v4
            with:
              name: node-app
   
          - uses: azure/login@v2
            with:
              creds: |
                {
                  "clientId": "${{ secrets.AZURE_APP_ID }}",
                  "clientSecret":  "${{ secrets.AZURE_PASSWORD }}",
                  "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}",
                  "tenantId": "${{ secrets.AZURE_TENANT_ID }}"
                }
   
          - name: 'Deploy to Azure Web App'
            id: deploy-to-webapp
            uses: azure/webapps-deploy@v3
            with:
              app-name: ${{ env.AZURE_WEBAPP_NAME }}
              slot-name: ${{ env.AZURE_WEBAPP_SLOT_NAME }}
              package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
   
          - name: logout
            run: |
              az logout
   

5. Guarda y confirma los cambios del archivo de flujo de trabajo directamente en la rama principal de tu repositorio.

   La confirmación desencadena la acción de GitHub para ejecutarse de nuevo e implementar tu código. Esta vez, el principal de servicio se usa para realizar la autenticación.

Prueba las actualizaciones de aplicaciones utilizando el enrutamiento de tráfico por slots

El enrutamiento del tráfico con ranuras le permite dirigir una parte predefinida del tráfico de usuario a cada ranura. Inicialmente, el 100 % del tráfico se dirige al sitio de producción. Sin embargo, puede enviar 10% del tráfico a la ranura de ensayo. Este enfoque para enrutamiento del tráfico por ranura envía automáticamente al 10% de los usuarios que intentan acceder a la ranura de prueba. El enfoque no requiere ningún cambio en la instancia de Azure Front Door. Para más información sobre los entornos de almacenamiento provisional y de intercambio de ranuras en App Service, consulte Configuración de entornos de ensayo en Azure App Service.

Mover código del entorno de ensayo al entorno de producción

Después de terminar de probar y validar en las ranuras de ensayo, puede realizar un intercambio de ranuras desde la ranura de ensayo al sitio de producción. Completa el intercambio para todas las instancias de tu aplicación en cada región. Durante un intercambio de ranuras, la plataforma App Service garantiza que la ranura de destino no experimente tiempo de inactividad.

1. Realice el intercambio de la aplicación web principal :

   az webapp deployment slot swap --resource-group <resource-group> -name <primary-web-app-name> --slot stage --target-slot production
   

2. Realice el intercambio de la aplicación web de respaldo :

   az webapp deployment slot swap --resource-group <resource-group> -name <standby-web-app-name> --slot stage --target-slot production
   

3. Después de unos minutos, vaya al punto de conexión de Azure Front Door en el portal de Azure y verifique que el cambio de ranuras se ha realizado correctamente.

En este momento, las aplicaciones están en funcionamiento y los cambios que realice en el código fuente de la aplicación desencadenarán automáticamente una actualización en ambas ranuras de ensayo. Cuando esté listo para mover ese código a producción, puede repetir entonces el proceso de intercambio de ranuras.

Evitar interrupciones y problemas de continuidad mediante implementaciones de varias regiones

Puede evitar posibles interrupciones o problemas con la continuidad a través de las regiones quitando temporalmente un sitio que está realizando un intercambio de slots del grupo de origen de Azure Front Door. Esta acción ayuda a evitar que los clientes vean diferentes versiones de la aplicación al mismo tiempo. También es útil cuando se realizan cambios significativos en las aplicaciones. La retirada temporal hace que todo el tráfico se redirija al otro origen.

1. En el portal de Azure, vaya a la instancia de Azure Front Door.

2. En el menú de la izquierda, seleccione Configuración>.

3. En la lista de grupos de origen, seleccione el grupo de origen que contiene la ranura que desea quitar temporalmente.

4. En el panel Actualizar grupo de origen, busque el espacio que se va a quitar en la lista de Nombre de host de origen.

5. Seleccione Más acciones (...) >Elimine y, a continuación, seleccione Actualizar.

   

   El cambio puede tardar varios minutos.

6. Cuando esté listo para permitir el tráfico a la ranura eliminada, vuelva al panel Actualizar grupo de origen .

7. En la parte superior, seleccione + Agregar un origen para volver a agregar el espacio de origen al grupo de origen.

   

Creación de grupos de origen adicionales y cambio de asociaciones de rutas

Si prefiere no eliminar y volver a agregar orígenes, puede crear grupos de origen adicionales para la instancia de Azure Front Door. A continuación, puede asociar la ruta al grupo de origen que apunta al origen previsto.

Por ejemplo, puede crear dos grupos de origen adicionales, uno para la región principal (activa) y otro para la región en espera (pasiva). Si la región primaria está experimentando un cambio, asocie la ruta a la región en espera. Si la región en espera está experimentando un cambio, asocie la ruta a la región primaria. Cuando se completen todos los cambios, puede asociar la ruta con el grupo de orígenes original que contiene ambas regiones. Este método funciona porque una ruta solo se puede asociar a un grupo de orígenes a la vez.

Considere una configuración con tres grupos de origen:

• El Main-Origin grupo contiene tanto las aplicaciones web principales como las secundarias, cada una de ellas en sus respectivas regiones.
• El Primary-Origin grupo contiene solo la aplicación web principal de la región activa.
• El Standby-Origin grupo contiene solo la aplicación web en espera en la región pasiva.

Supongamos que la aplicación web principal está experimentando un cambio. Antes de que se inicien los cambios, la asociación de ruta del Main-Origin grupo se cambia al Secondary-Origin grupo. Esta acción garantiza que todo el tráfico se enruta a la aplicación web de respaldo en su región respectiva mientras la aplicación web principal de su región respectiva está siendo modificada.

Siga estos pasos para cambiar la asociación de rutas de un grupo de origen:

1. En el portal de Azure, vaya a la instancia de Azure Front Door.

2. En el menú de la izquierda, seleccione Configuración>.

3. En la lista de grupos de origen, busque un grupo de origen que muestre el indicador No asociado en la columna Rutas .

4. Seleccione Más acciones (...) >Asocie el punto de conexión y la ruta.

   

5. En el panel Asociar rutas , seleccione una o varias rutas para asociar con el grupo de origen y, a continuación, seleccione Asociar.

   

Restringir el acceso al sitio de herramientas avanzadas

Con App de Azure servicio, el sitio de herramientas avanzadas/SCM se usa para administrar las aplicaciones e implementar el código fuente de la aplicación. Considere la posibilidad de bloquear el sitio de herramientas avanzadas o SCM, ya que es probable que no se tenga que llegar a este sitio mediante Front Door. Por ejemplo, puede configurar restricciones de acceso que solo le permitan realizar las pruebas y habilitar la implementación continua con la herramienta que prefiera. Si usa ranuras de implementación, para los espacios de producción en concreto, puede denegar casi todo el acceso al sitio de SCM, ya que las pruebas y la validación se realizan con los espacios de ensayo.

Contenido relacionado

• Implementación de una aplicación web de varias regiones de alta disponibilidad
• Revisar la arquitectura base de una aplicación web con zonificación redundante de alta disponibilidad.