A product image can be served repeatedly to many visitors. A quote may contain conditions intended for one buyer, in one currency, for one period. Placing both behind a content delivery network does not make the same cache policy appropriate for both. Before optimising a private response for reuse, establish who may read it and whether another request should receive the same content.

For international buyers, this is a reasonable question to ask of a supplier portal: does the system distinguish access to my quote from access to the website? For Chinese exporters commissioning that portal, it is a concrete acceptance issue that should be resolved with the implementation team rather than assumed from a successful login demonstration.

Three decisions happen at different boundaries

AWS announced CloudFront support for Lambda Web Functions origins on 12 October. Its announcement describes edge delivery and caching, alongside Origin Access Control, or OAC, that restricts the origin to requests arriving through CloudFront. It also distinguishes applications that authenticate their own users. The support excludes the CloudFront China region, so it should not be presented as a universal regional capability.

OAC concerns the path from the CDN to the origin. It does not decide whether a particular visitor is entitled to a particular quote. The application still needs to check buyer identity, ownership and relevant permissions. A request can have arrived through the approved infrastructure and still be inappropriate for the requested business record.

Caching makes a further decision: which requests may reuse an existing response. If the application generates different content for different buyers, the cache configuration must not collapse those differences into one reusable object. It is insufficient to demonstrate that the origin authenticates a request correctly if a later edge hit can reuse a response without that origin execution.

These distinctions also explain why an obscure quote number is not an access policy. The identifier locates the record. It does not establish the reader's authority, and putting more account information in a URL is not a substitute for proper authorisation or a considered cache design.

Inspect the policy, not just the response header

The current CloudFront managed-policy documentation gives a useful warning. CachingOptimized omits cookies and query strings from its cache key and has a minimum time to live greater than zero. AWS states that a positive minimum TTL causes caching for at least that period even when the origin sends no-cache, no-store or private directives.

Consequently, “the application sets private” is only part of the answer. The operator needs to inspect the policy attached to the actual path, its minimum TTL and the identity information forwarded to the origin. A policy designed to reduce cache fragmentation can be appropriate for public assets while being a poor default for buyer-dependent responses.

CloudFront also provides CachingDisabled, with its TTL values set to zero, for content that should not be cached. That does not implement buyer authentication. It addresses response reuse. For a private quote route, deliberately avoiding shared caching is generally a simpler starting point than attempting to encode every commercial condition into a shared cache key.

The rest of the site does not have to lose caching as a consequence. Public product descriptions, generic diagrams and other genuinely common resources can use separate behaviours. The useful design boundary follows the response's audience and sensitivity, not a blanket choice between “CDN enabled” and “CDN disabled”.

Test the second visitor

A single successful session demonstrates very little about shared-response isolation. Use authorised test accounts and non-sensitive test records. Visit the relevant route as one account, then request it as another. Check the actual content or refusal, rather than only the status displayed by the browser. Repeat with a logged-out request and with a record that should no longer be available.

Run the sequence in both account orders. A first request with no reusable response available may behave correctly while a later request reuses the wrong content. The intended outcome remains explicit: each buyer receives their own permitted result or an appropriate denial, never the other buyer's conditions. Keep these tests separate from checks that merely demonstrate a working sign-in page.

This is distinct from keeping buyer parameters inside their own application request. Request-local state concerns what concurrent application work reads and writes. Edge caching concerns reuse of an already generated response. Correcting one layer does not establish correctness at the other.

For a private quote, a correct response or a correct refusal matters more than a higher cache-hit ratio. Keep the public delivery path fast where reuse is appropriate, and make buyer-specific response handling a separate, demonstrable decision.

Sources