Adding a CDN in front of an existing web host

A CDN and a web host coexist as two layers rather than competing products. The CDN sits in front, answering requests for cached resources from anywhere on the network, while your host continues to run the application and origin database. Getting the two to work together well is mostly about DNS, SSL, and a few origin rules, and it does not require moving hosts.

How they fit together

When you add a CDN, the public record for your domain changes from pointing directly at the host to pointing at the CDN. The CDN then fetches what it needs from your origin, which is still your existing host, over an origin connection.

The relationship works because the CDN handles the traffic it can serve from cache, and only returns to the origin for requests it cannot, typically the first visit, a miss, or a resource marked uncacheable. The origin still sees real load, usually less of it, and the CDN can also apply SSL, caching headers, and security rules at the edge.

The main technical point to get right is that the origin must accept and be identifiable to the CDN. When the CDN asks your host for a page, it sends a request that still includes your original Host header, so the virtual host on your server can respond correctly.

The safe addition

Follow this order to avoid a visible outage.

1. Confirm your host can answer both HTTP and HTTPS. If you are using the CDN for TLS at the edge, the origin still needs at least one mode that works, typically Full or Full strict if you want a verified certificate on the origin too.
2. Start with one low-risk hostname, often www, rather than changing the apex immediately. Watch it for a few minutes before rolling out the whole zone.
3. Set the record to proxy mode so traffic flows through the CDN, keeping a record of your direct origin IP for later origin-level firewalling.
4. Turn on caching only for static assets first, such as images, CSS, and JavaScript, and leave HTML uncached or short-TTL until you confirm dynamic pages still behave.
5. If you previously hardened the host to accept traffic only from certain IPs, add the CDN egress IP ranges now or real visitors will see errors.

Verify the result

After the switch, check that a cached asset is served from the CDN, that a fresh request still reaches the origin and updates, and that HTTPS works end to end without certificate warnings. Look at a waterfall to confirm you have not added a slow hop: the origin TTFB should stay similar while static delivery should improve.

Then decide on origin security. Since direct traffic is no longer necessary, restricting the origin to CDN IPs is a sensible hardening step and removes one public attack surface. See lock down the origin IP and CDN static asset setup for the further detail.

The result is a setup where the host stays exactly where it was and the CDN makes it faster and safer, with both layers doing what each is best at.