For a subscription streaming service, how would you decide between enforcing entitlement with CloudFront signed cookies at the edge and having every media request authorized by your own API?
answer
- decide once, or decide every time
- a bearer credential cannot be recalled
- expiry is your revocation lever
- per-user URLs wreck the shared cache
- refresh endpoint is the compromise
basics
~20 sEdge enforcement trades revocation and audit granularity for cache efficiency and latency. Authorize once at your API, issue short-lived signed cookies, and keep per-request checks at the origin only where an immediate decision genuinely matters.
solid answer
~60 sFrame it as where the authorization decision is made and how long it stays valid. **Edge enforcement** with signed cookies moves the decision to session start: CloudFront verifies a signature locally, the origin never sees the request, and every entitled viewer shares the same cached object — which is the whole reason to run a CDN. The price is that a signed cookie is a bearer credential valid until it expires; you cannot revoke one, so a cancelled subscription or a shared credential stays live for the remainder of its lifetime, and the only record of the access is in CloudFront logs rather than your application's. **Origin enforcement** gives a fresh decision per request and a clean audit trail, but puts your API in the path of every segment fetch, scales with traffic rather than with sessions, and defeats caching if you make responses user-specific. In practice you combine them: authorize at the API, issue cookies with a lifetime short enough that expiry *is* your revocation, refresh them from an endpoint that re-checks entitlement, and set that lifetime by how much post-cancellation access the business will tolerate.
go deeper
Understand that CloudFront can check a signature itself so the request never reaches your servers, and that the alternative is your own API approving every request.
Explain the mechanics behind the tradeoff: signed cookies leave URLs shared so caching works, verification happens at the edge with no backend call, and the credential is valid until its expiry timestamp.
Show the production consequences and the hybrid design — short lifetimes with a refresh endpoint, key custody and rotation via the key group, cache-hit ratio as a first-class concern, and an explicit plan for auditing edge-served access.
Own the framing. Derive cookie lifetime from the tolerable revocation lag, justify where per-request checks earn their cost, name the business inputs — sharing rates, licensing terms, origin egress cost, audit obligations — and be willing to say which content should not be edge-enforced at all.
## The real axis: decision freshness versus decision cost Every access-control design picks a point on one line. At one end the decision is made once and encoded in a credential that is cheap to verify afterwards; at the other it is made afresh on every request, at the cost of a round trip to whatever holds the truth. CloudFront signed cookies sit hard at the cheap-verification end: CloudFront checks an RSA signature at the edge with no call to anything, so the marginal cost of an authorization is effectively zero and the latency is nil. Calling your own API per request sits at the other end. ## What edge enforcement buys Three things, and they compound at scale. **Cache efficiency.** Because signed cookies leave the URL untouched, ten thousand entitled viewers request the identical object URL and share one cached copy at each edge location. Origin egress collapses to near nothing for popular content. Per-user URLs, by contrast, fragment the cache and can turn a CDN into an expensive proxy. **Latency and blast radius.** A video player fetches a manifest and then a segment every few seconds. Putting an API call in front of each one adds a round trip to every fetch and makes your authorization service a hard dependency of playback — when it degrades, every stream stalls, including those already in progress. **Origin scale.** Session-rate traffic is orders of magnitude lower than segment-rate traffic. Authorizing once per session sizes your service against the smaller number. ## What edge enforcement costs **No revocation.** This is the honest weakness. A signed cookie is a bearer credential: whoever holds it can use it until `DateLessThan` passes. Cancel a subscription, discover credential sharing, or find an account compromised, and CloudFront will keep honouring the cookie you already issued. Your levers are short lifetimes, an `IpAddress` condition in a custom policy — which breaks mobile clients that roam between Wi-Fi and cellular — and rotating the key group's public keys, which is a blunt instrument that invalidates *everyone* signed with that key. **Audit granularity.** The access is recorded in CloudFront standard or real-time logs, not in your application's audit trail, and correlating an edge log line back to a user identity requires that you deliberately put something correlatable into the request. If a regulator or an abuse investigation needs "which user watched what, when", design for it up front. **Key custody.** You now hold a private key whose compromise mints unlimited access. It needs the same handling as any signing key: stored in Secrets Manager or KMS-wrapped, never in the repository, rotatable without downtime by having the key group hold old and new public keys during the overlap. ## The hybrid that people actually build Authorize at the API when a session starts or a play begins — that is where you already know the user, the subscription state and the device. Issue signed cookies with a **short** lifetime, chosen so that expiry is your revocation mechanism: minutes to a small number of hours, depending on how much post-cancellation viewing the business will accept. Provide a refresh endpoint that the client calls before expiry, and re-check entitlement there; that single call per refresh interval is the compromise between per-request freshness and per-session cheapness. Keep a hard per-request check only where the decision genuinely cannot wait — a purchase, a download of a master asset, an admin surface. When you need a real decision at the edge rather than a signature check, Lambda@Edge on the origin-request trigger can consult a store — but it runs only on cache misses, adds cost and latency, and re-couples you to a data dependency. Reach for it when it earns its place, not by default. ## How to argue it in an interview Name the business inputs, not just the mechanisms: what does an hour of unentitled viewing cost, how common is credential sharing, what does the licensing contract require, what is the cost of your origin serving segment traffic directly, and what does the audit obligation say. Then show the design falling out of those numbers — cookie lifetime derived from the tolerable revocation lag, refresh interval derived from the lifetime, per-request checks reserved for the few operations that justify them. The candidate who says "signed cookies, obviously" and the candidate who says "always check the API" have both skipped the actual question.
- How do you handle a subscription cancelled mid-session?Accept a bounded lag and size it deliberately. The already-issued cookie stays valid until it expires, so set the lifetime to the maximum post-cancellation access the business will tolerate and rely on the refresh endpoint to deny the next renewal. If the tolerance is genuinely zero, edge enforcement is the wrong mechanism for that content and the decision has to move to the origin.
- Someone proposes per-user signed URLs for every video segment instead of cookies. What is your objection?It fragments the cache. The signature rides in the query string, so each user requests a distinct URL and the CDN can no longer serve many viewers from one cached object — origin egress and cost climb toward what you would pay without a CDN. It also forces manifest rewriting per user. Cookies achieve the same authorization while keeping URLs shared.
- What would make you put a Lambda@Edge authorization check on origin request instead?A decision that must consult live state and cannot wait for the next cookie refresh — a per-title licence window, a device concurrency limit, a geo-fenced release. It runs only on cache misses, so the cost is bounded, but it re-introduces a data dependency in the request path. Justify it per use case rather than adopting it as the default posture.
- How do you preserve an audit trail if authorization happens at the edge?Plan for it deliberately. Application logs will only show the session-start authorization and each refresh, so enable CloudFront real-time or standard logs and carry a correlatable identifier — a session id in the path or a header you control — so edge access can be joined back to a user. Retro-fitting this after an abuse investigation starts is painful.
saying these in an interview costs you the question
- Claims a signed cookie can be revoked on demand
- Puts an API call in front of every media segment by default
- Uses per-user URLs and expects a good cache-hit ratio
- Sets multi-day cookie lifetimes without weighing revocation lag
- Assumes application logs capture edge-served access