I have question on traffic manager geographic routing with nested weighted profile

Traffic Manager geographic routing always chooses the endpoint based on the geographic mapping in the parent profile, not on where the child endpoints actually are or which region they “should” serve.

Key points for this scenario:

1. How geographic + nested weighted works
   • The parent profile is set to Geographic.
   • For each DNS query, Traffic Manager:
     1. Looks at the source IP of the DNS resolver (not the user’s VM or browser) to infer the geographic region.
     2. Finds the first matching geographic mapping on an endpoint in the parent profile (state → country/region → regional grouping → World).
     3. Returns that endpoint. If that endpoint is a nested profile, the child profile’s routing method (Weighted in this case) is applied only inside that child profile.
   • A geographic region can be mapped to only one endpoint in a profile using Geographic routing. There is no automatic failover to another endpoint for that region.
2. Why East US users may be going to West
   • If the North America / US / East states mapping on the parent profile is not correctly assigned, or if the North America / US / West states mapping is broader (for example mapped at a higher level like “United States” or “North America”), the lookup may match the West mapping first.
   • Traffic Manager uses an internal IP-to-region map based on the DNS resolver’s IP. If the user’s DNS resolver is physically or logically located in a “West” state/region (or in a region mapped to the West endpoint), the query will be routed to the West endpoint even if the user is in East US.
3. What to check in the parent geographic profile
   • Ensure that:
     • The East US states are mapped only to the nested East profile (or to the nested profile that should serve East), and
     • The West US states are mapped only to the nested West profile.
   • Verify that no endpoint in the parent profile has a broader region (for example, “United States” or “North America”) that would “catch” both East and West queries before the more specific state mappings.
   • Confirm that each geographic region (state, country, regional grouping, World) is assigned to exactly one endpoint in the parent profile.
4. Whether to use Performance instead of Geographic
   • Geographic routing is for enforcing a geo-fence: “users from region X must go to endpoint Y,” regardless of latency.
   • Performance routing is for sending users to the lowest-latency endpoint, which often but not always corresponds to geographic proximity.
   • If the requirement is: “Users from East US must always be served by the East endpoint,” then Geographic is correct, but the geo-mapping must be fixed.
   • If the requirement is: “Users should go to whichever endpoint is fastest, typically in their region,” then a Performance profile (possibly nested under a Geographic parent for higher-level geo separation) is more appropriate.
5. Recommended pattern
   • Keep the parent profile as Geographic with endpoints that are nested profiles (as already done), each nested profile containing multiple endpoints (for example, multiple East-region endpoints with Weighted or Performance routing inside).
   • Carefully configure Geo-mapping on the parent profile so that:
     • East US states → East nested profile
     • West US states → West nested profile
     • UK → UK nested profile
   • Avoid assigning overlapping or broader regions (like “North America” or “United States”) to the West endpoint if East should be separate.

This configuration ensures that:

• Geographic routing in the parent profile sends queries from each state/region to the correct nested profile.
• The nested Weighted profile then distributes traffic only among the endpoints for that region.

References:

• Traffic Manager routing methods
• Traffic Manager Frequently Asked Questions (FAQ)
• Traffic Manager endpoint monitoring
• Tutorial: Configure the geographic traffic routing method using Traffic Manager