Perguntas frequentes sobre o Azure Front Door

O Azure Front Door é um serviço baseado em nuvem que fornece seus aplicativos de forma mais rápida e confiável. Ele usa o balanceamento de carga de camada 7 para distribuir o tráfego entre várias regiões e pontos de extremidade. Ele também oferece aceleração dinâmica de site (DSA) para otimizar o desempenho da Web e failover quase em tempo real para garantir a alta disponibilidade. O Azure Front Door é um serviço totalmente gerenciado, portanto, você não precisa se preocupar com dimensionamento ou manutenção.

O Azure Front Door é um serviço que oferece muitos benefícios para seus aplicativos Web, como a aceleração dinâmica de site (DSA), que melhora o desempenho e a experiência do usuário de seus sites. O Azure Front Door também manipula o descarregamento de TLS/SSL e o TLS de ponta a ponta, o que aprimora a segurança e a criptografia do tráfego da Web. Além disso, o Azure Front Door fornece Firewall de Aplicativo Web, afinidade de sessão baseada em cookie, roteamento baseado em caminho de URL, certificados gratuitos e vários gerenciamentos de domínio e muito mais. Para saber mais sobre os recursos e os recursos do Azure Front Door, consulte comparação de camadas.

O Azure Front Door e o Gateway de Aplicativo do Azure são balanceadores de carga para tráfego HTTP/HTTPS, mas têm escopos diferentes. O Front Door é um serviço global que pode distribuir solicitações entre regiões, enquanto o Gateway de Aplicativo é um serviço regional que pode balancear solicitações em uma região. O Azure Front Door funciona com unidades de escala, clusters ou unidades de selo, enquanto o Gateway de Aplicativo do Azure funciona com VMs, contêineres ou outros recursos na mesma unidade de escala.

O Gateway de Aplicativo por trás do Front Door é útil nessas situações:

• Você deseja equilibrar o tráfego não apenas globalmente, mas também dentro de sua rede virtual. O Front Door só pode fazer o balanceamento de carga baseado em caminho em nível global, mas o gateway de aplicativo pode fazer isso em sua rede virtual.
• Você precisa de Drenagem de Conexão, que o Front Door não dá suporte. O Gateway de Aplicativo pode habilitar a Drenagem de Conexão para suas VMs ou contêineres.
• Você deseja descarregar todo o processamento TLS/SSL e usar apenas solicitações HTTP em sua rede virtual. O Gateway de Aplicativo por trás do Front Door pode conseguir essa configuração.
• Você deseja usar a afinidade de sessão no nível regional e do servidor. O Front Door pode enviar o tráfego de uma sessão de usuário para o mesmo back-end em uma região, mas o Gateway de Aplicativo pode enviá-lo para o mesmo servidor no back-end.

Encadear duas CDNs geralmente não é uma abordagem recomendada, Embora funcione, traz algumas desvantagens

1. A aceleração de última milha da CDN depende da manutenção da conexão com a origem e da escolha do caminho ideal para a origem, a fim de obter os melhores resultados. Encadear duas CDNs normalmente anula alguns dos benefícios da aceleração de última milha.
2. Os controles de segurança se tornam menos eficazes na segunda CDN. Qualquer ACL baseada no IP do cliente não funcionará na segunda CDN, pois ela verá o nó de saída da primeira CDN como o IP do cliente. O conteúdo ainda será inspecionado.
3. Muitas organizações têm dificuldade em lidar com a complexidade de solucionar problemas que envolvem duas CDNs encadeadas, dificultando a identificação de qual CDN está causando o problema.

Para usar o Azure Front Door, você deve ter um VIP público ou um nome DNS acessível publicamente. O Azure Front Door usa o IP público para rotear o tráfego para sua origem. Um cenário comum é implantar um Azure Load Balancer atrás do Front Door. Você também pode usar o Link Privado com o Azure Front Door Premium para se conectar a um balanceador de carga interno. Para obter mais informações, confira habilitar o Link Privado com o balanceador de carga interno.

O Azure Front Door dá suporte a HTTP, HTTPS e HTTP/2.

O Azure Front Door dá suporte ao protocolo HTTP/2 para conexões de cliente. No entanto, a comunicação do pool de back-end usa o protocolo HTTP/1.1. O suporte a HTTP/2 está ativado por padrão.

Você pode usar diferentes tipos de origens para o Azure Front Door, como:

• Armazenamento (Blob do Azure, sites Clássicos e Estáticos)
• serviço de nuvem
• Serviço de Aplicativo
• Aplicativo Web Estático
• Gerenciamento da API
• Gateway de Aplicativo
• Endereço IP público
• Azure Spring Apps
• Instâncias de Contêiner
• Aplicativos de Contêiner
• Qualquer nome de host personalizado com acesso público.

A origem deve ter um IP público ou um nome de host DNS que possa ser resolvido publicamente. Você pode misturar e combinar back-ends de diferentes zonas, regiões ou até mesmo de fora do Azure, desde que eles estejam acessíveis publicamente.

O Azure Front Door não se limita a nenhuma região do Azure, mas opera globalmente. O único local que você precisa escolher ao criar um Front Door é o local do grupo de recursos, que determina onde os metadados do grupo de recursos são armazenados. O perfil do Front Door é um recurso global e sua configuração é distribuída para todos os locais de borda em todo o mundo.

Para obter a lista completa de pontos de presença (POPs) que fornecem balanceamento de carga global e entrega de conteúdo para o Azure Front Door, consulte Locais de POP do Azure Front Door. Essa lista é atualizada regularmente à medida que novos POPs são adicionados ou removidos. Você também pode usar a API do Azure Resource Manager para consultar a lista atual de POPs programaticamente.

O Azure Front Door é um serviço que distribui seu aplicativo globalmente em várias regiões. Ele usa uma infraestrutura comum que é compartilhada por todos os clientes, mas você pode personalizar seu próprio perfil do Front Door para configurar os requisitos específicos do aplicativo. As configurações de outros clientes não podem afetar a configuração do Front Door, que é isolada da deles.

Você pode redirecionar componentes de cadeia de caracteres de host, caminho e consulta de uma URL com o Azure Front Door. Para saber como configurar o redirecionamento de URL, consulte Redirecionamento de URL.

O Front Door não classifica as rotas para seu aplicativo Web. Em vez disso, ele escolhe a rota que melhor se ajusta à solicitação. Para descobrir como o Front Door corresponde às solicitações de rotas, consulte Como o Front Door corresponde às solicitações a uma regra de roteamento.

Para garantir o desempenho ideal dos recursos do Front Door, você só deve permitir que o tráfego proveniente do Azure Front Door chegue à sua origem. Como resultado, solicitações não autorizadas ou mal-intencionadas encontram as políticas de segurança e roteamento do Front Door e têm acesso negado. Para saber como proteger sua origem, consulte Tráfego seguro para as origens do Azure Front Door.

O endereço IP do anycast de front-end do Front Door é fixo e pode não ser alterado desde que você use o Front Door. No entanto, o endereço IP fixo do anycast de front-end do Front Door não é uma garantia. Evite depender diretamente do IP.

O Azure Front Door é um serviço dinâmico que roteia o tráfego para o melhor back-end disponível. Ele não oferece IPs de front-end estáticos ou dedicados no momento.

Sim. Consulte a propriedade MatchedRulesSetName em Logs de acesso.

Sim. Para obter mais informações, consulte Resposta da Microsoft a ataques DDoS contra HTTP/2.

Sim. O Azure Front Door é compatível com os cabeçalhos X-Forwarded-For, X-Forwarded-Host e X-Forwarded-Proto. Esses cabeçalhos ajudam o Front Door a identificar o IP e o protocolo do cliente original. Se o X-Forwarded-For já estiver presente, o Front Door adicionará o IP do soquete do cliente ao final da lista. Caso contrário, ele cria o cabeçalho com o IP do soquete do cliente como o valor. Para X-Forwarded-Host e X-Forwarded-Proto, o Front Door substitui os valores existentes por seus próprios.

Para obter mais informações, consulte Cabeçalhos HTTP compatíveis com o Front Door.

O tempo de implantação para novas configurações do Front Door varia dependendo do tipo de alteração. Normalmente, leva entre 3 e 20 minutos para que as alterações sejam propagadas para todos os nossos locais de borda em todo o mundo.

As atualizações para rotas ou grupos de origem/pools de back-end são perfeitas e não causam nenhum tempo de inatividade (supondo que a nova configuração esteja correta). As atualizações de certificado também são feitas atomicamente, portanto, não há risco de interrupção.

Não. Atualmente, o Azure Front Door dá suporte apenas a HTTP/1.1 da borda até a origem. Para que o gRPC funcione, o HTTP/2 é necessário.

• Os perfis do Front Door Standard/Premium e da CDN do Azure podem ser movidos entre grupos de recursos ou assinaturas sem qualquer tempo de inatividade. Para realizar a movimentação, siga estas instruções.
• O Front Door Classic não oferece suporte a movimentação entre grupos de recursos ou assinaturas. Nesse caso, você pode migrar o perfil Classic para Standard/Premium e, em seguida, realizar a movimentação.
• Se o cliente tiver o WAF associado ao Front Door Standard/Premium, a operação de movimentação falhará. O cliente precisa primeiro desassociar as políticas do WAF, mover e, depois, associá-las novamente.

Para usar a camada Azure Front Door Standard, Premium ou (clássica), você precisa de um IP público ou de um nome DNS que possa ser resolvido publicamente. Esse requisito de um IP público ou um nome DNS que pode ser resolvido publicamente permite que o Azure Front Door encaminhe o tráfego para seus recursos de back-end. Você pode usar recursos do Azure, como Gateways de Aplicativo ou Azure Load Balancers, para rotear o tráfego para recursos em uma rede virtual. Se estiver usando uma camada Premium do Front Door, você poderá habilitar o Link Privado para se conectar às origens por trás de um balanceador de carga interno em um ponto de extremidade privado. Para obter mais informações, confira Proteger origens com Link Privado.

Um grupo de origem é uma coleção de origens que pode lidar com tipos semelhantes de solicitações. Você precisa de um grupo de origem diferente para cada aplicativo ou carga de trabalho diferente.

Em um grupo de origem, você cria uma origem para cada servidor ou serviço que pode atender a solicitações. Se sua origem tiver um balanceador de carga, como o Gateway de Aplicativo do Azure ou estiver hospedada em um PaaS que tenha um balanceador de carga, o grupo de origem terá apenas uma origem. Sua origem cuida do failover e do balanceamento de carga entre as origens que o Front Door não vê.

Por exemplo, se você hospedar um aplicativo no Serviço de Aplicativo do Azure, a configuração do Front Door dependerá de quantas instâncias de aplicativo você tem:

• Implantação de região única: criar um grupo de origem. Nesse grupo de origem, crie uma origem para o aplicativo do Serviço de Aplicativo. Seu aplicativo do Serviço de Aplicativo pode ser expandido entre os trabalhadores, mas o Front Door vê uma origem.
• Implantação ativa/passiva de várias regiões: criar um grupo de origem. Nesse grupo de origem, crie uma origem para cada aplicativo do Serviço de Aplicativo. Defina a prioridade de cada origem para que o aplicativo principal tenha uma prioridade maior do que o aplicativo de backup.
• Implantação ativa/ativa de várias regiões: criar um grupo de origem. Nesse grupo de origem, crie uma origem para cada aplicativo do Serviço de Aplicativo. Configure a prioridade de cada origem da mesma maneira. Defina o peso de cada origem para controlar quantas solicitações vão para essa origem.

Para saber mais, consulte Origens e grupos de origem no Azure Front Door.

O Azure Front Door é um serviço que fornece entrega da Web rápida e confiável para seus aplicativos. Ele oferece recursos como cache, balanceamento de carga, segurança e roteamento. No entanto, você precisa estar ciente de alguns tempos limite e limites que se aplicam ao Azure Front Door. Esses tempos limite e limites incluem o tamanho máximo da solicitação, o tamanho máximo da resposta, o tamanho máximo do cabeçalho, o número máximo de cabeçalhos, o número máximo de regras e o número máximo de grupos de origem. Você pode encontrar as informações detalhadas sobre esses tempos limite e limites na documentação do Azure Front Door.

As atualizações de configuração para a maioria dos conjuntos de regras são feitas em menos de 20 minutos. A regra será aplicada logo após a conclusão da atualização.

O Azure Front Door e a CDN do Azure são dois serviços que fornecem entrega da Web rápida e confiável para seus aplicativos. No entanto, eles não são compatíveis uns com os outros, pois compartilham a mesma rede de sites de borda do Azure para fornecer conteúdo aos usuários. Essa rede compartilhada causa conflitos entre suas políticas de roteamento e cache. Portanto, você precisa escolher o Azure Front Door ou a CDN do Azure para seu aplicativo, dependendo dos requisitos de desempenho e segurança.

O fato de ambos os perfis usarem os mesmos sites de borda do Azure para lidar com solicitações de entrada causa essa limitação que impede que você aninhar um perfil do Azure Front Door atrás de outro. Essa configuração causaria conflitos de roteamento e problemas de desempenho. Portanto, você deve garantir que seus perfis do Azure Front Door sejam independentes e não sejam encadeados, caso precise usar vários perfis para seus aplicativos.

O Azure Front Door usa três marcas de serviço para gerenciar o tráfego entre seus clientes e suas origens:

• A marca de serviço AzureFrontDoor.Backend contém os endereços IP que o Front Door usa para acessar suas origens. Você pode aplicar essa marca de serviço ao configurar a segurança para suas origens.
• A marca de serviço AzureFrontDoor.Frontend contém os endereços IP que os clientes usam para acessar o Front Door. Você pode aplicar a marca de serviço AzureFrontDoor.Frontend quando quiser controlar o tráfego de saída que pode se conectar aos serviços por trás do Azure Front Door.
• A marca de serviço AzureFrontDoor.FirstParty é reservada para um grupo seleto de serviços da Microsoft hospedados no Azure Front Door.

Para obter mais informações sobre casos de uso de marcas de serviço do Azure Front Door, confira as marcas de serviço disponíveis.

O Azure Front Door tem um tempo limite de 5 segundos para receber cabeçalhos do cliente. A conexão será encerrada se o cliente não enviar cabeçalhos dentro de 5 segundos para o Azure Front Door depois de estabelecer a conexão TCP/TLS. Você não pode configurar esse valor de tempo limite.

O Azure Front Door tem um tempo limite de atividade HTTP de 90 segundos. A conexão será encerrada se o cliente não enviar dados por 90 segundos, que é o tempo limite de atividade HTTP para o Azure Front Door. Você não pode configurar esse valor de tempo limite.

Você não pode usar os mesmos domínios para mais de um ponto de extremidade do Front Door, pois o Front Door precisa distinguir a rota (protocolo + host + combinação de caminho) para cada solicitação. Se você tiver rotas duplicadas em diferentes pontos de extremidade, o Azure Front Door não poderá processar as solicitações corretamente.

No momento, não oferecemos a opção de mover domínios de um ponto de extremidade para outro sem nenhuma interrupção no serviço. Você precisa planejar algum tempo de inatividade se quiser migrar seus domínios para um ponto de extremidade diferente.

A funcionalidade de Link Privado do Azure Front Door é independente de região e funcionará mesmo se você escolher uma região diferente daquela onde sua origem está localizada. Nesses casos, para garantir menor latência, escolha sempre a região do Azure mais próxima da origem ao optar por habilitar o ponto de extremidade do Link Privado do Azure Front Door. Estamos no processo de habilitar suporte para mais regiões. Quando houver suporte para uma nova região, você poderá seguir estas instruções para transferir gradualmente o tráfego para a nova região.

O Azure Front Door é uma plataforma que distribui o tráfego em todo o mundo e pode escalar verticalmente para atender às demandas do aplicativo. Ele usa a borda de rede global da Microsoft para fornecer capacidade global de balanceamento de carga que permite que você alterne todo o aplicativo ou microsserviços específicos para diferentes regiões ou nuvens se houver falha.

Para evitar erros ao fornecer arquivos grandes, verifique se o servidor de origem inclui o cabeçalho Content-Range na resposta e se o valor do cabeçalho corresponde ao tamanho real do corpo da resposta.

Você pode encontrar mais detalhes sobre como configurar sua origem e o Front Door para entrega de arquivos grandes em entrega de arquivos grandes.

O fronting de domínio é uma técnica de rede que permite a um invasor ocultar o destino real de uma solicitação mal-intencionada usando um nome de domínio diferente no handshake do TLS e no cabeçalho do host HTTP.

O Azure Front Door (camada Standard, Premium e Clássico) ou a CDN Standard do Azure da Microsoft (clássica) criada após 8 de novembro de 2022, têm o bloqueio de fronting de domínio habilitado. Em vez de bloquear uma solicitação com cabeçalhos de host e SNI incompatíveis, permitiremos a discrepância se os dois domínios pertencerem à mesma assinatura e estiverem incluídos nas regras de roteamento/rotas. A imposição de bloqueio de fronting de domínio será iniciada em 22 de janeiro de 2024 para todos os domínios existentes. A imposição pode requerer até duas semanas para propagar para todas as regiões.

Quando o Front Door bloqueia uma solicitação devido a uma incompatibilidade:

• O cliente recebe uma resposta de código de erro HTTP 421 Misdirected Request.
• O Azure Front Door registra o bloqueio nos logs de diagnóstico na propriedade Informações de Erro com o valor SSLMismatchedSNI.

Para obter mais informações sobre o fronting de domínio, consulte Protegendo nossa abordagem de fronting de domínio no Azure e Proibindo o fronting de domínio no Azure Front Door e na CDN Standard do Azure da Microsoft (clássica).

O Front Door usa o TLS 1.2 como a versão mínima para todos os perfis criados após setembro de 2019.

Você pode optar por usar o TLS 1.0, 1.1, 1.2 ou 1.3 com o Azure Front Door. Para saber mais, leia o artigo TLS de ponta a ponta do Azure Front Door.

O Azure Front Door é um serviço que fornece entrega da Web rápida e segura. Ele permite que você defina como o tráfego da Web é roteado e otimizado em várias regiões e pontos de extremidade. Os recursos do Azure Front Door, como perfis do Front Door e regras de roteamento, só são cobrados quando estão habilitados. No entanto, as políticas e as regras do firewall do aplicativo Web (WAF) são cobradas independentemente de seu status. Mesmo se você desabilitar uma política ou regra do WAF, ela ainda incorrerá em custos para você.

Não.

Não.

O AFD não dá suporte à compactação dinâmica para conteúdos superiores a 8 MB. No entanto, se o conteúdo já foi comprimido pela origem, o Front Door dá suporte ao fornecimento de conteúdo estático comprimido acima de 8 MB, desde que a solicitação por intervalo seja compatível e a codificação de transferência fragmentada não esteja habilitada.

Não.

Para obter informações sobre logs e outros recursos de diagnóstico, confira Monitoramento de métricas e logs para o Front Door.

Você pode armazenar logs de diagnóstico em sua própria conta de armazenamento e escolher por quanto tempo mantê-los. Como alternativa, os logs de diagnóstico podem ser enviados para os Hubs de Eventos ou logs do Azure Monitor. Para obter mais informações, confira Diagnóstico do Azure Front Door.

Para acessar os logs de auditoria do Azure Front Door, você precisa visitar o portal. Selecione sua porta de entrada na página do menu e selecione em registro de atividades. O Log de Atividades fornece os registros das operações do Azure Front Door.

Você pode configurar alertas para o Azure Front Door com base em métricas ou logs. Ao fazer isso, você pode monitorar o desempenho e a integridade dos hosts front-end.

Para obter informações sobre como criar alertas para o Azure Front Door Standard e Premium, consulte configurar alertas.

Próximas etapas

• Saiba como Criar um perfil do Azure Front Door.
• Saiba mais sobre a Arquitetura do Azure Front Door.