Azure Front Door preguntas más frecuentes (FAQ)

Azure Front Door es un servicio basado en la nube que ofrece sus aplicaciones de forma más rápida y confiable. Usa el equilibrio de carga de nivel 7 para distribuir el tráfico entre varias regiones y puntos de conexión. También ofrece aceleración de sitios dinámicos (DSA) para optimizar el rendimiento web y la conmutación por error casi en tiempo real para garantizar la alta disponibilidad. Azure Front Door es un servicio totalmente administrado, por lo que no tiene que preocuparse por el escalado ni el mantenimiento.

Azure Front Door y Azure Application Gateway son equilibradores de carga para el tráfico HTTP/HTTPS, pero tienen ámbitos diferentes. Front Door es un servicio global que puede distribuir solicitudes entre regiones, mientras que Application Gateway es un servicio regional que puede equilibrar las solicitudes dentro de una región. Azure Front Door funciona con unidades de escala, clústeres o unidades de implementación, mientras que Azure Application Gateway funciona con máquinas virtuales, contenedores u otros recursos de la misma unidad de escala.

Puede usar diferentes tipos de orígenes para Azure Front Door, como:

• Almacenamiento (Azure blob, clásico, sitios web estáticos)
• servicio en la nube
• Servicio de Aplicaciones
• Aplicación web estática
• API Management
• Application Gateway
• Dirección IP pública
• Azure Spring Apps
• Azure Container Instances
• Aplicaciones de contenedor
• Cualquier nombre de host personalizado con acceso público.

El origen debe tener una dirección IP pública o un nombre de host DNS que se pueda resolver públicamente. Puede combinar y emparejar backends de diferentes zonas, regiones o incluso fuera de Azure, siempre y cuando sean accesibles públicamente.

Azure Front Door no se limita a ninguna región de Azure, pero funciona globalmente. La única ubicación que eliges al crear una Puerta Principal es la ubicación del grupo de recursos, que determina dónde se almacenan los metadatos del grupo. El perfil de Front Door es un recurso global y su configuración se distribuye a todas las ubicaciones perimetrales de todo el mundo.

Para obtener la lista completa de puntos de presencia (POP) que proporcionan equilibrio de carga global y entrega de contenido para Azure Front Door, consulte Ubicaciones de POP de Azure Front Door. Esta lista se actualiza periódicamente a medida que se agregan o quitan nuevos POP. También puede usar la API de Azure Resource Manager para consultar la lista actual de POP mediante programación.

Azure Front Door es un servicio que distribuye la aplicación globalmente entre varias regiones. Utiliza una infraestructura común que comparten todos sus clientes, pero puedes personalizar tu propio perfil de Puerta Principal para configurar los requisitos específicos de tu aplicación. Las configuraciones de otros clientes no pueden afectar a la configuración de Front Door, que está aislada de la suya.

Front Door no ordena las rutas de la aplicación web. En su lugar, elige la ruta que mejor se adapta a la solicitud. Para averiguar cómo Front Door hace coincidir las solicitudes con las rutas, consulte Cómo Front Door hace coincidir las solicitudes con una regla de enrutamiento.

Para garantizar un rendimiento óptimo de las características de Front Door, permita únicamente que el tráfico procedente de Azure Front Door llegue a su origen. Como resultado, las solicitudes no autorizadas o malintencionadas encuentran las directivas de seguridad y enrutamiento de Front Door y se les deniega el acceso. Para obtener información sobre cómo proteger su origen, consulte Protección del tráfico a orígenes de Azure Front Door.

Los tiempos de propagación de configuración para una única operación de creación, actualización, eliminación o WAF para los perfiles de Azure Front Door y CDN pueden tardar hasta 15 minutos para mayor seguridad. Una única operación de purga de caché se completa en 10 minutos. Los cambios consecutivos pueden extender el tiempo total de despliegue a aproximadamente 30 minutos. Cada actualización de configuración, incluyendo ajustes de conjuntos de reglas, cambios de enrutamiento, actualizaciones de origen o dominio, y modificaciones de WAF, se trata como una operación global. Si envías operaciones adicionales mientras la primera operación aún se está propagando (dentro de su ventana de ~15 minutos), el sistema las pone en cola y comienza solo después de que la operación anterior haya completado. En este escenario, la primera operación se completa en los primeros 15 minutos y los cambios posteriores se procesan en la ventana siguiente. Se están llevando a cabo mejoras en la plataforma en curso que reducirán aún más este tiempo.

Envío de varias solicitudes de purga

Cada solicitud de purga puede incluir hasta 100 direcciones URL (combinación de dominio y ruta de acceso). El primer lote se procesa y hace efecto en aproximadamente 10 minutos.

Si tienes más de 100 URLs que eliminar, debes esperar y verificar que el primer lote se haya completado antes de enviar el siguiente. Si envías una nueva solicitud de purga antes de que termine el lote anterior, la solicitud es rechazada.

Ejemplo: Purgar 256 direcciones URL

1. Envíe las primeras 100 direcciones URL en la solicitud de purga inicial.
2. Espera aproximadamente 10 minutos y verifica que el primer lote se haya completado correctamente.
3. Envíe las siguientes direcciones URL 101-200 en la segunda solicitud.
4. Espera aproximadamente 10 minutos a que termine la segunda tanda.
5. Envíe las direcciones URL restantes de 201 a 256 en la tercera solicitud.

Las actualizaciones de rutas o grupos de origen/grupos de back-end son perfectas y no provocan ningún tiempo de inactividad (suponiendo que la nueva configuración sea correcta). Las actualizaciones de certificados también se realizan de forma atómica, por lo que no hay tiempo de inactividad.

• Puedes mover los perfiles Front Door Standard/Premium y Azure CDN entre grupos de recursos o suscripciones sin ningún tiempo de inactividad. Para ejecutar el movimiento, siga estas instrucciones.
• Azure Front Door (classic) no soporta moverse entre grupos de recursos ni suscripciones. En su lugar, puedes migrar el perfil de Azure Front Door (classic) a Standard/Premium y luego ejecutar el movimiento.
• Si asocias una política WAF con Azure Front Door Standard o Premium, la operación de traslado falla. Primero debe desvincular la directiva de WAF, completar el traslado y, a continuación, volver a vincular la directiva.

Azure Front Door ofrece muchos beneficios para tus aplicaciones web, como la aceleración dinámica del sitio (DSA), que mejora el rendimiento y la experiencia de usuario de tus sitios. Azure Front Door también gestiona la descarga de TLS/SSL y TLS de extremo a extremo, lo que mejora la seguridad y el cifrado de tu tráfico web. Además, Azure Front Door ofrece un cortafuegos para aplicaciones web, afinidad de sesión basada en cookies, enrutamiento basado en rutas de URL, certificados gratuitos, gestión de múltiples dominios y más. Para obtener más información sobre las características y funcionalidades de Azure Front Door, consulte la comparación de niveles.

Azure Front Door soporta HTTP, HTTPS y HTTP/2.

Azure Front Door admite el protocolo HTTP/2 para las conexiones de cliente. Sin embargo, la comunicación del grupo de back-end usa el protocolo HTTP/1.1. La compatibilidad con HTTP/2 está activada de manera predeterminada.

No. Actualmente, Azure Front Door solo admite HTTP/1.1 desde el borde hasta el origen. Para que gRPC funcione, se requiere HTTP/2.

Puede redirigir los componentes de host, ruta de acceso y cadena de consulta de una dirección URL con Azure Front Door. Para aprender a configurar la redirección de URL, consulta Redirección de URL.

Sí. Consulta la MatchedRulesSetName propiedad en Registros de acceso.

Sí. Para obtener más información, vea Microsoft respuesta a ataques DDoS contra http/2.

No. Azure Front Door no puede forzar el tráfico de cliente a un POP específico. Las solicitudes se enrutan a la ubicación perimetral más cercana disponible para garantizar el rendimiento y la fiabilidad. Si necesita restringir el acceso por geografía, use reglas personalizadas de Azure Web Application Firewall (WAF) con condiciones de GeoMatch. Este enfoque permite o bloquea las solicitudes basadas en el país o región del cliente, pero no vuelve a enrutar esos clientes a un POP diferente en otro país o región. Por ejemplo, si bloquea el país o región A, las solicitudes de los clientes en país o región A se bloquean, independientemente del POP que los hubiera podido servir. Para obtener más información, consulte Geo-filtering in Azure WAF for Azure Front Door.

Azure Front Door admite los encabezados X-Forwarded-For, X-Forwarded-Host y X-Forwarded-Proto. Estos encabezados ayudan a Front Door a identificar la dirección IP y el protocolo de cliente originales. Si X-Forwarded-For ya está presente, Front Door agrega la dirección IP del socket de cliente al final de la lista. De lo contrario, crea el encabezado con la dirección IP del socket de cliente como valor. Para X-Forwarded-Host y X-Forwarded-Proto, Front Door reemplaza los valores existentes por sus propios valores.

Para obtener más información, consulte Encabezados HTTP compatibles con Front Door.

Para usar Azure Front Door Standard o Azure Front Door (classic), necesitas una dirección IP pública o un nombre DNS públicamente resoluble. Este requisito permite que Azure Front Door enrute el tráfico a tus recursos de backend. Puede usar Azure recursos como Application Gateway o Azure Equilibradores de carga para enrutar el tráfico a los recursos de una red virtual. Si usas Azure Front Door Premium, puedes usar Private Link para conectarte a orígenes detrás de un balanceador de carga interno a través de un endpoint privado. Para obtener más información, consulte Orígenes seguros con Private Link.

No. Para la seguridad, Azure Front Door solo admite la autenticación basada en identidad administrada al acceder a certificados en Key Vault. Para obtener más información, consulte Use las identidades administradas en Azure Front Door.

No. Azure Front Door no admite actualmente la integración de identidad administrada con Azure Event Hubs.

No. Azure Front Door no admite actualmente páginas de error personalizadas.

Application Gateway detrás de Front Door es útil en estas situaciones:

• Quiere equilibrar el tráfico no solo globalmente, sino también dentro de tu red virtual. Front Door solo puede realizar el equilibrio de carga basado en rutas de acceso en el nivel global, pero Application Gateway puede hacerlo dentro de tu red virtual.
• Necesita drenaje de conexiones, que Front Door no admite. Application Gateway puede habilitar el drenaje de conexiones para las máquinas virtuales o contenedores.
• Desea descargar todo el procesamiento TLS/SSL y usar solo solicitudes HTTP en tu red virtual. Application Gateway detrás de Front Door puede lograr esta configuración.
• Quiere usar la afinidad de sesión en el nivel regional y de servidor. Front Door puede enviar el tráfico desde una sesión de usuario al mismo back-end de una región, pero Application Gateway puede enviarlo al mismo servidor en el back-end.

Encadenar dos CDNs no suele ser recomendable. Aunque puede funcionar, presenta las siguientes desventajas:

1. La aceleración de la última milla de una CDN funciona manteniendo el flujo de conexión con el origen y encontrando el camino óptimo hacia el origen para lograr los mejores resultados. El encadenamiento de dos CDN normalmente niega algunas de las ventajas de la aceleración de última milla.
2. Los controles de seguridad son menos efectivos en la segunda CDN. El control de acceso basado en IP del cliente no funciona allí porque la segunda CDN identifica el nodo de salida de la primera CDN como la IP del cliente. La carga útil de contenido sigue siendo inspeccionada.
3. Encadenar dos CDN aumenta la complejidad de la resolución de problemas. Cuando ocurre un problema, puede ser difícil determinar qué CDN lo está causando.

Para usar Azure Front Door, debe tener una VIP pública o un nombre DNS al que se pueda acceder públicamente. Azure Front Door usa la dirección IP pública para enrutar el tráfico al origen. Un escenario común es implementar un Azure Load Balancer detrás de Front Door. También puede usar Private Link con Azure Front Door Premium para conectarse a un equilibrador de carga interno. Para obtener más información, consulte enable Private Link con el equilibrador de carga interno.

Azure Front Door y Azure CDN son dos servicios que proporcionan entrega web rápida y confiable para las aplicaciones. Sin embargo, no son compatibles entre sí, ya que comparten la misma red de sitios perimetrales de Azure para entregar contenido a tus usuarios. Esta red compartida provoca conflictos entre sus directivas de enrutamiento y almacenamiento en caché. Por lo tanto, debe elegir Azure Front Door o Azure CDN para la aplicación, en función de los requisitos de rendimiento y seguridad.

El hecho de que ambos perfiles/endpoints usen el mismo POP de Azure edge para gestionar las solicitudes entrantes provoca una limitación que impide anidar un perfil/endpoint de Azure Front Door detrás de otro. Esta configuración provocaría conflictos de enrutamiento y problemas de rendimiento. Por lo tanto, si necesitas usar varios perfiles/endpoints para tus aplicaciones, deberías asegurarte de que tus perfiles/endpoints de Azure Front Door no estén encadenados.

Azure Front Door utiliza enrutamiento unicast para la resolución de nombres y enruta las solicitudes al punto óptimo de presencia (POP). Unicast sustituyó el método de enrutamiento Anycast que usaba anteriormente Azure Front Door.

Una solicitud de resolución de nombres para un origen detrás de Azure Front Door llega al punto de conexión de Traffic Manager de Front Door. Los perfiles de Traffic Manager de Front Door consumen numerosas señales de estado y disponibilidad de los PoP en todo el mundo. En función de estas señales, se devuelve la dirección IP de unidifusión del PoP óptimo de Front Door. Luego, la solicitud se realiza directamente a la dirección IP devuelta, que sigue a la arquitectura de enrutamiento de Front Door para devolver la respuesta al usuario o la aplicación.

Azure Front Door usa tres etiquetas de servicio para administrar el tráfico entre los clientes y sus orígenes:

• La etiqueta de servicio AzureFrontDoor.Backend contiene las direcciones IP que Front Door usa para acceder a sus orígenes. Puede aplicar esta etiqueta de servicio al configurar la seguridad para los orígenes.
• La etiqueta de servicio AzureFrontDoor.Frontend contiene las direcciones IP que los clientes usan para llegar a Front Door. Puede aplicar la etiqueta de servicio AzureFrontDoor.Frontend cuando quiera controlar el tráfico saliente que puede conectarse a los servicios detrás de Azure Front Door.
• La etiqueta de servicio AzureFrontDoor.FirstParty está reservada para un grupo de servicios Microsoft hospedado en Azure Front Door.

Para obtener más información sobre los escenarios de etiquetas de servicio de Azure Front Door, consulte etiquetas de servicio disponibles. Para mantenerse informado y tomar las medidas adecuadas durante cualquier cambio en las direcciones IP, desarrolle la automatización para obtener regularmente las direcciones IP más recientes mediante la API de detección de etiquetas de servicio o el archivo JSON.

Un grupo de origen es una colección de orígenes que puede controlar tipos similares de solicitudes. Necesita un grupo de origen diferente para cada aplicación o carga de trabajo diferente.

En un grupo de origen, se crea un origen para cada servidor o servicio que puede atender solicitudes. Si el origen tiene un equilibrador de carga, como Azure Application Gateway, o se hospeda en un PaaS que tiene un equilibrador de carga, el grupo de origen solo tiene un origen. Su origen se encarga de la conmutación por error y el equilibrio de carga entre orígenes que Front Door no ve.

Por ejemplo, si hospeda una aplicación en Azure App Service, la configuración de Front Door depende del número de instancias de aplicación que tenga:

• Implementación de una sola región: cree un grupo de origen. En ese grupo de origen, cree un origen para la aplicación de App Service. La aplicación de App Service puede escalar horizontalmente entre los trabajos, pero Front Door ve un origen.
• Implementación activa/pasiva de varias regiones: cree un grupo de origen. En ese grupo de origen, cree un origen para cada aplicación de App Service. Establezca la prioridad de cada origen para que la aplicación principal tenga una prioridad más alta que la aplicación de copia de seguridad.
• Implementación activa/activa de varias regiones: cree un grupo de origen. En ese grupo de origen, cree un origen para cada aplicación de App Service. Establezca la misma prioridad para todos los orígenes. Establezca el peso de cada origen para controlar el número de solicitudes que van a ese origen.

Para obtener más información, consulte Orígenes y grupos de origen en Azure Front Door.

Azure Front Door es un servicio que proporciona entrega web rápida y confiable para sus aplicaciones. Ofrece características como el almacenamiento en caché, el equilibrio de carga, la seguridad y el enrutamiento. Sin embargo, debe tener en cuenta algunos tiempos de espera y límites que se aplican a Azure Front Door. Estos tiempos de espera y límites incluyen el tamaño máximo de solicitud, el tamaño máximo de respuesta, el tamaño máximo de encabezado, el número máximo de encabezados, el número máximo de reglas y el número máximo de grupos de origen. Puede encontrar la información detallada sobre estos tiempos de espera y límites en la documentación de Azure Front Door.

La mayoría de los conjuntos de reglas actualizan sus configuraciones en menos de 15 minutos. La regla se aplica tan pronto como termina la actualización.

Azure Front Door tiene un tiempo de espera de 5 segundos para recibir encabezados de un cliente. Si el cliente no envía los encabezados en los 5 segundos posteriores a establecer una conexión TCP/TLS a Azure Front Door, la conexión se termina. No puedes configurar este tiempo de espera.

Azure Front Door tiene un tiempo de espera de conexión persistente HTTP de 90 segundos. La conexión finaliza si el cliente no envía datos durante 90 segundos, que es el tiempo de espera de mantenimiento de HTTP para Azure Front Door. No se puede configurar este valor de tiempo de espera.

No puede usar los mismos dominios para más de un punto de conexión de Front Door, ya que Front Door debe distinguir la ruta (protocolo + host + combinación de ruta de acceso) para cada solicitud. Si tiene rutas duplicadas en distintos puntos de conexión, Azure Front Door no puede procesar las solicitudes correctamente.

En este momento, no ofrecemos la opción de mover dominios de un punto de conexión a otro sin interrupciones en el servicio. Debe planear algún tiempo de inactividad si desea migrar los dominios a un punto de conexión diferente.

Azure Front Door Private Link es independiente de la región. Para la latencia más baja, selecciona la región Azure soportada más cercana a tu origen cuando actives un punto final Azure Front Door Private Link. Si la región del origen no se admite en la lista de regiones que admite Front Door Private Link, elija la siguiente región más cercana. El tráfico fluye desde el cliente al punto de conexión de Azure Front Door Private Link en la región admitida y, a continuación, atraviesa la red troncal Microsoft hacia su origen, manteniendo la conectividad privada. Esta configuración introduce latencia adicional debido al salto de red adicional entre regiones. Puedes usar las estadísticas de latencia de ida y vuelta de red de Azure para determinar la latencia extra debido a elegir la siguiente región más cercana. Cuando se admite una nueva región, puedes seguir estas instrucciones para desplazar gradualmente el tráfico a la nueva región.

Azure Front Door es una plataforma que distribuye el tráfico en todo el mundo y puede escalar verticalmente para satisfacer las demandas de la aplicación. Utiliza la red global edge de Microsoft para proporcionar un balanceo global de carga, lo que te permite mover toda tu aplicación o microservicios específicos a diferentes regiones o nubes si ocurre un fallo.

Para evitar errores al entregar archivos grandes, asegúrate de que tu servidor de origen incluya el Content-Range encabezado en la respuesta y que el valor del encabezado coincida con el tamaño real del cuerpo de la respuesta.

Puede encontrar más detalles sobre cómo configurar su origen y Front Door para la entrega de archivos grandes en Entrega de archivos grandes.

El fronting de dominio es una técnica de red que permite a un atacante ocultar el destino real de una solicitud malintencionada mediante un nombre de dominio diferente en el protocolo de enlace TLS y el encabezado host HTTP.

Los recursos de Azure Front Door (niveles Estándar, Premium y clásico) o de Azure CDN Estándar de Microsoft (clásico) creados después del 8 de noviembre de 2022 tienen habilitado el bloqueo de domain fronting. En lugar de bloquear una solicitud con encabezados SNI y host desajustados, permitimos la discrepancia si ambos dominios pertenecen a la misma suscripción y están incluidos en las rutas o reglas de enrutamiento. La aplicación del bloqueo de fronting de dominio comenzó el 22 de enero de 2024.

Cuando Front Door bloquea una solicitud debido a un error de coincidencia:

• El cliente recibe una respuesta de código de error HTTP 421 Misdirected Request.
• Azure Front Door registra el bloque en los registros de diagnóstico en la propiedad Error Info con el valor SSLMismatchedSNI.

Para obtener más información sobre el front-end de dominios, consulte Protección de nuestro enfoque para el front-end de dominios dentro de Azure y Prohibir el front-end de dominios en Azure Front Door y Azure CDN Estándar de Microsoft (clásico).

Front Door usa TLS 1.2 como versión mínima para todos los perfiles creados después de septiembre de 2019.

Puede elegir usar TLS 1.2 o 1.3 con Azure Front Door. Para obtener más información, lea el artículo Azure Front Door TLS de un extremo a otro.

A partir del 15 de agosto de 2025, DigiCert pasó a una nueva plataforma de validación de control de dominio (DCV) de software de código abierto (DCV) diseñada para mejorar la transparencia y la responsabilidad en los procesos de validación de dominios. DigiCert ya no soporta el flujo de trabajo legado de delegación CNAME DCV para la validación del control de dominio en los servicios de Azure especificados. Aprende más

El desuso afecta a los servicios que dependen de la validación basada en CNAME para la emisión y renovación automatizadas de certificados, entre los que se incluyen:

• Azure Front Door (clásico)
• Azure CDN de Microsoft (clásico)

Azure Front Door (clásico) y Azure CDN de Microsoft (clásico):

• A partir del 15 de agosto de 2025, ya no hay soporte para la incorporación de nuevos dominios, la creación de nuevos perfiles ni los certificados gestionados por Azure.
• A partir del 14 de abril de 2026, se retiran los certificados administrados existentes. Todos los certificados gestionados existentes son migrados por el cliente o el equipo de AFD al estándar Azure Front Door o premium. Por favor, use Azure Front Door Estándar o Premium para el certificado gestionado.

En la mayoría de los casos, no se requiere ninguna acción. Después de que se haya migrado tu perfil, Azure Front Door intenta automáticamente renovar tu certificado administrado si faltan 45 días o menos para su expiración.

• Si tu dominio está mapeado por CNAME a Azure Front Door y cumple con los requisitos de registro CAA y estado del dominio, el certificado se rota automáticamente. El trabajo de rotación automática se realiza cada 6 a 8 horas y tarda aproximadamente entre 24 y 48 horas en completarse. Si falla la rotación automática, el estado de validación del dominio cambia a 'Pendiente de validación', y puedes revalidar la propiedad del dominio para activar manualmente la validación.
• Si tu dominio no cumple estos requisitos de validación o tiene HTTPS desactivado, el estado del certificado cambia a Pendiente de revalidación y debes revalidar la propiedad del dominio.

Para renovar el certificado sin esperar la rotación automática, revalida manualmente la propiedad del dominio utilizando cualquiera de los siguientes métodos:

• Adición del registro de validación de DNS necesario después del paso 3 para dominios pendientes de validación
• Activando la validación manualmente usando PowerShell o CLI de Azure (RefreshValidation).

No puedes desactivar los recursos de Azure Front Door. Solo puedes borrarlos. Los medidores variables como Data Transfer Out, Data Transfer In y Requests no se cobran cuando no hay tráfico, pero la tarifa base se cobra aunque no haya tráfico. Se cobra la tarifa base hasta que se elimina el perfil. En Azure Front Door (clásico), las directivas y reglas de WAF se facturan independientemente de su estado. Aunque deshabilite una directiva o regla de WAF, seguirá incurriendo en costos por usted.

No.

No.

Front Door no soporta compresión dinámica para contenido superior a 8 MB. Sin embargo, si el origen ya comprime el contenido, Front Door soporta servir contenido comprimido estático de más de 8 MB siempre que se soporte la solicitud de rango y la codificación de transferencia en bloques no esté habilitada.

No.

Para obtener información sobre los registros y otras funcionalidades de diagnóstico, consulte Monitoring metrics and logs for Front Door (Supervisión de métricas y registros para Front Door).

Puede almacenar los registros de diagnóstico en su propia cuenta de almacenamiento y elegir cuánto tiempo se conservan. Alternativamente, puedes enviar los logs de diagnóstico a Event Hubs o a Azure Monitor. Para obtener más información, consulte Azure Front Door diagnostics.

Para acceder a los registros de auditoría de Azure Front Door, debe visitar el portal. Selecciona tu puerta principal en la página del menú y selecciona Registro de actividades. El registro de actividad proporciona registros de las operaciones de Azure Front Door.

Puede configurar alertas para Azure Front Door basadas en métricas o registros. Al hacerlo, puede supervisar el rendimiento y el estado de los hosts de front-end.

Para obtener información sobre cómo crear alertas para Azure Front Door Estándar y Premium, consulte configurar alertas.

Contenido relacionado

• Creación de un perfil de Azure Front Door
• Arquitectura de enrutamiento de Azure Front Door