Combining Azure Traffic Manager, CloudFlare & Azure App Service for Geographic Scale!

Introduction

For today’s post, let’s take a look at an architecture example where you want to provide a geographic deployment of your webapp by using a cloudbased WAF (like Cloudflare, or Akamai, …).

 

High Level Setup

So what will we be setting up & testing today?

The user will receive a url that is powered by “Azure Traffic Manager”. That will have three endpoints ; one in Europe, one in the US and one in Asia. These endpoints will be powered Cloudflare and back by an Azure Webapp.  You’re question will probably be ; “Why use that sequence?” Because the Traffic Manager is DNS based and will do a “basic” HTTP check. If you would setup the Traffic Manager behind Cloudflare/Akamai/…, then you would see the source IPs of that service. Thus you would be unable to route the clients to the nearest location.

 

 

Proof-of-Concept Setup

Let’s get ready to RUMBLE!!!! 😉 We’ll first start of by creating the resources in Azure;

Basically three webapps, where each is located in a different region, and a traffic manager to serve as the primary ingestion point. For this demo, I’ve used the wordpress deployment from our marketplace and finished it off with a very basic “next-next-finish” deployment. Though I did change one thing, the website title reflects the location of the webapp.

Next up, I’ll create the DNS entries on Cloudflare and point them to the Azure Webapp ;

Once that has been done, I’ll be adding those names as custom domains to the webapps.

Why is that important? If you don’t do that, then the webapp will ignore the request and return a 404 (Page not Found). All requests are hostname based as the IPs can be shared across multiple webapps.

Let’s do a quick test… Whiiii! That went smooth!

Now we are going to add the cloudflare dns entries as endpoints to our Traffic Manager.

And here we can see that they have been added, where the last one was still in a “checking endpoint”-state ;

In regards to the traffic manager configuration; Here we’ll be choosing the “Performance” routing method. What does that one do? It will check the latency between the user and the endpoints. Afterwards it will redirect the user to the nearest location.

Do you recall what I said about the custom domain names and the domain name based checks? Let’s not forget to add the dns entry of our traffic manager!

Now we are all ready to go!

 

Testing

I’ll be using “webpagetest.org” to test the results from different regions ;

  • Test from “Dulles” in the US ;
  • Test from “Tokyo” in Japan (Asia) ;
  • Test from “Dublin” in Ireland (EU) ;

Here we can see that the client was served by a local service! So our setup worked nicely.

 

Closing Thoughts

  • Bear in mind that each url within the chain is still individually accessible. So you probably want to harden up the link between Cloudflare and the Webapp.
  • As mentioned, use the Traffic Manager as your first ingestion method. As otherwise you’ll need to be very creative yourself in terms of traffic routing. And trust me on this one, that isn’t going to end well.
  • Also be aware that Azure can provide WAF, CDN & DDOS protections too. Though if you want to rely on Cloudflare / Akamai / …, you can do this by using the above pattern.

 

Enjoy!

4 thoughts on “Combining Azure Traffic Manager, CloudFlare & Azure App Service for Geographic Scale!

  1. Hi, This is a great article. Thank you for the write up. I have a question regarding how CloudFlare is configured. I have a scenario where i too need to configure CloudFlare for my Azure App Service apps which has a Traffic Manager in front. I have to decide on if i need to setup CloudFlare in front of the Traffic Manager or should I configure CloudFlare behind the Traffic Manager (like you have described in your article). What are the pros and cons of these 2 approaches?

    1. If I’m correct, if you put Traffic Manager behind Cloudflare, then you will have less control over the geographic distribution. Because the TM will see the ip traffic coming from CF, and then deciding on a region based on that. That’s why I did my setup with TM in front of CF. Though do test both setups out and see what works best. Then you’re sure what happens… 😉

  2. One problem with this setup would be using certificates. At least in Azure CDN you would not be allowed to apply http://www.contoso.com as a custom domain to multiple CDN endpoints, even when using cdnverify.

    The cert issued by Azure CDN (verizon) is not wildcard, so the endpoint would identity as e.g. www-eu.contoso.com. (a custom wildcard cert might fix this though, but that is not always the desired solution).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.