Perguntas frequentes sobre o Azure Front Door

O Azure Front Door é um serviço baseado na nuvem que fornece as suas aplicações de forma mais rápida e fiá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 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 lida com o descarregamento de TLS/SSL e TLS de ponta a ponta, o que melhora a segurança e a criptografia do seu 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 gerenciamento de domínio e muito mais. Para saber mais sobre os recursos do Azure Front Door, consulte Comparação de camadas.

O Azure Front Door e o Azure Application Gateway 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 Application Gateway é um serviço regional que pode equilibrar solicitações dentro de uma região. O Azure Front Door funciona com unidades de escala, clusters ou unidades de carimbo, enquanto o Azure Application Gateway trabalha com VMs, contêineres ou outros recursos na mesma unidade de escala.

O Application Gateway atrás da porta da frente é útil nestas situações:

• Você quer equilibrar o tráfego não apenas globalmente, mas também dentro de sua rede virtual. O Front Door só pode fazer balanceamento de carga baseado em caminho em nível global, mas o Application Gateway pode fazê-lo em sua rede virtual.
• Você precisa de drenagem de conexão, que a porta da frente não suporta. O Application Gateway pode habilitar a Drenagem de Conexões 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 Application Gateway atrás da porta da frente pode conseguir essa configuração.
• Você deseja usar a afinidade de sessão no nível regional e no nível 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 Application Gateway pode enviá-lo para o mesmo servidor no back-end.

Encadear duas CDNs geralmente não é uma abordagem recomendada, funcionaria, mas vem com os seguintes contras

1. A aceleração da última milha da CDN utiliza manter o fluxo de conexão com a origem e encontrar o caminho ideal para a origem para alcançar os melhores resultados. Encadear duas CDNs normalmente anula alguns dos benefícios da aceleração da última milha.
2. Os controlos de segurança tornam-se menos eficazes na segunda CDN. Qualquer ACL baseada em IP de cliente não funcionará na segunda CDN, pois a segunda CDN verá o nó de saída da primeira CDN como IPs de cliente. A carga útil do conteúdo ainda será inspecionada.
3. Muitas organizações não conseguem lidar com a complexidade de solucionar problemas de duas CDNs que estão sendo encadeadas e, quando um problema, torna-se difícil descobrir qual CDN está tendo 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 Balanceador de Carga do Azure atrás da Front Door. Você também pode usar o Private Link com o Azure Front Door Premium para se conectar a um balanceador de carga interno. Para obter mais informações, consulte habilitar Private Link com balanceador de carga interno.

O Azure Front Door suporta HTTP, HTTPS e HTTP/2.

O Azure Front Door suporta o 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 (Web sites Blob, Clássico, Estáticos do Azure)
• Serviço cloud
• Serviço de Aplicações
• Aplicativo Web estático
• Gestão de API
• Gateway de Aplicação
• Endereço IP público
• Azure Spring Apps
• Instâncias de contentores
• 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 fora do Azure, desde que eles sejam acessíveis publicamente.

O Azure Front Door não está limitado a nenhuma região do Azure, mas opera globalmente. O único local que você precisa escolher ao criar uma Porta da Frente é o local do grupo de recursos, que determina onde os metadados do grupo de recursos são armazenados. O perfil Front Door é um recurso global e sua configuração é distribuída para todos os pontos de presença 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 POP do Azure Front Door. Esta 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 seus clientes, mas você pode personalizar seu próprio perfil Front Door para configurar os requisitos específicos do seu aplicativo. As configurações de outros clientes não podem afetar a configuração da porta frontal, que é isolada da deles.

Você pode redirecionar componentes de host, caminho e cadeia de caracteres de 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, escolhe a rota que melhor se adapta ao pedido. Para saber como o Front Door faz a correspondência entre solicitações e rotas, consulte Como o Front Door faz a correspondência entre solicitações e 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 maliciosas encontram as políticas de segurança e roteamento do Front Door e têm acesso negado. Para saber como proteger sua origem, consulte Proteger o tráfego para as origens da Porta da Frente do Azure.

O endereço IP do frontend anycast da sua Porta da Frente é fixo e pode não mudar enquanto você usar a Porta da Frente. No entanto, o endereço IP fixo do frontend anycast da sua porta frontal não é uma garantia. Evite confiar diretamente no IP.

O Azure Front Door é um serviço dinâmico que encaminha o tráfego para o melhor back-end disponível. Ele não oferece IPs de frontend 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.

O Azure Front Door suporta 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 adiciona 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, Front Door substitui os valores existentes por seus próprios.

Para obter mais informações, consulte Cabeçalhos HTTP suportados pela Front Door.

O tempo de implantação para novas configurações de porta frontal varia dependendo do tipo de alteração. Normalmente, leva entre 3 e 20 minutos para que as alterações se propaguem para todos os nossos pontos de presença em todo o mundo.

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

N.º Atualmente, o Azure Front Door suporta apenas HTTP/1.1 desde a borda até a origem. Para que o gRPC funcione, é necessário HTTP/2.

• Os perfis Front Door Standard/Premium e Azure CDN podem ser movidos entre grupos de recursos ou subscrições sem qualquer tempo de inatividade. Para executar a mudança, siga estas instruções.
• O Front Door Classic não suporta a movimentação entre grupos de recursos ou assinaturas. Em vez disso, você pode migrar o perfil Classic para Standard/Premium e, em seguida, executar a mudança.
• Se o cliente tiver o WAF associado ao Front Door Standard/Premium, a operação de movimentação falhará. O cliente tem que desassociar as políticas do WAF primeiro, mover e depois associar.

Para usar o Azure Front Door Standard, Premium ou camada (clássica), você precisa de um IP público ou 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 roteie o tráfego para seus recursos de back-end. Você pode usar recursos do Azure, como Gateways de Aplicativo ou Balanceadores de Carga do Azure, para rotear o tráfego para recursos em uma rede virtual. Se você usar a camada Front Door Premium, poderá usar o Private Link para se conectar às origens por trás de um balanceador de carga interno com um ponto de extremidade privado. Para obter mais informações, consulte Origens seguras 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 que é diferente.

Em um grupo de origem, você cria uma origem para cada servidor ou serviço que pode atender 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 origens que o Front Door não vê.

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

• Implantação de região única: crie 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 em várias regiões: crie 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 em várias regiões: crie 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 ser a mesma. Defina o peso de cada origem para controlar quantos pedidos 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 na 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 entre si, porque compartilham a mesma rede de sites de borda do Azure para fornecer conteúdo aos seus 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 de seus requisitos de desempenho e segurança.

O fato de que ambos os perfis usariam 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 encadeados, se precisar usar vários perfis para seus aplicativos.

O Azure Front Door usa três tags 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 etiqueta 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 AzureFrontDoor.Frontend marca de serviço quando quiser controlar o tráfego de saída que pode se conectar aos serviços por trás da Porta da Frente do Azure.
• A marca de serviço AzureFrontDoor.FirstParty está reservada para um grupo selecionado de serviços da Microsoft hospedados no Azure Front Door.

Para obter mais informações sobre cenários de marcas de serviço do Azure Front Door, consulte Tags 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 a Porta da Frente do Azure depois de estabelecer a conexão TCP/TLS. Não é possível configurar esse valor de tempo limite.

O Azure Front Door tem um tempo limite de keep-alive HTTP de 90 segundos. A conexão será encerrada se o cliente não enviar dados por 90 segundos, que é o tempo limite de keep-alive HTTP para o Azure Front Door. Não é possível configurar esse valor de tempo limite.

Você não pode usar os mesmos domínios para mais de um ponto de extremidade Front Door, porque Front Door precisa distinguir a rota (combinação protocolo + host + caminho) para cada solicitação. Se você tiver rotas duplicadas em pontos de extremidade diferentes, 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 endpoint para outro sem qualquer interrupção no serviço. Você precisa planejar algum tempo de inatividade se quiser migrar seus domínios para um ponto de extremidade diferente.

O recurso Azure Front Door Private Link é independente da região e funcionará mesmo se você escolher uma região diferente da região onde sua origem está localizada. Nesses casos, para garantir uma latência mais baixa, você sempre deve escolher uma região do Azure mais próxima de sua origem ao optar por habilitar o ponto de extremidade do Azure Front Door Private Link. Estamos no processo de viabilizar o apoio a mais regiões. Quando uma nova região é suportada, você pode seguir estas instruções para mudar 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 ser dimensionada para atender às demandas do seu aplicativo. Ele usa a borda de rede global da Microsoft para fornecer capacidade de balanceamento de carga global que permite alternar todo o seu aplicativo ou microsserviços específicos para diferentes regiões ou nuvens se houver falha.

Para evitar erros ao entregar arquivos grandes, verifique se o servidor de origem inclui o Content-Range cabeçalho 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 Front Door para entrega de arquivos grandes em Entrega de arquivos grandes.

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

O Azure Front Door (camada Standard, Premium e Classic) ou o Azure CDN Standard de recursos da Microsoft (clássicos) criados 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 SNI e host incompatíveis, permitimos a discrepância se os dois domínios pertencerem à mesma assinatura e estiverem incluídos nas regras de rotas/roteamento. A aplicação do bloqueio de fronting de domínio começará em 22 de janeiro de 2024 para todos os domínios existentes. A aplicação pode levar até duas semanas para se propagar para todas as regiões.

Quando o Front Door bloqueia um pedido devido a uma incompatibilidade:

• O cliente recebe uma resposta de código de erro HTTP 421 Misdirected Request .
• O Azure Front Door registra o bloco nos logs de diagnóstico na propriedade Error Info com o valor SSLMismatchedSNI.

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

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 rápida e segura pela Web. Ele permite que você defina como seu tráfego da Web é roteado e otimizado em várias regiões e endpoints. Os recursos da Porta da Frente do Azure, como perfis da Porta da Frente e regras de roteamento, só são cobrados quando estão habilitados. No entanto, as políticas e regras do firewall de aplicativo Web (WAF) são cobradas independentemente de seu status. Mesmo que você desative uma política ou regra do WAF, ela ainda incorre em custos para você.

N.º

N.º

O AFD não suporta compressão dinâmica para conteúdos com mais de 8 MB. No entanto, se o conteúdo já tiver sido comprimido pela origem, o Front Door suporta o fornecimento de conteúdo estático comprimido com mais de 8 MB, desde que o pedido de intervalo seja suportado e a codificação de transferência em partes não esteja ativada.

N.º

Para obter informações sobre os registos e outras capacidades de diagnóstico, veja Monitorizar métricas e registos do 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 Hubs de Eventos ou logs do Azure Monitor. Para obter mais informações, consulte Diagnóstico da porta frontal do Azure.

Para acessar os logs de auditoria do Azure Front Door, você precisa visitar o portal. Selecione a sua Porta da Frente na página do menu e selecione no Registo 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 de seus hosts front-end.

Para saber como criar alertas para o Azure Front Door Standard e Premium, consulte Configurar alertas.

Próximos passos

• Saiba como criar um perfil do Azure Front Door .
• Saiba mais sobre a arquitetura do Azure Front Door.