Azure Front Door

1. Azure Front Door Overview
2. Requirements Mapping
3. Architecture Design
4. Traffic Flow Diagrams
5. Implementation Guide
6. Configuration Commands
7. Security Configuration
8. Monitoring and Analytics

1. Azure Front Door Overview

Azure Front Door is a global, scalable entry point that uses Microsoft's global edge network to create fast, secure, and widely scalable web applications. It provides application acceleration, SSL offloading, and global load balancing with instant failover.

Global Load Balancing

Distributes traffic across multiple backend pools worldwide for optimal performance and availability.

SSL Offloading

Terminates SSL connections at the edge, reducing backend server load and improving performance.

Web Application Firewall

Protects applications from common web vulnerabilities and attacks at the edge.

Content Caching

Caches static content at edge locations for faster content delivery to users.

2. Requirements Mapping to Azure Front Door Features

Understanding how business requirements map to Azure Front Door capabilities is crucial for effective design:

graph LR A[Business Requirements] --> B[Performance Requirements] A --> C[Security Requirements] A --> D[Availability Requirements] A --> E[Scalability Requirements] B --> F[Global CDN] B --> G[Dynamic Site Acceleration] B --> H[Protocol Optimization] C --> I[WAF Protection] C --> J[SSL/TLS Termination] C --> K[DDoS Protection] D --> L[Health Probes] D --> M[Automatic Failover] D --> N[Multi-Region Backends] E --> O[Auto-scaling] E --> P[Load Balancing] E --> Q[Traffic Routing] F --> R[Azure Front Door Features] G --> R H --> R I --> R J --> R K --> R L --> R M --> R N --> R O --> R P --> R Q --> R

Requirements Mapping Explanation:

This diagram illustrates how different business requirements map to Azure Front Door features. Performance requirements drive the need for CDN, acceleration, and optimization features. Security requirements are addressed through WAF, SSL termination, and DDoS protection. Availability requirements are met through health monitoring, failover capabilities, and multi-region support. Scalability requirements are handled through auto-scaling, load balancing, and intelligent traffic routing.

Detailed Requirements Mapping

Low Latency → Edge Locations

Requirement: Sub-100ms response times globally
Solution: 100+ edge locations worldwide with anycast routing

High Availability → Multi-Region Failover

Requirement: 99.99% uptime SLA
Solution: Automatic failover between backend pools across regions

Security → WAF + SSL

Requirement: Protection against web attacks
Solution: Web Application Firewall with custom rules and SSL termination

Scalability → Global Load Balancing

Requirement: Handle traffic spikes automatically
Solution: Intelligent load balancing with session affinity options

3. Architecture Design

Azure Front Door architecture consists of multiple components working together to provide a comprehensive global application delivery solution.

graph TB subgraph "User Layer" U1[Mobile Users] U2[Desktop Users] U3[API Clients] end subgraph "Azure Front Door" FD[Front Door Service] subgraph "Edge Locations" E1[North America PoP] E2[Europe PoP] E3[Asia PoP] end subgraph "Security Layer" WAF[Web Application Firewall] SSL[SSL Termination] DDOS[DDoS Protection] end end subgraph "Backend Pools" subgraph "Primary Region - East US" P1[App Service 1] P2[App Service 2] P3[Storage Account] end subgraph "Secondary Region - West Europe" S1[App Service 3] S2[App Service 4] S3[Storage Account] end subgraph "Tertiary Region - Southeast Asia" T1[App Service 5] T2[App Service 6] T3[Storage Account] end end U1 --> E1 U2 --> E2 U3 --> E3 E1 --> FD E2 --> FD E3 --> FD FD --> WAF WAF --> SSL SSL --> DDOS DDOS --> P1 DDOS --> P2 DDOS --> P3 DDOS --> S1 DDOS --> S2 DDOS --> S3 DDOS --> T1 DDOS --> T2 DDOS --> T3

Architecture Components Explanation:

This architecture diagram shows the complete Azure Front Door solution structure. Users connect to the nearest Point of Presence (PoP) for optimal performance. The Front Door service routes traffic through security layers including WAF, SSL termination, and DDoS protection before reaching backend pools distributed across multiple Azure regions. This design ensures high availability, security, and performance through geographic distribution and redundancy.

4. Traffic Flow Diagrams

Normal Traffic Flow

sequenceDiagram participant U as User participant E as Edge Location participant FD as Front Door participant WAF as Web App Firewall participant BE as Backend Pool participant HS as Health Service Note over U,HS: Normal Request Flow U->>E: 1. HTTPS Request E->>FD: 2. Route to Front Door FD->>WAF: 3. Security Check WAF->>FD: 4. Request Approved FD->>HS: 5. Check Backend Health HS->>FD: 6. Healthy Backends List FD->>BE: 7. Forward Request BE->>FD: 8. Response FD->>E: 9. Cache & Forward E->>U: 10. HTTPS Response Note over U,HS: Cache Hit Scenario U->>E: 11. Subsequent Request Note over E: Content in Cache E->>U: 12. Cached Response

Normal Traffic Flow Explanation:

This sequence diagram illustrates the typical request flow through Azure Front Door. When a user makes a request, it's routed to the nearest edge location, then through Front Door's security layers including WAF inspection. The system checks backend health before routing to the optimal backend. Responses are cached at the edge for subsequent requests, significantly improving performance for future users.

Failover Traffic Flow

sequenceDiagram participant U as User participant FD as Front Door participant P as Primary Backend participant S as Secondary Backend participant M as Health Monitor Note over U,M: Failover Scenario U->>FD: 1. Request FD->>M: 2. Check Primary Health M->>FD: 3. Primary Unhealthy FD->>S: 4. Route to Secondary S->>FD: 5. Response FD->>U: 6. Success Response Note over U,M: Health Recovery M->>P: 7. Health Probe P->>M: 8. Health OK M->>FD: 9. Primary Recovered Note over U,M: Traffic Restoration U->>FD: 10. New Request FD->>P: 11. Route to Primary P->>FD: 12. Response FD->>U: 13. Success Response

Failover Traffic Flow Explanation:

This diagram shows how Azure Front Door handles backend failures. When the health monitor detects an unhealthy primary backend, traffic is automatically routed to healthy secondary backends. The system continuously monitors backend health and automatically restores traffic to the primary backend once it recovers, ensuring high availability with minimal user impact.

Geographic Load Balancing Flow

graph TB subgraph "Global Users" U1[US Users] U2[EU Users] U3[Asia Users] end subgraph "Front Door Routing Logic" FD[Front Door Service] LB[Load Balancer] GEO[Geographic Routing] PERF[Performance Routing] end subgraph "Backend Regions" US[US East Backend Pool] EU[West Europe Backend Pool] ASIA[Southeast Asia Backend Pool] end U1 --> FD U2 --> FD U3 --> FD FD --> LB LB --> GEO LB --> PERF GEO --> US GEO --> EU GEO --> ASIA PERF --> US PERF --> EU PERF --> ASIA US --> U1 EU --> U2 ASIA --> U3

Geographic Load Balancing Explanation:

This diagram demonstrates how Azure Front Door implements intelligent geographic load balancing. Users are automatically routed to the nearest healthy backend based on both geographic proximity and real-time performance metrics. This approach minimizes latency while ensuring optimal resource utilization across all regions.

SSL/TLS Termination Flow

sequenceDiagram participant C as Client participant E as Edge Location participant FD as Front Door participant B as Backend Note over C,B: SSL Handshake at Edge C->>E: 1. TLS ClientHello E->>C: 2. TLS ServerHello + Certificate C->>E: 3. Key Exchange E->>C: 4. TLS Handshake Complete Note over C,B: Encrypted Application Data C->>E: 5. Encrypted HTTPS Request E->>FD: 6. Decrypted HTTP Request Note over C,B: Backend Communication FD->>B: 7. HTTP/HTTPS to Backend B->>FD: 8. HTTP Response FD->>E: 9. HTTP Response E->>C: 10. Encrypted HTTPS Response

SSL/TLS Termination Flow Explanation:

This sequence shows how Azure Front Door handles SSL termination at the edge. The TLS handshake occurs between the client and the edge location, reducing latency and offloading encryption overhead from backend servers. The edge location decrypts incoming requests and can communicate with backends using either HTTP or HTTPS, providing flexibility in backend configuration while maintaining security.

WAF Protection Flow

flowchart TD A[Incoming Request] --> B{WAF Analysis} B -->|Clean Request| C[Allow to Backend] B -->|Malicious Pattern| D[Block Request] B -->|Suspicious| E[Rate Limiting Check] E -->|Within Limits| F[Log & Allow] E -->|Exceeds Limits| G[Throttle/Block] C --> H[Backend Processing] D --> I[Return 403 Forbidden] F --> H G --> J[Return 429 Too Many Requests] H --> K[Response to Client] I --> L[Security Log Entry] J --> L L --> M[Azure Monitor/Sentinel]

WAF Protection Flow Explanation:

This flowchart illustrates how Azure Front Door's Web Application Firewall processes incoming requests. Each request undergoes security analysis using OWASP rules and custom policies. Clean requests proceed to backends, while malicious requests are blocked. Suspicious requests may trigger rate limiting. All security events are logged to Azure Monitor for analysis and alerting, providing comprehensive protection and visibility.

5. Implementation Guide

Implementing Azure Front Door requires careful planning and step-by-step configuration. Here's a comprehensive implementation approach:

Command Execution Flow and Dependencies

graph TB subgraph "Phase 1: Foundation Setup" A1[az login] --> A2[az account set --subscription] A2 --> A3["az group create
--name rg-frontdoor-prod
--location 'East US'"] A3 --> A4["az afd profile create
--profile-name afd-myapp-prod
--sku Standard_AzureFrontDoor"] end subgraph "Phase 2: Endpoint & Origin Groups" A4 --> B1["az afd endpoint create
--endpoint-name myapp-endpoint
--profile-name afd-myapp-prod"] A4 --> B2["az afd origin-group create
--origin-group-name primary-backend-pool
--probe-path /health"] A4 --> B3["az afd origin-group create
--origin-group-name secondary-backend-pool
--probe-path /health"] end subgraph "Phase 3: Backend Origins" B2 --> C1["az afd origin create
--origin-name eastus-backend
--origin-group-name primary-backend-pool
--host-name myapp-eastus.azurewebsites.net
--priority 1"] B3 --> C2["az afd origin create
--origin-name westeurope-backend
--origin-group-name secondary-backend-pool
--host-name myapp-westeurope.azurewebsites.net
--priority 2"] end subgraph "Phase 4: Routing Configuration" B1 --> D1["az afd custom-domain create
--custom-domain-name myapp-custom-domain
--host-name www.myapp.com
(Optional)"] B1 --> D2["az afd route create
--route-name main-route
--origin-group primary-backend-pool
--patterns-to-match /*"] B1 --> D3["az afd route create
--route-name api-route
--origin-group primary-backend-pool
--patterns-to-match /api/*"] B1 --> D4["az afd route create
--route-name static-content-route
--origin-group primary-backend-pool
--patterns-to-match /static/*,/images/*"] end subgraph "Phase 5: Security (WAF)" A3 --> E1["az network front-door waf-policy create
--name MyAppWAFPolicy
--sku Standard_AzureFrontDoor
--mode Prevention"] E1 --> E2["az network front-door waf-policy managed-rules add
--type Microsoft_DefaultRuleSet
--version 2.1
--action Block"] E1 --> E3["az network front-door waf-policy managed-rules add
--type Microsoft_BotManagerRuleSet
--version 1.0
--action Block"] E1 --> E4["az network front-door waf-policy rule create
--name RateLimitRule
--rule-type RateLimitRule
--rate-limit-threshold 100"] E4 --> E5["az network front-door waf-policy rule match-condition add
--name RateLimitRule
--match-variable RemoteAddr"] E1 --> E6["az network front-door waf-policy rule create
--name GeoBlockRule
--rule-type MatchRule
--action Block"] E6 --> E7["az network front-door waf-policy rule match-condition add
--name GeoBlockRule
--operator GeoMatch
--match-values CN,RU"] E7 --> E8["az afd security-policy create
--security-policy-name MyAppSecurityPolicy
--domains myapp-endpoint
--waf-policy MyAppWAFPolicy"] end subgraph "Phase 6: Caching Rules" A4 --> F1["az afd rule-set create
--rule-set-name CachingRules
--profile-name afd-myapp-prod"] F1 --> F2["az afd rule create
--rule-name StaticContentCaching
--rule-set-name CachingRules
--cacheDuration 1.00:00:00
--matchValues css,js,png,jpg"] F1 --> F3["az afd rule create
--rule-name APINoCaching
--rule-set-name CachingRules
--cacheBehavior BypassCache
--matchValues /api/"] F3 --> F4["az afd route update
--route-name main-route
--rule-sets CachingRules"] end subgraph "Phase 7: Monitoring" A4 --> G1["az monitor diagnostic-settings create
--name FrontDoorDiagnostics
--logs FrontDoorAccessLog,FrontDoorHealthProbeLog"] G1 --> G2["az monitor metrics alert create
--name 'Front Door Health Probe Failure'
--condition 'avg OriginHealthPercentage < 50'"] G1 --> G3["az monitor metrics alert create
--name 'Front Door High Error Rate'
--condition 'avg Percentage4XX > 10'"] end subgraph "Phase 8: Testing & Validation" G3 --> H1["curl -I https://myapp-endpoint.azurefd.net"] H1 --> H2["az network front-door waf-policy show
--query policySettings.mode"] H2 --> H3["az afd route list
--endpoint-name myapp-endpoint
--output table"] H3 --> H4["az afd origin show
--origin-name eastus-backend
--query enabledState"] H4 --> H5["az afd endpoint purge
--content-paths /*"] end %% Dependencies between phases D2 --> E8 D3 --> E8 D4 --> E8 C1 --> D2 C1 --> D3 C1 --> D4 C2 --> D2 C2 --> D3 C2 --> D4

Command Flow and Dependencies Explanation:

This comprehensive diagram shows the exact order and dependencies for Azure Front Door implementation. Each phase builds upon the previous ones:

Phase 1 (Foundation): Establishes authentication, subscription context, resource group, and Front Door profile
Phase 2 (Structure): Creates endpoint and origin groups that will contain the backends
Phase 3 (Backends): Adds actual backend servers to the origin groups with priority settings
Phase 4 (Routing): Configures how traffic flows from endpoint to backends with custom domains and route patterns
Phase 5 (Security): Implements WAF protection with multiple rule types and associates with endpoints
Phase 6 (Performance): Sets up caching rules and associates them with routes
Phase 7 (Monitoring): Enables logging and alerting for operational visibility
Phase 8 (Validation): Tests the complete configuration to ensure proper functionality

The arrows show strict dependencies - commands must be executed in this order for successful deployment. Key command parameters are included to show exactly what each step configures.

Implementation Architecture

graph TB subgraph "Implementation Phases" P1[Phase 1: Planning] P2[Phase 2: Resource Creation] P3[Phase 3: Configuration] P4[Phase 4: Security Setup] P5[Phase 5: Testing & Validation] P6[Phase 6: Go-Live & Monitoring] end subgraph "Phase 1 Activities" P1A[Requirements Analysis] P1B[Architecture Design] P1C[Naming Convention] P1D[Resource Planning] end subgraph "Phase 2 Activities" P2A[Create Resource Group] P2B[Create Front Door Profile] P2C[Configure Endpoints] P2D[Set Up Backend Pools] end subgraph "Phase 3 Activities" P3A[Routing Rules] P3B[Health Probes] P3C[Load Balancing] P3D[Caching Policies] end P1 --> P1A P1 --> P1B P1 --> P1C P1 --> P1D P2 --> P2A P2 --> P2B P2 --> P2C P2 --> P2D P3 --> P3A P3 --> P3B P3 --> P3C P3 --> P3D P1 --> P2 P2 --> P3 P3 --> P4 P4 --> P5 P5 --> P6

Implementation Phases Explanation:

This diagram outlines the systematic approach to implementing Azure Front Door. The implementation is divided into six distinct phases, each with specific activities. Phase 1 focuses on planning and design, Phase 2 on resource creation, Phase 3 on core configuration, Phase 4 on security implementation, Phase 5 on testing and validation, and Phase 6 on deployment and ongoing monitoring. This structured approach ensures nothing is overlooked and provides clear milestones.

6. Configuration Commands

Here are comprehensive Azure CLI commands for implementing Azure Front Door:

Initial Setup and Resource Creation

Azure Login and Subscription Setup

# Login to Azure
az login

# Set subscription
az account set --subscription "your-subscription-id"
                

Purpose: These commands establish the foundation for all Azure CLI operations by authenticating your session and selecting the appropriate subscription context. The login command opens a browser window for secure authentication, while the subscription command ensures all subsequent resource operations target the correct Azure subscription.

Parameters Explanation:

az login - Authenticates your session with Azure using browser-based login
--subscription - Specifies which Azure subscription to use for subsequent commands

Resource Group Creation

# Create resource group
az group create \
    --name "rg-frontdoor-prod" \
    --location "East US" \
    --tags environment=production service=frontdoor
                

Purpose: Creates a logical container that holds related Azure resources for the Front Door solution. Resource groups provide a way to organize, manage, and control access to resources as a unit. The naming convention follows Azure best practices, and tags enable cost tracking and resource management across environments.

Parameters Explanation:

--name - Name of the resource group (using naming convention: rg-service-environment)
--location - Azure region where metadata will be stored (doesn't affect Front Door global distribution)
--tags - Key-value pairs for resource organization and cost tracking

Front Door Profile Creation

# Create Front Door profile (Standard/Premium tier)
az afd profile create \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --sku "Standard_AzureFrontDoor" \
    --tags environment=production service=frontdoor
                

Purpose: Creates the main Front Door service instance that will handle global traffic distribution. The profile acts as the top-level container for all Front Door configurations including endpoints, routing rules, and security policies. Choosing the right SKU is crucial as it determines available features - Standard provides core functionality while Premium adds advanced security capabilities.

Parameters Explanation:

--profile-name - Unique name for the Front Door profile
--resource-group - Resource group to contain the Front Door profile
--sku - Service tier: Standard_AzureFrontDoor (basic features) or Premium_AzureFrontDoor (advanced security)
--tags - Metadata tags for resource management and billing

Endpoint and Origin Configuration

Front Door Endpoint Creation

# Create Front Door endpoint
az afd endpoint create \
    --endpoint-name "myapp-endpoint" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --location "Global" \
    --tags environment=production
                

Purpose: Creates the public-facing endpoint that users will connect to access your application. This endpoint becomes the entry point to your application through Azure's global edge network. The endpoint receives a globally unique FQDN (like myapp-endpoint.azurefd.net) that automatically routes users to the nearest Point of Presence for optimal performance.

Parameters Explanation:

--endpoint-name - Unique name for the endpoint (becomes part of the FQDN)
--profile-name - Front Door profile to create the endpoint in
--resource-group - Resource group containing the Front Door profile
--location - "Global" indicates this is a globally distributed endpoint
--tags - Resource tags for organization

Primary Origin Group Creation

# Create origin group for primary backend
az afd origin-group create \
    --origin-group-name "primary-backend-pool" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --probe-request-type "HEAD" \
    --probe-protocol "Https" \
    --probe-interval-in-seconds 120 \
    --probe-path "/health" \
    --sample-size 4 \
    --successful-samples-required 3 \
    --additional-latency-in-milliseconds 50
                

Purpose: Creates a logical grouping of backend servers that serve the same content, enabling intelligent load balancing and health monitoring. The origin group defines how Front Door determines which backends are healthy and available to serve traffic. The health probe configuration ensures that unhealthy backends are automatically removed from rotation, providing high availability and fault tolerance.

Parameters Explanation:

--origin-group-name - Logical group name for related backend origins
--probe-request-type - HTTP method for health checks (HEAD is lightweight)
--probe-protocol - Protocol for health probes (Https/Http)
--probe-interval-in-seconds - How often to check backend health (120 seconds)
--probe-path - Endpoint path to test for health status
--sample-size - Number of health probe samples to evaluate
--successful-samples-required - Minimum successful probes to consider backend healthy
--additional-latency-in-milliseconds - Acceptable latency threshold for routing decisions

Primary Backend Origin Creation

# Create origin for East US backend
az afd origin create \
    --origin-name "eastus-backend" \
    --origin-group-name "primary-backend-pool" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --host-name "myapp-eastus.azurewebsites.net" \
    --origin-host-header "myapp-eastus.azurewebsites.net" \
    --http-port 80 \
    --https-port 443 \
    --priority 1 \
    --weight 1000 \
    --enabled-state "Enabled"
                

Purpose: Defines the actual backend server within the origin group that will handle traffic. This command registers your application backend (in this case, an Azure App Service in East US) with Front Door. The priority and weight settings control traffic distribution - priority 1 makes this the preferred backend, while weight determines the proportion of traffic when multiple backends have the same priority.

Parameters Explanation:

--origin-name - Unique name for this specific backend origin
--origin-group-name - Origin group this backend belongs to
--host-name - FQDN of the backend server
--origin-host-header - Host header sent to backend (often same as host-name)
--http-port - Port for HTTP traffic to backend (typically 80)
--https-port - Port for HTTPS traffic to backend (typically 443)
--priority - Priority for traffic routing (1 = highest priority)
--weight - Load balancing weight (higher = more traffic)
--enabled-state - Whether this origin is active (Enabled/Disabled)

Secondary Origin Group for Disaster Recovery

# Create secondary origin group for disaster recovery
az afd origin-group create \
    --origin-group-name "secondary-backend-pool" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --probe-request-type "HEAD" \
    --probe-protocol "Https" \
    --probe-interval-in-seconds 120 \
    --probe-path "/health" \
    --sample-size 4 \
    --successful-samples-required 3 \
    --additional-latency-in-milliseconds 50
                

Purpose: Establishes a secondary backend pool for disaster recovery scenarios, ensuring business continuity if the primary region becomes unavailable. This secondary group uses identical health probe settings to the primary group, maintaining consistent monitoring standards across all backend pools. This configuration enables automatic failover to maintain service availability during regional outages.

Parameters Explanation:

This creates a secondary origin group with identical health probe settings to the primary group. This ensures consistent health monitoring across all backend pools for reliable failover behavior.

Secondary Backend Origin Creation

# Create origin for West Europe backend
az afd origin create \
    --origin-name "westeurope-backend" \
    --origin-group-name "secondary-backend-pool" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --host-name "myapp-westeurope.azurewebsites.net" \
    --origin-host-header "myapp-westeurope.azurewebsites.net" \
    --http-port 80 \
    --https-port 443 \
    --priority 2 \
    --weight 1000 \
    --enabled-state "Enabled"
                

Purpose: Adds a geographically distributed backend server in West Europe to provide regional redundancy and improved performance for European users. The lower priority (2) ensures this origin only receives traffic when higher priority origins are unavailable, making it ideal for disaster recovery scenarios while also serving as a performance optimization for users closer to Europe.

Parameters Explanation:

--priority - Set to 2 (lower priority than primary) for failover scenarios
--host-name - Points to West Europe App Service instance
Other parameters identical to primary origin for consistency

Routing Rules and Load Balancing

Custom Domain Configuration (Optional)

# Create custom domain (optional)
az afd custom-domain create \
    --custom-domain-name "myapp-custom-domain" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --host-name "www.myapp.com" \
    --certificate-type "ManagedCertificate"
                

Purpose: Configures a custom domain name for your application instead of using the default Azure Front Door domain. This provides a branded experience for users and allows you to use your own domain name. Azure can automatically manage SSL certificates for custom domains, handling renewal and security without manual intervention. Before running this command, ensure you have created a CNAME record pointing your domain to the Front Door endpoint.

Parameters Explanation:

--custom-domain-name - Internal name for the custom domain configuration
--host-name - Your actual domain name (requires DNS CNAME pointing to Front Door)
--certificate-type - "ManagedCertificate" (Azure manages SSL) or "CustomerCertificate" (bring your own)

Main Application Route

# Create route for main application
az afd route create \
    --route-name "main-route" \
    --endpoint-name "myapp-endpoint" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --origin-group "primary-backend-pool" \
    --supported-protocols "Http,Https" \
    --patterns-to-match "/*" \
    --forwarding-protocol "HttpsOnly" \
    --link-to-default-domain "Enabled" \
    --https-redirect "Enabled"
                

Purpose: Creates the primary routing rule that directs all incoming traffic to your application backends. This route handles the majority of your application traffic and implements security best practices by enforcing HTTPS. The catch-all pattern "/*" ensures that any request not handled by more specific routes will be processed by this rule, providing comprehensive coverage.

Parameters Explanation:

--route-name - Unique name for this routing rule
--origin-group - Which backend pool to route traffic to
--supported-protocols - Protocols accepted from clients (Http, Https, or both)
--patterns-to-match - URL patterns this route handles ("/*" = all paths)
--forwarding-protocol - Protocol used to backend (HttpsOnly, HttpOnly, or MatchRequest)
--link-to-default-domain - Whether route applies to the default .azurefd.net domain
--https-redirect - Automatically redirect HTTP requests to HTTPS

API-Specific Route

# Create route for API endpoints
az afd route create \
    --route-name "api-route" \
    --endpoint-name "myapp-endpoint" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --origin-group "primary-backend-pool" \
    --supported-protocols "Https" \
    --patterns-to-match "/api/*" \
    --forwarding-protocol "HttpsOnly" \
    --link-to-default-domain "Enabled" \
    --query-string-caching-behavior "IgnoreQueryString"
                

Purpose: Creates a specialized routing rule specifically for API endpoints with configurations optimized for dynamic content. This route ensures API requests are handled securely with HTTPS-only access and appropriate caching behavior. The query string caching behavior is configured to ignore query parameters, preventing inappropriate caching of dynamic API responses that may vary based on request parameters.

Parameters Explanation:

--patterns-to-match - "/api/*" targets only API endpoints
--supported-protocols - "Https" only for API security
--query-string-caching-behavior - "IgnoreQueryString" ensures API responses aren't cached inappropriately

Static Content Route with Caching

# Create route for static content with caching
az afd route create \
    --route-name "static-content-route" \
    --endpoint-name "myapp-endpoint" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --origin-group "primary-backend-pool" \
    --supported-protocols "Https" \
    --patterns-to-match "/static/*,/images/*,/css/*,/js/*" \
    --forwarding-protocol "HttpsOnly" \
    --link-to-default-domain "Enabled" \
    --query-string-caching-behavior "IgnoreQueryString"
                

Purpose: Establishes a dedicated route for static assets like images, stylesheets, and JavaScript files with caching optimizations. This route is designed to maximize performance by aggressively caching static content at edge locations worldwide. The multiple path patterns ensure comprehensive coverage of common static asset locations, reducing origin server load and improving user experience through faster content delivery.

Parameters Explanation:

--patterns-to-match - Multiple patterns separated by commas for static assets
--query-string-caching-behavior - "IgnoreQueryString" optimizes caching for static content
This route is optimized for static assets that benefit from aggressive caching

Security Configuration (WAF)

Basic WAF Policy Creation

# Create WAF policy
az network front-door waf-policy create \
    --resource-group "rg-frontdoor-prod" \
    --name "MyAppWAFPolicy" \
    --sku "Standard_AzureFrontDoor" \
    --disabled false \
    --mode "Prevention"
                

Purpose: Creates a Web Application Firewall policy that provides security protection against common web attacks and vulnerabilities. The WAF acts as a shield between your application and potential threats, filtering malicious traffic before it reaches your backend servers. Setting the mode to "Prevention" ensures that detected threats are actively blocked rather than just logged.

Parameters Explanation:

--name - Unique name for the WAF policy
--sku - Must match Front Door SKU (Standard or Premium)
--disabled - false = policy is active, true = policy is disabled
--mode - "Prevention" blocks attacks, "Detection" only logs them

OWASP Core Rule Set Configuration

# Add managed rule set (OWASP Core Rule Set)
az network front-door waf-policy managed-rules add \
    --policy-name "MyAppWAFPolicy" \
    --resource-group "rg-frontdoor-prod" \
    --type "Microsoft_DefaultRuleSet" \
    --version "2.1" \
    --action "Block"
                

Parameters Explanation:

--type - "Microsoft_DefaultRuleSet" provides OWASP Core Rule Set protection
--version - Rule set version (2.1 is current stable version)
--action - Default action when rules are triggered (Block, Log, Allow)

Bot Protection Rule Set

# Add bot protection rule set
az network front-door waf-policy managed-rules add \
    --policy-name "MyAppWAFPolicy" \
    --resource-group "rg-frontdoor-prod" \
    --type "Microsoft_BotManagerRuleSet" \
    --version "1.0" \
    --action "Block"
                

Parameters Explanation:

--type - "Microsoft_BotManagerRuleSet" detects and blocks malicious bots
--version - "1.0" is the current bot protection version
--action - "Block" prevents malicious bot traffic from reaching backends

Rate Limiting Custom Rule

# Create custom rule for rate limiting
az network front-door waf-policy rule create \
    --resource-group "rg-frontdoor-prod" \
    --policy-name "MyAppWAFPolicy" \
    --name "RateLimitRule" \
    --priority 100 \
    --rule-type "RateLimitRule" \
    --action "Block" \
    --rate-limit-duration-in-minutes 1 \
    --rate-limit-threshold 100
                

Parameters Explanation:

--priority - Rule execution order (lower numbers execute first)
--rule-type - "RateLimitRule" for traffic throttling, "MatchRule" for pattern matching
--rate-limit-duration-in-minutes - Time window for rate calculation (1 minute)
--rate-limit-threshold - Maximum requests allowed per time window (100)

Rate Limiting Match Condition

# Add match condition for rate limiting rule
az network front-door waf-policy rule match-condition add \
    --resource-group "rg-frontdoor-prod" \
    --policy-name "MyAppWAFPolicy" \
    --name "RateLimitRule" \
    --match-variable "RemoteAddr" \
    --operator "IPMatch" \
    --match-values "0.0.0.0/0"
                

Parameters Explanation:

--match-variable - "RemoteAddr" applies rate limit per client IP
--operator - "IPMatch" for IP-based matching
--match-values - "0.0.0.0/0" applies to all IP addresses

Geographic Blocking Rule

# Create custom rule to block specific countries (example)
az network front-door waf-policy rule create \
    --resource-group "rg-frontdoor-prod" \
    --policy-name "MyAppWAFPolicy" \
    --name "GeoBlockRule" \
    --priority 200 \
    --rule-type "MatchRule" \
    --action "Block"
                

Parameters Explanation:

--name - "GeoBlockRule" descriptive name for geographic filtering
--priority - 200 (executes after rate limiting rule)
--rule-type - "MatchRule" for pattern-based blocking

Geographic Match Condition

# Add geo-location match condition
az network front-door waf-policy rule match-condition add \
    --resource-group "rg-frontdoor-prod" \
    --policy-name "MyAppWAFPolicy" \
    --name "GeoBlockRule" \
    --match-variable "RemoteAddr" \
    --operator "GeoMatch" \
    --match-values "CN,RU" \
    --negate true
                

Parameters Explanation:

--operator - "GeoMatch" for country-based filtering
--match-values - ISO country codes to match (CN=China, RU=Russia)
--negate - true means block these countries, false means allow only these countries

WAF Policy Association

# Associate WAF policy with Front Door endpoint
az afd security-policy create \
    --resource-group "rg-frontdoor-prod" \
    --profile-name "afd-myapp-prod" \
    --security-policy-name "MyAppSecurityPolicy" \
    --domains "myapp-endpoint" \
    --waf-policy "/subscriptions/your-subscription-id/resourceGroups/rg-frontdoor-prod/providers/Microsoft.Network/frontdoorwebapplicationfirewallpolicies/MyAppWAFPolicy"
                

Parameters Explanation:

--security-policy-name - Name for the security policy association
--domains - Front Door domains to apply the WAF policy to
--waf-policy - Full resource ID of the WAF policy to associate

Caching and Optimization

Rule Set Creation for Caching

# Create caching rule for static content
az afd rule-set create \
    --rule-set-name "CachingRules" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod"
                

Parameters Explanation:

--rule-set-name - Container for grouping related routing and caching rules
Rule sets allow you to apply multiple rules to routes in an organized manner

Static Content Caching Rule

# Add rule for static content caching
az afd rule create \
    --rule-name "StaticContentCaching" \
    --rule-set-name "CachingRules" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --order 1 \
    --match-processing-behavior "Continue" \
    --actions '[{
        "name": "CacheExpiration",
        "parameters": {
            "cacheBehavior": "Override",
            "cacheType": "All",
            "cacheDuration": "1.00:00:00"
        }
    }]' \
    --conditions '[{
        "name": "UrlFileExtension",
        "parameters": {
            "operator": "Equal",
            "matchValues": ["css", "js", "png", "jpg", "gif", "ico", "svg"],
            "transforms": ["Lowercase"]
        }
    }]'
                

Parameters Explanation:

--order - Rule execution priority within the rule set (1 = highest)
--match-processing-behavior - "Continue" = process other rules, "Stop" = stop after this rule
cacheBehavior - "Override" replaces backend cache headers, "SetIfMissing" only sets if not present
cacheType - "All" caches everything, "Query" includes query strings in cache key
cacheDuration - Cache time in format "days.hours:minutes:seconds" (1 day here)
operator - "Equal" for exact match, "Contains" for partial match
transforms - "Lowercase" normalizes file extensions for consistent matching

API No-Cache Rule

# Create rule for API no-cache
az afd rule create \
    --rule-name "APINoCaching" \
    --rule-set-name "CachingRules" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --order 2 \
    --match-processing-behavior "Continue" \
    --actions '[{
        "name": "CacheExpiration",
        "parameters": {
            "cacheBehavior": "BypassCache",
            "cacheType": "All"
        }
    }]' \
    --conditions '[{
        "name": "UrlPath",
        "parameters": {
            "operator": "BeginsWith",
            "matchValues": ["/api/"],
            "transforms": ["Lowercase"]
        }
    }]'
                

Parameters Explanation:

--order - Set to 2 (executes after static content rule)
cacheBehavior - "BypassCache" prevents caching of API responses
operator - "BeginsWith" matches URLs starting with specified pattern
matchValues - ["/api/"] targets all API endpoints
This ensures dynamic API content is never cached

Rule Set Association with Route

# Associate rule set with route
az afd route update \
    --route-name "main-route" \
    --endpoint-name "myapp-endpoint" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --rule-sets "CachingRules"
                

Parameters Explanation:

--rule-sets - Applies the "CachingRules" rule set to the main route
This enables the caching behavior for all traffic matching the main route
Multiple rule sets can be applied by separating names with commas

Health Monitoring and Diagnostics

Diagnostic Logging Configuration

# Enable diagnostic logging
az monitor diagnostic-settings create \
    --resource "/subscriptions/your-subscription-id/resourceGroups/rg-frontdoor-prod/providers/Microsoft.Cdn/profiles/afd-myapp-prod" \
    --name "FrontDoorDiagnostics" \
    --logs '[{
        "category": "FrontDoorAccessLog",
        "enabled": true,
        "retentionPolicy": {
            "enabled": true,
            "days": 30
        }
    }, {
        "category": "FrontDoorHealthProbeLog",
        "enabled": true,
        "retentionPolicy": {
            "enabled": true,
            "days": 30
        }
    }]' \
    --metrics '[{
        "category": "AllMetrics",
        "enabled": true,
        "retentionPolicy": {
            "enabled": true,
            "days": 30
        }
    }]' \
    --storage-account "your-storage-account-id"
                

Parameters Explanation:

--resource - Full resource ID of the Front Door profile to monitor
FrontDoorAccessLog - Logs all requests processed by Front Door
FrontDoorHealthProbeLog - Logs backend health probe results
retentionPolicy.days - How long to keep logs (30 days for compliance)
AllMetrics - Captures performance metrics like latency, request count, error rates
--storage-account - Where to store the diagnostic data

Health Probe Failure Alert

# Create alerts for health probe failures
az monitor metrics alert create \
    --name "Front Door Health Probe Failure" \
    --resource-group "rg-frontdoor-prod" \
    --scopes "/subscriptions/your-subscription-id/resourceGroups/rg-frontdoor-prod/providers/Microsoft.Cdn/profiles/afd-myapp-prod" \
    --condition "avg OriginHealthPercentage < 50" \
    --description "Alert when origin health drops below 50%" \
    --evaluation-frequency "1m" \
    --window-size "5m" \
    --severity 2 \
    --action-groups "your-action-group-id"
                

Parameters Explanation:

--condition - "avg OriginHealthPercentage < 50" triggers when less than 50% of backends are healthy
--evaluation-frequency - How often to check the condition (every 1 minute)
--window-size - Time window for metric aggregation (5 minutes)
--severity - Alert severity: 0=Critical, 1=Error, 2=Warning, 3=Informational, 4=Verbose
--action-groups - Defines who gets notified and how (email, SMS, webhook, etc.)

High Error Rate Alert

# Create alert for high error rate
az monitor metrics alert create \
    --name "Front Door High Error Rate" \
    --resource-group "rg-frontdoor-prod" \
    --scopes "/subscriptions/your-subscription-id/resourceGroups/rg-frontdoor-prod/providers/Microsoft.Cdn/profiles/afd-myapp-prod" \
    --condition "avg Percentage4XX > 10" \
    --description "Alert when 4XX error rate exceeds 10%" \
    --evaluation-frequency "1m" \
    --window-size "5m" \
    --severity 3 \
    --action-groups "your-action-group-id"
                

Parameters Explanation:

--condition - "avg Percentage4XX > 10" alerts when 4XX errors exceed 10% of total requests
--severity - Set to 3 (Informational) as 4XX errors may indicate client issues, not system failures
Percentage4XX metric tracks client errors (400-499 HTTP status codes)
This helps identify potential application issues or malicious traffic patterns

Validation and Testing Commands

Basic Connectivity Testing

# Test endpoint connectivity
curl -I https://myapp-endpoint.azurefd.net
                

Command Explanation:

curl -I - Sends HTTP HEAD request to test connectivity without downloading content
Returns HTTP headers including status code, server information, and caching headers
Useful for verifying Front Door is responding and SSL certificates are valid

WAF Policy Status Verification

# Check WAF policy status
az network front-door waf-policy show \
    --resource-group "rg-frontdoor-prod" \
    --name "MyAppWAFPolicy" \
    --query "policySettings.mode"
                

Parameters Explanation:

--query - JMESPath query to extract specific information (policy mode)
Returns "Prevention" or "Detection" to confirm WAF operational mode
Helps verify WAF is actively protecting (Prevention) vs. just logging (Detection)

Routing Rules Validation

# Validate routing rules
az afd route list \
    --endpoint-name "myapp-endpoint" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --output table
                

Parameters Explanation:

--output table - Formats output in readable table format
Shows all configured routes, their patterns, and associated origin groups
Useful for verifying routing configuration and troubleshooting traffic flow issues

Origin Health Status Check

# Check origin health status
az afd origin show \
    --origin-name "eastus-backend" \
    --origin-group-name "primary-backend-pool" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --query "enabledState"
                

Parameters Explanation:

--query "enabledState" - Returns "Enabled" or "Disabled" status
Verifies whether the origin is actively receiving traffic
Helps troubleshoot routing issues and failover scenarios

Failover Testing - Disable Primary Origin

# Test failover by disabling primary origin
az afd origin update \
    --origin-name "eastus-backend" \
    --origin-group-name "primary-backend-pool" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --enabled-state "Disabled"
                

Parameters Explanation:

--enabled-state "Disabled" - Temporarily disables the primary origin
Forces traffic to failover to secondary origins for testing
Should be followed by testing to verify failover behavior
Important: Remember to re-enable after testing!

Re-enable Primary Origin

# Re-enable primary origin
az afd origin update \
    --origin-name "eastus-backend" \
    --origin-group-name "primary-backend-pool" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --enabled-state "Enabled"
                

Parameters Explanation:

--enabled-state "Enabled" - Restores the primary origin to service
Traffic will gradually shift back to primary origin based on health probe results
Monitor metrics to ensure smooth traffic restoration

Cache Purging for Testing

# Purge cache for testing
az afd endpoint purge \
    --endpoint-name "myapp-endpoint" \
    --profile-name "afd-myapp-prod" \
    --resource-group "rg-frontdoor-prod" \
    --content-paths "/*"
                

Parameters Explanation:

--content-paths - Specifies which cached content to purge ("/*" = all content)
Forces fresh content fetch from origins on next request
Useful for testing content updates and caching behavior
Can specify specific paths like "/images/*" for targeted purging

7. Security Configuration

Security is paramount in Azure Front Door implementation. Here's a comprehensive security configuration approach:

graph TB subgraph "Security Layers" L1[DDoS Protection Basic] L2[Web Application Firewall] L3[SSL/TLS Termination] L4[IP Filtering] L5[Rate Limiting] L6[Geo Filtering] end subgraph "WAF Rule Sets" W1[OWASP Core Rule Set] W2[Microsoft Bot Manager] W3[Custom Rules] W4[Known Bad Actors] end subgraph "Certificate Management" C1[Azure Managed Certificates] C2[Custom Certificates] C3[Certificate Renewal] C4[HTTPS Redirect] end subgraph "Monitoring & Alerts" M1[Security Events] M2[Attack Patterns] M3[Threat Intelligence] M4[Incident Response] end L2 --> W1 L2 --> W2 L2 --> W3 L2 --> W4 L3 --> C1 L3 --> C2 L3 --> C3 L3 --> C4 L1 --> M1 L2 --> M1 L4 --> M1 L5 --> M1 L6 --> M1 M1 --> M2 M2 --> M3 M3 --> M4

Security Configuration Explanation:

This diagram illustrates the comprehensive security architecture for Azure Front Door. Multiple security layers work together to provide defense in depth. DDoS protection is automatically included, while WAF provides application-layer protection using multiple rule sets. SSL/TLS termination ensures encrypted communications with flexible certificate management options. IP filtering, rate limiting, and geo-filtering provide additional controls. All security events are monitored and can trigger automated responses through integration with Azure Security Center and Sentinel.

Advanced Security Configuration

Premium WAF Policy with Request Body Inspection

# Create advanced WAF policy with exclusions
az network front-door waf-policy create \
    --resource-group "rg-frontdoor-prod" \
    --name "AdvancedWAFPolicy" \
    --sku "Premium_AzureFrontDoor" \
    --disabled false \
    --mode "Prevention" \
    --request-body-check "Enabled" \
    --request-body-limit 128
                

Parameters Explanation:

--sku "Premium_AzureFrontDoor" - Required for advanced security features
--request-body-check "Enabled" - Inspects POST/PUT request bodies for threats
--request-body-limit 128 - Maximum request body size to inspect (KB)
Premium SKU provides additional protection against sophisticated attacks

Managed Rules with Exclusions

# Configure managed rule set with exclusions
az network front-door waf-policy managed-rules add \
    --policy-name "AdvancedWAFPolicy" \
    --resource-group "rg-frontdoor-prod" \
    --type "Microsoft_DefaultRuleSet" \
    --version "2.1" \
    --action "Block" \
    --exclusions '[{
        "matchVariable": "RequestHeaderNames",
        "selectorMatchOperator": "Equals",
        "selector": "User-Agent"
    }]'
                

Parameters Explanation:

--exclusions - Defines what to exclude from WAF inspection
matchVariable - "RequestHeaderNames" excludes specific headers from inspection
selectorMatchOperator - "Equals" for exact match, "Contains" for partial
selector - "User-Agent" header excluded (prevents false positives from legitimate user agents)

IP Allowlist Security Rule

# Create IP allowlist rule
az network front-door waf-policy rule create \
    --resource-group "rg-frontdoor-prod" \
    --policy-name "AdvancedWAFPolicy" \
    --name "IPAllowlistRule" \
    --priority 10 \
    --rule-type "MatchRule" \
    --action "Allow"
                

Parameters Explanation:

--priority 10 - Very low priority number (executes first)
--action "Allow" - Explicitly allows traffic from trusted IPs
Allowlist rules should have highest priority to bypass other restrictions

IP Allowlist Match Condition

# Add IP allowlist condition
az network front-door waf-policy rule match-condition add \
    --resource-group "rg-frontdoor-prod" \
    --policy-name "AdvancedWAFPolicy" \
    --name "IPAllowlistRule" \
    --match-variable "RemoteAddr" \
    --operator "IPMatch" \
    --match-values "203.0.113.0/24,198.51.100.0/24"
                

Parameters Explanation:

--match-values - CIDR blocks for trusted IP ranges
"203.0.113.0/24" - Example trusted corporate network range
"198.51.100.0/24" - Example partner network range
Multiple IP ranges separated by commas for comprehensive allowlisting

\ --action "Block" \ --exclusions '[{ "matchVariable": "RequestHeaderNames", "selectorMatchOperator": "Equals", "selector": "User-Agent" }]' # Create IP allowlist rule az network front-door waf-policy rule create \ --resource-group "rg-frontdoor-prod" \ --policy-name "AdvancedWAFPolicy" \ --name "IPAllowlistRule" \ --priority 10 \ --rule-type "MatchRule" \ --action "Allow" # Add IP allowlist condition az network front-door waf-policy rule match-condition add \ --resource-group "rg-frontdoor-prod" \ --policy-name "AdvancedWAFPolicy" \ --name "IPAllowlistRule" \ --match-variable "RemoteAddr" \ --operator "IPMatch" \ --match-values "203.0.113.0/24,198.51.100.0/24"

Table of Contents

1. Azure Front Door Overview

Global Load Balancing

SSL Offloading

Web Application Firewall

Content Caching

2. Requirements Mapping to Azure Front Door Features

Detailed Requirements Mapping

Low Latency → Edge Locations

High Availability → Multi-Region Failover

Security → WAF + SSL

Scalability → Global Load Balancing

3. Architecture Design

4. Traffic Flow Diagrams

Normal Traffic Flow

Failover Traffic Flow

Geographic Load Balancing Flow

SSL/TLS Termination Flow

WAF Protection Flow

5. Implementation Guide

Command Execution Flow and Dependencies

Implementation Architecture

6. Configuration Commands

Initial Setup and Resource Creation

Azure Login and Subscription Setup

Resource Group Creation

Front Door Profile Creation

Endpoint and Origin Configuration

Front Door Endpoint Creation

Primary Origin Group Creation

Primary Backend Origin Creation

Secondary Origin Group for Disaster Recovery

Secondary Backend Origin Creation

Routing Rules and Load Balancing

Custom Domain Configuration (Optional)

Main Application Route

API-Specific Route

Static Content Route with Caching

Security Configuration (WAF)

Basic WAF Policy Creation

OWASP Core Rule Set Configuration

Bot Protection Rule Set

Rate Limiting Custom Rule

Rate Limiting Match Condition

Geographic Blocking Rule

Geographic Match Condition

WAF Policy Association

Caching and Optimization

Rule Set Creation for Caching

Static Content Caching Rule

API No-Cache Rule

Rule Set Association with Route

Health Monitoring and Diagnostics

Diagnostic Logging Configuration

Health Probe Failure Alert

High Error Rate Alert

Validation and Testing Commands

Basic Connectivity Testing

WAF Policy Status Verification

Routing Rules Validation

Origin Health Status Check

Failover Testing - Disable Primary Origin

Re-enable Primary Origin

Cache Purging for Testing

7. Security Configuration

Advanced Security Configuration

Premium WAF Policy with Request Body Inspection

Managed Rules with Exclusions

IP Allowlist Security Rule

IP Allowlist Match Condition

8. Monitoring and Analytics

Advanced Monitoring Configuration

Performance Optimization Commands

Conclusion

Key Benefits Achieved

Best Practices Implemented