A while ago I created a sample that demonstrated some frontdoor capabilities but I never got around to writing about it until now.
In my sample I focused on closest-region, automatic failover and SSL termination benefits but Frontdoor actually offers much more.
What is Azure Frontdoor
First of all a summary of what it offers:
Azure Frontdoor is a scalable and secure entry point for your global application.
In a nutshell it provides:
- Request acceleration via anycast and use of the private global network within Azure to route traffic between datacenters
- Load balancing across Azure regions to provide automatic failover
- SSL offloading at over 130 global endpoints
- Central WAF to protect against DDoS and other malicious attacks
How does it work
When setting up Azure Frontdoor you specify one or multiple backend pools behind it with one or multiple servers each.
Users then have a single endpoint (frontdoor) that automatically directs them to the closest pool without them noticing.
Azure figures this out automatically by finding the closest entrypoint (PoP) to the user location and then routing the traffic from there to the closest datacenter based on your backend pool definitions.
This automatically gives the best performance for your global application as your requests always travel the shortest distance.
As I demonstrated in the sample on github a connection from frontdoor can also be much faster than without it. Especially if the closest region is down and the traffic needs to be routed further.
In the (extreme) example I gave, traffic routed from Europe to USA (because the European backend is down) is twice as fast (250ms vs 500ms) when compared to regular internet traffic.
This is both thanks to SSL offloading and the private network that exists between all Azure datacenters.
While Microsoft doesn’t give any guarantees for their private network speeds it is pretty much consistently faster than routing across the puplic internet. Couple that with SSL offloading at the edge (your SSL connection is terminated at the closest PoP and a hot SSL connection that is already established between the PoP and backend pool is reused; saving a lot of roundtrip time) this speeds up traffic.
When building a global application the automatic health probes you can setup allow automatic failover incase any region is down without you having to do anything (your application will need to be built in such a way that it can handle traffic hitting any global backend - e.g. by using services such as Cosmos DB as a globally replicated data store).
Finally the WAF can be used to protect your application at the edge. DDoS and other attacks can be fend off automatically. (Note that you still should secure all your backend endpoints e.g. yb placing them in a VNET and prevent internet access. Azure Frontdoor adds just another layer of protection).
There are now multiple Azure services that offer similar features: Frontdoor, Application Gateway, Traffic Manager and Load Balancer.
As always they each have their specific usecases (that sometimes overlap):
- Frontdoor is intended for global load balancer for HTTP(S) traffic - use if your application needs to failover across many regions that can always serve the same content
- Traffic Manager is also a global load balancer for your non-HTTP(S) traffic - use if DNS routing is enough and your application is deployed globally
- Application Gateway - use to balance requests in a single region (e.g. your product has multiple frontends in the same region that can benefit from loadbalancing)
- Load Balancer - use to balance backend requests in a single region (e.g. your frontend is deployed via a CDN and you have geo redundant backends in a region)
Overall the chart from the documentation helps a lot in deciding which service is suited best:
If you want to read more about Azure Frontdoor I recommend you check out the documentation.