Introduction: 

Azure Front Door is typically used to ensure that users can access web applications in the event of a regional outage, balance requests between instances and to support rate limiting. It works well with CDN. Azure Front Door focuses on global load balancing and site-acceleration and Azure CDN offers static content caching and acceleration. By bringing security with threat protection and advanced OWASP capabilities, Azure Front Door makes CDN a remarkable cloud-native solution. 

By itself, Azure Front Door enables us to define, manage, and monitor global routing for our web traffic by optimizing the best performance and instant global failover for high availability. With Front Door, we can transform our global (multi-region) consumer and enterprise applications into robust, high-performance, and personalized modern applications, APIs, and content that reaches a global audience with Azure. Azure Front Door works at Layer 7 of HTTP/HTTPS layer and uses anycast protocol with split TCP and Microsoft’s global network for improving global connectivity. 

If we are designing a microservice architecture that will be hosted in an Azure Kubernetes service cluster, and all its consumers are on the same virtual network, then those microservices can be exposed to the consumer apps via an Azure API management premier tier with virtual network connection. This would allow all the ingress access to the microservices to be restricted to a single private IP address and protected by mutual TLS authentication. It would also facilitate rate limiting of incoming microservice calls. In such a case, the use of Azure Front Door is not advisable. On the other hand, if we deploy multiple instances of Azure Web Applications across several regions, then we need to design an access solution that can balance requests across all instances and ensure business continuity in the face of regional outages, then an Azure Front Door is advisable. 

Both Azure Traffic Manager and Azure Front Door can perform global load balancing of web traffic across Azure regions and regional load balancing can be performed by Azure Application Gateway with complimentary capabilities at global and regional level. However, Azure Front Door And Application Gateway can better monitor and secure web requests than just that provided by routing rules from Traffic Manager. 

 

Comparison to Application Gateway: 

Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications whether they are hosted as standalone or behind an ingress. When compared to Azure Front Door that offers global load balancing across regions and is preferred for direct connectivity to the internet, App Gateway is suitable for backends contained within a region or is not open to the public internet. Both provide web application firewall and App Gateway provides features such as SSL/TLS termination, autoscaling, zone-redundancy, static VIP, Ingress controller for Azure Kubernetes Service resources, URL based routing, multiple site hosting, redirection, session affinity, websocket and http/2 traffic, connection draining, custom error pages, rewrite of http headers and URL, and sizing. It is preferable to choose the v2 sku that includes the WAF.   

 

Front Door as a replacement or addition to Application Gateway: 

The best practice for Azure Front Door suggests the following design: 

 

 

Note: The diagram above indicates that you don't need separate Azure Front Door for different application gateways. All those gateways whether they are dedicated to app services or AKS instance can be added into the backend pool of the Azure Front Door. 

BCDR considerations: 

• Active/active – both regions are active, and load balanced equally. If one of the regions becomes unavailable, it is taken out of rotation. 

• Active/Passive with hot standby: Traffic goes to one region, while the other is running and ready to accept connections. The other is usually allocated in a different region and is always running. 

• Active/Passive with cold standby: Traffic goes to one region while the other waits on cold standby. The secondary region isn’t allocated until needed for a failover. This is less cost but takes longer. 

  

Feature	Cost	RTO	RPO
Active-Active	Most expensive	Near real-time or seconds	Near real-time or seconds
Active/Passive with hot standby	Somewhat expensive	Minutes	Minutes
Active/Passive with cold standby	Least expensive	Hours	Hours

WAF-Policy: 

The same waf policy that works for application gateways can also be associated with the FrontDoor and this brings OWASP version 3.1 managed rule set. Custom rules to allow Optum IPs are also added to the existing WAF-policies which works for the Azure Front Door. 

The WAF is one of the most critical pieces to manage the ingress traffic to the web applications. It implements the open source OWASP ModSecurity Core Rule Set which is a set of general attack detection rules. The CRS aims to protect the web applications from a wide range of attacks, including the OWASP Top Ten, with a minimum of false alerts. The top attack categories include SQL injection, Cross Site Scripting, Local file inclusion, Remote file inclusion, Code Injection, Httpoxy (http requests through a proxy), Shellshock, Shell injection, Session Fixation, Bot detection, and Error leakages. The most recent version released is 3.3.5 and includes security fixes, non-breaking changes, and other improvements. Many IaC providers offer only lower versions and the public cloud resource management itself lag the most recent versions. The OWASP 3.1 is good enough to cover almost all the top attack categories.