Azure Front Door Perguntas Frequentes (FAQ)

Azure Front Door é um serviço baseado na cloud que entrega 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 dynamic site acceleration (DSA) para otimizar o desempenho da Web e failover em tempo quase real para garantir alta disponibilidade. Azure Front Door é um serviço totalmente gerido, por isso não precisa de se preocupar com escalabilidade ou manutenção.

Azure Front Door e Gateway de Aplicação do Azure são ambos balanceadores de carga para tráfego HTTP/HTTPS, mas têm âmbitos 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 trabalha com unidades de escala, clusters ou unidades de carimbo, enquanto o Gateway de Aplicação do Azure trabalha com VMs, contentores ou outros recursos na mesma unidade de escala.

Pode usar diferentes tipos de origens para Azure Front Door, tais como:

• Armazenamento (Azure Blob, Classic, sites estáticos)
• Serviço cloud
• Serviço de Aplicações
• Aplicativo Web estático
• API Management
• Gateway de Aplicação
• Endereço IP público
• Azure Spring Apps
• Container Instances
• Container Apps
• 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. Podes misturar backends de diferentes zonas, regiões ou até fora do Azure, desde que sejam acessíveis ao público.

Azure Front Door não está limitado a nenhuma região do Azure, mas opera globalmente. A única localização que escolhe ao criar uma Porta Principal é a localização do grupo de recursos, que determina onde os metadados do grupo de recursos estã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 a lista completa de pontos de presença (POPs) que fornecem balanceamento global de carga e entrega de conteúdo para Azure Front Door, veja Azure Front Door POP locations. Esta lista é atualizada regularmente à medida que novos POPs são adicionados ou removidos. Também pode usar a API do Azure Resource Manager para consultar programaticamente a lista atual de POPs.

Azure Front Door é um serviço que distribui a sua aplicação globalmente em várias regiões. Utiliza uma infraestrutura comum que todos os seus clientes partilham, mas pode personalizar o seu próprio perfil Front Door para configurar os requisitos específicos da sua aplicação. As configurações de outros clientes não podem afetar a configuração da porta frontal, que é isolada da deles.

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 ótimo das funcionalidades do Front Door, permita apenas 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 a origem no Azure Front Door, veja Proteger o tráfego para as origens do Azure Front Door.

Os tempos de propagação de configuração para uma única operação de criação, atualização, eliminação ou WAF para perfis Azure Front Door e CDN podem demorar até 15 minutos para maior segurança. Uma única operação de purga de cache é concluída em 10 minutos. Alterações consecutivas podem prolongar o tempo total de implementação para aproximadamente 30 minutos. Cada atualização de configuração, incluindo ajustes de conjuntos de regras, alterações de roteamento, atualizações de origem ou domínio e modificações de WAF, é tratada como uma operação global. Se enviar operações adicionais enquanto a primeira ainda estiver a propagar-se (dentro da sua janela de ~15 minutos), o sistema coloca-as em fila e só as inicia após a conclusão da operação anterior. Neste cenário, a primeira operação é concluída nos primeiros 15 minutos, e as alterações subsequentes são processadas na janela seguinte. Estão em curso melhorias na plataforma que irão reduzir ainda mais este tempo.

Enviar várias requisições de exclusão

Cada solicitação de limpeza pode incluir até 100 URLs (combinação de domínio e caminho). O primeiro lote é processado e faz efeito em aproximadamente 10 minutos.

Se tiver mais de 100 URLs para eliminar, deve esperar e verificar que o primeiro lote foi concluído antes de submeter o próximo lote. Se submeter um novo pedido de purga antes do lote anterior terminar, o pedido é rejeitado.

Exemplo: Limpar 256 URLs

1. Envie os primeiros 100 URLs na solicitação de limpeza inicial.
2. Espere aproximadamente 10 minutos e verifique se o primeiro lote foi concluído com sucesso.
3. Envie os próximos 101-200 URLs na segunda solicitação.
4. Espere aproximadamente 10 minutos para a segunda fornada terminar.
5. Envie os 201-256 URLs restantes na terceira solicitação.

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 certificado também são feitas de forma atómica, portanto, não há qualquer interrupção.

• Pode mover perfis Front Door Standard/Premium e CDN do Azure entre grupos de recursos ou subscrições sem qualquer tempo de inatividade. Para executar a mudança, siga estas instruções.
• O Azure Front Door (classic) não suporta a transferência entre grupos de recursos ou subscrições. Pode, em vez disso, migrar o perfil Azure Front Door (classic) para Standard/Premium e depois executar a mudança.
• Se associar uma política WAF ao Azure Front Door Standard ou Premium, a operação de mudança falha. Deve primeiro dissociar a política WAF, concluir a mudança e depois reassociar a apólice.

O Azure Front Door oferece muitos benefícios para as suas aplicações web, como a aceleração dinâmica do site (DSA), que melhora o desempenho e a experiência do utilizador dos seus sites. O Azure Front Door também gere o offloading TLS/SSL e o TLS de ponta a ponta, o que melhora a segurança e a encriptação do seu tráfego web. Além disso, o Azure Front Door oferece firewall para aplicações web, afinidade de sessão baseada em cookies, encaminhamento baseado em caminhos de URL, certificados gratuitos, gestão de múltiplos domínios e muito mais. Para saber mais sobre as funcionalidades e capacidades do Azure Front Door, consulte comparação de níveis.

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

O Azure Front Door suporta o protocolo HTTP/2 para ligações de clientes. 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.

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

Pode redirecionar componentes host, path e query string de uma URL com o Azure Front Door. Para aprender a configurar o redirecionamento de URLs, consulte Redirecionamento de URL.

Sim. Consulte a MatchedRulesSetName propriedade em Registos de Acesso.

Sim. Para mais informações, veja Microsoft resposta a ataques DDoS contra HTTP/2.

Não. O Azure Front Door não pode forçar o tráfego do cliente para um POP específico. Os pedidos são encaminhados para a localização de borda disponível mais próxima para garantir desempenho e fiabilidade. Se precisar de restringir o acesso por geografia, use as regras personalizadas do Firewall de Aplicações Web do Azure (WAF) com condições GeoMatch. Esta abordagem permite ou bloqueia pedidos com base no país/região do cliente, mas não redireciona esses clientes para um POP diferente noutro país/região. Por exemplo, se bloquear o país/região A, os pedidos de clientes do país/região A são bloqueados independentemente de qual POP os teria servido. Para mais detalhes, consulte Geo-filtragem no Azure WAF para Azure Front Door.

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, o Front Door substitui os valores existentes pelos seus.

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

Para usar o Azure Front Door Standard ou o Azure Front Door (clássico), precisa de um endereço IP público ou de um nome DNS publicamente resolvível. Este requisito permite que o Azure Front Door encaminhe o tráfego para os seus recursos de backend. Pode usar recursos do Azure como Application Gateways ou Azure Load Balancers para encaminhar tráfego para recursos numa rede virtual. Se usares o Azure Front Door Premium, podes usar o Private Link para te ligares às origens atrás de um balanceador de carga interno através de um endpoint privado. Para mais informações, consulte Origens seguras com Private Link.

Não. Para segurança, o Azure Front Door suporta apenas autenticação gerida baseada em identidade ao aceder a certificados no Key Vault. Para mais informações, consulte Usar identidades geridas em Azure Front Door.

Não. O Azure Front Door atualmente não suporta integração de identidade gerida com o Hubs de Eventos do Azure.

Não. O Azure Front Door atualmente não suporta páginas de erro personalizadas.

O Application Gateway behind Front Door é ú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 esvaziamento de conexões, que o Front Door 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 é recomendado. Embora possa funcionar, tem as seguintes desvantagens:

1. A aceleração da última milha de uma CDN funciona mantendo o fluxo da ligação com a origem e encontrando a rota ideal até à origem para obter os melhores resultados. Interligar duas CDNs normalmente anula alguns dos benefícios da aceleração do último trecho.
2. Os controlos de segurança são menos eficazes na segunda CDN. O controlo de acesso baseado em IP do cliente não funciona lá porque a segunda CDN identifica o nó de saída da primeira CDN como o IP do cliente. A carga útil de conteúdo continua a ser inspecionada.
3. Encadear duas CDNs aumenta a complexidade da resolução de problemas. Quando ocorre um problema, pode ser difícil determinar qual CDN o está a causar.

Para usar o Azure Front Door, deve ter um VIP público ou um nome DNS acessível publicamente. O Azure Front Door usa o IP público para encaminhar o tráfego para a sua origem. Um cenário comum é instalar um Balanceador de Carga do Azure atrás do Front Door. Também pode usar o Private Link com o Azure Front Door Premium para se ligar a um balanceador de carga interno. Para mais informações, consulte habilitar o Private Link com um balanceador de carga interno.

Azure Front Door e CDN do Azure são dois serviços que fornecem uma entrega web rápida e fiável para as suas aplicações. No entanto, não são compatíveis entre si, porque partilham a mesma rede de sites edge do Azure para entregar conteúdo aos seus utilizadores. Essa rede compartilhada causa conflitos entre suas políticas de roteamento e cache. Portanto, tem de escolher entre Azure Front Door ou CDN do Azure para a sua aplicação, dependendo dos seus requisitos de desempenho e segurança.

O facto de ambos os perfis/endpoints utilizarem o mesmo POP de periferia do Azure para processar os pedidos recebidos cria uma limitação que impede o aninhamento de um perfil/endpoint do Azure Front Door por trás de outro. Essa configuração causaria conflitos de roteamento e problemas de desempenho. Portanto, se precisares de usar múltiplos perfis/endpoints para as tuas aplicações, deves garantir que os teus perfis/endpoints do Azure Front Door não estão encadeados.

O Azure Front Door utiliza encaminhamento unicast para resolução de nomes e encaminha os pedidos para o ponto de presença (POP) ideal. A Unicast substituiu o método de encaminhamento Anycast que o Azure Front Door usava anteriormente.

Um pedido de resolução de nome para uma origem atrás do Azure Front Door chega ao endpoint do Traffic Manager do Front Door. Os perfis do Gestor de Tráfego da Front Door consomem inúmeros sinais de estado e disponibilidade dos PoPs em todo o mundo. Com base nestes sinais, o endereço IP unicast do PoP (Ponto de Presença) ótimo da Porta de Entrada é retornado. O pedido é então feito diretamente para o endereço IP devolvido, que segue a "arquitetura de encaminhamento" do Front Door para devolver a resposta ao utilizador ou aplicação.

O Azure Front Door utiliza três etiquetas de serviço para gerir o tráfego entre os seus clientes e as suas origens:

• A etiqueta de serviço AzureFrontDoor.Backend contém os endereços IP que o Front Door usa para aceder à sua origem. 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. Pode aplicar a etiqueta de serviço AzureFrontDoor.Frontend quando quiser controlar o tráfego de saída que pode ligar-se aos serviços atrás de Azure Front Door.
• A etiqueta de serviço AzureFrontDoor.FirstParty está reservada para um grupo selecionado de serviços Microsoft alojados no Azure Front Door.

Para obter mais informações sobre cenários de tags de serviço do Azure Front Door, consulte tags de serviço disponíveis. Para se manter informado e tomar as medidas apropriadas durante quaisquer alterações nos endereços IP, desenvolva automação para buscar regularmente os endereços IP mais recentes usando a API de descoberta de tags de serviço ou o arquivo JSON.

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 a sua origem tiver um balanceador de carga, como o Gateway de Aplicação do Azure, ou estiver alojada num PaaS que tenha um balanceador de carga, então o grupo de origem só tem uma origem. A sua origem cuida do failover e do balanceamento de carga entre origens que o Front Door não vê.

Por exemplo, se hospeda uma aplicação no Serviço de Aplicações do Azure, a forma como configura o Front Door depende de quantas instâncias de aplicação tem:

• Implantação de região única: crie um grupo de origem. Nesse grupo de origem, crie uma origem para a aplicação do App Service. Seu aplicativo do App Service pode ser escalado para vários trabalhadores, mas o Front Door considera apenas 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 em Azure Front Door.

Azure Front Door é um serviço que fornece entrega web rápida e fiável para as suas aplicações. Ele oferece recursos como cache, balanceamento de carga, segurança e roteamento. No entanto, deve estar atento a alguns tempos de espera 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. Pode encontrar a informação detalhada sobre estes tempos de espera e limites na documentação Azure Front Door.

A maioria dos conjuntos de regras atualiza as suas configurações em menos de 15 minutos. A regra aplica-se assim que a atualização terminar.

Azure Front Door tem um timeout de 5 segundos para receber cabeçalhos de um cliente. Se o cliente não enviar cabeçalhos dentro de 5 segundos após estabelecer uma ligação TCP/TLS para o Azure Front Door, a ligação é terminada. Não podes configurar este timeout.

Azure Front Door tem um timeout de 90 segundos para conexões HTTP persistentes. A ligação é terminada se o cliente não enviar dados durante 90 segundos, que é o timeout HTTP keep-alive 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 do Front Door, porque o Front Door precisa distinguir a rota (combinação de protocolo + host + caminho) para cada solicitação. Se tiver rotas duplicadas entre diferentes endpoints, o Azure Front Door não consegue processar os pedidos 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. Deve planear algum tempo de inatividade se quiser migrar os seus domínios para um endereço final diferente.

Azure Front Door Private Link é agnóstico em relação à região. Para a latência mais baixa, selecione a região Azure suportada mais próxima da sua origem quando ativar um endpoint Azure Front Door Private Link. Se a região da sua origem não for suportada na lista de regiões suportadas pelo Front Door Private Link, escolha a região mais próxima. O tráfego flui do cliente para o endpoint Azure Front Door Private Link na região suportada, depois atravessa a rede Microsoft backbone até à sua origem, mantendo a conectividade privada. Esta configuração introduz latência extra devido ao salto extra da rede entre regiões. Pode usar as estatísticas de latência de ida e volta da rede do Azure para determinar a latência extra devido à escolha da próxima região mais próxima. Quando uma nova região é suportada, pode seguir estas instruções para transferir gradualmente o tráfego para a nova região.

Azure Front Door é uma plataforma que distribui tráfego pelo mundo e pode escalar para satisfazer as exigências da sua aplicação. Utiliza a rede global edge da Microsoft para fornecer balanceamento global de carga, que permite mover toda a sua aplicação ou microserviços específicos para diferentes regiões ou clouds caso ocorra uma falha.

Para evitar erros ao entregar ficheiros grandes, certifique-se de que o seu servidor de origem inclui o Content-Range cabeçalho na resposta e que 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.

Os recursos do Azure Front Door (escalões Standard, Premium e clássico) ou do CDN do Azure Standard da Microsoft (clássico) criados após 8 de novembro de 2022 têm o bloqueio de domain fronting ativado. Em vez de bloquear um pedido com SNI e cabeçalhos de host incompatíveis, permitimos a discrepância se os dois domínios pertencerem à mesma subscrição e estiverem incluídos nas regras de rotas ou de roteamento. A imposição do bloqueio de domain fronting começou em 22 de janeiro de 2024.

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 .
• Azure Front Door regista o bloco nos registos de diagnóstico sob a propriedade Informação de Erro com o valor SSLMismatchedSNI.

Para mais informações sobre "domain fronting", consulte Securing our approach to domain fronting within Azure e Prohibiting domain fronting on Azure Front Door e CDN do Azure 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.

Podes escolher usar TLS 1.2 ou 1.3 com Azure Front Door. Para saber mais, leia o artigo Azure Front Door TLS de ponta a ponta.

A partir de 15 de agosto de 2025, a DigiCert fez a transição para uma nova plataforma de validação de controlo de domínio (DCV) de software open source (OSS), concebida para aumentar a transparência e a responsabilização nos processos de validação de domínios. O DigiCert já não suporta o fluxo de trabalho legado CNAME Delegation DCV para validação de controlo de domínio nos serviços Azure especificados. Mais informações

A substituição afeta os serviços que dependem da validação baseada em CNAME para emissão e renovação automatizadas de certificados, incluindo:

• Azure Front Door (clássico)
• CDN do Azure do Microsoft (clássico)

Azure Front Door (classic) e CDN do Azure da Microsoft (classic):

• A partir de 15 de agosto de 2025, já não há suporte para onboarding de novos domínios, criação de novos perfis ou certificados geridos pelo Azure.
• A partir de 14 de abril de 2026, os certificados geridos existentes são retirados de serviço. Todos os certificados geridos existentes são migrados pelo cliente ou pela equipa AFD para o padrão Azure Front Door ou premium. Por favor, utilize o Azure Front Door Standard ou Premium para o certificado gerido.

Na maioria dos casos, não é necessária qualquer ação. Depois de o seu perfil ser migrado, o Azure Front Door tenta automaticamente renovar o seu certificado gerido se este estiver a menos de 45 dias de expirar.

• Se o seu domínio estiver mapeado através de CNAME para o Azure Front Door e cumprir os requisitos dos registos CAA e do estado do domínio, o certificado é renovado automaticamente. O trabalho de rotação automática é executado a cada 6 a 8 horas e demora aproximadamente 24 a 48 horas a ser concluído. Se a rotação automática falhar, o estado de validação do domínio muda para 'Pendente de validação', e pode revalidar a propriedade do domínio para ativar manualmente a validação.
• Se o seu domínio não cumprir estes requisitos de validação ou tiver o HTTPS desativado, o estado do certificado muda para Pendente de revalidação, e deve revalidar a propriedade do domínio.

Para renovar o certificado sem esperar pela rotação automática, revalide manualmente a propriedade do domínio utilizando um dos seguintes métodos:

• Adicionar o registo de validação DNS necessário após o passo 3 para domínios pendentes de validação
• Ativar a validação manualmente usando PowerShell ou CLI do Azure (RefreshValidation).

Não podes desativar os recursos do Azure Front Door. Só podes apagá-los. Medidores variáveis como Data Transfer Out, Data Transfer In e Requests não são cobrados quando não há tráfego, mas a taxa base é cobrada mesmo que não haja tráfego. A taxa base é cobrada até que o perfil seja eliminado. Para Azure Front Door (clássico), as políticas e regras WAF são cobradas independentemente do seu estatuto. Mesmo que você desative uma política ou regra do WAF, ela ainda incorre em custos para você.

Não.

Não.

O Front Door não suporta compressão dinâmica para conteúdos superiores a 8 MB. No entanto, se a origem já comprimir o conteúdo, o Front Door suporta fornecer conteúdo estático comprimido superior a 8 MB, desde que o pedido de intervalo seja suportado e a codificação de transferência por blocos não esteja ativada.

Não.

Para mais informações sobre logs e outras capacidades de diagnóstico, consulte Monitorização 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. Em alternativa, pode enviar logs de diagnóstico para o Event Hubs ou para os logs do Azure Monitor. Para mais informações, consulte diagnósticos do Azure Front Door.

Para aceder aos registos de auditoria do Azure Front Door, precisa de visitar o portal. Selecione a sua Porta da Frente na página do menu e selecione Registo de Atividades. O Registo de Atividades fornece-lhe os registos das operações do seu Azure Front Door.

Pode configurar alertas para 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 Azure Front Door Standard e Premium, consulte configurar alertas.

Conteúdo relacionado

• Criar um perfil do Azure Front Door
• Arquitetura de roteamento do Azure Front Door