In a CloudFront distribution, what is the difference between an origin and a cache behavior, and how does CloudFront decide which origin serves an incoming request?
answer
- two lists: backends and routing rules
- path pattern picks the origin
- order matters, first match wins
- default behavior is the catch-all
- one distribution, several backends
basics
~20 sAn origin is a backend CloudFront fetches from: an S3 bucket, a load balancer, any HTTP server. A cache behavior maps a URL path pattern to one origin. CloudFront tests behaviors in their configured order and falls back to the default behavior.
solid answer
~50 sA distribution holds two separate lists. **Origins** are the backends: each has an id, a domain name (an S3 bucket, an ALB, an EC2 host, any reachable HTTP server) and connection settings such as the origin protocol policy, an optional origin path and custom headers. **Cache behaviors** are the routing layer: each has a path pattern, a `TargetOriginId` naming the origin it sends matching requests to, and its own handling settings — viewer protocol policy, allowed HTTP methods, cache policy, origin request policy, function associations. When a request reaches an edge location, CloudFront walks the ordered cache behaviors and uses the *first* whose path pattern matches; if none match, the default cache behavior (path pattern `*`) handles it. Origins say what the backends are; behaviors say which backend a path goes to and on what terms. That split is what lets one domain front several backends.
code
json · 23 lines{
"Origins": {
"Quantity": 2,
"Items": [
{ "Id": "spa-bucket", "DomainName": "app-assets.s3.eu-west-1.amazonaws.com" },
{ "Id": "api-alb", "DomainName": "api-alb-123.eu-west-1.elb.amazonaws.com" }
]
},
"CacheBehaviors": {
"Quantity": 1,
"Items": [
{
"PathPattern": "/api/*",
"TargetOriginId": "api-alb",
"ViewerProtocolPolicy": "redirect-to-https"
}
]
},
"DefaultCacheBehavior": {
"TargetOriginId": "spa-bucket",
"ViewerProtocolPolicy": "redirect-to-https"
}
}go deeper
Be able to say plainly that origins are the backends and cache behaviors route path patterns to them, and that the default behavior catches whatever nothing else matched.
Explain the precedence order and that the first matching pattern wins, and name the settings that live per behavior — allowed methods, viewer protocol policy, cache and origin request policies.
Show you design with the split: one hostname fronting static and dynamic backends, methods and timeouts tuned per behavior, and awareness that a mis-ordered pattern silently shadows the rule below it.
Own the question of how many distributions an estate should have — behavior sprawl in one distribution versus per-service distributions, and what each choice costs in change blast radius and ownership boundaries.
## Two lists, not one A CloudFront distribution is a configuration document containing two independent lists: `Origins`, and `CacheBehaviors` plus exactly one `DefaultCacheBehavior`. Grasping that they are separate is most of what this question tests — an engineer who believes a distribution has *an* origin (singular) cannot design anything past a single static site. ## Origins: the backends An origin is a place CloudFront can fetch from. Each entry carries an `Id` you choose, a `DomainName`, and per-origin settings. The main flavours: - **S3 bucket origin** — the bucket's REST endpoint (`my-bucket.s3.eu-west-1.amazonaws.com`). CloudFront treats this specially and can sign requests to it with Origin Access Control. - **Custom origin** — any HTTP(S) endpoint: an Application Load Balancer, an EC2 instance, an API Gateway endpoint, a Lambda function URL, a server in your own data centre, or even an S3 bucket configured as a static *website* endpoint (that variant is a custom origin, not a bucket origin, because it speaks plain HTTP and is public). - **VPC origin** — a private ALB, NLB or EC2 instance inside your VPC, reached without exposing it to the internet. - **Origin group** — a primary/secondary pair used as a behavior's target for failover. Per-origin settings include the origin protocol policy (`http-only`, `https-only`, `match-viewer`), an origin path prefix that CloudFront prepends before forwarding, custom headers CloudFront injects on every origin request, and — for custom origins only — connection and read timeouts and retry counts. ## Cache behaviors: the routing table Each cache behavior is a rule. Its `PathPattern` is matched against the request path with `*` and `?` wildcards — for example `/api/*`, `/static/*`, `*.jpg`. Matching is **case-sensitive** and there is no regular-expression support; you cannot match on the query string or on a header here. The critical mechanic is ordering. Behaviors are an ordered list with an explicit precedence, CloudFront evaluates them from the top, and the **first** match wins — later, more specific patterns never get a chance. Put `/api/v2/*` above `/api/*`, not below it. The default cache behavior is implicit last and its pattern is `*`; every distribution has one and you cannot delete it. Besides the target origin, each behavior owns: - `ViewerProtocolPolicy` — `allow-all`, `redirect-to-https`, or `https-only`. - `AllowedMethods` — GET/HEAD, plus OPTIONS, plus the write methods. A behavior pointing at an S3 bucket origin normally allows only reads; an API behavior needs POST, PUT, PATCH and DELETE. - A cache policy and an origin request policy, which decide what is cached and what is forwarded. - Optional response headers policy and edge function associations. ```json { "Origins": [ { "Id": "spa-bucket", "DomainName": "app-assets.s3.eu-west-1.amazonaws.com" }, { "Id": "api-alb", "DomainName": "api-alb-123.eu-west-1.elb.amazonaws.com" } ], "CacheBehaviors": [ { "PathPattern": "/api/*", "TargetOriginId": "api-alb" } ], "DefaultCacheBehavior": { "TargetOriginId": "spa-bucket" } } ``` ## Why the split matters Because routing is per-behavior, one distribution and one certificate can serve a static front end and a dynamic API under the same hostname, each with its own methods, caching and origin. It also means a mistake is per-behavior: an API behavior that inherits the default's read-only method set will reject every POST with 403, and a `/static/*` behavior placed below a `*`-like pattern will simply never fire. ## Common confusions An origin is not a target group and CloudFront does not load-balance across origins — if you want several backends behind one behavior, put a load balancer in front and make that the origin, or use an origin group for failover only. And origins are shared: several behaviors may point at the same origin id with completely different settings.
- You add a behavior for `/api/v2/*` below an existing `/api/*` behavior and it never seems to take effect. Why?CloudFront evaluates cache behaviors in their configured precedence order and stops at the first path pattern that matches. `/api/*` already matches `/api/v2/anything`, so the more specific rule below it is unreachable. Move `/api/v2/*` above `/api/*`. The rule of thumb is most-specific-first, with the default `*` behavior always last.
- What is the practical difference between using an S3 bucket origin and pointing CloudFront at the same bucket's static website endpoint?The bucket endpoint is an S3 REST origin: CloudFront can sign requests with Origin Access Control, so the bucket stays private. The website endpoint is a plain HTTP custom origin: it requires public access and cannot be locked to CloudFront, but it does provide S3's own index-document and redirect handling. Private content means the bucket origin.
- Can one cache behavior send requests to more than one origin?No. A behavior names exactly one `TargetOriginId`. The only multi-backend construct is an origin group, which is a primary/secondary pair for failover, not load balancing. To spread traffic across several instances, put an ALB or NLB in front of them and make the load balancer the origin.
saying these in an interview costs you the question
- Thinks a distribution can only have one origin
- Assumes CloudFront load-balances requests across origins
- Believes the longest matching path pattern wins
- Thinks path patterns support regular expressions
- Confuses an origin with an ALB target group