Azure CDN can make your content load faster for users worldwide, but its magic lies in a surprisingly simple mechanism: caching static assets on servers geographically closer to them.
Let’s see it in action. Imagine you have a website hosted in Azure App Service in the West US region. You’ve got some images and CSS files that don’t change often.
# First, create a CDN profile. This is a container for your endpoints.
az cdn profile create --name my-cdn-profile --resource-group my-resource-group --sku Standard_Microsoft
Now, you’ll create an endpoint within that profile. This endpoint is what users will actually interact with, and it points to your origin server (your App Service in this case).
# Create an endpoint for your profile, pointing to your App Service.
# Replace 'your-app-service-name.azurewebsites.net' with your actual App Service hostname.
az cdn endpoint create --name my-cdn-endpoint \
--profile-name my-cdn-profile \
--resource-group my-resource-group \
--origin your-app-service-name.azurewebsites.net \
--origin-host-header your-app-service-name.azurewebsites.net \
--sku Standard_Microsoft
Once this is done, Azure CDN will provision a global network of Points of Presence (PoPs). When a user in, say, Europe requests an image from your-cdn-endpoint.azureedge.net/images/logo.png, the request is routed to the nearest European PoP. If that PoP has a cached copy of logo.png, it serves it directly. If not, it fetches it from your App Service in West US, caches it, and then serves it to the user. Subsequent requests for logo.png from users near that PoP will be served from the cache, drastically reducing latency.
The problem this solves is the inherent latency of fetching content from a single origin server, especially for users geographically distant from it. By distributing static content across a global network and serving it from the edge, CDN minimizes the round-trip time for content delivery.
Internally, when you create a CDN endpoint, Azure provisions resources across its global network. For the Standard_Microsoft SKU, this means leveraging Microsoft’s own global network infrastructure. The origin parameter tells the CDN where to fetch content from when it’s not cached. The origin-host-header is crucial; it’s the Host header that the CDN will send to your origin server. This is important because your origin server might be configured to respond differently based on the Host header, especially if you’re hosting multiple sites or using custom domains.
The levers you control are primarily the CDN profile’s SKU (which determines the network provider and features like rules engine capabilities) and the endpoint’s origin configuration. You can also define caching rules, which dictate how long content stays in the cache and under what conditions. For instance, you might want to cache images for a year but CSS files for only a day. This is managed through Rules Engines, which allow you to create specific conditions and actions.
For example, you can set up a rule that says "IF the request URL path contains '.jpg' THEN set the Cache-Control header to 'public, max-age=31536000' (one year)."
{
"name": "CacheImages",
"order": 100,
"source": "Microsoft",
"conditions": [
{
"name": "UrlPath",
"parameters": {
"matchType": "Wildcard",
"selector": "*.jpg",
"transforms": []
}
}
],
"actions": [
{
"name": "SetResponseHeader",
"parameters": {
"headerName": "Cache-Control",
"value": "public, max-age=31536000",
"odataType": "#Microsoft.Azure.Cdn.Models.DeliveryRuleResponseHeaderActionParameters"
}
}
]
}
You apply these rules to your CDN endpoint via the Azure portal or CLI.
The most surprising thing about CDN is how it handles dynamic content. While primarily for static assets, advanced configurations and specific SKUs (like Standard_Microsoft or Standard_Akamai) can use techniques like route optimization and TCP connection optimization to speed up dynamic content delivery by finding the most efficient path across the internet to your origin, even if they can’t cache the content itself. This isn’t about caching; it’s about intelligent routing.
Once you’ve got your content serving from the CDN, the next common challenge is managing cache invalidation when your content does change.