What is a Content Delivery Network (CDN )?
A CDN (Content Delivery Network) is a system of distributed servers strategically placed across various geographic locations to deliver content to users more efficiently. The primary goal of a CDN is to reduce latency and improve the speed of delivering content such as web pages, images, videos, and other media to end-users.
Here's how a CDN works:
- Content Distribution: The CDN caches copies of content (like static assets, images, videos, etc.) on servers located in multiple data centers around the world. These servers are known as edge servers.
- Geographic Proximity: When a user requests content from a website, the CDN directs the request to the nearest edge server, reducing the distance the data must travel. This results in faster load times and better performance.
- Caching: Static content is stored in the CDN cache, so subsequent requests for the same content can be served quickly without needing to go back to the origin server every time.
- Load Balancing: CDNs also help manage traffic by distributing user requests across multiple servers, which helps prevent overloading any single server and ensures smooth performance even during traffic spikes.
Benefits of Using a CDN:
- Improved Speed & Performance: Faster content delivery, especially for global users, as data is served from the nearest server.
- Reduced Latency: Minimizes delays in loading by shortening the distance between users and content.
- Scalability: CDNs can handle large volumes of traffic and scale automatically to accommodate spikes.
- Reliability & Availability: If one server goes down, others can take over, ensuring high availability and reducing downtime.
- Enhanced Security: CDNs can provide additional layers of security, including DDoS protection, SSL encryption, and bot mitigation.
CDNs are commonly used for websites, video streaming services, e-commerce platforms, and any web application that requires fast and reliable content delivery on a global scale.
Adobe Managed CDN & Its Configurations
AEM as a Cloud Service provides a set of features that can be configured at the Adobe-managed CDN layer to alter either incoming requests or outgoing responses. Below operations are allowed in AEM as a cloud CDN.
- Request transformations – Modify various aspects of incoming requests, such as headers, paths, and parameters.
Request transformation rules enable you to modify incoming requests. These rules allow you to set, remove, or modify paths, query parameters, and headers (including cookies) based on specific matching conditions, such as regular expressions. Additionally, you can define variables that can be referenced later in the evaluation process.
Common use cases include simplifying application URLs or mapping legacy URLs.
Limitations: As mentioned previously, there is a size limit for the configuration file. Therefore, organizations with more extensive requirements should define their rules at the Apache/Dispatcher layer.
- Response transformations – Alter headers in outgoing responses before they reach the client (e.g., a web browser).
Response transformation rules enable you to set or remove headers in the CDN's outgoing responses. Additionally, as shown in the example above, you can reference a variable that was previously set in a request transformation rule. You can also modify the response's status code.
- Client-side redirects – Initiate a redirect on the client’s browser.
Client-side redirect rules allow you to perform 301, 302, and other similar types of redirects. When a rule matches, the CDN responds with a status line that includes the appropriate status code and message (e.g., HTTP/1.1 301 Moved Permanently), along with the location header set.
Both absolute and relative locations with fixed values are supported.
Limitations: Please note that the total size of the configuration file, including traffic filter rules, cannot exceed 100KB.
- Origin selectors – Redirect traffic to a different origin backend.
You can use the AEM CDN to direct traffic to different back-ends, including non-Adobe applications, based on specific criteria such as path or subdomain.
- Traffic Filter Rules (including WAF)
Traffic Filter Rules (including WAF) are also configurable at the CDN, allowing you to control which traffic is allowed or denied by the CDN. This feature has already been released, and you can learn more about it on the Traffic Filter Rules, including WAF rules page.
- Configuring CDN Error Pages
If the CDN is unable to contact its origin, you can create a rule that points to a self-hosted custom error page, which will be rendered instead. To learn more about this, refer to the Configuring CDN Error Pages article.
How do we configure Adobe AEM as Cloud Service CDN?
All these above rules, declared in a configuration file in source control, are deployed by using the Cloud Manager config pipeline. Be aware that the cumulative size of the configuration file, including traffic filter rules, cannot exceed 100KB.
How do we Setup AEM As Cloud CDN rules
Before configuring traffic at the CDN, follow these steps:
1. Create a Configuration File:
o Create a file named cdn.yaml (or a similar name), which will reference various configuration snippets outlined in the sections below.
2. Define Common Properties:
o Each snippet in the configuration should include the following common properties, as described under Config Pipeline:
o kind: "CDN"
o version: "1"
o metadata:
o envTypes: ["dev"]
3. File Placement:
o Place the file in a top-level folder named config (or something similar), as described under Config Pipeline.
4. Create a Config Pipeline in Cloud Manager:
o Set up a Config Pipeline in Cloud Manager as described under Config Pipeline.
5. Deploy the Configuration:
o Once the configuration is set up, deploy it using the Cloud Manager pipeline.
By following these steps, you can properly configure and deploy traffic management rules to the CDN in AEM.
Limitations of Adobe CDN Configuration Rules
Please note that the total size of the configuration file, including traffic filter rules, cannot exceed 100KB. Therefore, organizations with more extensive requirements should define their rules at the Apache/Dispatcher layer.
Migrating from AEM On Premise to AEM As Cloud Service Steps
