Azure CDN Profiles and Endpoints

A Content Delivery Network (CDN) is a distributed network of servers placed at geographic Points of Presence (PoPs) close to end users. When a user requests content, the CDN serves it from the nearest PoP cache instead of your origin server. This reduces latency (especially for users far from your origin region), lowers origin server load, and improves resilience. Azure CDN integrates natively with Blob Storage, App Service, and any publicly reachable HTTP origin.

Azure CDN is offered through multiple provider tiers: Azure CDN Standard from Microsoft — the default, tightly integrated option with basic caching rules and HTTP/2 support. Azure CDN Standard from Akamai — broad global PoP coverage with fast propagation. Azure CDN Standard/Premium from Verizon — advanced rules engine and analytics (Premium tier). Each provider has different feature sets and pricing; for most AZ-900 scenarios, Azure CDN Standard from Microsoft is the focus.

An Azure CDN profile is the top-level container that groups CDN endpoints and determines the provider and pricing tier. A CDN endpoint is a specific hostname (e.g. myapp.azureedge.net) that maps to an origin. Each endpoint has its own caching behaviour configuration. One profile can contain multiple endpoints — for example, separate endpoints for static assets, API responses, and video streams with different caching rules for each.

The Time-to-Live (TTL) controls how long a cached response stays in the PoP before it must be refreshed from the origin. You can set caching rules at three levels: global caching rule (applies to all requests on the endpoint), custom rules (match by path pattern or file extension), and query string behaviour (cache separately for each unique query string or ignore query strings). Content-type based TTLs — longer for images, shorter for HTML — are a best practice.

One of the most common Azure CDN configurations uses a Blob Storage container as the origin. Upload static assets (images, CSS, JS, videos) to a storage account, make the container public-readable, and configure a CDN endpoint pointing to the blob's primary endpoint (myaccount.blob.core.windows.net). The CDN caches the blobs at PoPs worldwide, and users download from the nearest PoP rather than the storage region. You can also use a custom origin hostname for static website hosting.

When you update content on the origin (e.g. deploy a new version of a JavaScript file), cached copies in PoPs may serve stale content until TTL expires. Cache purge immediately evicts specified files or all cached content from every PoP, forcing the next request to re-fetch from the origin. You can purge specific URLs, wildcard paths (e.g. /assets/*), or all content on an endpoint. Purge propagation takes 2–3 minutes to reach all PoPs globally.

By default, CDN endpoints use the .azureedge.net domain. To serve content from your own domain (e.g. static.contoso.com), add it as a custom domain on the CDN endpoint by creating a CNAME record pointing to the endpoint hostname. Once added, you can enable HTTPS on the custom domain using either an Azure-managed certificate (free, auto-renewing) or your own certificate stored in Key Vault. HTTPS enforcement redirects HTTP traffic automatically.

Enabling file compression on a CDN endpoint reduces the file size delivered over the network by compressing text-based assets (HTML, CSS, JavaScript, SVG) with gzip or Brotli. The CDN compresses content before caching it at the PoP, so subsequent requests for the same asset receive the compressed version without additional CPU overhead. Compression is particularly impactful for JS bundles that can be 5–10 times smaller after compression.

Geo-filtering on a CDN endpoint allows you to allow or block access to your content from specific countries. This can be used for content licensing compliance (e.g. a video licensed only in certain countries), regulatory requirements, or blocking countries known to be high sources of malicious traffic. Geo-filter rules are configured per country code and per URL path — you can block only a specific content directory rather than the entire endpoint.

Azure CDN provides built-in usage analytics in the portal including bandwidth consumed, hit/miss ratio, total requests, and bandwidth savings versus serving from origin. For Microsoft-tier CDN, you can also send access logs to a Log Analytics workspace or Storage account via diagnostic settings, enabling KQL queries on raw CDN access log data. Analysing cache hit ratios helps you tune TTLs — a low cache-hit ratio means most requests pass through to the origin, defeating the purpose of the CDN.

Azure CDN and Azure Front Door both cache content at PoPs, but they serve different primary purposes. Azure CDN excels at caching and delivering static content from a single origin at low cost. Azure Front Door adds intelligent global load balancing and routing across multiple origin backends, health probes for automatic failover, a built-in Web Application Firewall, and path-based routing — making it the better choice for multi-region active-active web applications. You will often use both in a solution.

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

In this lesson you learned: Azure CDN profiles and endpoints deliver cached content from PoPs close to users to reduce latency, caching rules and TTL control how long content is cached before re-fetching from the origin, and cache purge immediately evicts stale content after origin updates. Next up we explore Azure Front Door for global load balancing and routing across multiple backend origins.