Cloud / Amazon CloudFront Interview questions

Amazon CloudFront is AWS's content delivery network (CDN) service. It caches and serves static and dynamic content - HTML, CSS, JavaScript, images, video, and API responses - from a global network of edge locations so requests don't have to travel all the way back to the origin server.

CloudFront sits in front of an origin, which can be an S3 bucket, an EC2 instance, an Application Load Balancer, or any custom HTTP server. It integrates natively with services like S3, ACM, Route 53, Lambda@Edge, and AWS WAF.

Typical use cases include accelerating static websites, streaming video, speeding up API responses, and adding a security layer in front of an application.

A content delivery network (CDN) is a geographically distributed set of servers that cache copies of content close to end users, cutting down the network distance - and therefore latency - between a viewer and the content they're requesting.

CloudFront is AWS's CDN. Reasons teams pick it over a third-party CDN include tight integration with S3, EC2, Lambda, and ACM; a global network of edge locations; pay-as-you-go pricing; built-in DDoS protection through AWS Shield Standard at no extra cost; and the ability to run custom logic at the edge with CloudFront Functions and Lambda@Edge.

For workloads already living in AWS, CloudFront also avoids extra egress hops to a third-party CDN's own infrastructure.

Edge locations (also called points of presence, or POPs) are the physical data centers CloudFront uses to cache content near viewers. There are hundreds spread across the globe, and they are separate from AWS Regions and Availability Zones.

When a viewer makes a request, DNS routes it to the edge location that offers the lowest latency. If the requested object is already cached there, CloudFront serves it immediately - a cache hit. If not, CloudFront looks further upstream (a regional edge cache, then the origin) before returning and caching the response.

Because edge locations have finite storage, less-popular objects can get evicted to make room for more frequently requested ones.

An origin is the source CloudFront pulls content from when it can't serve a request out of cache. Every cache behavior in a distribution points to exactly one origin (or an origin group for failover).

CloudFront supports two origin types:

• S3 origin - an S3 bucket accessed through its REST API endpoint (recommended, supports Origin Access Control) or, less commonly, its static website hosting endpoint.
• Custom origin - any HTTP server, such as an EC2 instance, an Application Load Balancer, an on-premises server, or another CDN, reachable over HTTP or HTTPS.

A single distribution can define multiple origins and route different path patterns to each one via its cache behaviors.

A distribution is the configuration object that ties everything about a CDN deployment together: which origin(s) to use, which domain names it responds to, which TLS certificate to present, which cache behaviors apply to which paths, and settings like price class, logging, and WAF association.

Each distribution gets a default domain name like d111111abcdef8.cloudfront.net, and you can attach one or more custom alternate domain names (CNAMEs) backed by an ACM certificate.

Older CloudFront generations also supported a separate "RTMP" streaming distribution type; that has been retired, and today everything is a single distribution type built around HTTP/HTTPS delivery.

A cache behavior is a rule inside a distribution that maps a URL path pattern (like /images/* or /api/*) to a specific origin and a specific set of settings - allowed HTTP methods, cache policy, origin request policy, whether viewers must use HTTPS, and which edge functions run.

A distribution always has one default cache behavior (path pattern *) plus any number of additional behaviors you define. CloudFront evaluates behaviors top-to-bottom and uses the first one whose path pattern matches; the default behavior is always the fallback.

This lets one distribution serve, for example, static assets from S3 and API traffic from an ALB, each with its own caching rules.

An invalidation removes an object from CloudFront's edge caches before its TTL naturally expires, forcing the next request for that path to go back to the origin for a fresh copy.

You submit invalidations by exact path (/images/logo.png) or wildcard (/images/*). AWS gives a monthly allotment of free invalidation paths; beyond that, each path is billed.

Invalidations aren't instant everywhere at once, and because of the per-path cost, teams handling frequent updates often prefer cache-busting with versioned filenames or query strings instead of invalidating.

Signed URLs restrict access to an individual file by embedding a policy and cryptographic signature directly in the URL's query string. CloudFront validates the signature and policy (expiration time, and optionally IP range) before serving the object.

They're generated using a trusted key group tied to a public/private key you manage. The private key signs URLs server-side; CloudFront verifies them with the corresponding public key.

Signed URLs suit granting time-limited access to specific files - like a paid video or a private download - handed out individually, rather than through a shared client using cookies.

Signed cookies achieve the same goal as signed URLs - restricting access to private content - but apply to multiple files at once without modifying every URL.

CloudFront sets three cookies - CloudFront-Policy, CloudFront-Signature, and CloudFront-Key-Pair-Id - in the viewer's browser after they authenticate. Every subsequent request carries the cookies, and CloudFront validates them the same way it validates a signed URL's query parameters.

Signed cookies suit scenarios like a subscription video site where a logged-in user should browse many private assets without regenerating a signed URL for each one.

Origin Access Control (OAC) lets a CloudFront distribution be the only path into a private S3 bucket. CloudFront signs every request to the bucket using AWS Signature Version 4 (SigV4), and the bucket policy accepts requests only from that distribution.

OAC is the current recommended approach, replacing the older Origin Access Identity (OAI). It supports SSE-KMS encrypted buckets, works in every AWS Region, and covers all S3 operations, not just GET.

Setup means creating an OAC resource, attaching it to the S3 origin, and updating the bucket policy to allow the cloudfront.amazonaws.com service principal scoped to that distribution's ARN, while blocking other public access.

CloudFront Functions are lightweight pieces of JavaScript that run directly at CloudFront edge locations, on every request, with sub-millisecond execution time.

They only run on the viewer request and viewer response events, can't access the network, the file system, or a request body, and are capped at a small code size. Typical uses include normalizing the cache key, rewriting URLs, redirecting requests, and simple header-based authorization checks.

Because they're so cheap and fast, CloudFront Functions are the default choice for edge logic unless a task genuinely needs more compute or external connectivity.

Lambda@Edge lets you run Node.js or Python Lambda functions at AWS's edge network, triggered by any of four CloudFront events: viewer request, origin request, origin response, and viewer response.

Compared to CloudFront Functions, Lambda@Edge functions have real compute behind them - they can call external APIs, read from a database, manipulate a request body, and use third-party packages - at the cost of higher latency and higher per-invocation price.

Functions on the viewer events can run up to 5 seconds; functions on the origin events, which only fire on a cache miss, can run up to 30 seconds. You must author and deploy Lambda@Edge functions from the us-east-1 Region.

The cache key is the set of request attributes CloudFront uses to decide whether two requests should be treated as "the same object" for caching. At minimum it always includes the request's domain name and URL path.

Beyond that, a cache policy controls whether specific query strings, headers, or cookies are folded into the key. Including more attributes creates more distinct cache entries but lowers your cache hit ratio if those attributes vary a lot without actually changing the response.

A common mistake is including a header or query string in the cache key "just in case," which fragments the cache unnecessarily.

A price class controls which subset of CloudFront's global edge locations can serve your distribution's content, which affects both cost and the latency viewers in different regions experience.

Viewers outside the selected regions are still served - just from the nearest included edge location - so this is a cost/performance trade-off, not an access restriction.

TTL (Time To Live) is how long CloudFront keeps an object in an edge cache before treating it as stale and re-checking with the origin.

TTL can come from the origin's own Cache-Control or Expires headers, or be set explicitly in a cache policy using three values: minimum TTL, maximum TTL, and default TTL (used when the origin sends no caching headers at all).

A short TTL keeps content fresher but sends more requests to the origin; a long TTL improves cache hit ratio but risks serving stale content, unless you plan to invalidate or version the URL when content changes.

Every distribution can serve HTTPS out of the box using its default *.cloudfront.net domain with a certificate CloudFront manages for you.

To serve HTTPS on your own domain, you attach a certificate from AWS Certificate Manager (ACM), issued in us-east-1 regardless of where your other resources live, and associate it with your alternate domain names. CloudFront presents this certificate using Server Name Indication (SNI) by default, at no extra cost; a legacy dedicated-IP custom SSL option exists for the rare client that doesn't support SNI.

The viewer protocol policy on each cache behavior decides whether HTTP is allowed, redirected, or rejected, and a separate origin protocol policy controls how CloudFront talks to the origin.

CloudFront can forward the full standard set of HTTP methods to an origin: GET, HEAD, OPTIONS, PUT, POST, PATCH, and DELETE.

Each cache behavior has an "allowed methods" setting with two common options:

• GET, HEAD - read-only distributions, such as static websites or media delivery.
• GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE - needed when CloudFront sits in front of a full API or application.

Separately, "cached methods" is narrower - CloudFront only ever caches responses to GET, HEAD, and optionally OPTIONS. Responses to the other methods are always passed straight through and never cached.

Custom error pages let CloudFront return a branded, friendly response instead of a raw origin error, and optionally cache that response briefly to shield an unhealthy origin from repeated hits.

In the distribution's error pages settings, you map specific HTTP status codes (403, 404, 500, 502, and so on) to a replacement object - often a static HTML page in S3 - along with the status code CloudFront should return to the viewer and how long to cache that error response.

This is also useful for single-page applications: mapping a 403/404 from the origin to /index.html with a 200 response code lets client-side routing take over.

Every distribution is automatically assigned a unique default domain name like d123456abcdef.cloudfront.net, which works immediately with no extra DNS setup.

Most production setups instead front the distribution with one or more alternate domain names (CNAMEs) pointed at it via a Route 53 alias record or a standard CNAME. Using an alternate domain name requires an ACM certificate covering that domain to be attached.

A given alternate domain name can only be associated with one distribution at a time across an account, since CloudFront uses it to route incoming requests to the right distribution.

The standard setup points CloudFront at the bucket's REST API endpoint, protected with Origin Access Control so the bucket stays fully private and is only reachable through CloudFront.

A less common alternative uses the bucket's static website hosting endpoint, which supports features like index documents and redirect rules but only serves over HTTP and can't be locked down with OAC - the bucket has to allow public reads.

For most workloads the REST API endpoint plus OAC is the better default: it keeps the bucket private, supports HTTPS end-to-end, and works with features like SSE-KMS encryption.

These two services solve different problems and are often used together rather than as substitutes.

A very common architecture puts CloudFront in front of an ALB: CloudFront caches what it can and forwards everything else to the ALB, which load-balances across EC2 instances, ECS tasks, or Lambda functions.

Invalidation tells CloudFront to drop a specific cached path across edge locations so the next request re-fetches it from the origin. It requires no change to how clients reference the file, but each invalidation path beyond the monthly free allotment is billed, and propagation isn't instantaneous.

Versioned URLs instead give every new version of a file a unique name or query string - app.v2.js or app.js?v=2 - so old and new versions simply live as different cache entries with no invalidation needed.

Versioning scales better for frequent deploys and is effectively free, so it's preferred for build artifacts like JS/CSS bundles. Invalidation still earns its place for content you can't easily rename, or for emergency takedowns.

Origin Access Identity (OAI) was CloudFront's original mechanism for locking an S3 bucket to a distribution, but it has real limitations: it can't sign every S3 API operation with SigV4, doesn't support SSE-KMS-encrypted buckets, and isn't available in every Region.

Origin Access Control (OAC) replaces it and closes those gaps - full SigV4 signing, SSE-KMS support, every AWS Region, and additional origin types beyond plain S3, such as AWS Elemental MediaStore.

AWS now recommends OAC for all new distributions, since it gives finer-grained IAM control over exactly which distribution, and which actions, a bucket policy trusts.

CloudFront evaluates a distribution's cache behaviors in the exact order they're listed and applies the first path pattern that matches - there's no automatic "most specific wins" logic, so ordering is part of your configuration.

Path patterns can use wildcards (* and ?) - for example, /images/*.jpg or /api/*. The default cache behavior, with path pattern *, always exists and is always evaluated last, acting as the catch-all.

A practical implication: if a broad pattern like /api/* is placed above a narrower one like /api/v2/*, the narrower rule never gets reached.

Both let you run code at the edge, but they trade off differently: CloudFront Functions optimize for the cheapest, fastest execution on every request; Lambda@Edge trades latency and cost for real compute and access to the origin-facing events Functions can't reach.

Reach for Lambda@Edge whenever a task needs something CloudFront Functions structurally can't do:

• Running on an origin request or origin response event - choosing an origin dynamically, or rewriting a response body based on origin headers.
• Calling an external API or database, such as validating a session token against DynamoDB.
• Reading or transforming a request body - CloudFront Functions can't access it at all.
• Using third-party packages for tasks like image resizing or complex JWT validation.
• Needing more compute or memory than the Functions runtime allows.

If none of those apply and the logic is simple string/header manipulation on every request, CloudFront Functions is almost always the cheaper, lower-latency choice.

Improving cache hit ratio mostly comes down to making the cache key as narrow as it can be while still being correct, and giving objects room to actually stay cached.

1. Forward only the query strings, headers, and cookies the origin actually varies its response on - not "all" by default.
2. Set sensible Cache-Control headers or TTLs so objects live long enough to be reused.
3. Enable Origin Shield so cache misses across edge locations converge on one place before hitting the origin.
4. Normalize URLs and query string ordering with a CloudFront Function.
5. Enable compression so cached objects are stored and served efficiently.
6. Avoid cache-busting query strings on content that hasn't actually changed.

Monitor progress with the CloudFront cache statistics report, which breaks hit ratio down by status code and path.

A viewer request moves through a predictable sequence of hops, with up to four possible points where edge functions can intervene.

sequenceDiagram
    participant V as Viewer
    participant E as Edge Location
    participant R as Regional Edge Cache
    participant O as Origin
    V->>E: HTTP request
    Note over E: CloudFront Function / Lambda@Edge (viewer request)
    alt Cache hit at edge
        E-->>V: Cached response
    else Cache miss
        E->>R: Forward request
        alt Cache hit at regional cache
            R-->>E: Cached response
        else Cache miss
            Note over E,O: Lambda@Edge (origin request)
            R->>O: Forward to origin
            O-->>R: Origin response
            Note over E,O: Lambda@Edge (origin response)
            R-->>E: Response, cached
        end
        Note over E: CloudFront Function / Lambda@Edge (viewer response)
        E-->>V: Response
    end

On a cache hit, the edge location returns the cached object directly with no origin round trip. On a cache miss, the request climbs to the regional edge cache and, if still not found, to the origin, with the response cached on the way back down.

By default, a distribution using the default cache policy ignores query strings and most headers when forming the cache key - two URLs differing only by ?ref=email would be treated as the same cached object.

A cache policy lets you change that per cache behavior across three dimensions: query strings (none, an allow-list, all-except, or all), headers (none or an allow-list), and cookies (the same options). Whichever you include gets folded into the cache key.

This is essential for pages that vary by a query string, like currency, but including a noisy value - a timestamp or session ID - fragments the cache and tanks hit ratio.

HTTP's own semantics are the root reason: POST is defined for submitting data that changes state on the server, and its response is generally specific to that one submission, not something an unrelated request should reuse.

CloudFront's "cached methods" setting reflects this - it only ever caches responses to GET, HEAD, and optionally OPTIONS, even if POST is included in "allowed methods" so it can reach the origin at all. A POST always passes through and its response is delivered but never stored at the edge.

The same logic applies to PUT, PATCH, and DELETE - allowed through when needed, but non-cacheable by design.

When the origin responds with an error status, CloudFront's behavior depends on how the distribution's custom error responses are configured for that status code.

If a custom error response is defined, CloudFront can serve a replacement object instead of passing the raw error through, and cache that replacement for a configurable error caching minimum TTL, protecting a struggling origin from repeated retries.

If an origin group is configured for failover, specific status codes (commonly 500, 502, 503, 504, and optionally 403/404) trigger CloudFront to retry against the secondary origin instead of returning the error immediately.

Start with the CloudFront cache statistics report, which shows hit ratio trends and lets you drill into which paths or status codes drive misses.

1. Check the cache policy - an overly broad set of forwarded query strings, headers, or cookies fragments the cache key.
2. Inspect the origin's Cache-Control/Expires headers for no-store, no-cache, or a very short max-age.
3. Look for cache-busting patterns, like a timestamp embedded in the URL by the client.
4. Confirm TTLs on the cache policy aren't set too low.
5. Enable Origin Shield if many edge locations independently miss on the same popular object.
6. Use real-time or standard access logs to see the actual x-edge-result-type per request.

Change one variable at a time and re-check the statistics report, since cache key and TTL changes interact.

Regional edge caches sit in the request path between the global edge locations that serve viewers directly and your origin. They're deployed in a smaller number of AWS Regions and each has a much larger cache than any individual edge location.

On a cache miss at an edge location, CloudFront checks the nearest regional edge cache before going to the origin. Because regional edge caches hold more objects for longer, they absorb "long-tail" content that has fallen out of a smaller edge location's cache but is still occasionally requested.

Not everything flows through them: dynamic content and non-cacheable methods like PUT, POST, PATCH, and DELETE go straight from the edge location to the origin, bypassing the regional edge cache layer entirely, since there's nothing useful to cache there.

You attach an AWS WAF web ACL directly to a CloudFront distribution, and every request is evaluated against that web ACL's rules at the edge, before it reaches your origin or consumes cache capacity for a blocked request.

A web ACL combines your own custom rules (rate-based rules, string/regex matches against headers or the URI, IP set matches) with AWS Managed Rule Groups covering things like the OWASP Top 10 and known bad bots.

WAF and CloudFront's own geo-restriction feature overlap in purpose but work differently: geo-restriction is a simple allow/deny list by country baked into the distribution, while WAF's geo-match rules combine with other conditions for more nuanced blocking.

Both use CloudFront's edge network to get traffic onto AWS's backbone quickly, but they solve different problems: CloudFront repeatedly serves cached content to end users, while Transfer Acceleration speeds up individual PUT/GET operations that wouldn't benefit from caching at all.

Field-level encryption adds an extra layer of protection for specific sensitive fields in an HTTPS POST body - like a credit card number - so the value stays encrypted even after it leaves CloudFront and travels through your own application stack.

You configure which fields to encrypt and upload a public key; CloudFront encrypts those fields as the request passes through, while everything else stays in plaintext. Only a system holding the matching private key can decrypt the protected fields.

This limits exposure: even components inside your own infrastructure that don't need to see the raw value - load balancers, application servers, logs - never get a plaintext copy of it.

Real-time logs stream log records for a distribution to an Amazon Kinesis Data Stream within seconds of each request, compared to CloudFront's standard access logs, which are batched and delivered to S3 with a noticeably longer delay.

You configure a real-time log config per cache behavior, choosing a sampling rate and exactly which fields to include - edge location, cache result, response time, status code, and more.

Because the data lands in Kinesis, you can attach it to a Lambda consumer or Kinesis Data Firehose to build near-live dashboards or alerting - useful for catching a traffic spike or an error surge minutes sooner than batched logs allow.

Choose a custom origin whenever content genuinely needs to be generated or processed rather than just stored and served, or when it doesn't live in S3 at all.

• The origin is an application server - EC2, an ALB, ECS, or a container platform - producing dynamic, per-request responses.
• You need CloudFront to forward custom headers or a request body to logic running on that server.
• The content lives outside AWS entirely - on-premises or another cloud provider.
• You need full control over response headers, status codes, or business logic a static file store can't provide.

An S3 origin remains the better fit for static assets - images, video, downloadable files, a prebuilt app bundle - that just need to be stored durably and handed back unchanged.

Lambda@Edge can attach a function to any of four points in the request/response cycle, and each point suits a different job.

flowchart LR
    A["Viewer Request"] -->|auth, redirects, A/B routing| B["Cache Check"]
    B -->|miss| C["Origin Request"]
    C -->|choose origin, add headers| D[Origin]
    D --> E["Origin Response"]
    E -->|inject headers, transform body| F["Cache Store"]
    F --> G["Viewer Response"]
    B -->|hit| G
    G -->|final header tweaks, cookies| H[Viewer]

Viewer request functions run on every request before the cache is checked, commonly for authentication or routing. Origin request functions run only on a cache miss, right before CloudFront contacts the origin, and are used to choose between origins or add origin-specific headers.

Origin response functions run right after the origin replies, before the object is cached, for modifying a body or injecting cache-control headers. Viewer response functions run on every request, cached or not, for final cookie or header adjustments.

CloudFront cost comes primarily from data transfer out, requests, and any invalidations/edge functions used, so optimization touches several levers.

1. Pick the narrowest price class that still covers your actual audience instead of defaulting to Price Class All.
2. Push TTLs as high as freshness requirements allow to reduce origin fetches.
3. Enable compression to transfer fewer bytes per response.
4. Replace frequent invalidations with versioned file names.
5. Use Origin Shield where the origin is expensive to run - it costs a little more per request but can cut origin compute and egress costs.
6. Prefer CloudFront Functions over Lambda@Edge for simple edge logic.
7. For large, predictable usage, evaluate a committed-use discount option rather than pure on-demand pricing.

Reviewing the AWS Cost Explorer breakdown by usage type regularly is the fastest way to see which lever actually moves the needle for a given workload.

Origin Shield adds one more caching layer, placed in a single AWS Region you choose, that sits between all of your regional edge caches and the origin itself.

Without it, a popular object simultaneously missing from caches on multiple continents can trigger several near-identical requests to the origin at once. Origin Shield consolidates those into a single request, since every regional edge cache checks Origin Shield first on a miss, rather than going straight to the origin.

This is most valuable when the origin is slow or expensive to serve from - dynamic rendering, on-the-fly transcoding, or a backend that's easy to overload - since it directly reduces duplicate load reaching that origin, at the cost of a small additional per-request charge and a bit of extra latency on a true cache miss.

All three price classes deliver content globally - the difference is which edge locations are eligible to serve your distribution, which shapes both your bill and how close the "nearest" edge location actually is for viewers outside the cheaper tiers.

Price Class 100 fits an audience concentrated in North America and Europe, where paying for worldwide coverage would pay for capacity nobody uses. Price Class 200 adds most of the rest of the world except the costliest regions - a reasonable middle ground for an internationally used product. Price Class All is worth it when you have meaningful traffic from every region, including South America, or when consistent low latency everywhere is a hard requirement, such as a global live-streaming platform.

Because price class is a per-distribution setting, a multi-tenant platform can mix classes - Price Class All for a public marketing site, Price Class 100 for an internal admin tool - to match spend to where it actually matters.

CloudFront supports HTTP/1.1, HTTP/2, and HTTP/3 between the viewer and the edge location; you enable which versions a distribution accepts, and CloudFront negotiates the best one the client supports.

HTTP/2 multiplexes multiple requests over a single TCP connection, cutting the connection-setup overhead that hurt HTTP/1.1 when a page needed many small assets. HTTP/3 goes further by running over QUIC (built on UDP instead of TCP), avoiding TCP head-of-line blocking and recovering faster from packet loss - a meaningful improvement on mobile and other lossy networks.

Enabling HTTP/3 doesn't change how CloudFront talks to your origin - that connection uses whatever protocol the origin supports - it only affects the viewer-facing hop, and older clients simply fall back to HTTP/1.1 automatically.

When a viewer connects to CloudFront over a custom domain, the TLS handshake happens at the edge location, and a second, independent handshake can happen between CloudFront and the origin.

sequenceDiagram
    participant V as Viewer
    participant E as Edge Location
    participant O as Origin
    V->>E: ClientHello (SNI: www.example.com)
    Note over E: Match SNI to ACM cert for that domain
    E-->>V: ServerHello + certificate
    V->>E: Key exchange, Finished
    Note over V,E: TLS session established
    E->>O: New TLS handshake (if origin protocol policy = HTTPS)
    O-->>E: Certificate, key exchange
    Note over E,O: Separate TLS session to origin

The viewer-facing handshake uses SNI to pick the right certificate when a single edge location serves many distributions with different domains - CloudFront reads the hostname in ClientHello and presents the matching ACM certificate.

The edge-to-origin leg is a separate TLS session governed by the distribution's origin protocol policy, and it needs its own valid certificate on the origin side if that policy requires HTTPS.

A 403 from an S3-backed distribution almost always traces back to a permissions mismatch between CloudFront and the bucket, rather than a CloudFront bug.

1. Confirm the bucket policy allows the cloudfront.amazonaws.com service principal, scoped to your distribution's ARN - a common mistake is leaving an old OAI-style policy after switching to OAC.
2. Check that S3 Block Public Access settings aren't conflicting with the intended access path.
3. Verify the origin path on the distribution actually points at where the objects live in the bucket.
4. Rule out AWS WAF blocking the request if a web ACL is attached - WAF-blocked requests also surface as 403s.
5. Confirm the requested object exists; S3 can return 403 instead of 404 for missing objects when the caller lacks s3:ListBucket permission.

S3 server access logs and CloudFront's own logs, cross-referenced by timestamp, usually pinpoint which of these it is quickly.

Origin failover uses an origin group - a primary origin plus a secondary - so CloudFront can automatically retry a failed request against the secondary instead of surfacing the error to the viewer.

You configure which HTTP status codes count as a failure worth failing over on, typically 500, 502, 503, and 504, and optionally 403/404. CloudFront tries the primary first for every request; only on a qualifying failure does it retry the secondary.

This matters for availability because CloudFront itself has no built-in health checking that proactively takes a bad origin out of rotation the way a load balancer does - failover here is reactive, triggered per request by an actual error. It's a cheap way to add resilience against a full origin outage or a bad deployment, without a separate DNS failover mechanism.

CloudFront always checks a request's URL path against cache behaviors in list order and stops at the first pattern that matches - there's no automatic "most specific wins" logic.

If /api/* had been listed above /api/v2/*, every request under /api/v2/ would match the broader rule first and the more specific one would never fire - a subtle bug that shows up as "wrong cache policy applied to some API version."

The practical difference shows up in request flow: dynamic content and non-cacheable methods skip the regional edge cache entirely and go straight from the edge location to the origin, since there's no benefit caching them at an intermediate layer they'll never reuse.

Both layers exist for the same underlying goal - reducing round trips to the origin - just at different distances from the viewer and with different cache sizes.

Securing a CloudFront distribution end-to-end means treating it as a stack of independent controls, not a single setting to flip.

1. Lock down the origin - Origin Access Control for an S3 origin, or a security group/firewall restricted to CloudFront's traffic for a custom origin.
2. Enforce HTTPS on both legs - a viewer protocol policy that redirects or requires HTTPS, and an HTTPS-only origin protocol policy.
3. Attach AWS WAF with managed rule groups and rate-based rules to filter malicious requests before they reach your origin.
4. Use signed URLs or signed cookies for content that shouldn't be publicly downloadable.
5. Add field-level encryption for sensitive form fields that need to stay encrypted past the edge.
6. Rely on AWS Shield Standard (automatic) for baseline DDoS protection, and consider Shield Advanced for critical distributions.
7. Restrict by geography with CloudFront geo-restriction if content is only licensed for certain countries.

None of these substitutes for the others - a distribution with WAF but a public S3 bucket is still fully exposed through direct bucket access.

CloudFront supports disaster recovery patterns by combining origin groups for automatic failover with multi-Region origins underneath them, so a Regional outage doesn't have to mean a full outage for viewers.

flowchart TD
    V["Viewer Request"] --> CF["CloudFront Edge"]
    CF --> OG["Origin Group"]
    OG -->|primary| P["Primary Origin - Region A"]
    P -->|healthy| CF
    P -->|error status matches failover criteria| S["Secondary Origin - Region B"]
    S --> CF

The typical setup replicates data to both Regions - S3 Cross-Region Replication for object storage, or an active-passive/active-active application deployment behind an ALB in each Region - and configures the origin group so a qualifying failure (a 5xx, or a timeout) at the primary automatically routes that request to the secondary.

Because failover happens per request at the CloudFront layer rather than through DNS, there's no DNS propagation delay to wait out - typically the slowest part of a traditional multi-region failover design. The trade-off is that failover is reactive - it only engages once CloudFront sees a qualifying error - so it doesn't substitute for active health monitoring on the origins themselves.