CDN vs dispatcher config question

Hi @jayv25585659 ,

You can use the CDN to cache static files like CSS, JS, and images for a long TTL, and also to handle things like security, geo-routing, and edge logic. The dispatcher is mainly used to cache dynamic pages, handle AEM-specific cache clearing, and control headers and caching time.

Since your team can easily manage the dispatcher, it makes sense to let dispatcher rules take priority. Use Cache-Control headers from the dispatcher to guide the CDN and avoid setting the same rules in both places.

Thanks.

Hi @jayv25585659 ,

Your instinct is solid, and this is a common challenge in AMS or similar environments where you have limited control over the CDN but full control over the Dispatcher.

General Rule of Thumb: Ownership & Control

Split responsibilities based on who owns what and how frequently things need to change.

Dispatcher (AEM Team-Owned)

Use the Dispatcher to control aspects that:

  - Change often

  - Are tied to content or site logic

  - Require fast iteration by the development team

Typical Dispatcher settings:

  - Caching rules for dynamic HTML (short TTL or no TTL)

  - Cache invalidation logic tied to AEM publishing

  - Headers like Cache-Control, Expires, and X-Dispatcher

  - URL rewrites/redirects specific to AEM paths

  - Whitelisting paths to avoid caching certain responses

  - Security filters (e.g., allowed paths/methods)

CDN (AMS-Owned or 3rd Party)

Use the CDN to handle edge-level concerns that:

  - Don't change often

  - Improve performance, availability, or security

  - Can benefit from global edge presence

Typical CDN responsibilities:

  - Caching static assets (e.g., /etc.clientlibs, images, PDFs) with long TTL

  - Geo-routing / geo-blocking

  - DDoS protection, rate limiting

  - TLS/SSL termination

  - GZIP/Brotli compression

  - Security headers (e.g., Strict-Transport-Security, X-XSS-Protection) – if not set on origin

  - Redirects for vanity domains (e.g., example.com → www.example.com)

Strategy Recommendation

  - Set cache-control headers in Dispatcher → CDN respects and follows those headers.

  - Avoid duplication — don't configure the same logic in both unless there's a fallback reason.

  - Document boundaries clearly between Dispatcher/CDN to avoid confusion.

  - Use Edge Diagnostics (e.g., curl with -I) to confirm header behavior.

Your setup: Dispatcher has priority

You're right:

  - If your team can update Dispatcher without AMS, then set authoritative headers and caching there.

  - Let CDN be “dumb”: just forward and cache based on Dispatcher rules. This avoids bottlenecks.

Regards,
Amit Vishwakarma

Caching strategies in the CDN vs. Dispatcher should be deliberate, and the answer changes depending on your operational needs for control, efficiency, and team agility.

Where to Set Caching—CDN vs Dispatcher

Dispatcher

• Best for:
  • Fine-grained, quickly adjustable control (paths, TTLs, headers)
  • Security filtering (URL/headers/IPS)
  • Content authorization (permissions, login, etc.)
  • Rules that may change frequently, or that your team wants to update without a ticket to AMS (since dispatchers are usually customer-managed or more easily changeable than CDN).
• Typical use:
  • Set default cache TTL and rules (e.g., what cache, what not to cache).
  • Invalidate cache immediately after AEM publishes/flushes.
  • Block or rewrite URLs, filter headers.
  • Dispatcher never caches requests with query strings by default.

CDN

• Best for:
  • Wide, global edge caching (performance, traffic offload)
  • Extra layer if redundancy/high availability needed
  • Geo-based routing, WAF, DDoS protection
  • Caching static assets (images, JS, CSS) at the edge
  • Rules that are stable (changes must go through AMS, often less frequent)
• Typical use:
  • Cache-Control headers from Dispatcher/AEM are honored.
  • For assets and public content, set longer cache lifetimes.
  • Use as the "outermost" cache—reducing hits to Dispatcher/AEM.
• Note: If you BYOCDN, you are 100% responsible for its setup/clear/invalidation.

What is commonly recommended?

• Set core caching logic in the Dispatcher. Why? Teams can manage and iterate without waiting for AMS/support/ticket.
• Dispatcher should set all critical Cache-Control and Surrogate-Control headers. The CDN will usually honor these.
• CDN caching acts as a performance multiplier, not your source of truth for business logic.
• Let Dispatcher (and AEM) be source-of-truth for TTL, invalidation triggers, and cacheability.

Strategy in Practice

• Single source of truth: Manage rules in one place (Dispatcher), ensuring consistency and quicker troubleshooting.
• CDN as a “follower”: CDN follows cache headers and cacheability rules set by Dispatcher. If a change is critical/urgent, you can update Dispatcher config and have the change propagate globally (after existing CDN TTLs expire).
• Use Surrogate-Control headers if you want to control what the CDN caches and for how long.
• Purge/invalidate at the Dispatcher for fast effect; CDN may require timed expiry or manual purge (usually slower).

TL;DR: Your approach is sound—set primary caching rules in Dispatcher, keep the CDN config as simple as possible, and rely on standard cache headers. This minimizes the footprint of CDN changes that require AMS intervention, and enables your team to move faster.

“The simplest way is for the origin for AEM and dispatcher to respond with the proper caching headers. And the simplest way to do that is to set these headers in the dispatcher. You can also set them in AEM, but Apache configurations give you a declarative way to do it.”
(Source: Delivering Fast Experiences with Experience Manager Cloud Service)
More: 

• Dispatcher understanding caching - Experience League

If you have edge-case needs (e.g., segmentation, geo-restrictions, special WAF rules), those might still need to be configured at the CDN. But for all standard, content-driven caching requirements: → Set at Dispatcher, let CDN follow, and keep your cache-tech debt low.