Optimizing CDN Caching and TTL

1. The Foundation: Time-to-Live (TTL) and Cache-Control

Before we touch any Azure settings, it's vital to understand the core concept that governs all caching: the Time-to-Live (TTL).

A TTL is simply a duration that specifies how long a cached resource should be considered "fresh." While an object is within its TTL, the CDN will serve its cached copy without asking the origin server. Once the TTL expires, the CDN will re-validate the content with the origin server the next time it's requested.

So, how do we set this TTL? The standard mechanism is the Cache-Control HTTP response header sent by the origin server (e.g., your Blob Storage or Web App). This header gives directives to all caches in the request path, including the CDN and the user's browser.

To get a quick but clear overview of the most important Cache-Control directives, let's watch a segment from a system design video.

To summarize the key directives:

• public: The resource can be stored by any cache (ideal for CDNs).
• private: The resource can only be stored by the end-user's private cache (their browser), not a shared cache like a CDN.
• max-age=<seconds>: This is the TTL. For example, max-age=3600 tells the cache to store the resource for 1 hour.
• no-store: The resource must not be cached anywhere.

In a typical .NET application, you would set these response headers in your code to control caching behavior. However, Azure CDN provides its own powerful rules engine to manage caching, which can even override the headers sent by your origin.

2. Overriding Behavior with Azure CDN Caching Rules

What if your origin doesn't send Cache-Control headers, or you want to enforce a different policy without changing your application's code? This is where Azure CDN caching rules come in. The Azure CDN Standard from Microsoft profile, which we are using, offers a flexible rules engine to define caching behavior at the CDN level.

There are two main types of caching rules:

Global Caching Rules

These rules apply to all traffic to your CDN endpoint. You can define a default caching behavior for everything.

The most important setting here is Caching behavior, which has three options:

• Bypass cache: Do not cache. Every request will be sent to the origin.
• Override: Ignore any Cache-Control headers from the origin. Always use the TTL specified in the CDN rule.
• Set if missing: If the origin does not send a Cache-Control header, use the TTL specified in this rule. If it does send one, respect the origin's header. This is often the most flexible and recommended default setting.

Custom Caching Rules

Global rules are a blunt instrument. More often, you'll want different rules for different types of content. For example:

• Cache images and fonts for a very long time (e.g., 90 days).
• Cache CSS and JavaScript files for a medium duration (e.g., 7 days).
• Cache your main HTML pages for a very short time, or not at all (e.g., 1 hour).

Custom rules allow you to do this by matching requests based on conditions like URL Path or File Extension.

Rules are processed in order from top to bottom. A more specific rule placed later in the list can override a more general one.

The following article provides excellent detail on both global and custom rules.

3. The Impact of Query Strings

Query strings (the part of a URL after a ?) present a unique challenge for caching. By default, a CDN treats styles.css?v=1 and styles.css?v=2 as two completely different files. This is useful for "cache busting," where you change the version in the query string to force clients to download a new file.

However, sometimes query strings are used for other purposes, like analytics (index.html?utm_source=newsletter), where the content is identical. In these cases, caching each unique URL is inefficient and reduces your cache hit ratio.

Azure CDN gives you control over this behavior:

• Ignore query strings: The CDN removes the query string before checking its cache. index.html?v=1 and index.html?v=2 are treated as the same file.
• Bypass caching for query strings: The CDN will not cache any content that has a query string.
• Cache every unique URL: The default behavior. Each URL with a different query string is a separate entry in the cache.

4. Hands-On: Configuring Caching Rules with Azure CLI

Let's apply these concepts to the CDN endpoint you created in the previous lesson. We will use the Azure CLI to add two caching rules:

1. A global rule to set a default TTL of 1 day if the origin doesn't specify one.
2. A custom rule to override the cache duration for our sample.txt file to only 10 minutes.

Open your terminal and ensure you have the variables from the last lesson set:

# Ensure these variables match the resources from the previous lesson
RESOURCE_GROUP="your-resource-group-name"
CDN_PROFILE_NAME="cdn-profile-..."
CDN_ENDPOINT_NAME="cdn-endpoint-..."

Step 1: Add a Global Caching Rule

This rule will be processed first (order 1). It matches any request (--operator Any) and sets the cache behavior to SetIfMissing with a duration of 1 day.

az cdn endpoint rule add \
  --resource-group $RESOURCE_GROUP \
  --profile-name $CDN_PROFILE_NAME \
  --name $CDN_ENDPOINT_NAME \
  --order 1 \
  --rule-name "GlobalSetIfMissing" \
  --match-variable RequestUri \
  --operator Any \
  --action-name CacheExpiration \
  --cache-behavior SetIfMissing \
  --cache-duration "1.00:00:00"

Step 2: Add a Custom Caching Rule

This rule will be processed second (order 2). It specifically matches files with a .txt extension and Overrides any other setting, enforcing a 10-minute cache duration.

az cdn endpoint rule add \
  --resource-group $RESOURCE_GROUP \
  --profile-name $CDN_PROFILE_NAME \
  --name $CDN_ENDPOINT_NAME \
  --order 2 \
  --rule-name "CustomTxtFileCache" \
  --match-variable UrlFileExtension \
  --operator Equal \
  --match-values "txt" \
  --transforms "Lowercase" \
  --action-name CacheExpiration \
  --cache-behavior Override \
  --cache-duration "0.00:10:00"

It can take a few minutes for rule changes to propagate through the CDN. Once they have, you can test by accessing your sample.txt file via the CDN URL. Using your browser's developer tools (F12), inspect the network request for the file and look at the response headers. You should see a Cache-Control: public, max-age=600 header (600 seconds = 10 minutes), and an X-Cache header indicating a cache TCP_HIT or TCP_MISS.

Conclusion

You have now gained fine-grained control over your CDN's behavior. By understanding and configuring caching rules, you can make deliberate trade-offs between performance and content freshness.

Key Takeaways:

• Time-to-Live (TTL) dictates how long content is served from the cache before re-validation.
• The origin server's Cache-Control header is the standard way to define TTL.
• Azure CDN Caching Rules (Global and Custom) allow you to enforce caching policies at the edge, even overriding origin headers.
• Global rules set a default behavior, while custom rules target specific content based on paths or file types.
• Query string caching behavior is critical for maximizing your cache hit ratio.

Next Steps

We have spent this module focused on optimizing application performance with caching and CDNs. In the next module, we will pivot to another critical pillar of cloud development: security. Our first lesson will introduce the Microsoft Identity Platform, covering its core components like Microsoft Entra ID, OAuth 2.0, and OpenID Connect, which are the building blocks for securing your applications and APIs.