CDN in AEM as a Cloud Service cdn
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 satisfies most customer’s performance and security requirements. For the publish tier, customers can optionally point to it from their own CDN, which they must manage. This scenario is 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 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:
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. You can limit traffic to the publish service for a given environment (for example, limiting staging by a range of IP addresses) by way of the Cloud Manager user interface.
See Managing IP Allow Lists to learn more.
Configuring Traffic at the CDN cdn-configuring-cloud
You can configure traffic at the CDN in various ways, including:
- blocking malicious traffic with Traffic Filter Rules (including optionally licensable advanced WAF rules)
- modifying the nature of the request and response
- applying 301/302 client-side redirects
- declaring origin selectors to reverse proxy a request to non-AEM backends
Learn how to configure these features by using YAML files in git and deploying them by using the Cloud Manager Config Pipeline.
Configuring CDN Error Pages cdn-error-pages
A CDN error page can be configured to override the default, unbranded page that is served to the browser in the rare event that AEM cannot be reached. For more details, see Configuring CDN error pages.
Purge Cached Content at the CDN purge-cdn
Setting TTL using the HTTP Cache-Control header is an effective approach to balance content delivery performance and content freshness. However, in scenarios where it is critical to immediately serve updated content, it may be beneficial to directly purge the CDN cache.
Read about configuring a purge API token and purging cached CDN content.
Basic Authentication at the CDN basic-auth
For light authentication use cases including business stakeholders reviewing content, protect content by displaying a basic auth dialog requiring a username and password. Learn more and join the early adopter program.
Customer CDN Points to AEM-managed CDN point-to-point-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 presented 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:
-
Point your CDN to the Adobe CDN’s ingress as its origin domain. For example,
publish-p<PROGRAM_ID>-e<ENV-ID>.adobeaemcloud.com. -
Set SNI to the Adobe CDN’s ingress.
-
Set the Host header to the origin domain. For example:
Host:publish-p<PROGRAM_ID>-e<ENV-ID>.adobeaemcloud.com. -
Set the
X-Forwarded-Hostheader with the domain name so AEM can determine the host header. For example:X-Forwarded-Host:example.com. -
Set
X-AEM-Edge-Key. The value should be configured using a Cloud Manager config pipeline, as described in this article.- 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-Foris used to determine the client IP. So, it becomes the responsibility of the trusted caller (that is, the customer-managed CDN) to ensure the correctness of theX-Forwarded-*headers (see the note below). - Optionally, access to Adobe CDN’s ingress can be blocked when an
X-AEM-Edge-Keyis not present. Inform Adobe if you need direct access to Adobe CDN’s ingress (to be blocked).
- Needed so that the Adobe CDN can validate the source of the requests and pass the
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 setting the X-AEM-Edge-Key, you can test that the request is routed correctly as follows.
In Linux®:
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>"
In Windows:
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>"
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.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.The extra hop between the customer CDN and the AEM CDN is only needed if there is a cache miss. By using the cache optimization strategies described in this article, the addition of a customer CDN should only introduce negligible latency.
This customer CDN configuration is supported for the publish tier, but not in front of the author tier.
Sample CDN vendor configurations sample-configurations
Presented below are several configuration examples from several leading CDN vendors.
Akamai
Amazon CloudFront
Cloudflare
Common Errors common-errors
The sample configurations provided show the base settings needed, but a customer configuration may have other impacting rules that remove, modify, or re-arrange the headers needed for AEM as a Cloud Service to serve the traffic. Below are common errors that occur when configuring a customer managed CDN to point to AEM as a Cloud Service.
Redirection to the Publish Service Endpoint
When a request receives a 403 forbidden response, it means that the request is missing some required headers. A common cause for this is that the CDN is managing both apex and www domain traffic, but is not adding the correct header for the www domain. This problem can be triaged by checking your AEM as a Cloud Service CDN logs and verifying the needed request headers.
Too Many Redirects Loop
When a page gets a “Too Many Redirect” loop, some request header is being added at the CDN that matches a redirect that forces it back to itself. As an example:
- A CDN rule is created to match either the apex domain or the www domain, and adds the X-Forwarded-Host header of the apex domain only.
- A request for an apex domain matches this CDN rule, which adds the apex domain as the X-Forwarded-Host header.
- A request is sent to the origin where a redirect matches the host header explicitly for the apex domain (for example, ^example.com).
- A rewrite rule is triggered, which rewrites the request for the apex domain to https with the www subdomain.
- That redirect is then sent to the customer’s edge, where the CDN rule is re-triggered re-adding the X-Forwarded-Host header for the apex domain not the www subdomain. Then the process starts over until the request fails.
To resolve this problem, assess your SSL redirect strategy, CDN rules, redirect and rewrite rule combinations.
Geolocation Headers geo-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 depend 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.