Preguntas más frecuentes sobre Azure Front Door

Azure Front Door es una red de entrega de aplicaciones (ADN) como servicio que ofrece diversas funcionalidades de equilibrio de carga de capa 7 para sus aplicaciones. Proporciona aceleración de sitios dinámicos (DSA), junto con equilibrio de carga global con conmutación por error casi en tiempo real. Es un servicio altamente disponible y escalable que está completamente administrado por Azure.

Azure Front Door admite la aceleración de sitios dinámicos (DSA), la descarga de TLS/SSL y TLS de un extremo a otro, firewall de aplicaciones web, afinidad de sesión basada en cookies, enrutamiento basado en ruta de dirección URL, certificados gratuitos y administración de múltiples dominios, entre otras características. Para obtener una lista completa de las características admitidas, consulte Overview of Azure Front Door (Información general de Azure Front Door).

Aunque tanto Front Door como Application Gateway son equilibradores de carga de capa 7 (HTTP/HTTPS), la principal diferencia es que Front Door es un servicio no regional, mientras que Application Gateway es un servicio regional. Front Door puede equilibrar la carga entre las diferentes unidades de escalado/clústeres/unidades de marca entre regiones, y Application Gateway, por su parte, le permite equilibrar la carga entre las máquinas virtuales y contenedores, entre otros, que se encuentran dentro de la unidad de escalado.

Los principales escenarios en que se debería usar Application Gateway detrás de Front Door son los siguientes:

• Front Door puede realizar el equilibrio de carga basado en rutas solo a nivel global, pero si se desea equilibrar la carga del tráfico incluso a nivel de la red virtual, debería utilizarse Application Gateway.
• Puesto que Front Door no funciona en un nivel de máquina virtual o el contenedor, no puede hacer purga de conexiones. Por contra, Application Gateway sí le permite hacer purga de conexiones.
• Con una instancia de Application Gateway detrás de Front Door, es posible lograr el 100 % de la descarga de TLS/SSL y enrutar solo solicitudes HTTP dentro de su red virtual (VNET).
• Tanto Front Door como Application Gateway admiten la afinidad de la sesión. Mientras que Front Door puede dirigir el tráfico posterior desde una sesión de usuario en el mismo clúster o back-end en una región determinada, Application Gateway puede establecer la afinidad del tráfico al mismo servidor en el clúster.

Azure Front Door necesita una VIP pública o un nombre DNS disponible públicamente al que enrutar el tráfico. La implementación de Azure Load Balancer detrás de Front Door es un caso de uso común.

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

La compatibilidad con el protocolo HTTP/2 está disponible únicamente para los clientes que se conectan a Azure Front Door. La comunicación con los back-end en el grupo de back-end se produce a través de HTTP/1.1. La compatibilidad con HTTP/2 está habilitada de forma predeterminada.

Los grupos de back-end pueden estar compuestos de instancias de Storage, aplicaciones web, Kubernetes o cualquier otro nombre de host personalizado que tenga conectividad pública. Azure Front Door requiere que los back-end se definan a través de una dirección IP pública o un nombre de host DNS que pueda resolverse públicamente. Los miembros de grupos de back-end pueden estar entre zonas, regiones e incluso fuera de Azure, siempre y cuando dispongan de conectividad pública.

Azure Front Door es un servicio global y no está asociado a ninguna región de Azure específica. La única ubicación que debe especificar al crear una instancia de Front Door es la ubicación del grupo de recursos, que es básicamente dónde se almacenarán los metadatos para el grupo de recursos. El propio recurso de Front Door se crea como un recurso global, y la configuración se implementa globalmente en todas las ubicaciones perimetrales.

Para obtener la lista completa de las ubicaciones perimetrales de Azure Front Door, consulte Ubicaciones perimetrales de Azure Front Door.

Azure Front Door es un servicio multiinquilino distribuido globalmente. Por lo tanto, la infraestructura de Front Door se comparte entre todos sus clientes. Sin embargo, cuando crea un perfil de Front Door, define la configuración específica necesaria para la aplicación y ninguno de los campos realizados a su Front Door afectan a otras configuraciones de Front Door.

Sí. De hecho, el servicio Azure Front Door admite la redirección de cadenas de host, ruta de acceso y consulta, así como de parte de la URL. Obtenga más información sobre la redirección de URL.

Las rutas de Front Door no están ordenadas y se selecciona una ruta específica en función de la mejor coincidencia. Obtenga más información sobre cómo hace coincidir Front Door las solicitudes con una regla de enrutamiento.

Las características de Front Door funcionan mejor cuando el tráfico solo fluye a través de Front Door. Debe configurar el origen para bloquear el tráfico que no se ha enviado a través de Front Door. Para más información, consulte Protección del tráfico a los orígenes de Azure Front Door.

La dirección IP de difusión por proximidad de su instancia de Front Door normalmente no debería cambiar y es posible que permanezca estática durante la vigencia de Front Door. Sin embargo, esto no se puede garantizar. No asuma ninguna dependencia directa de la dirección IP.

No, Azure Front Door actualmente no admite direcciones IP de difusión por proximidad de front-end estáticas o dedicadas.

Sí, Azure Front Door admite los encabezados X-Forwarded-For, X-Forwarded-Host y X-Forwarded-Proto. Para X-Forwarded-For, si el encabezado ya estaba presente, Front Door le agrega la dirección IP del socket del cliente. En caso contrario, agrega el encabezado con la dirección IP del socket del cliente como valor. En el caso de For X-Forwarded-Host y X-Forwarded-Proto, el valor se invalida.

Obtenga más información sobre los encabezados HTTP que admite Front Door.

Se crean la mayoría de las instancias de Front Door, y las actualizaciones tardan entre 3 y 20 minutos en implementarse globalmente en toda la ubicación perimetral.

Las actualizaciones de las rutas o los grupos de back-end se realizan sin problemas y no provocarán ningún tiempo de inactividad (si la nueva configuración es correcta). Las actualizaciones de certificados también son atómicas y no provocarán ninguna interrupción, a menos que se cambie de "AFD Managed" (Administrado por AFD) a "Use your own cert" (Usar certificado propio) o viceversa.

Los niveles Azure Front Door estándar, premium y (clásico) requieren una IP pública o un nombre DNS de resolución pública para enrutar el tráfico a los recursos del backend. Los recursos de Azure, como los Application Gateways o los Azure Load Balancers, pueden permitir el enrutamiento a los recursos dentro de una red virtual. Si usa un nivel Premium de Front Door, puede habilitar Private Link para conectarse a los orígenes detrás de un equilibrador de carga interno a través de un punto de conexión privado. Para más información, consulte Orígenes seguros con Private Link.

Un grupo de orígenes representa un conjunto de orígenes que funcionalmente pueden atender los mismos tipos de solicitudes. Debe usar un grupo de orígenes diferente para cada aplicación o carga de trabajo.

Dentro de un grupo de orígenes, cree un origen para cada instancia de servicio o servidor que pueda atender solicitudes. Si el origen es un equilibrador de carga, como Azure Application Gateway, o si está hospedado en una oferta de plataforma como servicio (PaaS) que incluye un equilibrador de carga, el grupo de orígenes solo puede contener un único origen. Internamente, el origen controla la conmutación por error y la distribución de carga entre los orígenes, pero esto es invisible para Front Door.

Por ejemplo, supongamos que hospeda una aplicación en Azure App Service. La forma en la que configure Front Door depende del número de instancias de aplicación que implemente:

• Implementación en una sola región: cree un único grupo de orígenes. Dentro de ese grupo de orígenes, cree un único origen para representar la aplicación de App Service. Es posible que la aplicación de App Service esté configurada para escalarse horizontalmente entre instancias de trabajo, pero, desde la perspectiva de Front Door, hay un único origen.
• Implementación de tipo activo/pasivo en varias regiones: cree un único grupo de orígenes. Dentro de ese grupo de orígenes, cree un origen para cada una de las aplicaciones de App Service. Configure la prioridad de cada origen para asegurarse de que la aplicación principal tenga una prioridad más alta que la aplicación secundaria.
• Implementación de tipo activo/activo en varias regiones: cree un único grupo de orígenes. Dentro de ese grupo de orígenes, cree un origen para cada una de las aplicaciones de App Service. Configure la misma prioridad para todos los orígenes. Configure el peso de cada origen para establecer la proporción de solicitudes que deben ir a ese origen.

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

Conozca todos los tiempos de espera y límites documentados del servicio Azure Front Door.

La mayoría de las actualizaciones de la configuración del motor de reglas se completan en menos de 20 minutos. Puede esperar que la regla surta efecto en cuanto se complete la actualización.

Azure Front Door y Azure CDN no se pueden configurar juntos porque ambos servicios usan los mismos sitios perimetrales de Azure al responder a las solicitudes.

Azure Front Door admite tres etiquetas de servicio:

• La etiqueta de servicio AzureFrontDoor.Backend proporciona la lista de direcciones IP que Front Door usa para conectarse a los orígenes. Puede usar esta etiqueta de servicio al proteger el tráfico que va a sus orígenes.
• La etiqueta de servicio AzureFrontDoor.Frontend, que proporciona la lista de direcciones IP que los clientes usan al conectarse a Front Door. Puede usar la etiqueta de servicio AzureFrontDoor.Frontend al controlar el tráfico saliente que se debe permitir para conectarse a los servicios implementados detrás de Azure Front Door.
• La etiqueta de servicio AzureFrontDoor.FirstParty se usa internamente en Azure.

Consulte las etiquetas de servicio disponibles para obtener más información sobre casos de uso de etiquetas de servicio de Azure Front Door.

Azure Front Door es una plataforma multiinquilino distribuida globalmente con grandes volúmenes de capacidad para satisfacer las necesidades de escalabilidad de la aplicación. Ofrecida desde el perímetro de la red global de Microsoft, Front Door proporciona una funcionalidad de equilibrio de carga global que le permite conmutar por error la aplicación entera o incluso microservicios individuales a través de regiones o nubes diferentes.

A partir del 8 de noviembre de 2022, todos los recursos nuevos de Azure Front Door, Azure Front Door (clásico) o Azure CDN estándar de Microsoft (clásico) que se creen bloquearán cualquier solicitud HTTP que muestre el comportamiento de frente de dominio. Se bloquearán las solicitudes HTTP/HTTPS en las que el encabezado host no coincida con la extensión SNI de TLS original que se haya usado durante la negociación de TLS.

Si desea bloquear el comportamiento de domain fronting de los recursos existentes de cualquier instancia de Azure Front Door Estándar y Premium, Azure Front Door (clásico) y Azure CDN Estándar de Microsoft (clásico), o para nuevos recursos de estos servicios de Microsoft (clásico), cree una solicitud de soporte técnico y proporcione la información de suscripción y recursos. Después de habilitar el comportamiento de bloqueo de domain fronting, los recursos de Azure Front Door y Azure CDN Estándar de Microsoft (clásico) bloquearán cualquier solicitud HTTP que muestre este comportamiento.

Si Front Door bloquea una solicitud debido a esta falta de coincidencia, el cliente recibirá una respuesta de código de error HTTP "421 Solicitud incorrecta" y Front Door registrará el bloqueo en sus registros de diagnóstico en la propiedad "Información del error" con el valor "SSLMismatchedSNI".

Todos los perfiles de Front Door creados después de septiembre de 2019 usan TLS 1.2 como valor mínimo predeterminado.

Front Door admite las versiones 1.0, 1.1 y 1.2 de TLS. Aún no se admite TLS 1.3. Consulte TLS de un extremo a otro con Azure Front Door para obtener más detalles.

Los recursos de Azure Front Door, como los perfiles y las reglas de enrutamiento de Front Door, no se facturan si están deshabilitados. Las directivas y reglas de WAF se facturan incluso si están deshabilitadas.

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).

Los registros de diagnóstico fluyen hacia la cuenta de almacenamiento de los clientes y estos pueden establecer la directiva de retención según sus preferencias. También se pueden enviar registros de diagnóstico a un centro de eventos o a registros de Azure Monitor. Para más información, consulte el artículo sobre el diagnóstico de Azure Front Door.

Los registros de auditoría están disponibles para Azure Front Door. En el portal, haga clic en Registro de actividad en la hoja de menú de su instancia de Front Door para acceder al registro de auditoría.

Sí, Azure Front Door admite las alertas. Las alertas se configuran en métricas. Para obtener referencia a la creación de alertas, consulte Configurar alertas. Para más información sobre las métricas disponibles en el monitor de diagnóstico de Front Door, consulte Métricas de Front Door.

Pasos siguientes

• Aprenda a crear una instancia de Front Door.
• Más información acerca de cómo funciona Front Door.