Azure Front Door design considerations

Introduction

As discussed in a previous blog post regarding Azure load balancing service options, Azure Front Door (AFD) is one of the many available load balancing options in Azure, the alternative options being the following:

Azure Front Door allows for a truly global service which includes Web Application Firewall (WAF), Content Delivery Network (CDN) and Distributed Denial of Service (DDOS) protection. This article provides at high-level the most common Azure Front Door design considerations.

Azure Front Door design considerations

When designing your Azure Front Door solution, take into account the following Azure Front Door parameters and plan accordingly based on your organization requirements:

  • Front-ends and custom domains. Each defined AFS front end or custom domain has the following parameters:
    • The frontend host specifies a desired subdomain on Front Door's default domain i.e. azurefd.net to route traffic from that host via Front Door. You can optionally onboard custom domains as well.
    • Session Affinity (enabled/disabled)
    • Web application firewall (Enabled/Disabled). If enabled, at least one WAF policy must be associated.
    • When using custom domains, create a DNS mapping from your custom domain to the Front Door azurefd.net frontend host with your DNS provider. You may need to enable custom domain HTTPS and define minimum TLS version and certificate managed type (Front Door Managed vs. Use my own certificate). The Azure Front Door Managed option is not supported for apex/root domains.
  • Backend pools. These are for example the Azure App Services which are linked with an Azure Front Door front-end. A backend pool service can be Azure App service or any other supported Azure service. A backend pool is a set of equivalent backends to which Front Door load balances your client requests. A backend pool can comprise one or more backends (with priorities and weights defined). Each backend pool has the following parameters:
    • Backend Host Type
    • Backend Host header
    • The host header value sent to the backend with each request. If you leave this blank, the request hostname determines this value. Azure services, such as Web Apps, Blob Storage, and Cloud services, require this host header value to match the target host name by default.
    • HTTP port
    • HTTPS port
    • Priority
    • Weight
    • Health probes for the backend pool. Front Door sends periodic HTTP/HTTPS probe requests to each of your configured backends to determine the proximity and health of each backend to load balance your end user requests. A path and protocol (HTTP/HTTPS) must be chosen, as well as a probe method and interval in seconds. Regarding probe methods, HTTP method the health probe uses when querying the backend pool instances. Use HEAD if you do not need to check the response body.
    • Load balancing parameters. Configure the load balancing settings to define what sample set we need to use to call the backend as healthy or unhealthy. The latency sensitivity with value zero (0) means always send it to the fastest available backend, else Front Door will round robin traffic between the fastest and the next fastest backends within the configured latency sensitivity.
  • Routing rules. Each AFD routing rule has the following parameters:
    • Accepted protocols (HTTP/HTTPS)
    • Frontends/domains included in the routing rule
    • Patterns to match. Set this to all the URL path patterns that this route will accept. For example, you can set this to /users/* to accept all requests on the URL www.contoso.com/users/*.
    • Rules engine configuration. Once a route for a Front Door is matched, the Rules Engine configuration associated with this routing rule is executed, followed by general route configuration defined here.
    • Route type (forward or redirect). Set the route type to define how Front Door should handle requests for this route i.e. forward them to a backend or redirect the users to a different URL.
    • Backend pool. The associated App Service or other Azure supported service to be used as the backend pool for this routing rule.
    • Forwarding protocol. Protocol to use for forwarding request to backend or match the protocol from incoming request (HTTP/HTTPS).
    • URL rewrite. Path to use when constructing the request for URL rewrite to forward to the backend. A custom forwarding path must be provided if applicable.
    • Caching. Enable caching for this routing rule. When enabled, Front Door will cache your static content. There is a query string caching behavior which must be chosen if caching is enabled. This sets how Front Door treats cacheable objects when the request URL contains query strings. This option has no effect when caching is turned off for the asset. This setting does not modify query string values sent back to the origin. Also decide if you will be using the default cache duration or a custom minimum cache duration.
    • Use dynamic compression (enabled / disabled).
  • Custom HTTP(S) routing rules based on the Azure Front Door Rules Engine. The Rules Engine allows you to customize how HTTP requests are handled at the edge and provides more control of the behavior of your web application. To learn more about the rules engine, consult the following Microsoft Docs article: Front Door Rules Engine Overview.
  • WAF policies. Natively integrated and platform managed, Azure Web Application Firewall (WAF) provides protection of your web applications from common exploits and vulnerabilities. Web applications are increasingly the targets of malicious attacks such as denial-of-service floods, SQL injection attacks, and cross-site scripting attacks. Preventing such attacks in application code can be challenging and may require rigorous maintenance, patching, and monitoring at multiple layers of the application topology. A centralized web application firewall helps make security management much simpler and gives better assurance to application administrators against threats or intrusions. In addition, a WAF solution can react to a security threat faster by patching a known vulnerability at a central location, instead of securing each individual web application. Learn more about WAF.

Troubleshooting Azure Front Door routing issues

If you have followed a best-practice design and you are still facing issues, make sure you first consult the Microsoft troubleshooting guide for Azure Front Door, which is available at: https://docs.microsoft.com/en-us/azure/frontdoor/front-door-troubleshoot-routing.

Sources

https://docs.microsoft.com/en-us/azure/frontdoor/

https://docs.microsoft.com/en-us/azure/frontdoor/front-door-custom-domain

https://docs.microsoft.com/en-us/azure/dns/dns-delegate-domain-azure-dns

https://medium.com/@ajith.ramawickrama/deploying-multi-region-high-available-web-application-in-azure-with-app-services-sql-database-393bb2559f12