CDN
Intermediate 13 min read CDN

Origins & Distributions

One front door, many back rooms

A distribution is the routing layer: which origin answers which path, with which cache/TLS/policy. Multiple origins per distribution plus origin groups and shields structure user traffic without extra DNS hops.

origindistributionbehaviororigin grouporigin shieldpath pattern
Prerequisites: CDN Basics
Before we start

What you will learn

  • Map path behaviors to different origins
  • Distinguish origin group, shield and primary/secondary origins
  • Explain origin connection troubleshooting (SSL, latency, host header)
In 60 seconds

A distribution binds a public hostname to behaviors — ordered path patterns, each pointing at an origin and carrying its own TTL/geographic/header settings. Origins can be grouped (failover) and shielded (collapse edge fan-out into one regional hop).

Introduction

What is this?

Behavior fields: path pattern (/*, /api/*, /images/*), origin of choice, viewer protocol policy, cache policy, OAI/OAC restriction, signed URL/cookie requirement, WAF association. Origin types: S3/Storage (static), or a custom origin (LB/App Service/instance) — for custom origins set Host/SNI correctly and match cert. Origin group: list of origins with failover criteria (5xx/connect). Origin shield: single regional cache that edges talk to instead of each hitting origin directly — fewer, larger origin requests and better origin amortization.

Motivation

Why do you need it?

  • A single distribution + behaviors beats many hostnames per concern.
  • Origin groups give cheap failover without a whole new distribution.
  • Origin shield turns N + M origin calls into one, protecting the origin's connection budget.
  • Placing static assets and API behind the same edge simplifies certs, pricing and WAF posture.
Think about it

Mental model

Imagine

A receptionist routing visitors by department and room

Think of

Distribution behaviors

The receptionist (edge/behavior router) sends /images visitors to the stockroom (asset origin) and /api visitors to the data room (API origin), each with its own rules, and calls the second floor only if the first floor is down (failover).

Mechanics

How it works

  • The edge maps the request path against ordered behaviors (first match wins).
  • Matching behavior selects its origin, cache policy and any signing/WAF rules.
  • On a miss the edge fetches the origin honoring the behavior's cache key and headers.
  • If origin group configured and primary fails health/fetch, the edge retries the backup origin.
  • Shield absorbs all edge misses so origin sees ~one request per object per TTL window.

Behaviors route by path.

cdn.example.com
/* → HTML origin
/assets/* → S3 origin
/api/* → LB origin
Failover
Hands-on

Examples

Two-origin distribution sketch

Two-origin distribution sketch
behaviors:
  - path: /assets/*
    origin: s3-static
    cache: immutable, max-age=1y
    OAC: signed concept
  - path: /api/*
    origin: app-lb
    cache: no-store
    waf: managed rules  # product-agnostic shape

Traffic self-routes: heavy static to object storage, dynamic to the app, each under the same edge hostname and cert.

Real world

In production

  • Frontend + API + image service behind one Front Door profile with three route configurations.
  • Terraform module that fat-fingers origin groups so a down ASG fails over to the warm standby region.
  • Media platform serving video from an S3 origin through a shielded region cache for 10x origin offload.
Guidelines

Best practices

  • Order behaviors most-specific-first; the default catch-all goes last.
  • Keep origin policies identical across group members to avoid behavior drift in failover.
  • Use ASW/Action host header consistency so the origin's virtual hosts answer correctly.
  • Perimeter-test cached vs bypassed paths: secrets must live only in bypass behaviors.
Watch out

Common mistakes

  • Putting no-store data behind a cached behavior and leaking it via a chance cache key.
  • Forgetting the origin's TLS/SNI when rewiring a behavior to a new LB.
  • Routing everything through S3-caching behavior and then breaking authenticated endpoints.
  • Assuming the default origin also secures the ones you added later.
When things break

Debugging tips

  • Request both /assets/x and /api/x and compare influenced cache vs bypass headers.
  • Add a per-behavior aren't-bypassing sanity flag (e.g. cache-control no-store) before deploys.
  • Check origin connect errors in edge logs — they map to a specific origin group member.
  • Test failover by stopping the primary origin and issuing a fresh miss.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

A distribution behavior is selected by:

2

Which do you add to let edges coalesce misses into few origin calls?

Go deeper

Official documentation

CloudFront origins and origin groups
docs
Azure Front Door origins
docs