Slow requests from the Newark Cloudflare datacenter to services in Azure Canada Central when using "Microsoft network routing"

Question

Hello,

Our services are protected by Cloudflare and there seem to be a much higher latency than expected when connecting to any of our service in the Canada Central region from the Cloudflare datacenter in Newark. An average of 800ms instead of about 60ms. This is new as of a few weeks ago.

We have determined that switching from "Microsoft routing" to "Internet routing" on storage accounts greatly helps the situation but it does not seem that we can do the same on our app services.

Cloudflare support is not currently offering anything more than upselling us to a plan that would let us control the routing a bit more on their side.

Considering this seems specific to Microsoft routing, is there any way to have this slowness looked at at Microsoft? Or any configuration we have control of that might help our case?

Thanks!

Answer 1

Hello Steven Deblois

When Microsoft routing is used, traffic is sent through Microsoft’s private WAN, which includes the Microsoft Edge, backbone, and regional infrastructure. In contrast, Internet routing keeps traffic on the public internet and chooses the shortest BGP path.

If traffic comes from Cloudflare, Microsoft routing often directs it through less optimal Microsoft POPs, requiring cross-continent backbone transfers. This results in high RTT (800ms+), even between regions that are close to each other.

This issue is well known for Azure Storage, which is why Microsoft allows users to select a routing preference for that service.

Unfortunately, Azure App Service does not expose a routing preference because App Service is always Microsoft‑routed preference So there is no supported configuration to replicate the “Internet routing” behavior you used on Storage Accounts This is by design—not a misconfiguration on your side.

Here's an effective workaround that will help address this issue.

Putting Azure Front Door (Standard/Premium) or Azure CDN (Microsoft) in front of App Service Terminates traffic at Microsoft’s edge close to Cloudflare and Avoids long-haul Microsoft backbone hops which Dramatically reduces latency in multi‑CDN scenarios This is the Microsoft‑recommended architectural solution when fronted by third‑party CDNs.

---

I hope this has been helpful!

If the above is unclear or you are unsure about something, please add a comment below.

Please click Accept Answer and upvote if the above was helpful.

Answer 2

Hello @ Steven Deblois,

Thank you for reaching out to Microsoft Q&A.

Thanks for reaching out with all the details. it's really helpful that you've already tested Internet routing on your storage accounts and seen the latency drop from ~800 ms down to the expected ~60 ms range. That confirms the issue is tied to the default Microsoft Global Network routing path from Cloudflare's Newark edge into Canada Central.

Suggested solution with AFD:

A solid option here is to put Azure Front Door (Standard or Premium tier) in front of your App Service. Front Door uses a global anycast network, so traffic from Cloudflare hits the nearest Front Door POP first and is then intelligently routed to your origin in Canada Central. While it doesn't let you set "Internet routing" on the frontend like a public IP does, its optimized paths, split TCP, and latency-based routing often deliver much better end-to-end performance than a direct App Service endpoint.

Quick setup steps:

1. Create an Azure Front Door Standard or Premium profile in the portal.
2. Add your App Service as an origin (select App Service type, use the .azurewebsites.net hostname, and enable forwarding the host header or set your custom domain).
3. Create an origin group and a routing rule linking your frontend domain to the origin.
4. Update your Cloudflare origin to point to the Front Door frontend hostname (or your custom domain via CNAME).

Reference :
Azure Front Door overview

Add an App Service as an origin in Azure Front Door

Traffic routing methods to origins in Azure Front Door

If the answer is helpful, please click "Accept Answer" and "Upvote" it. If you have extra questions about this answer, please click "Comment".

Answer 3

Thank you for both of your detailed responses!

I understand the underlying issue better now but adding Azure Front Door simply to solve a latency issue seems quite pricy and redundant compared to Cloudlfare's offer. We will take all of this into consideration and choose the next best step for us.

Thanks!

Answer 4

For Azure Storage, switching from Microsoft network routing to Internet routing is supported and can reduce latency in some network paths, as you observed. This is configured via the storage account’s network routing preference, which lets traffic either:

• Use the Microsoft global network (default, optimized for low-latency path selection and reliability), or
• Minimize traversal on the Microsoft global network by handing off to the transit ISP earlier to lower networking costs.

However, this routing preference feature is specific to Azure Storage public endpoints. The provided information does not describe an equivalent per‑service routing preference for Azure App Service, so the same configuration change cannot be applied directly to App Service.

Given that the issue appears only when using Microsoft network routing and only from a specific Cloudflare POP (Newark) toward Canada Central, this is likely a path or peering issue within or into the Microsoft global network rather than something that can be tuned from the App Service resource itself.

The recommended next steps are:

1. Collect detailed network measurements (latency, traceroutes from Cloudflare Newark toward the Canada Central endpoints, and from a few other locations for comparison) to clearly isolate the problem path.
2. Once the problem is isolated to the Azure side (for example, unexpected detours or high latency inside the Microsoft network), open a support ticket with Azure Support so the networking team can investigate the routing and peering behavior for that path.
3. If internal troubleshooting reaches a limit, escalate by sharing your test results and traces with Azure Support as documented, so they can validate and adjust routing if needed.

There is no documented customer‑controlled setting on App Service equivalent to Storage’s routing preference that would change how Microsoft’s backbone carries traffic from Cloudflare to Canada Central. Investigation and remediation would therefore require Azure Support engagement once the issue is well isolated.

---

References:

• Network routing preference for Azure Storage
• Troubleshoot performance in Azure storage accounts
• Troubleshoot network performance
• Troubleshooting network performance