CDN in AEM as a Cloud Service

AEM as Cloud Service is shipped with a built-in CDN. Its main purpose is to reduce latency by delivering cacheable content from the CDN nodes at the edge, near the browser. It is fully managed and configured for optimal performance of AEM applications.

The AEM managed CDN will satisfy most customer’s performance and security requirements. For the publish tier, customers can optionally point to it from their own CDN, which they will need to manage. This will be allowed on a case-by-case basis, based on meeting certain pre-requisites including, but not limited to, the customer having a legacy integration with their CDN vendor that is difficult to abandon.

AEM Managed CDN

Follow the sections below to use Cloud Manager self-service UI to prepare for content delivery by using AEM’s out-of-the-box CDN:

  1. Managing SSL Certificates
  2. Managing Custom Domain Names

Restricting traffic

By default, for an AEM managed CDN setup, all public traffic can make its way to the publish service, for both production and non-production (development and stage) environments. If you wish to limit traffic to the publish service for a given environment (for example, limiting staging by a range of IP addresses) you can do this in a self-service way via Cloud Manager UI.

Refer to Managing IP Allow Lists to learn more.

CAUTION

Only requests from the allowed IPs will be served by AEM’s managed CDN. If you point your own CDN to the AEM managed CDN, then make sure the IPs of your CDN are included in the allowlist.

Customer CDN points to AEM Managed CDN

If a customer must use its existing CDN, they may manage it and point it to the AEM managed CDN, providing the following are satisfied:

  • Customer must have an existing CDN that would be onerous to replace.
  • Customer must manage it.
  • Customer must be able to configure the CDN to work with AEM as a Cloud Service - see the configuration instructions below.
  • Customer must have engineering CDN experts that are on call in case related issues arise.
  • Customer must perform and successfully pass a load test before going to production.

Configuration instructions:

  1. Set the X-Forwarded-Host header with the domain name. For example: X-Forwarded-Host:example.com.
  2. Set Host header with the origin domain, which is the AEM CDN’s ingress. For example: Host:publish-p<PROGRAM_ID>-e<ENV-ID>.adobeaemcloud.com.
  3. Send the SNI header to the origin. Like the Host header, the SNI header must be the origin domain.
  4. Set either the X-Edge-Key or the X-AEM-Edge-Key (if your CDN strips X-Edge-*). The value should come from Adobe.
    • This is needed so that the Adobe CDN can validate the source of the requests and pass the X-Forwarded-* headers to the AEM application. For example, X-Forwarded-Host is used by AEM to determine the Host header and X-Forwarded-For is used to determine the client IP. So, it becomes the responsibility of the trusted caller (i.e. the customer-managed CDN) to ensure the correctness of the X-Forwarded-* headers (see the note below).
    • Optionally, access to Adobe CDN’s ingress can be blocked when an X-Edge-Key is not present. Please inform Adobe if you need direct access to Adobe CDN’s ingress (to be blocked).

Before accepting live traffic, you should validate with Adobe’s customer support that the end-to-end traffic routing is functioning correctly.

NOTE

Customers that manage their own CDN should ensure the integrity of the headers that are sent through to AEM’s CDN. For instance, it is recommended that customers clear all X-Forwarded-* headers and set them to known and controlled values. For example, X-Forwarded-For should contain the client’s IP address, while X-Forwarded-Host should contain the site’s host.

There is potentially a small performance hit due to the extra hop, although hops from the customer CDN to the AEM managed CDN are likely to be efficient.

Please note that this customer CDN configuration is supported for the publish tier, but not in front of the author tier.

Geolocation Headers

The AEM managed CDN adds headers to each request with:

  • country code: x-aem-client-country
  • continent code: x-aem-client-continent

The values for the country codes are the Alpha-2 codes described here.

The values for the continent codes are:

  • AF Africa
  • AN Antarctica
  • AS Asia
  • EU Europe
  • NA North America
  • OC Oceania
  • SA South America

This information may be useful for use cases such as redirecting to a different url based on the origin (country) of the request. Use the Vary header for caching responses that are dependent on geo information. For example, redirects to a specific country landing page should always contain Vary: x-aem-client-country. If needed, you can use Cache-Control: private to prevent caching. See also Caching.

On this page