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.
Also, see the following videos Cloud 5 AEM CDN Part 1 and Cloud 5 AEM CDN Part 2 for additional information about CDN in AEM as a Cloud Service.
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:
Custom domains are supported in Cloud Manager only if you are using the AEM managed CDN. If you bring your own CDN and point it to the AEM managed CDN you will have to use that specific CDN to manage domains not Cloud Manager.
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.
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.
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:
Point your CDN to the Adobe CDN’s ingress as its origin domain. For example,
SNI must also be set to the Adobe CDN’s ingress.
Set the Host header to the origin domain. For example:
X-Forwarded-Host header with the domain name so AEM can determine the host header. For example:
X-AEM-Edge-Key. The value should come from Adobe.
X-Forwarded-*headers to the AEM application. For example,
X-Forwarded-Foris 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).
X-AEM-Edge-Keyis not present. Please inform Adobe if you need direct access to Adobe CDN’s ingress (to be blocked).
See the Sample CDN vendor configurations section for configuration examples from leading CDN vendors.
Before accepting live traffic, you should validate with Adobe’s customer support that the end-to-end traffic routing is functioning correctly.
After obtaining the
X-AEM-Edge-Key, you can test that the request is routed correctly as follows.
curl https://publish-p<PROGRAM_ID>-e<ENV-ID>.adobeaemcloud.com -H "X-Forwarded-Host: example.com" -H "X-AEM-Edge-Key: <PROVIDED_EDGE_KEY>"
curl https://publish-p<PROGRAM_ID>-e<ENV-ID>.adobeaemcloud.com --header "X-Forwarded-Host: example.com" --header "X-AEM-Edge-Key: <PROVIDED_EDGE_KEY>"
When using your own CDN, you do not need to install domains and certificates in Cloud Manager. The routing in the Adobe CDN will be done by using the default domain
publish-p<PROGRAM_ID>-e<ENV-ID>.adobeaemcloud.com which should be sent in the request
Host header. Overwriting the request
Host header with a custom domain name can cause the request to be incorrectly routed by the Adobe CDN.
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.
Sandbox program environments do not support a customer-provided CDN.
The extra hop between the customer CDN and the AEM CDN is only needed in the event of a cache miss. By using the cache optimization strategies described in this article, the addition of a customer CDN should only introduce negligible latency.
Please note that this customer CDN configuration is supported for the publish tier, but not in front of the author tier.
Presented below are several configuration examples from a number of leading CDN vendors.
The AEM managed CDN adds headers to each request with:
In case of customer managed CDN these headers will reflect the location of the customers CDN proxy server rather than the actual client. Therefore, for customer managed CDN, geolocation headers should be managed by the customers CDN.
The values for the country codes are the Alpha-2 codes described here.
The values for the continent codes are:
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.