Learn
Best CDN for Video Streaming in 2026: Full Comparison with Real Performance Data
Best CDN for Video Streaming in 2026: Full Comparison with Real Performance Data If you are choosing the best CDN for ...
A single misconfigured query string caching rule on Azure Front Door can fragment your cache into thousands of useless variants, each one a cold miss that hammers your origin. In Q1 2026, one SaaS platform traced a 38% spike in origin load to exactly that: a marketing team appending UTM parameters, and a default query string caching mode silently creating a unique cache key per click. Fixing the Azure CDN caching rules took ten minutes. The origin bill dropped by $4,200 that month. This article gives you the playbook to audit, configure, and pressure-test your Azure CDN cache configuration so problems like that never reach production. You will get a rules engine decision matrix, query string strategy selector, purge architecture for zero-downtime deployments, and a failure-mode section drawn from real operational patterns.

Microsoft consolidated Azure CDN from Verizon and Akamai SKUs into Azure Front Door Standard and Premium tiers throughout 2025. As of May 2026, new Azure CDN classic profiles can no longer be created; existing ones still function but receive no feature updates. Every new deployment lands on Azure Front Door, and that shift changes how you think about Azure CDN caching rules.
The most consequential 2026 update is the expanded rules engine in Front Door Standard, which now supports up to 25 conditions per rule and 10 rule sets per endpoint. Premium still offers the deeper condition set (socket address, SSL protocol, server port), but Standard closed the gap significantly. Origin group health probes also gained per-route override, which means your caching tier can health-check independently from your API tier.
Cache durations now respect a three-layer precedence: origin Cache-Control headers, Front Door caching rules, and the browser TTL override. Understanding that hierarchy is non-negotiable, because a misconfigured override silently wins.
Front Door evaluates caching behavior in a specific order, and the first match wins. Here is the effective precedence as of 2026:
| Priority | Source | Behavior |
|---|---|---|
| 1 (highest) | Rules Engine route override | Explicitly sets or disables caching; overrides everything below |
| 2 | Route-level caching toggle | Enables or disables caching for the entire route |
| 3 | Origin Cache-Control / Expires | Respected if no rules engine override exists and "Honor origin" is set |
| 4 (lowest) | Front Door default | Three days for most content types if no other directive exists |
The mistake engineers make most often: setting a generous max-age at the origin but leaving the route-level toggle on "Override always, 1 day." The route wins. Your carefully tuned origin headers are ignored. Audit route-level settings first.
How to configure Azure CDN query string caching is the single highest-impact decision for cache hit ratio on most web properties. Front Door offers three modes: Ignore Query String, Include All, and Include Specified. Here is when each one earns its place.
Best for static assets where query parameters serve only as cache busters or analytics trackers (utm_source, fbclid). All parameter variations resolve to one cache entry. This mode alone can lift cache hit ratios by 15–30% on marketing-heavy sites, based on 2026 operational data from teams running Front Door Standard at scale.
Necessary when query parameters produce genuinely different responses: paginated API results, search results, filtered catalog pages. The risk is cache fragmentation. If your parameter space is large, your effective hit ratio drops toward zero. Monitor x-cache headers closely.
The surgical option. You declare exactly which parameters matter for content variation (locale, sku, page) and Front Door ignores the rest. This is the right default for most applications in 2026. It requires you to know your parameter space, but it gives you the highest hit ratio without serving wrong content.
The rules engine is where Azure Front Door caching becomes programmable. Here are four patterns that solve real problems.
Match on file extension. Set fonts and hashed JS/CSS bundles to 365 days. Set images to 30 days. Set HTML to 5 minutes or no-cache. This is foundational, but too many teams still run a single TTL across everything.
If you serve different image resolutions or markup to mobile versus desktop, add a Vary-equivalent by including a request header condition (e.g., Sec-CH-UA-Mobile) in the cache key. Without this, mobile users get desktop content from cache or vice versa.
For compliance-sensitive content (pricing pages with regional currency, consent banners), add a geo condition to the rules engine. Front Door resolves the client's country at the edge. Combine with Include Specified query string mode so regional variants cache correctly.
Match on URL path prefix (/api/v2/user/, /dashboard/) and set caching behavior to disabled. This prevents accidental caching of personalized or token-bearing responses, which is a security incident waiting to happen.
Cache invalidation remains one of the two hard problems. Azure Front Door cache purge supports three scopes: single URL, wildcard path, and full domain. Propagation completes within 2–10 seconds across all edge locations as of 2026 measurements, a significant improvement from the 30–60 second window of 2024-era classic CDN profiles.
For CI/CD pipelines, the recommended pattern is: deploy new assets with content-hashed filenames, update the manifest or HTML to reference the new filenames, then issue a targeted purge only for the HTML or manifest file. This avoids a full-domain purge, which temporarily spikes origin load.
Automate purges via the Azure Front Door REST API (2024-02-01 API version, stable as of 2026) or through the az afd endpoint purge CLI command. Embed this in your deployment pipeline as a post-deploy step with a conditional gate: purge only if the deployment health check passes. A failed deploy that triggers a premature purge will serve broken references.
This section covers the patterns that generate support tickets, not the patterns in the docs.
If you purge a URL but clients still see old content, check browser cache first. Front Door purge clears the edge; it does not clear the end user's local cache. Set Cache-Control: no-cache on HTML responses so browsers always revalidate, while still letting the edge cache with s-maxage.
Rules engine conditions are evaluated top-down, first match wins. A broad match early in the list can override a specific match below it. Audit rule ordering by exporting the configuration via ARM template and reviewing the priority field numerically.
Common cause: the origin returns Cache-Control: private or Set-Cookie on responses you assumed were public. Front Door will not cache a response with Set-Cookie unless you explicitly override. Instrument origin response headers in a staging environment before promoting rules.
Front Door's purge is asynchronous and globally distributed. If edge locations in a specific geography appear delayed, check whether your Front Door profile's routing preference is set to Microsoft Network versus Internet. Microsoft Network routing keeps traffic on the backbone longer, which may affect purge propagation sequencing to distant PoPs.
| Workload | Query String Mode | Recommended TTL | Purge Strategy | Rules Engine Focus |
|---|---|---|---|---|
| Static marketing site | Ignore | HTML: 5 min; assets: 365 days | Purge HTML on deploy | Geo-based redirects |
| SaaS dashboard | Include Specified | API: no-store; shell: 1 hour | Content-hashed filenames | Auth path bypass |
| Video/media delivery | Include Specified (bitrate, token) | Segments: 24 hours; manifests: 2 sec | Wildcard purge on manifest path | Token auth + cache key |
| Game patch/DLC distribution | Ignore | Binaries: 30 days; index: 5 min | Purge index file on release | Large file optimization enabled |
| E-commerce catalog | Include Specified (sku, locale) | Product pages: 10 min; images: 7 days | Event-driven purge via webhook | Geo pricing + device-aware images |
This matrix is the starting point for your configuration, not the finish line. Every workload has edge cases that only emerge under production traffic.
Azure Front Door Premium runs approximately $330/month for the base fee alone (as of 2026 pricing), plus per-request and per-GB egress charges that add up fast at video or software distribution scale. A 50 TB/month workload on Front Door Premium can exceed $2,500/month in combined base, request, and transfer costs depending on geography mix.
For teams whose primary requirement is high-throughput static delivery rather than Front Door's WAF or Private Link integration, a dedicated CDN with volume-based pricing often makes more sense. BlazingCDN delivers fault tolerance and uptime comparable to CloudFront at a fraction of the cost, starting at $4 per TB for lower volumes and scaling down to $2 per TB at 2 PB/month commitments. For media or software distribution workloads where egress costs dominate the bill, that pricing differential compounds quickly.
In the route configuration, set the caching behavior to "Honor origin." Front Door will then respect Cache-Control and Expires headers from your origin server. Only add a rules engine override when specific paths need a different TTL than the origin provides.
Cache-Control headers are set at the origin and travel with the response. Azure CDN caching rules are configured at the edge and can override, supplement, or defer to those headers. Rules engine directives always win when both are present and the rule action is set to "Override."
As of Q1 2026, purge propagation completes within 2–10 seconds across all edge locations for single-URL and wildcard purges. Full-domain purges may take slightly longer under heavy load. Monitor the purge status via the REST API's async operation endpoint.
No. Azure Front Door caches only GET and HEAD responses. POST, PUT, DELETE, and PATCH requests are always forwarded to the origin. If you need to cache responses to POST-based search queries, consider refactoring the endpoint to accept GET with query parameters.
Enable diagnostic logs and export to Log Analytics. Query for the cacheStatus field: look at the ratio of HIT to MISS and PARTIAL_HIT. Common causes of low hit ratio include high query string cardinality, Set-Cookie in origin responses, and Cache-Control: private leaking from dynamic endpoints into static asset paths.
Azure Front Door does not natively support stale-while-revalidate as a cache directive as of May 2026. If your origin sends that header, Front Door ignores the stale-while-revalidate portion and uses only max-age or s-maxage for TTL calculation. Plan your TTLs accordingly.
Export your Front Door configuration as an ARM template and grep for cacheConfiguration. Count how many routes have an explicit override versus honoring origin. Compare that against your origin's actual Cache-Control headers for the same paths. The delta between what you intend and what the edge enforces is where your next performance gain lives. If your cache hit ratio on static assets is below 90%, the problem is almost certainly in query string mode or rule ordering. Fix those two things before you touch anything else.
Learn
Best CDN for Video Streaming in 2026: Full Comparison with Real Performance Data If you are choosing the best CDN for ...
Learn
Video CDN Providers Compared: BlazingCDN vs Cloudflare vs Akamai for OTT If you are choosing a video CDN for an OTT ...
Learn
Video CDN Pricing Explained: How to Stop Overpaying for Streaming Bandwidth Video already accounts for 38% of total ...