Adobe Managed CDN

The following steps illustrate how to use the Adobe Managed CDN (part of AEM Sites as a Cloud Service) to configure a property to deliver content from a site powered by Edge Delivery Services in Adobe Experience Manager Sites as a Cloud Service.

Prerequisites and limitations

• You must have a license for Edge Delivery Services as part of Adobe Experience Manager Sites
• You must own the domain under which you want to serve your site
• You need to be able to make Domain Name System (DNS) changes to the domain name
• You have the choice to bring your own certificate or ask Adobe to provide one provisioned by Let’s Encrypt
• HTTPS is required and IPv6 is not supported

Before you go live

There are two deployment options for going live with Adobe Managed CDN

1. Setup an HTTP proxy from an existing AEM Sites as a Cloud Service environment. This is typically used when you already have an existing environment and you want to migrate part of a site to Edge Delivery Services.
2. Setup a new Edge Delivery site independently of an AEM Sites as a Cloud Service environment. This is the approach used when you do not have an AEM author or publish environment and you want to use Edge Delivery Services on its own.

A checklist of the steps you need to do for both options:

1. Install or request a certificate in Cloud Manager (you need to do that for both www and non-www apex domains)
2. Install the the domains Cloud Manager (you need to do that for both www and apex domains)
3. Map the domains to your Edge Delivery site. (This will be done differently depending on what deployment option you chose)
4. Setup push invalidation in the project's configuration
5. Point the DNS CNAME of your www site to cdn.adobeaemcloud.com and the A records of your apex to the IP addresses listed below.

Option 1: setup a proxy from an existing environment

This requires an existing AEM Sites as a Cloud Service environment that needs to be configured via configuration pipeline to proxy some (or all) paths on your domain to your Edge Delivery Site. (see how to define a proxy using originSelectors and how to run a Configuration Pipeline).

Please note that a redirect from https://example.com to https://www.example.com needs to be defined using a redirect rule, but all other redirects may use the redirects spreadsheet

Option 2: setup an Edge Delivery site without an existing environment

In case you do not have an existing authoring/publish environment please follow the steps for setting up a new Edge Delivery site in Cloud Manager.

Please note that an automatic redirect will be established from https://example.com to https://www.example.com but all other redirects must happen through the redirects spreadsheet

Setup push invalidation

Push invalidation automatically purges content on the managed CDN whenever an author publishes content changes.

Content is purged by URL and by cache tag/key.

Push invalidation is enabled by adding specific properties to the project's configuration (an Excel workbook named .helix/config.xlsx in Sharepoint or a Google Sheet named .helix/config in Google Drive).

Configuration properties:

key	value	comment
cdn.prod.host	<Production Host>	Host name of production site, e.g. www.example.com
cdn.prod.type	managed

After making changes to the config sheet, preview it with the Sidekick to activate the changes.

Optionally lowering TTL of existing DNS records in preparation of going live for faster roll-out

If your existing DNS records for the domain which is set to go live, have a long time-to-live (TTL) (like 12 hours or more), then for faster roll-out of the site once it is live, you may want to set it to a lower TTL (like 1 hour or maybe even as low as 60 seconds). This ensures that after going live, the traffic starts getting routed to the new site faster instead of waiting for the original TTL to expire. Do remember to restore the TTL back to the original value while updating the DNS records for going live.

As you go live

Make or request following DNS change:

• For www.example.com set the CNAME DNS record to cdn.adobeaemcloud.com (see details)
• Use a high time to live (TTL) of 3600 seconds (one hour) or more. This will increase the reliability of site delivery in case of a DNS outage. If you lowered the TTL value for faster roll-out in preparation of going live, restore it to its original longer value.

If you want to establish an automatic redirect from from https://example.com to https://www.example.com the following additional steps are required

• For example.com set the A record to these four IP addresses: 151.101.3.10, 151.101.67.10, 151.101.131.10, and 151.101.195.10 (see details)
• If your DNS provider cannot support multiple IP addresses in an A record (e.g. GoDaddy), use any of the listed IP addresses. This will be a bit less reliable.
• Use the same high TTL as described above

Depending on your existing DNS setup including the TTL specified in the DNS records, these changes can take a few minutes to several hours to complete. If you have existing traffic on the site, make sure all redirects are in place or keep your existing site functional till the traffic has completely been redirected to the new site, which is essentially waiting out for the duration of the TTL in the DNS records to expire.

Please note that if you are hosting both apex and the www domains they both need to have the DNS configured for the certificate to be generated.

If you are looking for a timed launch, it is a good idea to create a temporary holding home page that will be replaced with the correct content at the desired launch time. As publishing in AEM is fast and predictable, this will give you more control over the visibility of your content than relying on DNS.

After you go live

The AEM team will verify your setup and let you know if any problems arise.