Difference(s) between Content Management System (CMS) and Content Delivery Network (CDN)?

Question

I'm trying to figure out how to compare CMS like Adobe Experience Manager (AEM) with CDN service like AWS CloudFront? Am I comparing apples to oranges?

Answer 1

Yes, you are comparing apples to oranges... but there's probably a reasonable explanation for that -- they are often used together.

A Content Management System (CMS) is a high-level system for creating, modifying, managing, organizing, and publishing of content, with WordPress (the software, not the service) being a common example.

Blog hosting web sites are examples of hosted CMS. WordPress (the company) is one example of a hosted (SaaS) CMS service.

A Content Delivery Network (CDN) is a low-level infrastructure provider that typically facilitates global, high-performance delivery of electronic content, using globally-distributed storage, infrastructure, and connectivity. Examples are Amazon CloudFront, Fastly, and CloudFlare.

CDNs typically do not authoritatively store or render the content, they only cache it, and the caching is globally-distributed, with copies of the content being held in geographic areas where it is frequently accessed. CDNs often behave like HTTP reverse proxies, pulling content from the authoritative origin server (often a cluster of identical servers), which may itself also be globally-distributed, though in some cases the CDN provides sufficient optimization to allow the origin to be in a single geographic location.

A CMS is often deployed "behind" a CDN -- the CMS server (cluster) is the origin server. Whether to do this is typically an easy decision, even at small scale. Viewers connect to the CDN and make requests, which the CDN will serve from the cache if possible and otherwise forward to the origin. The generated response is returned to the original requester as well as stored in the CDN's cache, if possible. This arrangement often allows the origin to be scaled smaller when deployed with a CDN than it could be without, since the CDNs cache means less workload for the origin.

Note, though, that CDNs tend to go beyond the simple definition of optimizing global static content delivery, and indeed beyond any proper definition of "CDN."

CDNs are increasingly integrating serverless compute services, such as CloudFront's Lambda@Edge and CloudFlare Workers which allow you to deploy serverless functions that can manipulate HTTP headers, make request routing decisions, and even generate rendered responses. This is outside the traditional scope of a CDN, but could conceivably be harnessed to embed an entire CMS into the CDN infrastructure, but this really doesn't blur the distinction between CMS (software) and CDN (infrastructure).

CloudFront also has the ability to detect simultaneous requests from multiple browsers in the same geographic area for exactly the same resource, using something called request collapsing. If a request for content that isn't in the edge cache is already in flight to the origin server and more requests for the same resource arrive, CloudFront will actually hold those pending requests waiting for the server to return the single response to the single request, and will clone that response to all the browsers that are waiting for it. Fastly supports this, too, and appears to provide more granularity of control than CloudFront, which implements the feature automatically.

Some CDNs can also pass-through requests/responses from web browser to origin server that are not properly "content" requests -- HTML form post requests, for example -- which provides multiple advantages, including simpler integration (all the site traffic can pass through a single domain, avoiding cross-origin complications), optimized transport and TCP stack, faster TLS negotiation (due to reduced round-trip time between the browser and the web server it connects to, which is at the CDN), and transforming HTTP/2 (browser-facing) to HTTP/1.1 (server-facing).

CDNs also intrinsically offer an layer of DDoS protection for the origin server, since traffic arrives at the CDN on the front side, and only the back side of the CDN is contacting your origin server. Requests must be valid, not servable from the cache, and not blocked by the mitigation systems in place at (and managed by) the CDN before your origin server will even see them.

But it's important to note that none of these features are properly part of the "CDN" definition; they are capabilities these services offer among others that are that are bundled into a product marketed as and designed around CDN concepts... so I would suggest that it is often a good idea to use one of these CDN services even in places where actual CDN functionality isn't called for.