Skip to lesson

AWSAWS Certified Generative AI Developer - Professional2026-104.1 Implement cost optimization and resource efficiency strategies

Authorize cache reuse within explicit partitions

Completed by the knowledge check

Learning objective

Partition caches by user/tenant authorization and context to prevent cross-user data leakage.

Core idea

A cache hit is another data-access path. If generation and retrieval enforce authorization but cache lookup does not, the optimization bypasses the original security boundary. The same question can legitimately produce different answers for two callers because their documents, account state, or permissions differ.

For an architect protecting a multi-tenant application, partition cached answers by the trusted scope that determines both access and meaning. Authenticate and authorize before lookup, constrain candidate selection, and recheck validity before release. Neither query similarity nor an unguessable key grants permission to an answer.

How it works

Derive a trusted scope

Resolve the caller’s tenant, principal, and effective entitlements from verified identity and server-side authorization state. Do not accept a tenant namespace supplied in the prompt or request body as the authority. The application can accept a requested tenant only after proving that the caller is entitled to that scope.

Define which dimensions affect the permitted result. A tenant identifier separates organizations, but it does not separate a manager’s personnel records from another employee’s records inside the same organization. Include a user boundary or validated entitlement class when the answer depends on narrower access. Include context such as account, product version, jurisdiction, language, and conversation state when those dimensions change meaning.

Represent authorization with stable scope identifiers and a revision that changes when reuse permissions change. These are application-defined values, not a Bedrock mechanism. A raw list of role names is insufficient if document grants change independently. Bind the cache scope to the actual source entitlements that produced the answer, and consult authoritative permissions when a hit is considered.

The request identity in 4.1.7 carries the scope and context. This lesson determines who can enter that identity and whether a returned artifact is still authorized. An identical question in a different permitted scope is a different cache lookup.

Constrain storage access

DynamoDB provides item-level building blocks for an exact-response cache. A design can use the trusted scope as its partition key and a request hash as its sort key. GetItem requires the complete primary key, so application lookup names both the authorized partition and the effective request identity.

Where callers use distinct IAM identities or scoped sessions, DynamoDB IAM policies can restrict partition-key values with dynamodb:LeadingKeys and the ForAllValues modifier. AWS’s fine-grained-access example compares leading keys with a federated user’s identity. Adapt the principle to a proven tenant identity rather than copying the example’s identity source into an unrelated system.

This protection depends on the identity AWS actually evaluates. A shared application role permitted to read every tenant partition does not acquire end-user isolation because a tenant field exists in the HTTP request. The service sees the application’s AWS permissions; the application must enforce end-user authorization, or deliberately use a correctly scoped AWS access path. See 3.2.2 for the distinction between IAM and application entitlements.

Restrict permitted operations too. AWS notes that Scan returns items regardless of leading keys and excludes it from the example’s restricted action list. Do not add a broad enumeration path that bypasses the intended item access boundary. Partitioning is useful only when every cache-access path respects it.

Scope semantic candidates and context

A semantic cache must not search an unrestricted population and return the highest-scoring answer. AWS’s ElastiCache guidance recommends tag and numeric filters derived from application context. Its example store searches within a namespace. Treat namespaces and metadata filters as application lookup mechanisms, then verify how the chosen implementation enforces them; they are not an automatic end-user authorization policy.

Choose either separate stores or indexes for required isolation, or a shared store with mandatory trusted partition constraints and access enforcement.

ElastiCache Role-Based Access Control (RBAC) assigns users to user groups and limits commands and key patterns through access strings. For example, on ~app::* -@all +@read permits read commands on keys beginning with app::. RBAC is the only access-control mechanism for serverless caches. It constrains the cache user the application connects as, not the application’s end user. Do not assume key patterns filter FT.SEARCH results over a shared index; enforce and test authorized candidate selection separately.

Reject records with absent or mismatched tenant and entitlement metadata. If the search cannot reliably constrain candidates to the approved scope, bypass that cache path. Never broaden the search to another tenant because the authorized partition has no hit.

Conversation context creates another partition boundary. “Summarize my account” depends on the identified account, and “What changed since then?” depends on conversation history. A globally reusable question vector omits both. AWS recommends combining the current message with relevant facts and recent messages for multi-turn semantic caching. Preserve the access scope of those facts as well as their meaning.

Store provenance identifying the documents or data snapshots behind each answer. Permission-aware retrieval from 1.4.6 applies when building a fresh answer; a response-cache hit can skip that retrieval. You must therefore retain enough provenance to verify that the caller still has access to the evidence embodied in the answer. Checking only the displayed citation is insufficient when uncited text contains restricted information.

Revoke reuse independently of cleanup

Check the current authorization revision and dependency scope before publication, including cache hits and results generated while permissions are changing. An entry valid when created can become invalid after a membership change or document revocation. Advance the revision, reject old candidates, and explicitly delete records when retention policy requires removal.

DynamoDB GetItem is eventually consistent by default; use ConsistentRead: true for a strongly consistent item read where the design requires it. This cannot make an external identity system and a cache read one atomic operation. Define the authoritative revocation check and fail closed when the required authorization state is unavailable.

DynamoDB time to live (TTL) deletes expired items typically within a few days. It cannot implement immediate revocation. Application expiration and authorization checks must reject records before physical cleanup. General deletion across derived data is covered in 3.2.10.

Key distinctions and trade-offs

Tenant partitioning and user partitioning solve different problems. Sharing an answer within a tenant is safe only when all consumers share the required entitlements and answer context. Per-user caching narrows sharing but can fragment reuse; an entitlement-class cache improves reuse only if class membership genuinely implies equivalent access.

Public answers can occupy a deliberately public partition, but admission must prove that the artifact depends only on approved public inputs. A response generated in a private context does not become public because its final wording looks generic. Separate public and private publication rules.

Encryption protects stored bytes against unauthorized storage access; it does not prevent an authorized application from returning the wrong tenant’s decrypted answer. Similarity thresholds address relevance, and result fingerprints address artifact identity. Neither replaces authorization.

Architecture / decision scenario

A benefits assistant serves two employers, with employees and HR specialists inside each employer. The same question about leave can require a general policy answer, a private employee-specific answer, or an HR-only case summary.

The application derives employer and effective entitlements before cache lookup. General policy answers use a scope shared only by permitted readers of that policy. Employee cases use a narrower principal or case-access scope; HR summaries require the corresponding entitlement revision. DynamoDB lookups include the trusted partition key, and the semantic cache restricts candidates to the same scope and policy context.

When an HR specialist loses case access, the authorization revision changes. A previously cached case summary is rejected even if its TTL has not elapsed and the question matches exactly. A miss never falls back to the other employer’s cache. If authorization state cannot be checked, the application withholds the protected response instead of treating a cache hit as permission.

Common exam traps

  • Partitioning only by tenant when users within that tenant have different grants.
  • Trusting a tenant identifier written by the caller or model.
  • Assuming a shared IAM role automatically enforces end-user entitlements.
  • Applying semantic similarity before a mandatory access boundary.
  • Using encryption, hashing, or TTL as an immediate authorization control.
  • Returning a private-context answer through a public partition because it sounds generic.

What to remember

Authorize before lookup and before release. Bind cache partitions to trusted tenant, user entitlements, and answer context, then enforce those boundaries on every read path. Preserve provenance and revision checks so that cached answers obey changed permissions even when generation and retrieval are skipped.

Knowledge check

References