Microsoft has been working on Azure Front Door Service for the past 5 years and over that time Microsoft has significantly simplified the devops processes and site reliability engineering playbook for many teams. But now Microsoft is finally ready to show the AFDS (no typo) to the world in a public preview

Azure Front Door Service (AFDS) is added to the array of Global Load Balancing services. This means that it’s positioned in the same space as Traffic Manager, the GEO load-balancer available in Azure since a long time already. When choosing a global load balancer between Traffic Manager and Azure Front Door for global routing, you should consider what’s similar and what’s different about the two services. Both services provide:

  • Multi-geo redundancy:

    If one region goes down, traffic seamlessly routes to the closest region without any intervention from the application owner.

  • Closest region routing:

    Traffic is automatically routed to the closest region

Let’s talk protocols!

Next to the services above, AFDS (not to be confused with ADFS) enables you to define, manage, and monitor the global routing for your web traffic by optimising for best performance and instant global failover for high availability. Front Door works at Layer 7 or HTTP/HTTPS layer and uses anycast protocol with split TCP and Microsoft’s global network for improving global connectivity. So, per your routing method selection in the configuration, you can ensure that Front Door is routing your client requests to the fastest and most available application backend. An application backend is any Internet-facing service hosted inside or outside of Azure. Front Door provides a range of traffic-routing methods and backend health monitoring options to suit different application needs and automatic failover models. Similar to Traffic Manager, Front Door is resilient to failures, including the failure of an entire Azure region.

AFDS provides Dynamic webSite Acceleration (DSA) including global HTTP load balancing. It looks at incoming HTTP requests and routes them to the closest service backend or region for the specified hostname, URL path, and configured rules. Front Door terminates HTTP requests at the edge of Microsofts’ network and actively probes the application for infrastructure health or latency changes. Front Door then always routes traffic to the fastest and most readily available (healthy) backend.

On a high level, when AFDS receives your clients request, it either answers them (if caching is enabled) or forwards them to the appropriate application backend (just like a reverse proxy).  When you want to optimise traffic, there are options to utilise technologies such as Anycast or Split TCP. Learn more about those routing architectures here.

In a little more detail, you can identify the following three steps when connecting to Azure Front Door Services:

  • After establishing a connection and doing an SSL handshake, when a request lands on a Front Door environment, matching a routing rule is the first step. This match basically is determining from all the configurations in Front Door, which particular routing rule to match the request to.
  • Once Front Door has a match for a routing rule based on the incoming request and if there is no caching, then the next step is to pull the health probe status for the backend pool associated with the matched route.
  • Finally, assuming there is no caching configured, the user request is forwarded to the “best” backend based on your Front Door routing method configuration.

Azure Front Door Service (AFDS) features:

AFDS provides the following feature-set at the time of writing this article. More could become available as time progresses.

  • Accelerated application performance

  • Increase application availability with smart health probes

  • URL-based routing

  • Multiple Site Hosting

  • Session Affinity

  • Secure Sockets Layer (SSL) termination

  • Custom domains and certificate management

  • Application layer security

  • URL rewrite

  • IPv6 support

Accelerated application performance

Using split TCP-based anycast protocol, Front Door ensures that your end users promptly connect to the nearest Front Door POP (Point of Presence). Using Microsofts’ global network for connecting to your application backends from Front Door POPs, ensure higher availability and reliability while maintaining performance. This connectivity to your backend is also based on least network latency.

Increase application availability with smart health probes

Front Door delivers high availability for your critical applications using its smart health probes, monitoring your backends for both latency and availability and providing instant automatic failover when a backend goes down. So, you can run planned maintenance operations on your applications without downtime. Front Door directs traffic to alternative backends while the maintenance is in progress.

URL-based routing

URL Path Based Routing allows you to route traffic to backend pools based on URL paths of the request. One of the scenarios is to route requests for different content types to different backend pools.

Multiple-site hosting

Multiple-site hosting enables you to configure more than one web site on the same Front Door configuration. This feature allows you to configure a more efficient topology for your deployments by adding different web sites to a single Front Door configuration. Based on your application’s architecture, you can 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.

Session affinity

The cookie-based session affinity feature is useful when you want to keep a user session on the same application backend. By using Front Door managed cookies, subsequent traffic from a user session gets directed to the same application backend for processing. This feature is important in cases where session state is saved locally on the backend for a user session.

Secure Sockets Layer (SSL) termination

Front Door supports SSL termination at the edge that is, individual users can set up SSL connection with Front Door environments instead of establishing it over long haul connections with the application backend. Additionally, Front Door supports both HTTP as well as HTTPS connectivity between Front Door environments and your backends. So, you can also set up end-to-end SSL encryption. For example, if Front Door for your application workload receives over 5000 requests in a minute, due to warm connection reuse, for active services, it will only establish say about 500 connections with your application backend, thereby reducing significant load from your backends.

Custom domains and certificate management

When you use Front Door to deliver content, a custom domain is necessary if you would like your own domain name to be visible in your Front Door URL. Having a visible domain name can be convenient for your customers and useful for branding purposes. Front Door also supports HTTPS for custom domain names. Use this feature by either choosing Front Door managed certificates for your traffic or uploading your own custom SSL certificate.

Application layer security

Azure Front Door allows you to author custom web application firewall (WAF) rules for access control to protect your HTTP/HTTPS workload from exploitation based on client IP addresses, country code, and http parameters. Additionally, Front Door also enables you to create rate limiting rules to battle malicious bot traffic.

The AFDS platform itself is protected by Azure DDoS Protection Basic. For further protection, Azure DDoS Protection Standard may be enabled at your VNETs and safeguard resources from network layer (TCP/UDP) attacks via auto tuning and mitigation. Front Door is a layer 7 reverse proxy, it only allows web traffic to pass through to backends and it blocks other types of traffic by default.

URL rewrite

Front Door supports URL rewrite by allowing you to configure an optional Custom Forwarding Path to use when constructing the request to forward to the backend. Front Door further allows you to configure Host header to be sent when forwarding the request to your backend.

IPv6 Protocol support – IPv6

Azure Front Door natively supports end-to-end IPv6 connectivity.

In conclusion, when you’re in need of a global load balancing with a lot of security and performance features, Azure Front Door Services might just be a fit for you! If you are looking for a DNS based global routing and do not have requirements for Transport Layer Security (TLS) protocol termination, (“SSL offload”) or per-HTTP/HTTPS request, application-layer processing, review Traffic Manager. If you are looking for load balancing between your servers in a region, at the application layer, review Application Gateway and for network layer load balancing, review Load Balancer. Your end-to-end scenarios might benefit when you combine some of these solutions described above.

That’s all for now. Thanks for reading and when you have any feedback or comments after reading this, please use the comments below or send me an e-mail. Don’t forget to lock your own front-door!

One Comment

  • Prakash says:

    In this diagram, Front door to Backend pool – how Traffic is flowing ? Internet IP of Backend Pool ? If Backend pool have open Internet IP, then they are available for port scanning tools on Internet for hackers ? Are their any specific Front door IP ranges need to be allowed on Backend pool ?