AWS Glossary
Amazon Verified Permissions
Amazon Verified Permissions is a managed fine-grained authorization service using Cedar policies — for applications that need to express "who can do what to which resource" outside of AWS IAM.
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
ifstatements. - 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
Related FactualMinds content
Related Services
AWS Security Consulting
AWS security consulting from an AWS Select Tier Partner. 2-week assessment, 4–6 week remediation, zero disruption. IAM hardening, public exposure, compliance gaps, and continuous monitoring.
Cloud Compliance Services — HIPAA, SOC 2, PCI DSS on AWS
Cloud compliance services — HIPAA, SOC 2, PCI DSS, ISO 27001, GDPR. Expert consulting from FactualMinds.
Need help with this topic?
Our AWS-certified team implements, audits, and optimizes these services in production — from Bedrock RAG pipelines to multi-account landing zones.