Azure Front Door provides a global, scalable entry point for your applications—combining load balancing, application acceleration, and security features on Microsoft’s global network.
Learning objectives (what you’ll learn)
- Understand the role and advantages of Azure Front Door as a global Layer 7 entry point.
- Compare the Standard and Premium SKUs to choose the right option for your scenario.
- Deploy Azure Front Door using Quick (wizard) and Custom (full configuration) creation flows.
- Configure routing rules, path-based routing, host/header matches, and secure redirection (e.g., HTTP → HTTPS).
- Define backend endpoints, origin types, backend pools, and host header settings.
- Configure health probes for reliable failover and availability.
- Apply SSL/TLS certificates and enable secure end-to-end connections.
What Front Door provides (high level)
- Global load balancing and edge routing using Microsoft’s POPs for improved latency and availability.
- Layer 7 intelligent routing: path-based, header-based, and priority/fallback routing.
- Performance features: caching at the edge, TLS termination at POPs, and connection optimizations.
- Security features: TLS termination, Web Application Firewall (WAF) integration, bot protection, and advanced policy controls (Premium).
Comparing SKUs
Use the table below to quickly compare core differences between the Standard and Premium SKUs. Choose Standard for common global load balancing and acceleration needs; choose Premium when you require advanced security controls and deeper integration with private origins.Deployment approaches
Decide between a quick setup for simple use cases and a custom setup for production-ready, complex architectures.
Quick creation is ideal to validate concepts quickly; custom creation gives you control over frontend hosts, detailed routing, probe tuning, and policy applications recommended for production.
Routing, redirects, and request transforms
Routing rules determine how Front Door matches and forwards requests. Common patterns:- Path-based routing: route
/api/*to API backends and/static/*to CDN-backed storage. - Header-based matches: route based on
Host,User-Agent, or custom headers. - Priority & fallback: primary backend with one or more fallback pools when the primary is unhealthy.
- Redirect rules: enforce
HTTP → HTTPS, canonical hostnames, or legacy path redirects. - Rewrite rules: rewrite request/response headers, or modify URLs/paths before forwarding to the origin.
- Use redirect rules to enforce HTTPS and canonical hostnames for SEO and user experience.
- Use rewrite rules only when backends require a specific host header or path format.
Backends and origin types
Front Door supports a variety of origin types. Typical origins include:- Azure App Service
- Azure Storage static websites
- Public IP addresses
- Virtual machines
- Kubernetes ingress controllers
- External hostnames and third-party origins
- Load balancing settings (priority, weight, session affinity)
- Health probe settings (protocol, path, interval)
- Host header behavior (use incoming host, custom host header, or override with origin hostname)
- Public static assets → Azure Storage static website or CDN
- API endpoints → App Service or Kubernetes ingress
- Private/internal services → Premium SKU with private origin support
Health probes
Health probes are essential for automated failover and availability. Configure probes to match the health-check endpoints implemented by your application. Probe settings to tune:- Protocol:
HTTPorHTTPS - Path: e.g.,
/healthzor/status - Interval: probe frequency (seconds)
- Timeout: how long to wait for a response
- Unhealthy threshold: number of consecutive failures before marking origin unhealthy
- Healthy threshold: number of successes to mark origin healthy again
Tune probes so that transient errors don’t cause unnecessary failovers but failures are detected quickly enough for good availability.
SSL/TLS and secure end-to-end
Front Door supports TLS termination at the edge and secure connections to backends. Key options:- Edge TLS termination: Azure-managed certificates (auto-renewed) or bring-your-own certificate.
- End-to-end TLS: Front Door communicates with your origins over HTTPS; you can set a custom host header if the backend needs a specific hostname.
- TLS policy: select allowed TLS versions and cipher suites to meet compliance and security posture.
- Use Azure-managed certificates for most public endpoints to simplify lifecycle management.
- For sensitive workloads or private origins, enable end-to-end TLS and validate backend certificates.
- Review allowed TLS versions and disable older, unsafe versions (e.g., TLS 1.0/1.1).
Recommended design checklist
- Choose SKU based on security and private-origin needs (Standard vs Premium).
- Define frontend hosts (custom domains) and attach managed certificates.
- Create backend pools with multiple origins and appropriate health probes.
- Implement routing rules: path-based, header-based, and priority/fallback policies.
- Configure caching and compression at the edge for static content.
- Apply WAF rules and bot protections as required.
- Monitor metrics and logs (Front Door logs, WAF logs, Application Insights) to detect anomalies.
Links and references
- Azure Front Door overview: https://learn.microsoft.com/azure/frontdoor/front-door-overview
- Front Door Standard/Premium documentation: https://learn.microsoft.com/azure/frontdoor/front-door-sku-comparison
- Azure Web Application Firewall (WAF): https://learn.microsoft.com/azure/web-application-firewall/
- TLS best practices: https://learn.microsoft.com/security/zero-trust/overview
- Azure managed certificates: https://learn.microsoft.com/azure/frontdoor/front-door-managed-certificates