Azure Front Door perguntas frequentes (perguntas frequentes)

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. Azure Front Door é um serviço totalmente gerenciado, portanto, você não precisa se preocupar com dimensionamento ou manutenção.

Azure Front Door e 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 Azure Front Door, como:

• Armazenamento (Azure blob, 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 combinar back-ends de diferentes zonas, regiões ou até mesmo fora do Azure, desde que estejam publicamente acessíveis.

Azure Front Door não se limita a nenhuma região Azure, mas opera globalmente. A única localização que você escolhe ao criar uma Porta Principal é a localização 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 POPs (pontos de presença) 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 Azure Resource Manager para consultar a lista atual de POPs programaticamente.

Azure Front Door é um serviço que distribui seu aplicativo globalmente em várias regiões. Ele usa uma infraestrutura comum que todos os seus clientes compartilham, mas você pode personalizar 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 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, permita apenas 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, 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, exclusão ou WAF para perfis Azure Front Door e CDN podem levar até 15 minutos para maior segurança. Uma única operação de purga de cache é concluída em 10 minutos. Mudanças consecutivas podem estender o tempo total de implantaçã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 você enviar operações adicionais enquanto a primeira ainda está se propagando (dentro de sua janela de ~15 minutos), o sistema as coloca em fila e só começa após a conclusão da operação anterior. Nesse cenário, a primeira operação é concluída dentro dos primeiros 15 minutos, e as mudanças subsequentes são processadas na janela seguinte. 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 10 minutos.

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

Exemplo: Limpar 256 URLs

1. Envie as primeiras 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 as próximas 101 a 200 URLs na segunda solicitação.
4. Espere aproximadamente 10 minutos para que a segunda leva seja concluída.
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.

• Você pode mover perfis Front Door Standard/Premium e CDN do Azure entre grupos de recursos ou assinaturas sem nenhum tempo de inatividade. Para realizar a movimentação, siga estas instruções.
• Azure Front Door (classic) não suporta movimentação entre grupos de recursos ou assinaturas. Você pode, em vez disso, migrar o perfil do Azure Front Door (classic) para Standard/Premium e, em seguida, realizar a movimentação.
• Se você associar uma política WAF ao Azure Front Door Standard ou Premium, a operação de mudança falha. Você deve primeiro desassociar a política WAF, concluir a mudança e então reassociar a apólice.

Azure Front Door oferece muitos benefícios para suas aplicações web, como aceleração dinâmica de sites (DSA), que melhora o desempenho e a experiência do usuário dos seus sites. Azure Front Door também gerencia o offloading TLS/SSL e TLS de ponta a ponta, o que aprimora a segurança e a criptografia 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, roteamento baseado em caminhos de URL, certificados gratuitos, gerenciamento de múltiplos domínios e muito mais. Para saber mais sobre os recursos e as capacidades do Azure Front Door, consulte a comparação de camadas.

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

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, 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 host, caminho e cadeia de consulta de uma URL com o Azure Front Door. Para aprender como configurar o redirecionamento de URLs, veja Redirecionamento de URL.

Sim. Veja a MatchedRulesSetName propriedade em Registros de Acesso.

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

Não. Azure Front Door não pode forçar o tráfego do cliente para um POP específico. As solicitações são roteadas para o ponto de presença disponível mais próximo para otimizar o desempenho e garantir a confiabilidade. Se você precisar restringir o acesso por geografia, use regras personalizadas do Firewall de Aplicativo Web do Azure (WAF) com condições de GeoMatch. Essa abordagem permite ou bloqueia solicitações com base no país/região do cliente, mas não redireciona esses clientes para um POP diferente em outro país/região. Por exemplo, se você bloquear o país/região A, as solicitações de clientes no país/região A serão bloqueadas, independentemente de qual POP as teria servido. Para obter mais informações, consulte Filtragem geográfica no WAF do Azure para Azure Front Door.

Azure Front Door dá suporte aos 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 Azure Front Door Standard ou Azure Front Door (clássico), você precisa de um endereço IP público ou de um nome DNS publicamente resoluble. Esse requisito permite que o Azure Front Door redirecione o tráfego para seus recursos de backend. Você pode usar recursos do Azure, como Application Gateways ou Azure Load Balancers, para rotear o tráfego para recursos em uma rede virtual. Se você usar o Azure Front Door Premium, pode usar o Link Privado para conectar às origens atrás de um balanceador de carga interno por meio de um endpoint privado. Para obter mais informações, consulte Secure origins with Link Privado.

Não. Para segurança, Azure Front Door dá suporte apenas à autenticação baseada em identidade gerenciada ao acessar certificados no Key Vault. Para obter mais informações, consulte Use identidades gerenciadas no Azure Front Door.

Não. Azure Front Door atualmente não dá suporte à integração de identidade gerenciada com Hubs de Eventos do Azure.

Não. Azure Front Door atualmente não dá suporte a páginas de erro personalizadas.

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 é recomendado. Embora possa funcionar, apresenta as seguintes desvans:

1. A aceleração de última milha de uma CDN funciona mantendo a transmissão de conexão com a origem e encontrando o caminho ideal até a origem para alcançar os melhores resultados. Encadear duas CDNs normalmente anula alguns dos benefícios da aceleração de última milha.
2. Os controles de segurança são menos eficazes na segunda CDN. O controle 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 ainda é inspecionada.
3. Encadear duas CDNs aumenta a complexidade da solução de problemas. Quando ocorre um problema, pode ser difícil determinar qual CDN está causando o problema.

Para usar Azure Front Door, você deve ter um VIP público ou um nome DNS acessível publicamente. 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 Link Privado com Azure Front Door Premium para se conectar a um balanceador de carga interno. Para mais informações, consulte habilitar Link Privado com balanceador de carga interno.

Azure Front Door e 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, pois compartilham a mesma rede de pontos 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 Azure Front Door ou CDN do Azure para seu aplicativo, dependendo de seus requisitos de desempenho e segurança.

O fato de ambos os perfis/endpoints usarem o mesmo Azure Edge POP para lidar com requisições recebidas causa uma limitação que impede que você organize um perfil/endpoint do Azure Front Door atrás de outro. Essa configuração causaria conflitos de roteamento e problemas de desempenho. Portanto, se você precisar usar múltiplos perfis/endpoints para suas aplicações, deve garantir que seus perfis/endpoints do Azure Front Door não estejam encadeados.

Azure Front Door usa roteamento unicast para resolução de nomes e direciona solicitações para o ponto ótimo de presença (POP). O Unicast substituiu o método de roteamento Anycast que o Azure Front Door usava anteriormente.

Uma solicitação de resolução de nomes para uma origem por trás do Azure Front Door chega ao ponto de extremidade do Gerenciador de Tráfego do Front Door. Os perfis do Gerenciador de Tráfego do Front Door consomem muitos sinais de integridade e disponibilidade dos PoPs em todo o mundo. A partir desses sinais, o endereço IP unicast do PoP ideal do Front Door é retornado. Em seguida, a solicitação é feita diretamente para o endereço IP retornado, que segue a arquitetura de roteamento do Front Door para retornar a resposta ao usuário ou aplicativo.

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 atrás do Azure Front Door.
• A marca de serviço AzureFrontDoor.FirstParty é reservada para um grupo seleto de serviços Microsoft hospedados no Azure Front Door.

Para obter mais informações sobre os 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 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 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, como configurar o 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 Origins e grupos de origem no Azure Front Door.

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

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

Azure Front Door tem um timeout de 5 segundos para receber cabeçalhos de um cliente. Se o cliente não enviar cabeçalhos em até 5 segundos após estabelecer uma conexão TCP/TLS para o Azure Front Door, a conexão é encerrada. Você não pode configurar esse timeout.

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 keep-alive HTTP para 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.

Azure Front Door Link Privado é independente de região. Para a menor latência, selecione a região Azure suportada mais próxima da sua origem ao ativar um endpoint Azure Front Door Link Privado. Se a região de sua origem não tiver suporte na lista de regiões com suporte do Front Door Link Privado, escolha a próxima região mais próxima. O tráfego flui do cliente para o ponto de extremidade do Azure Front Door Link Privado na região suportada e, em seguida, percorre a rede de backbone da Microsoft até a sua origem, mantendo a conectividade privada. Essa configuração introduz latência extra devido ao salto extra de rede entre regiões. Você 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, você pode seguir essas instruções para transferir gradualmente o tráfego para a nova regiã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 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 nuvens caso ocorra uma falha.

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

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

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.
• 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 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.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, o DigiCert passou para uma nova plataforma de DCV (validação de controle de domínio) de software livre (OSS) projetada para aprimorar a transparência e a responsabilidade nos processos de validação de domínio. O DigiCert não suporta mais o fluxo de trabalho legado CNAME Delegation DCV para validação de controle de domínio nos serviços 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 de Microsoft (clássico)

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

• A partir de 15 de agosto de 2025, não há mais suporte para onboarding de novos domínios, criação de novos perfis ou certificados gerenciados pelo Azure.
• A partir de 14 de abril de 2026, os certificados gerenciados existentes são desativados. Todos os certificados gerenciados existentes são migrados pelo cliente ou pela equipe da AFD para o padrão Azure Front Door ou premium. Use Azure Front Door Standard ou Premium para certificado gerenciado.

Na maioria dos casos, nenhuma ação é necessária. Depois que seu perfil for migrado, o Azure Front Door tentará automaticamente renovar seu certificado gerenciado se ele estiver a até 45 dias da expiração.

• Se o seu domínio estiver mapeado por CNAME para o Azure Front Door e atender aos requisitos do registro CAA e do status do domínio, o certificado será renovado automaticamente. O trabalho de rotação automática roda a cada 6 a 8 horas e leva aproximadamente de 24 a 48 horas para ser concluído. Se a rotação automática falhar, o estado de validação do domínio muda para 'Validação pendente', e você pode revalidar a propriedade do domínio para acionar manualmente a validação.
• Se seu domínio não atender a esses requisitos de validação ou tiver o HTTPS desativado, o estado do certificado muda para Pendente de revalidação, e você 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 usando um dos seguintes métodos:

• Adicionando o registro de validação DNS necessário para domínios pendentes de validação após a etapa 3
• Acionando validação manualmente usando PowerShell ou CLI do Azure (RefreshValidation).

Você não pode desativar os recursos do Azure Front Door. Você só pode deletá-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 sem tráfego. A taxa base é cobrada até que o perfil seja excluído. Para Azure Front Door (clássico), as políticas e regras 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 Front Door não suporta compressão dinâmica para conteúdo superior a 8 MB. No entanto, se a origem já comprime o conteúdo, o Front Door suporta servir conteúdo comprimido estático acima de 8 MB, desde que a requisição de alcance seja suportada e a codificação de transferência em blocos não esteja ativada.

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. Alternativamente, você pode enviar logs de diagnóstico para Event Hubs ou logs do Azure Monitor. Para obter mais informações, consulte Azure Front Door diagnostics.

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

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

Para saber como criar alertas para Azure Front Door Standard e Premium, consulte configure alerts.

Conteúdo relacionado

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