AWSAWS Certified Generative AI Developer - Professional2026-104.1 Implement cost optimization and resource efficiency strategies
Cache at the edge within privacy boundaries
Completed by the knowledge check
Learning objective
Apply CloudFront and Lambda@Edge caching only when content variation, access controls, and privacy boundaries permit.
Core idea
An edge cache can return content without contacting the origin. That is its latency benefit and its access-control hazard. If the origin normally decides what a caller can see, a cache hit can skip that decision unless the architecture enforces the required check before cached content is released.
For an architect placing a GenAI application behind CloudFront, decide eligibility per response class. Public, stable artifacts can be good edge candidates. Personalized answers require complete variation keys and enforceable authorization. Sensitive, contextual, or rapidly changing responses often belong on a cache-disabled edge path with application response caching behind the authorization boundary.
How it works
Separate delivery from answer reuse
CloudFront’s allowed HTTP methods determine which requests it forwards, not which responses it caches. CloudFront caches responses to GET and HEAD, and optionally OPTIONS. It does not cache responses to the other methods, including POST. Allowing all methods does not turn a POST inference API into an edge response cache.
A GenAI endpoint accepting POST requests can still use CloudFront for delivery and an authorized application cache for response reuse. Exact and semantic caches from 4.1.6 sit behind that API and understand the effective request. Do not redesign sensitive prompts as URL query strings merely to obtain edge hits: request contents must follow the workload’s privacy and logging policy.
A generated public artifact can instead have a GET representation with an explicit publication decision and versioned identity. Its eligibility comes from the artifact’s stable, approved contents, not from the fact that a model generated it. Keep public artifact publication separate from a private conversational response.
Include every response-changing dimension
A CloudFront cache policy controls which headers, cookies, and query strings participate in the cache key, along with cache lifetimes. If the origin varies its response by language, product version, or a tenant header, include the required dimensions in the key or disable caching for that behavior.
An origin request policy has a different job: it forwards additional information to the origin without necessarily adding it to the cache key. Forwarding a tenant cookie so the origin personalizes a miss does not partition later hits. If the cookie is omitted from the key, two viewers can select the same cached object despite receiving different origin responses on a miss.
Derive any normalized tenant or entitlement header from trusted identity before cache lookup. Reject a viewer-supplied value that claims a scope without authorization. Minimizing key variation is useful only after identifying which variation is irrelevant. A higher hit ratio obtained by merging incompatible users is a security defect.
Preserve authorization on hits
AWS documents that CloudFront removes Authorization from origin requests by default. It can be forwarded by including it in a cache policy, forwarding it through an origin request policy, or using an origin request policy that forwards all viewer headers. These choices do not provide the same cache isolation.
AWS specifically warns that forwarding Authorization without including it in the key can serve the same cached response to authorized and unauthorized viewers. Include it in the cache key when that is the required variation, or disable caching where the origin must process authorization. Even a token-specific key is not sufficient for a permission change that leaves the token unchanged; define how revocation is enforced before returning a hit.
For private files, CloudFront supports signed URLs and signed cookies through the cache behavior’s viewer-access restrictions. These mechanisms control access to the selected resource. They do not prove that an artifact built with one user’s context is appropriate for every viewer permitted to fetch it. Use an artifact identity and publication scope consistent with its contents.
Place Lambda@Edge at the correct event
Lambda@Edge functions execute at CloudFront trigger events. A viewer-request function runs before the cache lookup. An origin-request function runs only when CloudFront forwards a request to the origin; it does not run on a cache hit. An origin-response function runs after the origin responds and before CloudFront caches that response, with documented exceptions. On a cache hit, only the viewer-request function runs before cached content is released.
Therefore, an origin-request authorization function cannot be the sole access check for cached content. If your design uses Lambda@Edge to reject unauthorized viewers or derive a trusted key dimension, use the viewer-request stage before lookup. If that check requires unavailable authorization state, reject the protected request rather than letting the cache bypass it. Test warm hits as well as misses.
Lambda@Edge is an event hook, not a separate durable answer-cache database. Use it to implement the approved request and response transformations while CloudFront supplies the object cache. Each function must finish before CloudFront continues, so complex validation increases delivery latency.
If a function examines request content, account for the Include Body limits. CloudFront base64-encodes the body and truncates the exposed body at 40 KB for viewer-request events and 1 MB for origin-request events. With read-only body access, CloudFront still sends the full original body to the origin. A function that validates only the exposed prefix can therefore approve content it has not inspected. Reject or route oversized requests to complete origin-side validation; do not compute a supposedly complete response identity from a truncated prefix.
Make cache lifetime explicit
CloudFront’s minimum TTL can override privacy directives. When the cache policy’s minimum TTL is greater than zero, CloudFront caches content for at least that duration even when the origin sends Cache-Control: no-cache, no-store, or private.
For protected dynamic paths, use the managed CachingDisabled policy, whose minimum, maximum, and default TTL values are all zero. Configure the required origin forwarding independently; disabling cache storage does not automatically supply missing authentication headers. For eligible shared content, choose a cache policy whose lifetimes match the permitted staleness and whose key captures every required variant.
A minimum TTL of zero does not itself disable caching because other lifetime settings and origin headers still matter. Review the complete behavior rather than checking one header or one TTL field. Browser retention and application-cache retention are additional boundaries governed separately; see 3.2.10.
Key distinctions and trade-offs
Edge caching saves origin work only for eligible HTTP representations. Application caching can handle POST request contracts and richer authorization, but still requires the scope checks from 4.1.9. Choose the layer that can represent equality and enforce access correctly.
A broad shared key improves reuse but increases the burden of proving that all viewers can receive identical bytes. A token-specific key reduces sharing and can still serve stale permissions. Signed access controls, key variation, and revocation policy each solve a separate part of the problem.
Architecture / decision scenario
A product assistant exposes public versioned manuals and a private POST chat API. CloudFront caches the manuals with a key containing required language and version variation. The POST API uses CachingDisabled, forwards authorization to the origin, and performs response-cache lookup only after application entitlement checks.
The team also offers private generated GET reports. It refuses to share one path across tenants while merely forwarding the tenant cookie through an origin request policy. Each report has an authorized artifact scope, and any Lambda@Edge viewer validation runs at viewer-request time. Origin-request processing remains insufficient because a warm hit skips it.
A test sends two viewers to the same warmed report path and verifies that the second cannot obtain the first viewer’s bytes. Another test confirms that no-store is not defeated by a positive minimum TTL. An oversized prompt goes through complete origin validation rather than relying on Lambda@Edge’s truncated body. The team enables edge reuse only for response classes whose variation and access tests pass.
Common exam traps
- Assuming CloudFront caches POST responses because it forwards POST requests.
- Forwarding personalization data without including it in the cache key.
- Relying on origin-request Lambda@Edge authorization during a cache hit.
- Treating signed access as proof that a personalized artifact is shareable.
- Assuming
privateorno-storedefeats a positive minimum TTL. - Hashing or validating a truncated Lambda@Edge body as if it were complete.
What to remember
An edge hit skips the origin. Make response variation part of the key and enforce required access before lookup or disable caching. CloudFront cache policies, origin request policies, and Lambda@Edge event placement have separate roles. Use CachingDisabled for ineligible paths and application caching for authorized response reuse where HTTP edge caching cannot express the contract.
Knowledge check
A chat API accepts prompts as POST requests through CloudFront. The behavior allows all HTTP methods, and the team expects repeated prompts to be served from edge cache. Which design achieves answer reuse?
POST and rely on the behavior that allows all methodsGET query strings so the edge can cache themPOST and add an authorized application cache behind the APIPOST and attach a cache policy with a long default TTLGET , HEAD and optionally OPTIONS . Prompt reuse belongs in an application cache that understands the effective request and enforces entitlements. Moving prompts into URLs to win edge hits pushes sensitive content into query strings and logs.An origin personalizes generated reports by a tenant cookie. The cookie reaches the origin through an origin request policy, but the cache policy does not include it. What happens on a warm hit?
Viewer authorization for cached private reports runs in a Lambda@Edge function attached to the origin-request event. Where must the check run so that it applies to every request?
A protected path’s origin sends Cache-Control: no-store, but a test shows CloudFront still caching its responses. The behavior’s cache policy has a minimum TTL of 60 seconds. What fixes it?
private to the origin’s Cache-Control headerCachingDisabled cache policyAuthorization header to the origin request policyno-cache , no-store or private . A zero minimum alone does not disable caching, because default and maximum TTL still apply; CachingDisabled sets all three to zero. Forwarding still has to be configured separately.A viewer-request Lambda@Edge function hashes the request body to decide whether a prompt is an approved repeat, and passes it through on a match. Some prompts exceed 40 KB. What is the flaw?