Preguntas más frecuentes sobre Azure Front Door

En este artículo se proporcionan respuestas a las preguntas más frecuentes sobre las características y la funcionalidad de Azure Front Door. Si no ves la respuesta a tu pregunta, puedes ponerte en contacto con nosotros a través de los siguientes canales (en orden escalado):

1. La sección de comentarios de este artículo.

2. Comentarios de Azure Front Door.

3. Soporte técnico de Microsoft: Para crear una nueva solicitud de soporte técnico, en Azure Portal, en la pestaña Ayuda , seleccione el botón Ayuda + soporte técnico y, a continuación, seleccione Nueva solicitud de soporte técnico.

General

¿Qué es Azure Front Door?

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

¿Cuál es la diferencia entre Azure Front Door y Azure Application Gateway?

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 escalado, clústeres o unidades de stamp, mientras que Azure Application Gateway funciona con máquinas virtuales, contenedores u otros recursos en la misma unidad de escalado.

¿Qué tipo de recursos son compatibles actualmente como origen?

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
• Aplicaciones de Azure Spring
• Instancias de Contenedores
• Aplicaciones de contenedores
• Cualquier nombre de host personalizado con acceso público.

El origen debe tener una IP pública o un nombre de host DNS que se pueda resolver públicamente. Puede mezclar y combinar back-ends de diferentes zonas, regiones o incluso fuera de Azure, siempre que sean de acceso público.

¿En qué regiones puedo implementar los servicios de Azure Front Door?

Azure Front Door no se limita a ninguna región de Azure, sino que opera globalmente. La única ubicación que tiene que elegir al crear una puerta frontal es la ubicación del grupo de recursos, que determina dónde se almacenan los metadatos del grupo de recursos. El perfil de Front Door es un recurso global y su configuración se distribuye a todas las ubicaciones perimetrales del mundo.

¿Cuáles son las ubicaciones de los POP (puntos de presencia) de Azure Front Door?

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 añaden o eliminan nuevos COP. También puede usar la API de Azure Resource Manager para consultar la lista actual de POP mediante programación.

¿Cómo asigna Azure Front Door sus recursos entre los distintos clientes?

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

¿Cómo determina Azure Front Door el orden de las reglas de enrutamiento?

Front Door no ordena las rutas de la aplicación web. En su lugar, elige la ruta que mejor se adapte 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.

¿Cuáles son los pasos para restringir el acceso a mi back-end solo a Azure Front Door?

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

¿Cuál es el tiempo estimado para implementar una instancia de Azure Front Door? ¿Mi Front Door permanece operativo durante el proceso de actualización?

El tiempo de implementación de las nuevas configuraciones de Front Door varía en función del tipo de cambio. Normalmente, los cambios tardan entre 3 y 20 minutos en propagarse a todas nuestras ubicaciones periféricas en todo el mundo.

Nota:

Las actualizaciones personalizadas de certificados TLS/SSL pueden tardar más tiempo, desde varios minutos hasta una hora, en implementarse globalmente.

Las actualizaciones de rutas o grupos de origen/grupos de back-end son fluidas y no causan 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 riesgo de interrupción.

¿Puedo mover perfiles de Front Door y CDN entre grupos de recursos o suscripciones sin ningún tiempo de inactividad?

• Los perfiles de Front Door Standard/Premium y Azure CDN se pueden mover entre grupos de recursos o suscripciones sin ningún tiempo de inactividad. Para ejecutar el movimiento, siga estas instrucciones.
• Front Door Classic no admite el movimiento entre grupos de recursos o suscripciones. En su lugar, puede migrar el perfil Clásico a Estándar/Premium y, a continuación, ejecutar el movimiento.
• Si el cliente tiene WAF asociado a Front Door Standard/Premium, se producirá un error en la operación de movimiento. El cliente tiene que desasociar primero las directivas de WAF, moverlas y, a continuación, asociarlas.

Características y protocolos

¿Qué características admite Azure Front Door?

Azure Front Door es un servicio que ofrece muchas ventajas para sus aplicaciones web, como la aceleración dinámica de sitios (DSA), que mejora el rendimiento y la experiencia del usuario de sus sitios. Azure Front Door también controla la descarga de TLS/SSL y TLS de un extremo a otro, lo que mejora la seguridad y el cifrado del tráfico web. Además, Azure Front Door proporciona Web Application Firewall, afinidad de sesión basada en cookies, enrutamiento basado en rutas de acceso de URL, certificados gratuitos y administración de varios dominios, entre otros. Para más información sobre las características y funcionalidades de Azure Front Door, consulte Comparación de niveles.

¿Qué protocolos admite Azure Front Door?

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

¿Cómo admite Azure Front Door 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 utiliza el protocolo HTTP/1.1. La compatibilidad con HTTP/2 está activada de forma predeterminada.

¿Azure Front Door es compatible con gRPC?

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

¿Azure Front Door admite el redireccionamiento de HTTP a HTTPS?

Puede redirigir los componentes de host, ruta de acceso y cadena de consulta de una dirección URL con Azure Front Door. Para obtener información sobre cómo configurar la redirección de URL, consulte Redirección de URL.

¿AFD proporciona telemetría para mostrar qué reglas del motor de reglas procesa AFD para cada solicitud?

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

¿Puede AFD proporcionar protección contra los ataques DDoS 'HTTP/2 Rapid Reset'?

Sí. Para obtener más información, consulte Respuesta de Microsoft a los ataques DDoS contra HTTP/2.

¿Azure Front Door conserva los encabezados 'x-forwarded-for'?

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 del cliente original. 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 IP del socket del cliente como valor. Para X-Forwarded-Host y X-Forwarded-Proto, Front Door reemplaza los valores existentes por los suyos propios.

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

¿Azure Front Door tiene la capacidad de equilibrar la carga o enrutar el tráfico dentro de una red virtual?

Para usar el nivel Estándar o (clásico) de Azure Front Door, necesita una dirección IP pública o un nombre DNS que se pueda resolver públicamente. Este requisito de una dirección IP pública o un nombre DNS que se pueda resolver públicamente permite a Azure Front Door enrutar el tráfico a los recursos de back-end. Puede usar recursos de Azure, como Application Gateways o Azure Load Balancers, para enrutar el tráfico a los recursos de una red virtual. Si usa el nivel Premium de Front Door, puede usar Private Link para conectarse a orígenes detrás de un equilibrador de carga interno con un punto de conexión privado. Para obtener más información, consulte Orígenes seguros con Private Link.

Implementación de Front Door con otros servicios

¿Cuándo debo implementar una puerta de enlace de aplicaciones detrás de Front Door?

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

• Desea equilibrar el tráfico no solo globalmente, sino también dentro de la red virtual. Front Door solo puede realizar el equilibrio de carga basado en rutas de acceso a nivel global, pero Application Gateway puede hacerlo dentro de la 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 los contenedores.
• Desea descargar todo el procesamiento de TLS/SSL y usar solo solicitudes HTTP en la red virtual. Application Gateway detrás de Front Door puede lograr esta configuración.
• Desea utilizar la afinidad de sesión tanto en el nivel regional como en el de servidor. Front Door puede enviar el tráfico de 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.

¿Puedo implementar otra red CDN de un proveedor externo detrás o delante de Front Door?

Encadenar dos CDN generalmente no es un enfoque recomendado, funcionaría, pero viene con las siguientes desventajas

1. La aceleración de última milla de CDN utiliza mantener el flujo de conexión con el origen y encontrar la ruta óptima al origen para lograr los mejores resultados. Encadenar dos CDN juntas generalmente anula algunos de los beneficios de la aceleración de la última milla.
2. Los controles de seguridad se vuelven menos efectivos en la segunda CDN. Cualquier ACL basada en IP de cliente no funcionará en la segunda CDN, ya que la segunda CDN verá el nodo de salida de la primera CDN como IP de cliente. La carga útil de contenido se seguirá inspeccionando.
3. Muchas organizaciones no pueden manejar la complejidad de solucionar problemas de dos CDN encadenadas y, cuando surge un problema, se vuelve difícil averiguar qué CDN tiene el problema.

¿Puedo implementar Azure Load Balancer detrás de Front Door?

Para usar Azure Front Door, debe tener una dirección VIP pública o un nombre DNS que sea de acceso público. 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 Habilitación de Private Link con equilibrador de carga interno.

¿Es posible configurar Azure CDN detrás de mi perfil o punto de conexión de Front Door o al revés?

Azure Front Door y Azure CDN son dos servicios que proporcionan una 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 los usuarios. Esta red compartida provoca conflictos entre sus políticas 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.

¿Es posible configurar un perfil o punto de conexión de Azure Front Door detrás de otro perfil o punto de conexión de Front Door o de otro modo?

El hecho de que ambos perfiles o puntos de conexión usen el mismo POP perimetral de Azure para controlar las solicitudes entrantes provoca una limitación que impide anidar un perfil o punto de conexión de Azure Front Door detrás de otro. Esta configuración provocaría conflictos de enrutamiento y problemas de rendimiento. Por lo tanto, debe asegurarse de que los perfiles o puntos de conexión de Azure Front Door no estén encadenados, si necesita usar varios perfiles o puntos de conexión para las aplicaciones.

Direcciones IP y etiquetas de servicio de Front Door

¿La IP de difusión por proximidad de mi Front Door sigue siendo la misma durante toda su vida útil?

La dirección IP de la difusión por proximidad del front-end de Front Door es fija y es posible que no cambie mientras use Front Door. Sin embargo, la dirección IP fija de la difusión por proximidad del front-end de Front Door no es una garantía. Evite confiar directamente en la IP. 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.

¿Azure Front Door ofrece direcciones IP estáticas o dedicadas?

Azure Front Door es un servicio dinámico que enruta el tráfico al mejor back-end disponible. No ofrece IP de difusión anycast de frontend estáticas o dedicadas en este momento.

¿Cuáles son las etiquetas de servicio de red que admite Front Door?

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

• La etiqueta de servicio AzureFrontDoor.Backend contiene las direcciones IP que Front Door usa para acceder a los 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 AzureFrontDoor.Frontend servicio cuando desee controlar el tráfico saliente que se puede conectar a los servicios detrás de Azure Front Door.
• La etiqueta de servicio AzureFrontDoor.FirstParty está reservada para un grupo selecto de servicios de Microsoft hospedados 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.

Configuración

¿Cuáles son los procedimientos recomendados para crear orígenes y grupos de origen para Azure Front Door?

Un grupo de origen es una colección de orígenes que pueden controlar tipos similares de solicitudes. Necesita un grupo de origen diferente para cada aplicación o carga de trabajo que sea 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 está hospedado en una PaaS que tiene un equilibrador de carga, el grupo de origen solo tiene un origen. El 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 en una sola región: cree un grupo de origen. En ese grupo de orígenes, cree un origen para la aplicación de App Service. Es posible que la aplicación de App Service se escale horizontalmente entre los trabajos, pero Front Door ve un origen.
• Implementación activa/pasiva en varias regiones: cree un grupo de origen. En ese grupo de orígenes, cree un origen para cada aplicación del Servicio de aplicaciones. 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 en varias regiones: cree un grupo de origen. En ese grupo de orígenes, cree un origen para cada aplicación del Servicio de aplicaciones. Establezca la prioridad de cada origen para que sea la misma. Establezca el peso de cada origen para controlar cuántas solicitudes van a ese origen.

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

¿Cuáles son los valores predeterminados y máximos para los tiempos de espera y los límites de Azure Front Door?

Azure Front Door es un servicio que proporciona una entrega web rápida y confiable para las aplicaciones. Ofrece funciones como almacenamiento en caché, equilibrio de carga, seguridad y 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 información detallada sobre estos tiempos de espera y límites en la documentación de Azure Front Door.

¿Cuánto tiempo necesita Azure Front Door para aplicar una nueva regla agregada al motor de reglas de Front Door?

Las actualizaciones de configuración para la mayoría de los conjuntos de reglas se realizan en menos de 20 minutos. La regla se aplicará justo después de que finalice la actualización.

¿Cuál es el valor del tiempo de espera del encabezado desde el cliente hasta Azure Front Door?

Azure Front Door tiene un tiempo de espera de 5 segundos para recibir encabezados del cliente. La conexión finaliza si el cliente no envía encabezados en un plazo de 5 segundos a Azure Front Door después de establecer la conexión TCP/TLS. No se puede configurar este valor de tiempo de espera.

¿Cuál es el valor del tiempo de espera de mantenimiento de conexión HTTP para Azure Front Door?

Azure Front Door tiene un tiempo de espera de mantenimiento 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 HTTP para Azure Front Door. No se puede configurar este valor de tiempo de espera.

¿Es posible usar el mismo dominio para dos puntos de conexión de Front Door diferentes?

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 (combinación de protocolo + host + ruta de acceso) para cada solicitud. Si tiene rutas duplicadas en diferentes puntos de conexión, Azure Front Door no puede procesar las solicitudes correctamente.

¿Es posible migrar un dominio de un punto de conexión de Front Door a otro punto de conexión de Front Door sin ningún tiempo de inactividad?

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

La integración de Azure Front Door Privatelink no se admite en la región donde se encuentra mi origen. ¿Qué hago?

La característica Private Link de Azure Front Door es independiente de la región y funcionará incluso si elige una región diferente de la región en la que se encuentra el origen. En estos casos, para garantizar una latencia más baja, siempre debe elegir la región de Azure más cercana a su origen al elegir habilitar el punto de conexión de Private Link de Azure Front Door. Estamos en el proceso de permitir el apoyo a más regiones. Una vez que se admite una nueva región, puede seguir estas instrucciones para cambiar gradualmente el tráfico a la nueva región.

Rendimiento

¿Cómo garantiza Azure Front Door la alta disponibilidad y escalabilidad de sus servicios?

Azure Front Door es una plataforma que distribuye el tráfico en todo el mundo y se puede escalar verticalmente para satisfacer las demandas de la aplicación. Utiliza el perímetro de la red global de Microsoft para ofrecer una capacidad de equilibrio de carga global que le permite cambiar toda la aplicación o microservicios específicos a diferentes regiones o nubes si se produce un error.

¿Cuáles son las condiciones para almacenar en caché las respuestas a intervalos de mi origen?

Para evitar errores al entregar archivos de gran tamaño, asegúrese de que el 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 el origen y Front Door para la entrega de archivos grandes en Entrega de archivos grandes.

Configuración de TLS

¿Cómo bloquea Azure Front Door el frente de dominio?

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

Los recursos de Azure Front Door (nivel Estándar, Premium y Clásico) o Azure CDN Estándar de Microsoft (clásico) creados después del 8 de noviembre de 2022 tienen habilitado el bloqueo de frente de dominio. En lugar de bloquear una solicitud con SNI y encabezados de host que no coinciden, permitimos la discrepancia si los dos dominios pertenecen a la misma suscripción y están incluidos en las reglas de ruta/enrutamiento. La aplicación del bloqueo del domain fronting comenzará el 22 de enero de 2024 para todos los dominios existentes. La aplicación puede requerir hasta dos semanas para propagarse a todas las regiones.

Cuando Front Door bloquea una solicitud debido a una discrepancia:

• 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 Información de error con el valor SSLMismatchedSNI.

Para obtener más información sobre la fachada de dominio, consulte Protección de nuestro enfoque para la fachada de dominio en Azure y Prohibición de la fachada de dominio en Azure Front Door y Azure CDN Standard de Microsoft (clásico).

¿Qué versiones de TLS se admiten con Azure Front Door?

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

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

Facturación

¿Se me facturarán los recursos de Azure Front Door que estén deshabilitados?

Los recursos de Azure Front Door no se pueden deshabilitar. Solo se pueden eliminar. Los medidores variables como la transferencia de datos fuera, la transferencia de datos dentro y las solicitudes no se cobran cuando no hay tráfico, pero se cobra la tarifa base incluso si no hay tráfico. La tarifa base se cobrará hasta que se elimine el perfil. En el caso de AFD Classic, las directivas y reglas de WAF se cobran independientemente de su estado. Incluso si deshabilita una directiva o regla de WAF, sigue generando costos para usted.

Almacenamiento en caché

¿Es posible utilizar el encabezado de la solicitud HTTP como clave de caché?

No.

¿Front Door es compatible con ETag?

No.

¿Es posible admitir la compresión para tamaños de archivo superiores a 8 MB?

AFD no admite la compresión dinámica para contenido de más de 8 MB. Sin embargo, si el contenido ya se ha comprimido mediante el origen, Front Door admite el servicio de contenido comprimido estático de más de 8 MB siempre que se admita la solicitud de intervalo y no esté habilitada la codificación de transferencia fragmentada.

¿AFD admite la configuración del encabezado de autorización en la solicitud HTTP si el almacenamiento en caché está habilitado?

No.

Diagnósticos y registro

¿Cuáles son las métricas y los registros que proporciona Azure Front Door?

Para obtener información sobre los registros y otras funcionalidades de diagnóstico, consulte Supervisión de métricas y registros para Front Door.

¿Cuál es la duración de la retención de los registros de diagnóstico?

Puede almacenar registros de diagnóstico en su propia cuenta de almacenamiento y elegir cuánto tiempo conservarlos. Como alternativa, los registros de diagnóstico se pueden enviar a los registros de Event Hubs o Azure Monitor. Para más información, consulte el Diagnóstico de Azure Front Door.

¿Cuáles son los pasos para acceder a los registros de auditoría de Azure Front Door?

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

¿Cómo puedo configurar alertas para Azure Front Door?

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

Para obtener información sobre cómo crear alertas para Azure Front Door Standard y Premium, consulte Configuración de alertas.

Contenido relacionado

• Aprenda a crear un perfil de Azure Front Door.
• Obtenga información sobre la arquitectura de Azure Front Door.

En este artículo se proporcionan respuestas a las preguntas más frecuentes sobre las características y la funcionalidad de Azure Front Door. Si no ves la respuesta a tu pregunta, puedes ponerte en contacto con nosotros a través de los siguientes canales (en orden escalado):

1. La sección de comentarios de este artículo.

2. Comentarios de Azure Front Door.

3. Soporte técnico de Microsoft: Para crear una nueva solicitud de soporte técnico, en Azure Portal, en la pestaña Ayuda , seleccione el botón Ayuda + soporte técnico y, a continuación, seleccione Nueva solicitud de soporte técnico.

Azure Front Door es un servicio basado en la nube que entrega las aplicaciones de forma más rápida y confiable. Utiliza el equilibrio de carga de capa 7 para distribuir el tráfico entre varias regiones y puntos de conexión. También ofrece aceleración dinámica de sitios (DSA) para optimizar el rendimiento web y conmutación por error casi en tiempo real para garantizar una alta disponibilidad. Azure Front Door es un servicio totalmente administrado, por lo que no tiene que preocuparse por el escalado o 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 escalado, clústeres o unidades de stamp, mientras que Azure Application Gateway funciona con máquinas virtuales, contenedores u otros recursos en la misma unidad de escalado.

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
• Aplicaciones de Azure Spring
• Instancias de Contenedores
• Aplicaciones de contenedores
• Cualquier nombre de host personalizado con acceso público.

El origen debe tener una IP pública o un nombre de host DNS que se pueda resolver públicamente. Puede mezclar y combinar back-ends de diferentes zonas, regiones o incluso fuera de Azure, siempre que sean de acceso público.

Azure Front Door no se limita a ninguna región de Azure, sino que opera globalmente. La única ubicación que tiene que elegir al crear una puerta frontal es la ubicación del grupo de recursos, que determina dónde se almacenan los metadatos del grupo de recursos. El perfil de Front Door es un recurso global y su configuración se distribuye a todas las ubicaciones perimetrales del 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 añaden o eliminan nuevos COP. 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 en varias regiones. Usa una infraestructura común que comparten todos sus clientes, pero puede personalizar su propio perfil de Front Door para configurar los requisitos específicos de la 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 adapte 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, solo debe permitir que el tráfico procedente de Azure Front Door llegue a su origen. Como resultado, las solicitudes no autorizadas o malintencionadas se encuentran con las directivas de seguridad y enrutamiento de Front Door y se les deniega el acceso. Para obtener información sobre cómo proteger el origen, consulte Protección del tráfico a los orígenes de Azure Front Door.

El tiempo de implementación de las nuevas configuraciones de Front Door varía en función del tipo de cambio. Normalmente, los cambios tardan entre 3 y 20 minutos en propagarse a todas nuestras ubicaciones periféricas en todo el mundo.

Nota:

Las actualizaciones personalizadas de certificados TLS/SSL pueden tardar más tiempo, desde varios minutos hasta una hora, en implementarse globalmente.

Las actualizaciones de rutas o grupos de origen/grupos de back-end son fluidas y no causan 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 riesgo de interrupción.

• Los perfiles de Front Door Standard/Premium y Azure CDN se pueden mover entre grupos de recursos o suscripciones sin ningún tiempo de inactividad. Para ejecutar el movimiento, siga estas instrucciones.
• Front Door Classic no admite el movimiento entre grupos de recursos o suscripciones. En su lugar, puede migrar el perfil Clásico a Estándar/Premium y, a continuación, ejecutar el movimiento.
• Si el cliente tiene WAF asociado a Front Door Standard/Premium, se producirá un error en la operación de movimiento. El cliente tiene que desasociar primero las directivas de WAF, moverlas y, a continuación, asociarlas.

Azure Front Door es un servicio que ofrece muchas ventajas para sus aplicaciones web, como la aceleración dinámica de sitios (DSA), que mejora el rendimiento y la experiencia del usuario de sus sitios. Azure Front Door también controla la descarga de TLS/SSL y TLS de un extremo a otro, lo que mejora la seguridad y el cifrado del tráfico web. Además, Azure Front Door proporciona Web Application Firewall, afinidad de sesión basada en cookies, enrutamiento basado en rutas de acceso de URL, certificados gratuitos y administración de varios dominios, entre otros. Para más información sobre las características y funcionalidades de Azure Front Door, consulte Comparación de niveles.

Azure Front Door admite 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 utiliza el protocolo HTTP/1.1. La compatibilidad con HTTP/2 está activada de forma predeterminada.

No. Actualmente, Azure Front Door solo admite HTTP/1.1 desde el perímetro 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 obtener información sobre cómo configurar la redirección de URL, consulte Redirección de URL.

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

Sí. Para obtener más información, consulte Respuesta de Microsoft a los ataques DDoS contra HTTP/2.

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 del cliente original. 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 IP del socket del cliente como valor. Para X-Forwarded-Host y X-Forwarded-Proto, Front Door reemplaza los valores existentes por los suyos propios.

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

Para usar el nivel Estándar o (clásico) de Azure Front Door, necesita una dirección IP pública o un nombre DNS que se pueda resolver públicamente. Este requisito de una dirección IP pública o un nombre DNS que se pueda resolver públicamente permite a Azure Front Door enrutar el tráfico a los recursos de back-end. Puede usar recursos de Azure, como Application Gateways o Azure Load Balancers, para enrutar el tráfico a los recursos de una red virtual. Si usa el nivel Premium de Front Door, puede usar Private Link para conectarse a orígenes detrás de un equilibrador de carga interno con un punto de conexión privado. Para obtener más información, consulte Orígenes seguros con Private Link.

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

• Desea equilibrar el tráfico no solo globalmente, sino también dentro de la red virtual. Front Door solo puede realizar el equilibrio de carga basado en rutas de acceso a nivel global, pero Application Gateway puede hacerlo dentro de la 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 los contenedores.
• Desea descargar todo el procesamiento de TLS/SSL y usar solo solicitudes HTTP en la red virtual. Application Gateway detrás de Front Door puede lograr esta configuración.
• Desea utilizar la afinidad de sesión tanto en el nivel regional como en el de servidor. Front Door puede enviar el tráfico de 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 CDN generalmente no es un enfoque recomendado, funcionaría, pero viene con las siguientes desventajas

1. La aceleración de última milla de CDN utiliza mantener el flujo de conexión con el origen y encontrar la ruta óptima al origen para lograr los mejores resultados. Encadenar dos CDN juntas generalmente anula algunos de los beneficios de la aceleración de la última milla.
2. Los controles de seguridad se vuelven menos efectivos en la segunda CDN. Cualquier ACL basada en IP de cliente no funcionará en la segunda CDN, ya que la segunda CDN verá el nodo de salida de la primera CDN como IP de cliente. La carga útil de contenido se seguirá inspeccionando.
3. Muchas organizaciones no pueden manejar la complejidad de solucionar problemas de dos CDN encadenadas y, cuando surge un problema, se vuelve difícil averiguar qué CDN tiene el problema.

Para usar Azure Front Door, debe tener una dirección VIP pública o un nombre DNS que sea de acceso público. 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 Habilitación de Private Link con equilibrador de carga interno.

Azure Front Door y Azure CDN son dos servicios que proporcionan una 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 los usuarios. Esta red compartida provoca conflictos entre sus políticas 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 o puntos de conexión usen el mismo POP perimetral de Azure para controlar las solicitudes entrantes provoca una limitación que impide anidar un perfil o punto de conexión de Azure Front Door detrás de otro. Esta configuración provocaría conflictos de enrutamiento y problemas de rendimiento. Por lo tanto, debe asegurarse de que los perfiles o puntos de conexión de Azure Front Door no estén encadenados, si necesita usar varios perfiles o puntos de conexión para las aplicaciones.

La dirección IP de la difusión por proximidad del front-end de Front Door es fija y es posible que no cambie mientras use Front Door. Sin embargo, la dirección IP fija de la difusión por proximidad del front-end de Front Door no es una garantía. Evite confiar directamente en la IP. 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.

Azure Front Door es un servicio dinámico que enruta el tráfico al mejor back-end disponible. No ofrece IP de difusión anycast de frontend estáticas o dedicadas en este momento.

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

• La etiqueta de servicio AzureFrontDoor.Backend contiene las direcciones IP que Front Door usa para acceder a los 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 AzureFrontDoor.Frontend servicio cuando desee controlar el tráfico saliente que se puede conectar a los servicios detrás de Azure Front Door.
• La etiqueta de servicio AzureFrontDoor.FirstParty está reservada para un grupo selecto de servicios de Microsoft hospedados 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 pueden controlar tipos similares de solicitudes. Necesita un grupo de origen diferente para cada aplicación o carga de trabajo que sea 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 está hospedado en una PaaS que tiene un equilibrador de carga, el grupo de origen solo tiene un origen. El 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 en una sola región: cree un grupo de origen. En ese grupo de orígenes, cree un origen para la aplicación de App Service. Es posible que la aplicación de App Service se escale horizontalmente entre los trabajos, pero Front Door ve un origen.
• Implementación activa/pasiva en varias regiones: cree un grupo de origen. En ese grupo de orígenes, cree un origen para cada aplicación del Servicio de aplicaciones. 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 en varias regiones: cree un grupo de origen. En ese grupo de orígenes, cree un origen para cada aplicación del Servicio de aplicaciones. Establezca la prioridad de cada origen para que sea la misma. Establezca el peso de cada origen para controlar cuántas solicitudes van a ese origen.

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

Azure Front Door es un servicio que proporciona una entrega web rápida y confiable para las aplicaciones. Ofrece funciones como almacenamiento en caché, equilibrio de carga, seguridad y 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 información detallada sobre estos tiempos de espera y límites en la documentación de Azure Front Door.

Las actualizaciones de configuración para la mayoría de los conjuntos de reglas se realizan en menos de 20 minutos. La regla se aplicará justo después de que finalice la actualización.

Azure Front Door tiene un tiempo de espera de 5 segundos para recibir encabezados del cliente. La conexión finaliza si el cliente no envía encabezados en un plazo de 5 segundos a Azure Front Door después de establecer la conexión TCP/TLS. No se puede configurar este valor de tiempo de espera.

Azure Front Door tiene un tiempo de espera de mantenimiento 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 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 (combinación de protocolo + host + ruta de acceso) para cada solicitud. Si tiene rutas duplicadas en diferentes 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 ninguna interrupción en el servicio. Debe planificar algún tiempo de inactividad si desea migrar sus dominios a un punto de conexión diferente.

La característica Private Link de Azure Front Door es independiente de la región y funcionará incluso si elige una región diferente de la región en la que se encuentra el origen. En estos casos, para garantizar una latencia más baja, siempre debe elegir la región de Azure más cercana a su origen al elegir habilitar el punto de conexión de Private Link de Azure Front Door. Estamos en el proceso de permitir el apoyo a más regiones. Una vez que se admite una nueva región, puede seguir estas instrucciones para cambiar 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 se puede escalar verticalmente para satisfacer las demandas de la aplicación. Utiliza el perímetro de la red global de Microsoft para ofrecer una capacidad de equilibrio de carga global que le permite cambiar toda la aplicación o microservicios específicos a diferentes regiones o nubes si se produce un error.

Para evitar errores al entregar archivos de gran tamaño, asegúrese de que el 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 el origen y Front Door para la entrega de archivos grandes en Entrega de archivos grandes.

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

Los recursos de Azure Front Door (nivel Estándar, Premium y Clásico) o Azure CDN Estándar de Microsoft (clásico) creados después del 8 de noviembre de 2022 tienen habilitado el bloqueo de frente de dominio. En lugar de bloquear una solicitud con SNI y encabezados de host que no coinciden, permitimos la discrepancia si los dos dominios pertenecen a la misma suscripción y están incluidos en las reglas de ruta/enrutamiento. La aplicación del bloqueo del domain fronting comenzará el 22 de enero de 2024 para todos los dominios existentes. La aplicación puede requerir hasta dos semanas para propagarse a todas las regiones.

Cuando Front Door bloquea una solicitud debido a una discrepancia:

• 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 Información de error con el valor SSLMismatchedSNI.

Para obtener más información sobre la fachada de dominio, consulte Protección de nuestro enfoque para la fachada de dominio en Azure y Prohibición de la fachada de dominio en Azure Front Door y Azure CDN Standard 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 optar por usar TLS 1.2 o 1.3 con Azure Front Door. Para más información, lea el artículo TLS de un extremo a otro de Azure Front Door .

Los recursos de Azure Front Door no se pueden deshabilitar. Solo se pueden eliminar. Los medidores variables como la transferencia de datos fuera, la transferencia de datos dentro y las solicitudes no se cobran cuando no hay tráfico, pero se cobra la tarifa base incluso si no hay tráfico. La tarifa base se cobrará hasta que se elimine el perfil. En el caso de AFD Classic, las directivas y reglas de WAF se cobran independientemente de su estado. Incluso si deshabilita una directiva o regla de WAF, sigue generando costos para usted.

No.

No.

AFD no admite la compresión dinámica para contenido de más de 8 MB. Sin embargo, si el contenido ya se ha comprimido mediante el origen, Front Door admite el servicio de contenido comprimido estático de más de 8 MB siempre que se admita la solicitud de intervalo y no esté habilitada la codificación de transferencia fragmentada.

No.

Para obtener información sobre los registros y otras funcionalidades de diagnóstico, consulte Supervisión de métricas y registros para Front Door.

Puede almacenar registros de diagnóstico en su propia cuenta de almacenamiento y elegir cuánto tiempo conservarlos. Como alternativa, los registros de diagnóstico se pueden enviar a los registros de Event Hubs o Azure Monitor. Para más información, consulte el Diagnóstico de Azure Front Door.

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

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

Para obtener información sobre cómo crear alertas para Azure Front Door Standard y Premium, consulte Configuración de alertas.

Contenido relacionado

• Aprenda a crear un perfil de Azure Front Door.
• Obtenga información sobre la arquitectura de Azure Front Door.