In Amazon CloudFront, when would you protect private content with signed URLs versus signed cookies, and what does a trusted key group have to do with either?

## What "restrict viewer access" actually turns on By default CloudFront serves an object to anyone who knows the URL. Enabling *restrict viewer access* on a **cache behavior** changes that: from then on CloudFront serves a request only if it carries a valid signature produced by a private key whose matching public key you have handed to CloudFront. It is a per-cache-behavior switch, not a per-distribution one, so the normal shape is a single distribution where the behavior matching `/assets/*` is open and the behavior matching `/media/*` is signed. ## Key groups: who holds what You generate an RSA key pair yourself. The public half is uploaded to CloudFront as a *public key* and placed in a *key group*; the cache behavior lists that key group as a trusted key group. CloudFront never holds the private key — your application does, usually pulled from Secrets Manager or Parameter Store at startup — and uses it to sign. The older mechanism, *trusted signers*, required CloudFront key pairs created by the account's root user; it still exists but key groups are the current answer and the one to describe in an interview. A key group can hold several public keys at once, which is precisely what makes key rotation non-disruptive: add the new public key, start signing with the new private key, and drop the old public key only after every credential signed with it has expired. ## Anatomy of a signed URL A signed URL is the ordinary object URL with signing parameters appended. With a **canned policy** you get three: `Expires`, `Signature`, `Key-Pair-Id`. A canned policy can express only one thing — an expiry on one exact resource. With a **custom policy** the expiry is replaced by a base64url-encoded `Policy` document, and that document can additionally express a start time (`DateGreaterThan`), a source IP or CIDR (`IpAddress`), and a wildcard `Resource` covering many paths. Custom policies produce longer URLs; that is the price of the extra conditions. ## Anatomy of signed cookies Signed cookies carry the same material under cookie names: `CloudFront-Signature`, `CloudFront-Key-Pair-Id`, and either `CloudFront-Expires` (canned) or `CloudFront-Policy` (custom). Your login or entitlement endpoint sets them with `Set-Cookie` after checking the user's subscription; the browser then attaches them to every subsequent request to that domain automatically. Because cookies are scoped to a domain, the distribution has to be reached through an alternate domain name that you control and that is covered by the cookie's `Domain` attribute — you cannot set cookies for `cloudfront.net`. This is the mechanism's one hard prerequisite and a common stumbling block. ## Choosing between them Reach for a **signed URL** when the grant is for one file, when the client is not a browser and will not keep a cookie jar, when you want to email or embed a time-limited link, or when different objects need genuinely different expiries. Reach for **signed cookies** when a session needs access to many objects, when you do not want to rewrite the URLs inside a manifest or an HTML page, and when the same object URL should be shareable across all entitled viewers so the CDN cache stays effective. Mixing the two on one request is not the intent: if a request carries both, CloudFront uses the signed URL. ## What signing does not do A signed URL or cookie is a bearer credential with an expiry. Whoever holds it can use it, and there is no per-credential revocation — your levers are short expiries, `IpAddress` in a custom policy, and rotating the key group. Clock skew matters, since expiry is absolute time. Signing also protects only the CloudFront path: if the origin bucket or server is reachable directly by another route, the signature is decoration. And a CloudFront signed URL is not an S3 presigned URL — the latter is a SigV4 signature made with IAM credentials and validated by S3 itself, while a CloudFront signature is RSA, made with your own private key, and validated at the edge. ```javascript // signature parameters, canned policy // https://cdn.example.com/media/a.mp4?Expires=1767225600&Signature=...&Key-Pair-Id=KEXAMPLE123456 ```