Intro

Azure Front Door is a global, scalable entry-point that uses the Microsoft global edge network to create fast, secure, and widely scalable access to web applications.

Using split TCP-based anycast protocol, Front Door ensures that your end users promptly connect to the nearest Front Door POP (Point of Presence).

Documentation

• What is Azure Front Door?

• How do I lock down the access to my backend to only Azure Front Door?

Tips and TidBits

• Front Door works at Layer 7 (HTTP/HTTPS layer) using anycast protocol with split TCP and Microsoft's global network to improve global connectivity.

• Based on your routing method you can ensure that Front Door will route your client requests to the fastest and most available application backend.

• Front Door provides a range of traffic-routing methods and backend health monitoring options to suit different application needs and automatic failover scenarios.

Open

Front Door Features

The following features are included with Front Door:

• Accelerate 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).

• 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.

• URL-based routing

  • 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

  • Configure more than one web site on the same Front Door configuration.

• 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.

• TLS termination

  • Supports TLS termination at the edge that is, individual users can set up a TLS connection with Front Door environments instead of establishing it over long haul connections with the application backend.

• 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.

• URL redirection

  • Web applications are expected to automatically redirect any HTTP traffic to HTTPS. This ensures that all communication between the users and the application occurs over an encrypted path.

• 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.

• Protocol support - IPv6 and HTTP/2 traffic

  • Azure Front Door natively supports end-to-end IPv6 connectivity and also HTTP/2 protocol.

•  

Load Balancing

• Understand Azure load balancing - Pay attention to the global vs regional use and the type of traffic.

• The following table summarizes the Azure load balancing services by these categories:

Web Application Firewall (WAF) Feature

• What is Azure Web Application Firewall?

• Web Application Firewall (WAF) provides centralized protection of your web applications from common exploits and vulnerabilities.

• Web applications are increasingly targeted by malicious attacks that exploit commonly known vulnerabilities.

  • SQL injection and cross-site scripting are among the most common attacks.

Open

• WAF can be deployed with Azure Application Gateway, Azure Front Door, and Azure Content Delivery Network (CDN) service from Microsoft.

  • WAF on Azure CDN is currently under public preview. WAF has features that are customized for each specific service.

• Azure Web Application Firewall on Azure Front Door

You can configure custom rules WAF as follows:

• IP allow list and block list: You can control access to your web applications based on a list of client IP addresses or IP address ranges. Both IPv4 and IPv6 address types are supported. This list can be configured to either block or allow those requests where the source IP matches an IP in the list.

• Geographic based access control: You can control access to your web applications based on the country code that's associated with a client’s IP address.

• HTTP parameters-based access control: You can base rules on string matches in HTTP/HTTPS request parameters. For example, query strings, POST args, Request URI, Request Header, and Request Body.

• Request method-based access control: You base rules on the HTTP request method of the request. For example, GET, PUT, or HEAD.

• Size constraint: You can base rules on the lengths of specific parts of a request such as query string, Uri, or request body.

• Rate limiting rules: A rate control rule limits abnormally high traffic from any client IP address. You may configure a threshold on the number of web requests allowed from a client IP during a one-minute duration. This rule is distinct from an IP list-based allow/block custom rule that either allows all or blocks all request from a client IP. Rate limits can be combined with additional match conditions such as HTTP(S) parameter matches for granular rate control.

Highly available multi-region web application

• Highly available multi-region web application

• Reference architecture shows how to run an Azure App Service application in multiple regions to achieve high availability

• Primary and secondary regions. This architecture uses two regions to achieve higher availability. The application is deployed to each region. During normal operations, network traffic is routed to the primary region. If the primary region becomes unavailable, traffic is routed to the secondary region.

• Front Door. Front Door routes incoming requests to the primary region. If the application running that region becomes unavailable, Front Door fails over to the secondary region.

  • Key features included with Front Door:

    • Accelerated application performance by using split TCP-based anycast protocol.

    • Intelligent health probe monitoring for backend resources.

    • URL-path based routing for requests.

    • Enables hosting of multiple websites for efficient application infrastructure.

    • Cookie-based session affinity.

    • SSL offloading and certificate management.

    • Define your own custom domain.

    • Application security with integrated Web Application Firewall (WAF).

    • Redirect HTTP traffic to HTTPS with URL redirect.

    • Custom forwarding path with URL rewrite.

    • Native support of end-to-end IPv6 connectivity and HTTP/2 protocol.

• Geo-replication of SQL Database and/or Cosmos DB.

Caching with Azure Front Door

• Caching with Azure Front Door

• Front Door caches assets until the asset's time-to-live (TTL) expires.

• Whenever a client requests an asset with expired TTL, the Front Door environment retrieves a new updated copy of the asset to serve the request and then stores the refreshed cache.

• Sometimes you may wish to purge cached content from all edge nodes and force them all to retrieve new updated assets.

  • The reason could be because of updates to your web application, or to quickly update assets that contain incorrect information.

• Select the assets you want to purge from the edge nodes.

  • To clear all assets, select Purge all. Otherwise, in Path, enter the path of each asset you want to purge.

  • These formats are supported in the lists of paths to purge:

  • Single path purge: Purge individual assets by specifying the full path of the asset (without the protocol and domain), with the file extension, for example, /pictures/strasbourg.png;

  • Wildcard purge: Asterisk (*) may be used as a wildcard. Purge all folders, subfolders, and files under an endpoint with /* in the path or purge all subfolders and files under a specific folder by specifying the folder followed by /*, for example, /pictures/*.

  • Root domain purge: Purge the root of the endpoint with "/" in the path.

How do I lock down the access to my backend to only Azure Front Door?

To lock down your application to accept traffic only from your specific Front Door, you will need to:

• set up IP ACLs for your backend

  • Refer AzureFrontDoor.Backend section in Azure IP Ranges and Service Tags for Front Door's backend IP address range or

  • you can also use the service tag AzureFrontDoor.Backend in your network security groups.

• restrict the traffic on your backend to the specific value of the header 'X-Azure-FDID' sent by Front Door.

Compression

• File compression

• Front Door can dynamically compress content on the edge, resulting in a smaller and faster response time to your clients.

• In order for a file to be eligible for compression, caching must be enabled and the file must be of a MIME type to be eligible for compression.

• Additionally, the file must also be between 1 KB and 8 MB in size, inclusive

• These profiles support the following compression encodings:

  • Gzip (GNU zip)

  • Brotli

    • Brotli is a compression algorithm developed by Google and works best for text compression.

    • Brotli is primarily used by web servers and content delivery networks to compress HTTP content, making internet websites load faster.

  • If a request supports gzip and Brotli compression, Brotli compression takes precedence.

Design and configure Azure Front Door

• Design and configure Azure Front Door

• Azure Front Door is a global, scalable entry-point that uses the Microsoft global edge network to create fast, secure, and widely scalable web applications

• Front Door works at Layer 7 (HTTP/HTTPS layer) using anycast protocol with split TCP and Microsoft's global network to improve global connectivity.

• Based on your routing method you can ensure that Front Door will route 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 scenarios.

• Incoming match

  The following properties determine whether the incoming request matches the routing rule (or left-hand side):

  • HTTP Protocols (HTTP/HTTPS)

  • Hosts (for example, www.foo.com, *.bar.com)

  • Paths (for example, /, /users/, /file.gif)

  • Front Door attempts to match to the most-specific match first looking only at the left-hand side of the route.

  • It first matches based on HTTP protocol, then Frontend host, then the Path.

• Front Door speeds up the processing of requests by using caching.

  • If caching is enabled for a specific route, it uses the cached response.

  • If there is no cached response for the request, Front Door forwards the request to the appropriate backend in the configured backend pool.

• Azure Front Door redirects traffic at each of the following levels: protocol, hostname, path, query string. These functionalities can be configured for individual microservices since the redirection is path-based

• As part of configuring a redirect routing, you can also change the hostname or domain for the redirect request.

  • You can set this field to change the hostname in the URL for the redirection or otherwise preserve the hostname from the incoming request.

• The destination fragment is the portion of URL after '#', which is used by the browser to land on a specific section of a web page.

  • You can set this field to add a fragment to the redirect URL.

Configure health probes, including customization of HTTP response codes

• To determine the health and proximity of each backend for a given Front Door environment, each Front Door environment periodically sends a synthetic HTTP/HTTPS request to each of your configured backends.

• Front Door then uses these responses from the probe to determine the "best" backend resources to route your client requests.

• With the default probe frequency of 30 seconds, the probe volume on your backend should be about 200 requests per minute.

Front Door supports the following HTTP methods for sending the health probes:

• GET: The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.

• HEAD: The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.

• Because it has lower load and cost on your backends, for new Front Door profiles, by default, the probe method is set as HEAD.

Implement a Web Application Firewall on Azure Front Door

• Implement a Web Application Firewall on Azure Front Door

• When you create a Web Application Firewall (WAF) policy, by default the WAF policy is in Detection mode.

• In Detection mode, WAF does not block any requests; instead, requests matching the WAF rules are logged at WAF logs.

• To see WAF in action, you can change the mode settings from Detection to Prevention.

  • In Prevention mode, requests that match rules that are defined in Default Rule Set (DRS) are blocked and logged at WAF logs.

Azure-managed Default Rule Set includes rules against the following threat categories:

• Cross-site scripting

• Java attacks

• Local file inclusion

• PHP injection attacks

• Remote command execution

• Remote file inclusion

• Session fixation

• SQL injection protection

• Protocol attacker

Rules - Path matching

• Path matching

• After Azure Front Door Standard/Premium determines the specific frontend host and filtering possible routing rules to just the routes with that frontend host.

• Front Door then filters the routing rules based on the request path. We use a similar logic as frontend hosts:

  1. Look for any routing rule with an exact match on the Path

  2. If no exact match Paths, look for routing rules with a wildcard Path that matches

  3. If no routing rules are found with a matching Path, then reject the request and return a 400: Bad Request error HTTP response.

Tutorial: Configure HTTPS on a Front Door custom domain

• Tutorial: Configure HTTPS on a Front Door custom domain

• Azure Front Door supports HTTPS on a Front Door default hostname, by default.

  • For example, if you create a Front Door (such as https://contoso.azurefd.net), HTTPS is automatically enabled for requests made to https://contoso.azurefd.net.

  • However, once you onboard the custom domain 'http://www.contoso.com ' you'll need to additionally enable HTTPS for this frontend host.

• When you use a certificate managed by Azure Front Door, the HTTPS feature can be turned on with just a few clicks.

  • Azure Front Door completely handles certificate management tasks such as procurement and renewal.

  • After you enable the feature, the process starts immediately.

• You can use your own certificate to enable the HTTPS feature.

  • This process is done through an integration with Azure Key Vault, which allows you to store your certificates securely.

  • Azure Front Door uses this secure mechanism to get your certificate and it requires a few extra steps.

  • When you create your TLS/SSL certificate, you must create a complete certificate chain with an allowed certificate authority (CA) that is part of the Microsoft Trusted CA List.

    • If you use a non-allowed CA, your request will be rejected.

    • If a certificate without complete chain is presented, the requests which involve that certificate are not guaranteed to work as expected.