Merge pull request #52673 from sharad4u/release-ignite-frontdoor

Release ignite frontdoor

Author: TrishaMc

articles/frontdoor/TOC.yml

@@ -22,6 +22,8 @@
     href: front-door-backend-pool.md
   - name: DDoS protection and application layer security
     href: front-door-ddos-security.md
+  - name: Load-balancing with Azure’s application delivery suite
+    href: front-door-lb-with-azure-app-delivery-suite.md
   - name: Routing architecture
     href: front-door-routing-architecture.md
   - name: Traffic routing methods
@@ -38,6 +40,8 @@
     href: front-door-http2.md
   - name: HTTP headers protocol support
     href: front-door-http-headers-protocol.md
+  - name: Monitoring
+    href: front-door-diagnostics.md
 - name: Resources
   items:
   - name: Azure Roadmap

articles/frontdoor/front-door-custom-domain.md

@@ -111,8 +111,10 @@ After you've registered your custom domain, you can then add it to your Front Do
 
 6. Select **Add**.
 
-   Azure verifies that the CNAME record exists for the custom domain name you entered. If the CNAME is correct, your custom domain will be validated.   
+   Azure verifies that the CNAME record exists for the custom domain name you entered. If the CNAME is correct, your custom domain will be validated.
 
+>[!WARNING]
+> You **must** ensure that each of the frontend hosts (including custom domains) in your Front Door has a routing rule with a default path ('/\*') associated with it. That is, across all of your routing rules there must be at least one routing rule for each of your frontend hosts defined at the default path ('/\*'). Failing to do so, may result in your end-user traffic not getting routed correctly.
 
 ## Verify the custom domain
 

articles/frontdoor/front-door-ddos-security.md

@@ -14,9 +14,10 @@ ms.author: sharadag
 ---
 
 # DDoS protection and application layer security with Front Door
-Azure Front Door Service provides web application protection capability to safeguard your web applications from DDoS network attacks and common web vulnerabilities exploits like SQL Injection or Cross Site scripting (XSS). Enabled for http(s) front-ends, Front Door's application layer security is globally distributed and always on, stopping malicious attacks at Azure's network edge, far away from your backends. With added security and performance optimization, Front Door delivers fast and secure web experiences to your end users.
+Azure Front Door Service provides web application protection capability to safeguard your web applications from DDoS network attacks and common web vulnerabilities exploits like SQL Injection or Cross Site Scripting (XSS). Enabled for http(s) front-ends, Front Door's application layer security is globally distributed and always on, stopping malicious attacks at Azure's network edge, far away from your backends. With added security and performance optimization, Front Door delivers fast and secure web experiences to your end users.
 
-Front Door's application layer security is configured on each edge environment around the globe, in line with applications, and automatically blocks non-http(s) traffic from reaching your web applications. Our multi-tenant distributed architecture enables global protection at scale without sacrificing performance. For http(s) workloads, Azure Front Door web application protection service provides a rich rules engine for custom rules, pre-configured ruleset against common attacks, and detailed logging for all requests that matches a rule. Flexible actions including allow, block, or log only are supported.
+##DDoS protection
+Front Door's application protection is configured on each edge environment around the globe, in line with applications, and automatically blocks non-http(s) traffic from reaching your web applications. Our multi-tenant distributed architecture enables global protection at scale without sacrificing performance. For http(s) workloads, Front Door's web application protection service provides a rich rules engine for custom rules, pre-configured ruleset against common attacks, and detailed logging for all requests that matches a rule. Flexible actions including allow, block, or log only are supported.
 
 ## Custom access control rules
 - **IP Blacklists and whitelists:** You may configure custom rules to control access to your web applications based on list of client IP addresses. Both IP v4 and IP v6 are supported
@@ -37,9 +38,7 @@ Front Door's application layer security is configured on each edge environment a
 
 
 ## Monitoring
-- Front Door provides the ability to monitor web applications against attacks using real-time metrics that are integrated with Azure Monitor to track alerts and easily monitor trends. 
-- The JSON formatted log goes directly to the customer’s storage account. Customers have full control over these logs and can apply their own retention policies. Customers can also ingest these logs into their own analytics system.
-- Application security logs are also integrated with Operations Management Suite (OMS) so customers can use OMS log analytics to execute sophisticated fine grained queries.
+Front Door provides the ability to monitor web applications against attacks using real-time metrics that are integrated with Azure Monitor to track alerts and easily monitor trends.
 
 ## Pricing
 Front Door's application layer security is free during the preview.

articles/frontdoor/front-door-diagnostics.md

@@ -0,0 +1,39 @@
+---
+title: Azure Front Door Service - Metrics and Logging | Microsoft Docs
+description: This article helps you understand the different metrics and access logs that Azure Front Door Service supports
+services: frontdoor
+documentationcenter: ''
+author: sharad4u
+ms.service: frontdoor
+ms.devlang: na
+ms.topic: article
+ms.tgt_pltfrm: na
+ms.workload: infrastructure-services
+ms.date: 09/18/2018
+ms.author: sharadag
+---
+
+# Monitoring metrics for Front Door
+
+By using Azure Front Door Service, you can monitor your key metrics to validate the Front Door configuration, along with usage, health, and performance or your Front Door.
+
+## Metrics
+
+Metrics are a feature for certain Azure resources where you can view performance counters in the portal. For Front Door, the following metrics are available:
+
+| Metric | Metric Display Name | Unit | Dimensions | Description |
+| --- | --- | --- | --- | --- |
+| RequestCount | Request Count | Count | HttpStatus</br>HttpStatusGroup</br>ClientRegion</br>ClientCountry | The number of client requests served by Front Door.  |
+| RequestSize | Request Size | Bytes | HttpStatus</br>HttpStatusGroup</br>ClientRegion</br>ClientCountry | The number of bytes sent as requests from clients to Front Door. |
+| ResponseSize | Response Size | Bytes | HttpStatus</br>HttpStatusGroup</br>ClientRegion</br>ClientCountry | The number of bytes sent as responses from Front Door to clients. |
+| TotalLatency | Total Latency | Milliseconds | HttpStatus</br>HttpStatusGroup</br>ClientRegion</br>ClientCountry | The time calculated from when the client request was received by Front Door until the client acknowledged the last response byte from Front Door. |
+| BackendRequestCount | Backend Request Count | Count | HttpStatus</br>HttpStatusGroup</br>Backend | The number of requests sent from Front Door to backends. |
+| BackendRequestLatency | Backend Request Latency | Milliseconds | Backend | The time calculated from when the request was sent by Front Door to the backend until Front Door received the last response byte from the backend. |
+| BackendHealthPercentage | Backend Health Percentage | Percent | Backend</br>BackendPool | The percentage of successful health probes from Front Door to backends. |
+| WebApplicationFirewallRequestCount | Web Application Firewall Request Count | Count | PolicyName</br>RuleName</br>Action | The number of client requests processed by the application layer security of Front Door. |
+
+
+## Next steps
+
+- Learn how to [create a Front Door](quickstart-create-front-door.md).
+- Learn [how Front Door works](front-door-routing-architecture.md).

articles/frontdoor/front-door-lb-with-azure-app-delivery-suite.md

@@ -0,0 +1,86 @@
+---
+title: Azure Front Door Service - Load Balancing with Azure's applciation delivery suite | Microsoft Docs
+description: This article helps you learn about how Azure recommends load balancing with it's application delivery suite
+services: frontdoor
+documentationcenter: ''
+author: sharad4u
+ms.service: frontdoor
+ms.devlang: na
+ms.topic: article
+ms.tgt_pltfrm: na
+ms.workload: infrastructure-services
+ms.date: 09/10/2018
+ms.author: sharadag
+---
+
+# Load-balancing with Azure’s application delivery suite
+
+## Introduction
+Microsoft Azure provides multiple global and regional services for managing how your network traffic is distributed and load balanced: Traffic Manager, Front Door Service, Application Gateway, and Load Balancer.  Along with Azure’s many regions and zonal architecture, using these services together enable you to build robust, scalable high-performance applications.
+
+![Application Delivery Suite ][1]
+ 
+These services are broken into two categories:
+1. **Global load balancing services** such as Traffic Manager and Front Door distribute traffic from your end users across your regional backends, across clouds or even your hybrid on-premise services. Global load balancing routes your traffic to your closest service backend and reacts to changes in service reliability or performance to maintain always-on, maximal performance for your users. 
+2. **Regional load balancing services** such as Standard Load Balancer or Application Gateway provide the ability to distribute traffic within virtual networks (VNETs) across your virtual machines (VMs) or zonal service endpoints within a region.
+
+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.
+
+## Global load balancing
+**Traffic Manager** provides global DNS load balancing. It looks at incoming DNS requests and responds with a healthy backend, in accordance with the routing policy the customer has selected. Options for routing methods are:
+- Performance routing to send the requestor to the closest backend in terms of latency.
+- Priority routing to direct all traffic to a backend, with other backends as back up.
+- Weighted round-robin routing, which distributes traffic based on the weighting that is assigned to each backend.
+- Geographic routing to ensure that requestors located in specific geographic regions are directed to the backends mapped to those regions (for example, all requests from Spain should be directed to the US-East Azure region)
+- Subnet routing that allows you to map IP address ranges to backends so that requests coming from those will be sent to the specified backend (for example, all users connecting from your corporate HQ’s IP address range should get different web content than the general users)
+
+The client connects directly to that backend. Azure Traffic Manager detects when a backend is unhealthy and then redirects the clients to another healthy instance. Refer to [Azure Traffic Manager](../traffic-manager/traffic-manager-overview.md) documentation to learn more about the service.
+
+**Azure Front Door Service** provides dynamic website acceleration (DSA) including global HTTP load balancing.  It looks at incoming HTTP requests routes to the closest service backend / region for the specified hostname, URL path, and configured rules.  
+Front Door terminates HTTP requests at the edge of Microsoft’s network and actively probes to detect application or infrastructure health or latency changes.  Front Door then always routes traffic to the fastest and available (healthy) backend. Refer to Front Door's [routing architecture](front-door-routing-architecture.md) details and [traffic routing methods](front-door-routing-methods.md) to learn more about the service.
+
+## Regional load balancing
+Application Gateway provides application delivery controller (ADC) as a service, offering various Layer 7 load-balancing capabilities for your application. It allows customers to optimize web farm productivity by offloading CPU-intensive SSL termination to the application gateway. Other Layer 7 routing capabilities include round-robin distribution of incoming traffic, cookie-based session affinity, URL path-based routing, and the ability to host multiple websites behind a single application gateway. Application Gateway can be configured as an Internet-facing gateway, an internal-only gateway, or a combination of both. Application Gateway is fully Azure managed, scalable, and highly available. It provides a rich set of diagnostics and logging capabilities for better manageability.
+Load Balancer is an integral part of the Azure SDN stack, providing high-performance, low-latency Layer 4 load-balancing services for all UDP and TCP protocols. It manages inbound and outbound connections. You can configure public and internal load-balanced endpoints and define rules to map inbound connections to back-end pool destinations by using TCP and HTTP health-probing options to manage service availability.
+
+
+## Choosing a global load balancer
+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
+
+</br>The following table describes the differences between Traffic Manager and Azure Front Door Service:</br>
+
+| Traffic Manager |	Azure Front Door Service |
+| --------------- | ------------------------ |
+|**Any protocol:** Because Traffic Manager works at the DNS layer, you can route any type of network traffic; HTTP, TCP, UDP, etc. | **HTTP acceleration:** With Front Door traffic is proxied at the Edge of Microsoft’s network.  Because of this, HTTP(S) requests see latency and throughput improvements reducing latency for SSL negotiation and using hot connections from AFD to your application.|
+|**On-premise routing:** With routing at a DNS layer, traffic always goes from point to point.  Routing from your branch office to your on-prem datacenter can take a direct path; even on your own network using Traffic Manager. | **Independent scalability:** Because Front Door works with the HTTP request, requests to different URL paths can be routed to different backend / regional service pools (microservices) based on rules and the health of each application microservice.|
+|**Billing format:** DNS-based billing scales with your users and for services with more users, plateaus to reduce cost a higher usage. |**Inline security:** Front Door enables rules such as rate limiting and IP ACL-ing to let you protect your backends before traffic reaches your application. 
+
+</br>Because of the performance, operability and security benefits to HTTP workloads with Front Door, we recommend customers use Front Door for their HTTP workloads.    Traffic Manager and Front Door can be used in parallel to serve all traffic for your application. 
+
+## Building with Azure’s application delivery suite 
+We recommend that all websites, APIs, services be geographically redundant and deliver traffic to its users from the closest (lowest latency) location to them whenever possible.  Combining services from Traffic Manager, Front Door Service, Application Gateway, and Load Balancer enables you to build geographically and zonally redundant to maximize reliability, scale, and performance.
+
+In the following diagram, we describe an example service that uses a combination of all these services to build a global web service.   In this case, the architect has used Traffic Manager to route to global backends for file and object delivery, while using Front Door to globally route URL paths that match the pattern /store/* to the service they’ve migrated to App Service while routing all other requests to regional Application Gateways.
+
+In the region, for their IaaS service, the application developer has decided that any URLs that match the pattern /images/* are served from a dedicated pool of VMs that are different from the rest of the web farm.
+
+Additionally, the default VM pool serving the dynamic content needs to talk to a back-end database that is hosted on a high-availability cluster. The entire deployment is set up through Azure Resource Manager.
+
+The following diagram shows the architecture of this scenario:
+
+![Application Delivery Suite Detailed Architecture][2] 
+
+> [!NOTE]
+> This example is only one of many possible configurations of the load-balancing services that Azure offers. Traffic Manager, Front Door, Application Gateway, and Load Balancer can be mixed and matched to best suit your load-balancing needs. For example, if SSL offload or Layer 7 processing is not necessary, Load Balancer can be used in place of Application Gateway.
+
+
+## Next Steps
+
+- Learn how to [create a Front Door](quickstart-create-front-door.md).
+- Learn [how Front Door works](front-door-routing-architecture.md).
+
+<!--Image references-->
+[1]: ./media/front-door-lb-with-azure-app-delivery-suite/application-delivery-figure1.png
+[2]: ./media/front-door-lb-with-azure-app-delivery-suite/application-delivery-figure2.png

articles/frontdoor/media/front-door-lb-with-azure-app-delivery-suite/application-delivery-figure1.png

@@ -78,6 +78,9 @@ Next, you need to configure your application backend(s) in a backend pool for Fr
 Lastly, click the '+' icon on Routing rules to configure a routing rule. This is needed to map your frontend host to the backend pool, which basically is configuring that if a request comes to `myappfrontend.azurefd.net`, then forward it to the backend pool `myBackendPool`. 
 Click **Add** to add the routing rule for your Front Door. You should now be good to creating the Front Door and so click on **Review and Create**.
 
+>[!WARNING]
+> You **must** ensure that each of the frontend hosts in your Front Door has a routing rule with a default path ('/\*') associated with it. That is, across all of your routing rules there must be at least one routing rule for each of your frontend hosts defined at the default path ('/\*'). Failing to do so, may result in your end-user traffic not getting routed correctly.
+
 ## View Front Door in action
 Once you create a Front Door, it will take a few minutes for the configuration to be deployed globally everywhere. Once complete, access the frontend host you created, that is, go to a web browser and hit the URL `myappfrontend.azurefd.net`. Your request will automatically get routed to the nearest backend to you from the specified backends in the backend pool.