Optimising Performance with CDN Rules

Azure Front Door's rules engine (called Rule sets in Standard/Premium) allows you to intercept and modify HTTP requests and responses at the edge PoP before they are cached or forwarded to the origin. Without a rules engine, you would need to handle tasks like HTTP-to-HTTPS redirects, security response headers, and geo-blocking inside your origin application code — adding latency and coupling security concerns to business logic. Rules at the edge execute faster and reduce origin load.

One of the most common rules engine use cases is enforcing HTTPS. When a client requests your site over HTTP, a redirect rule at the Front Door edge immediately returns a 301 Moved Permanently (or 302 Found) response pointing to the HTTPS URL — without the request ever reaching the origin. This is faster than origin-side redirects and ensures all traffic is encrypted in transit. Configure it as a redirect action on requests where the RequestScheme condition equals HTTP.

Modern browsers support HTTP security headers that prevent common attacks. You can add these headers to all responses using rules engine Append response header actions, without modifying your origin server. Key headers include: Strict-Transport-Security (forces HTTPS for a period), X-Content-Type-Options: nosniff (prevents MIME sniffing), X-Frame-Options: DENY (prevents clickjacking), and Content-Security-Policy (restricts content sources). Adding these at the edge ensures consistent application across all origins.

Rules engine allows you to override the default cache TTL for specific URL patterns. For example, you may want to cache /static/images/* for 30 days but cache /api/* responses for only 60 seconds. Use a match condition on the RequestUri and a Route configuration override action that sets a custom cache duration. This allows fine-grained control over cache behaviour without creating multiple separate routes for each content type.

URL rewrite actions modify the request URL before it is forwarded to the origin without changing the URL the client sees. This is useful for sending requests from one URL structure to a different backend path. For example, rewrite /products/item/{id} to /catalog/v2/products/{id} to accommodate a backend API change without updating client links. URL rewrite is an action in the rules engine that modifies the URL path using string replacement or capture groups.

Geo-filtering at the rules engine level allows you to redirect or block users from specific countries based on the client's IP-derived geo-location. Unlike CDN geo-filtering (which returns 403), rules engine geo-filtering gives you more flexibility — you can redirect blocked countries to a landing page explaining regional availability, or route certain countries to region-specific origin groups (e.g. EU users to EU origins for GDPR compliance). The RemoteAddress geo match uses MaxMind's IP-to-country database.

Rules engine can add, overwrite, or delete request headers before forwarding to the origin. A common use is adding an X-Forwarded-For or a custom header like X-Front-Door-Id so the origin knows requests came through Front Door and can validate them. You can also delete the original Host header and replace it with the origin hostname — important when the origin validates the Host header. This gives you full control over what the origin server sees.

Rules engine conditions can match on request header values, enabling sophisticated routing logic. For example, route requests containing the header X-API-Version: 2 to a different origin group running the v2 API, while requests without that header go to the v1 origin. This enables blue-green API versioning at the edge without requiring separate hostnames for each API version. Header-based routing is also used for A/B testing by routing based on a custom user-segment cookie.

Response compression in Front Door compresses text-based responses (HTML, CSS, JavaScript, JSON) using gzip or Brotli before serving them from PoPs. Compression is most effective for large JS bundles, reducing transfer size by up to 70%. Enable compression in the route settings and specify the MIME types to compress. Compressed content is cached in compressed form at the PoP — so only the first request for each asset triggers compression; subsequent requests serve the cached compressed file instantly.

Origin Shield is an optional additional caching layer that Front Door places between the PoP edge nodes and the origin. When enabled, instead of each of the 100+ edge PoPs independently requesting uncached content from the origin, they all forward cache misses to a single regional origin shield PoP — which then forwards to the origin. This significantly reduces the number of requests hitting the origin (called the origin offload ratio) while still serving content globally from edge PoPs.

Before deploying rules engine changes to production, validate them using the diagnostics and test tools in the portal. The Diagnostic settings blade with detection mode WAF logs shows what rules match. For rules engine, you can also inspect actual request/response headers in the browser's developer tools after deploying to a staging environment, or use curl -v to send specific requests and verify the response headers and redirect behaviour are as expected before switching to production.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: Front Door rules engine handles HTTP-to-HTTPS redirects, security response headers, and cache-TTL overrides at the edge without origin changes, URL rewrite silently modifies request paths forwarded to the origin while URL redirect changes the client-facing URL, and Origin Shield reduces origin load by consolidating cache-miss requests through a regional shield node. Next up we explore Azure AI Services for adding intelligence to your applications.