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

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
• API Management
• Application Gateway
• Endereço IP público
• Aplicativos Spring do Azure
• 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.

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.

Os tempos de propagação de configuração para uma única operação de criação, atualização, exclusão, WAF e limpeza de cache para perfis do Azure Front Door e CDN podem levar até 45 minutos para maior segurança. As alterações consecutivas podem estender o tempo total de implantação para aproximadamente 90 minutos. Cada atualização de configuração, incluindo ajustes de conjunto de regras, alterações de roteamento, atualizações de origem ou domínio e modificações de WAF etc., é tratada como uma operação global. Se operações adicionais forem enviadas enquanto a primeira ainda estiver se propagando (dentro de sua janela de aproximadamente 45 minutos), serão enfileiradas e começarão somente após a conclusão da operação anterior. Nesse cenário, a primeira operação é concluída nos 45 minutos iniciais e as alterações subsequentes são processadas na janela a seguir. Aprimoramentos contínuos da plataforma estão em andamento, o que reduzirá ainda mais esse tempo.

Enviar várias solicitações de purga

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

Se você tiver mais de 100 URLs para limpar, deverá aguardar e verificar se o primeiro lote será concluído (aproximadamente 45 minutos) antes de enviar o próximo lote. Se você enviar uma nova solicitação de limpeza antes da conclusão do lote anterior, a solicitação será rejeitada.

Exemplo: Limpar 256 URLs

1. Envie as primeiras 100 URLs na solicitação de limpeza inicial.
2. Aguarde aproximadamente 45 minutos e verifique se o primeiro lote foi concluído com êxito.
3. Envie as próximas 101 a 200 URLs na segunda solicitação.
4. Aguarde aproximadamente 45 minutos para que o segundo lote seja concluído.
5. Envie as URLs 201-256 restantes na terceira solicitação.

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 de forma atômica, garantindo assim que não haja tempo de inatividade.

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

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 é compatível com 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.

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.

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.

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.

Para usar o Azure Front Door Standard ou a camada (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.

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 da última milha da CDN utiliza a manutenção do fluxo de conexão com a origem e a busca do caminho ideal para a origem para 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 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. O conteúdo ainda será inspecionado.
3. Muitas organizações não conseguem lidar com a complexidade da solução de problemas de duas CDNs encadeadas e, quando ocorre um problema, fica difícil descobrir qual CDN está com 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 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/pontos de extremidade usarem o mesmo POP de borda do Azure para lidar com solicitações recebidas causa uma limitação que impede você de aninhar um perfil/ponto de extremidade 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/pontos de extremidade do Azure Front Door não estejam encadeados, caso precise usar vários perfis/pontos de extremidade para seus aplicativos.

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. Para se manter informado e tomar as medidas adequadas durante quaisquer alterações nos endereços IP, desenvolva uma automação para buscar regularmente os endereços IP mais recentes usando a API de Descoberta de Marcas de Serviço ou o arquivo JSON.

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.

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 as 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. Para se manter informado e tomar as medidas adequadas durante quaisquer alterações nos endereços IP, desenvolva uma automação para buscar regularmente os endereços IP mais recentes usando a API de Descoberta de Marcas 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 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 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 Classic) 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 TLS 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.

Em 15 de agosto de 2025, a DigiCert descontinuará o suporte para o fluxo de trabalho herdado de DCV por Delegação CNAME. A DigiCert está migrando para uma nova plataforma de validação de controle de domínio (DCV) de software de código aberto (OSS) projetada para aprimorar a transparência e a responsabilidade nos processos de validação de domínio. A DigiCert não dará mais suporte ao fluxo de trabalho herdado de DCV por Delegação CNAME para validação de controle de domínio nos serviços do Azure especificados. Saiba mais

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 da Microsoft (clássica)

Azure Front Door (clássico) e CDN do Azure da Microsoft (clássico):

• Não haverá mais suporte para nova integração de domínio e criação de novo perfil.
• Não dará mais suporte a certificados gerenciados pelo Azure.
• Os scripts de automação para essas ações começarão a falhar.
• A transição para certificados gerenciados em domínios existentes não será mais permitida.
• Renovações emergentes de certificados gerenciados não serão possíveis devido à substituição da validação baseada em CNAME.

Os certificados gerenciados existentes serão renovados automaticamente antes de 15 de agosto de 2025 e permanecerão válidos até 14 de abril de 2026. No entanto, qualquer renovação necessária após 15 de agosto de 2025 não será possível.

Azure Front Door (clássico)

• Se você quiser criar novos domínios ou perfis ou usar certificados gerenciados do Azure, migre para o Azure Front Door Standard ou Premium antes de 15 de agosto de 2025.
• Se você já estiver usando certificados gerenciados do Azure em domínios existentes, poderá mover para ByOC (Traga Seu Próprio Certificado) ou migrar para o Azure Front Door Standard ou Premium antes de 15 de agosto de 2025.

CDN do Azure da Microsoft (clássica)

• Se você quiser criar novos domínios ou perfis ou usar certificados gerenciados do Azure, migre para o Azure Front Door Standard ou Premium antes de 15 de agosto de 2025.
• Se você já estiver usando certificados gerenciados do Azure em domínios existentes, poderá mover para ByOC (Traga Seu Próprio Certificado) ou migrar para o Azure Front Door Standard ou Premium antes de 15 de agosto de 2025.

Os recursos do Azure Front Door não podem ser desabilitados. Eles só podem ser excluídos. Medidores variáveis como Transferência de Dados de Saída, Transferência de Dados de Entrada e Solicitações 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 será cobrada até que o perfil seja excluído. Para o AFD Clássico, as políticas e regras do WAF são cobradas independentemente do 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.

Conteúdo relacionado

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