Amazon Verified Permissions

Definition

Amazon Verified Permissions is a managed authorization service for application-level access decisions — separate from AWS IAM. You store policies written in Cedar, an AWS-developed declarative policy language designed for fine-grained authorization. Applications call the IsAuthorized API with a principal, action, and resource; Verified Permissions evaluates Cedar policies in a policy store and returns Allow or Deny in milliseconds. It fits multi-tenant SaaS, document permissions, healthcare record access, and microservices where “Can user X perform action Y on resource Z in tenant T?” cannot be expressed cleanly in IAM.

When to use it

• Multi-tenant SaaS with per-tenant or per-customer authorization rules using Cedar policy templates.
• Auditable authorization outside application code — policies are versioned artifacts, not scattered if statements.
• Compliance-driven access models (HIPAA, SOC 2, ISO 27001) requiring documented, reviewable authorization logic.
• Identity-aware microservices — each service calls IsAuthorized at the request boundary with Cognito, OIDC, or custom principals.
• Replacing brittle RBAC spaghetti when role counts explode but you do not need a full custom policy engine.

When not to use it

• AWS infrastructure API permissions — that is IAM, SCPs, and resource policies.
• Three static roles with no tenant dimension — hardcoded checks may suffice until complexity grows.
• Requirement for Rego/Open Policy Agent ecosystem — Cedar is AWS-native; OPA remains the open-source alternative if portability is mandatory.
• Sub-millisecond authorization at extreme QPS without caching — plan for batch IsAuthorized or local policy evaluation patterns for hot paths.

Tips

• Model groups, roles, and resource hierarchies in Cedar — avoid one policy per user.
• Use policy templates for tenant isolation; bind tenant context at IsAuthorized call time, not hardcoded tenant IDs in static policies.
• Keep your entity store (users, groups, documents) in your database; pass entity references to Verified Permissions rather than duplicating full user catalogs inside the policy store.
• Integrate with Amazon Cognito or IAM Identity Center for principal claims; map JWT attributes to Cedar entities consistently.
• Log IsAuthorized decisions to CloudTrail and your app logs for forensic replay during access disputes.

Gotchas

Serious

• Storing authoritative user data only in Verified Permissions — it evaluates policies; your identity and data plane remain source of truth elsewhere.
• One policy per user at scale — policy store sprawl becomes unmanageable; Cedar’s value is abstraction (roles, hierarchies, templates).
• Skipping authorization on internal service-to-service calls — attackers pivot through “trusted” internal APIs; enforce at every boundary.

Regular

• Confusing Verified Permissions with Cognito groups alone — Cognito groups are coarse; Cedar expresses resource-level and conditional rules.
• Not testing Deny precedence — explicit Deny in Cedar wins; integration tests must cover deny paths.
• Cold-start policy propagation — policy updates may take seconds to propagate; do not assume instant global consistency in tests.

Official references

• What is Amazon Verified Permissions?
• Cedar policy language overview
• IsAuthorized API
• Policy stores

Related FactualMinds content

• AWS Cloud Security Consulting
• Cloud Compliance Services
• Amazon Verified Permissions and Cedar