Azure Front Door VS Azure Traffic Manager VS Azure Application Gateway VS Azure Load Balancer VS Content Delivery Network (CDN)

• Cloud native integrated
• Enables real-time hyperscale for single domain microservice apps where DNS traffic management cannot
• Provides applications with premium edge performance acceleration and caching via Microsoft’s unique global WAN
• Customers get a single pane of glass for service orchestration  and global traffic optics.
  

Main Feature:

• Accelerate application performance: Front Door ensures that your end users promptly connect to the nearest Front Door POP (Point of Presence)
• Increase application availability with smart health probes
• URL-based routing: Route Matching
• Configure Azure Front Door Service to either direct each web site to its own backend pool or have various web sites directed to the same backend pool
• Cookie-based session affinity
• (SSL) termination
• APP layer security
• Support  IPv6 and HTTP/2
  
• Global LB with HTTPS as recommended traffic
  

Note: It can be used with On-Prem Server (Example Web server hosted on your local environment)

Last Update: 10/10/2020

First of All Let’s understand each service:

Azure Front Door: Microsoft Azure Front Door (AFD) is a service that offers a single global entry point for customers accessing web apps, APIs, content and cloud services.    Through a single pane of glass and global infrastructure, AFD enables Azure customers to build, manage and secure their global applications and content. In other words Azure Front Door Is a global load balancing, but it is doing more by enhancing performance

Application Gateway: Application Gateway uses Azure Load Balancer at the transport level and then applies the routing rules to support layer-7 ( HTTP) load balancing.
 
Application Gateway currently supports the following:
1- HTTP load- balancing
2- SSL termination
3- Cookie based session affinity

The primary use cases for Application Gateway are :

1. If your application requires session affinity as an example the clients want to reach same backend virtual machine.
2. If your web servers do not want to handle the SSL overhead and you require the manage the SSL termination at the gateway.
3. If your application requires multiple HTTP request on the same TCP connection to be load balance on the different backend virtual machines
   
4. Regional LB with HTTPS as recommended traffic
   

 

Connectivity Options

• VMs in same VNet
• VMs across connected VNets
• Cloud services
• Hybrid connectivity to on premises VMs
• External servers
  

Azure Traffic Manager: Load Balancer for geographically distributed Datacenters. Azure Traffic Manager uses DNS to redirect requests to an appropriate geographical location endpoint. Traffic Manager does not see the traffic passing between the client and the service. It simply redirects the request based on most appropriate endpoints

Use case: load between two endpoints where your first endpoint is in Azure and second endpoint placed  in on-premise datacenter.

Global LB with Non-HTTPS as recommended traffic
 
Content Delivery Network (CDN): A content delivery network (CDN) is a system of distributed servers (network) that deliver pages and other Web content to a user, based on the geographic locations of the user, the origin of the webpage and the content delivery server.
Mechanism: Servers nearest to the website visitor respond to the request. The content delivery network copies the pages of a website to a network of servers that are dispersed at geographically different locations, caching the contents of the page. When a user requests a webpage that is part of a content delivery network, the CDN will redirect the request from the originating site's server to a server in the CDN that is closest to the user and deliver the cached content. CDNs will also communicate with the originating server to deliver any content that has not been previously cached

---

You can use Azure Traffic Manager with Azure CDN to load balance among multiple CDN endpoints for failover, geo-load balancing, and other scenarios. In a typical failover scenario, all client requests are first directed to the primary CDN profile; if the profile is not available, requests are then passed to the secondary CDN profile until your primary CDN profile is back online. Using Azure Traffic Manager in this way ensures your web application is always available
 
 
Azure Load Balancer: Azure LB is similar to Windows Server Load balancer Feature, but in a more classical sense as it can be used balancing load for VMs in the same way we were using traditional load balancers with our on-premise servers. Now since Azure load balancer is designed for cloud applications it can also be used to balance load to containers and PaaS applications along with VMs.

Global LB with Non-HTTPS as recommended traffic

Azure Load Balancer can be used in two configuration modes:

• External — Public load balancing
  
• Internal — Internal load balancing

 
LB Main Feature

• Up to 1000 backend VMs
• High availability through regional anycast IPs – single IP across availability Zones
• Drastically simplified NVA Resiliency – HA Ports
• Extensive health and diagnostic metrics

Finally, we can say that the services are broken into two categories along two dimensions: global versus regional, and HTTP(S) versus non-HTTP(S):

Global versus regional

• Global load-balancing services distribute traffic across regional backends, clouds, or hybrid on-premises services. These services route end-user traffic to the closest available backend. They also react to changes in service reliability or performance, in order to maximize availability and performance. You can think of them as systems that load balance between application stamps, endpoints, or scale-units hosted across different regions/geographies.
• Regional load-balancing services distribute traffic within virtual networks across virtual machines (VMs) or zonal and zone-redundant service endpoints within a region. You can think of them as systems that load balance between VMs, containers, or clusters within a region in a virtual network.
  

HTTP(S) versus non-HTTP(S)

• HTTP(S) load-balancing services are Layer 7 load balancers that only accept HTTP(S) traffic. They are intended for web applications or other HTTP(S) endpoints. They include features such as SSL offload, web application firewall, path-based load balancing, and session affinity.
  
  
• Non-HTTP/S load-balancing services can handle non-HTTP(S) traffic and are recommended for non-web workloads.
  
  

Combining global and regional services in your application provides an end-to-end reliable, performant, and secure way to route traffic to and from your users to your IaaS, PaaS, or on-premise services. In the next section, we describe each of these services.

If you are still confused for choosing the suitable solution you can refer to the below factors for easier determine

• Traffic type. Is it a web (HTTP/HTTPS) application? Is it public facing or a private application?
• Global versus. regional. Do you need to load balance VMs or containers within a virtual network, or load balance scale unit/deployments across regions, or both?
  
• Availability. What is the service SLA?
  
• Cost. See Azure pricing. In addition to the cost of the service itself, consider the operations cost for managing a solution built on that service.
  
• Features and limits. What are the overall limitations of each service
  

Treat this flowchart as a starting point. Every application has unique requirements, so use the recommendation as a starting point. Then perform a more detailed evaluation.