Você está configurando o Azure Front Door (Standard/Premium) com duas origens: Leste dos EUA e Europa Ocidental. Você quer que ambas as origens estejam ativas, que as solicitações dos clientes prefiram a origem de menor latência e que as origens não íntegras sejam automaticamente removidas da rotação. Cada origem expõe um endpoint HTTPS /healthz que retorna 200 quando íntegro. Como você deve configurar o grupo de origem?

A opção correta atende a todos os requisitos: ambas as origens ativas, menor latência e remoção automática de origens não íntegras. Colocar ambas as origens em um único grupo de origem permite que o Azure Front Door as gerencie em conjunto. A health probe HTTPS GET para /healthz a cada 30 segundos, considerando 200-399 como íntegro, garante que o Front Door monitore a saúde das origens e as remova da rotação se estiverem não íntegras. O balanceamento de carga de Latência com pesos iguais direciona o tráfego para a origem com menor latência para o cliente, enquanto a desabilitação da afinidade de sessão permite que o Front Door distribua as requisições de forma mais eficiente. As opções incorretas falham em vários aspectos: Criar dois grupos de origem com failover baseado em prioridade não atende ao requisito de ter ambas as origens ativas simultaneamente para balanceamento de carga de latência. Desabilitar health probes impede a detecção de origens não íntegras. Usar uma probe HTTP para a raiz pode não ser tão preciso quanto uma probe dedicada /healthz, e um balanceamento de carga ponderado com peso 0 para uma origem a desativaria. Colocar cada origem em um grupo separado e confiar na seleção manual da regra de roteamento não automatiza a seleção da origem de menor latência nem a remoção de origens não íntegras. Não configurar health probes é um risco de disponibilidade.