Vous configurez Azure Front Door (Standard/Premium) avec deux origines : USA Est et Europe Ouest. Vous souhaitez que les deux origines soient actives, que les requêtes client préfèrent l'origine avec la latence la plus faible et que les origines défectueuses soient automatiquement retirées de la rotation. Chaque origine expose un point de terminaison HTTPS /healthz qui renvoie 200 lorsqu'elle est saine. Comment devez-vous configurer le groupe d'origines ?

La bonne approche consiste à placer les deux origines dans un seul groupe d'origines avec une sonde d'intégrité HTTPS GET vers /healthz. Cela permet à Front Door de surveiller la santé de chaque origine et de les retirer automatiquement de la rotation si elles deviennent défectueuses, répondant ainsi à l'exigence de résilience. L'équilibrage de charge basé sur la latence avec des poids égaux garantit que les requêtes sont dirigées vers l'origine la plus proche et la plus rapide, tout en gardant les deux actives. Désactiver l'affinité de session est approprié car il n'est pas spécifié comme une exigence et peut interférer avec la distribution du trafic basée sur la latence. Les autres options sont incorrectes car : Créer deux groupes d'origines avec basculement par priorité et désactiver les sondes d'intégrité ne permet pas la distribution du trafic basée sur la latence ni la détection automatique des pannes. Utiliser une sonde HTTP vers la racine (/) n'est pas aussi précis que /healthz pour vérifier la santé de l'application, et un poids de 0 pour l'Europe Ouest l'empêcherait de recevoir du trafic. Placer chaque origine dans un groupe distinct et se fier à la sélection manuelle des règles de routage ne permet pas l'équilibrage de charge automatique basé sur la latence ni la détection des pannes.