Skip to content

SYSTEM Cited by 1 source

Amazon Verified Permissions

What it is

Amazon Verified Permissions (AVP) is AWS's managed Cedar policy engine — a service that takes (principal, action, resource, context) and evaluates it against a policy store of Cedar policies and a Cedar schema, returning Allow / Deny plus determining-policy metadata. AVP is the application-authorization counterpart to IAM (which is AWS-resource authorization): same policy-language family (Cedar inside), different scope of enforcement.

Core model

  • Policy store = the unit of isolation. Contains a schema (entity types + attributes + valid action combinations) and a set of Cedar policies + policy templates.
  • Schema = typed authorization model: entity types, attributes, principal / resource / action combinations. AVP validates that a policy is consistent with the schema at write time.
  • Cedar policies stored inside the policy store as first-class data. Static policies (inline Cedar) + policy templates (parameterized Cedar, instantiated per principal/resource).
  • IsAuthorized / IsAuthorizedWithToken APIs — synchronous evaluation calls; "millisecond-level" per AWS docs.
  • Integration with Cognito — AVP can evaluate a Cognito JWT directly (IsAuthorizedWithToken), mapping token claims onto Cedar principal attributes.

Per-tenant policy store as the multi-tenancy primitive

A policy store is the isolation boundary. For SaaS, the idiomatic pattern is one policy store per tenant (patterns/per-tenant-policy-store), with an application-maintained tenant_id → policy-store-id mapping (typically in DynamoDB). Convera chose this pattern for four stated reasons:

  • Low-effort tenant policy isolation.
  • Per-tenant schema + template customization.
  • Low-effort tenant onboarding / offboarding (create / delete policy store).
  • Per-tenant resource quotas (quota consumption scoped to a tenant).

(Source: sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization)

Relation to the AWS automated-reasoning portfolio

AVP productizes Cedar, which was itself extracted from a decade of internal work on policy semantics at AWS. Cedar is designed specifically to be analyzable — the language constrains itself so policies admit formal reasoning (reachability, overlap, equivalence). AVP therefore inherits the automated-reasoning story: policy analysis is not an afterthought, it was the design goal.

See systems/aws-policy-interpreter for the decade-long arc (IAM policy analysis → Zelkova → Cedar public → AVP).

Typical integration shape

Client → API Gateway → Lambda authorizer
                     → AVP.IsAuthorized(policy_store, principal, action, resource, context)
                     → Allow | Deny
                     → IAM policy → API Gateway allows / rejects

The patterns/lambda-authorizer pattern with AVP is the reference shape across Convera's four authorization flows (customer UI + API, internal customer-service apps, machine-to-machine, multi-tenant SaaS). Decisions are cached at two levels (API Gateway authorizer-decision cache + app-level Cognito token cache) so AVP itself is hit on cache-miss only.

Policy governance flow

Convera's production shape: Cedar policies stored in DynamoDB as the source of truth, changes captured by DynamoDB Streams, a sync pipeline continuously propagates changes into AVP. Edit rights gated by a strictly-regulated IAM role owned by infosec. Separation: policy authorship is IAM-bounded; policy evaluation is app-bounded via the Lambda authorizer.

What it is not

  • Not a replacement for IAM. IAM authorizes AWS API calls on AWS resources; AVP authorizes application-defined actions on application-defined resources.
  • Not a user directory. AVP evaluates attributes you give it; identity
  • claims come from Cognito / an enterprise IdP.
  • Not a secret store, not a cache layer. Decision caching is explicitly an app-level / API-Gateway concern.

Caveats

  • Public-footprint information mostly comes via AWS docs + AWS Architecture Blog. Internal mechanics of policy-store storage, consistency, and decision-path latency-distribution are not public.
  • Quota values and behavior at quota are not discussed in Convera's post despite per-tenant quota isolation being named as a benefit.

Seen in

  • sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization — Convera as the canonical production case study: four authorization modes (customer UI + API, internal customer-service apps federated through Okta, service-to-service, multi-tenant SaaS) on one shared Lambda-authorizer + AVP shape; per-tenant policy store with DynamoDB tenant_id → policy-store-id mapping; thousands of authz requests/sec at submillisecond latency, ~60% reduction in access-management operational overhead.
Last updated · 200 distilled / 1,178 read