What is a Content Delivery Network (CDN)?

Why Content Delivery Networks exist

Every public website and API has a physical origin: one or more servers that hold the authoritative application and content. If every user worldwide must reach that same place for every image, stylesheet, script, and page fragment, latency grows with distance, bandwidth costs rise, and a busy or attacked origin becomes a single point of pain.

A Content Delivery Network (CDN) moves copies of cacheable content—and often traffic-handling controls—into many edge locations called points of presence (PoPs). Users still request the same hostname. Behind that name, the CDN steers them toward a nearby edge that can answer quickly when the object is already stored.

CDNs began as a performance tool for static media. Today they are also an operational and security control plane: TLS termination, HTTP/2 and HTTP/3 front doors, WAF features, bot management, and DDoS absorption commonly live at the same edge that serves files.

How a CDN works

At a high level, a CDN sits between clients and your origin. DNS (and sometimes anycast routing) directs clients to an edge. The edge checks whether it can satisfy the request from cache. If not, it retrieves the response from origin or another cache tier, applies policy, and may store the result for later requests.

The request path, step by step

What CDNs typically deliver

Not every response belongs in cache. Personalized pages, authenticated APIs, checkout flows, and responses that vary by cookie or authorization header need explicit rules—often Cache-Control: private or no-store—so one user’s data is never served to another.

CDN vs origin vs load balancer

Teams sometimes treat these words as interchangeable. They solve different problems and usually work together.

A mature setup often uses all three: the CDN faces the public internet, the load balancer spreads traffic among origin instances, and the origin remains the source of truth for dynamic work and uncached content.

Benefits of using a CDN

These gains depend on configuration quality. Poor cache keys, accidental caching of private responses, or frequent full-site purges can erase performance benefits and create correctness incidents.

Security considerations at the edge

A CDN changes your attack surface. It can harden the public perimeter—and it can also hide misconfigurations until they affect every region at once.

Treat the CDN as part of your security boundary. Inventory every hostname it fronts, review who can purge caches or change rules, and verify that security headers survive edge rewrites.

Operational checklist for teams

• Map which hostnames terminate on the CDN and which still point directly at origin.
• Define cache policies by path: long TTLs for immutable assets, short or no-store for personalized and authenticated responses.
• Use content-hashed filenames for static assets so you can cache aggressively without stale-deploy surprises.
• Restrict origin firewalls or access lists so only the CDN (or expected networks) can reach application ports.
• Test purge, soft-purge, and rollback procedures before you need them during an incident.
• Confirm TLS versions, certificates, redirects, and security headers on the CDN edge—not only on origin.
• Monitor cache hit ratio, origin error rates, regional latency, and unexpected 4xx/5xx spikes by PoP when available.
• Apply SRI to third-party scripts and styles loaded from public CDNs, or self-host critical dependencies.
• Review who can change CDN rules, WAF policies, DNS, and certificates; require MFA and change logging.
• Document how the CDN interacts with your WAF, bot controls, and rate limits so bypass paths are intentional.

Choosing and configuring a CDN wisely

Do not select a CDN only by the number of advertised cities. Ask how cache keys are formed, how quickly purges propagate, whether you can restrict origin access, how TLS and HTTP versions are managed, and what visibility you get during a regional outage.

Useful evaluation questions include:

• Which responses are cached by default, and how do cookies or Authorization headers affect cache eligibility?
• Can you force HTTPS, modern TLS only, and consistent security headers at the edge?
• How do you invalidate content after a bad deploy without wiping the entire cache unnecessarily?
• What happens to users when origin is slow or down—stale-if-error, custom error pages, or hard failures?
• Are WAF, bot, and DDoS features tunable without creating silent false positives on APIs?
• Can you export logs with enough detail to investigate cache poisoning, abuse, and misrouting?

The right design depends on content mix. A documentation site may live almost entirely on long-lived edge caches. A banking app may use the CDN mainly as a hardened TLS and filtering front door with very little caching of HTML.

The practical takeaway

A Content Delivery Network (CDN) places cache and traffic controls at many edge locations so users reach content with less latency and origins face less repetitive load. Performance comes from sound cache policy. Resilience comes from distributed capacity and controlled failover behavior. Security comes from locking down origin, preventing sensitive caching, and treating the edge as a first-class control plane.

Use a CDN as infrastructure with explicit rules—not as a black box that “makes the site faster.” When cache keys, TTLs, TLS, headers, and access controls are intentional, the CDN becomes one of the highest-leverage layers in a modern web architecture.