Amazon Verified Permissions – Fine-Grained Authorization with Cedar
Amazon Verified Permissions is a fully managed, scalable permissions management and fine-grained authorization service for custom applications. It uses the Cedar policy language — an open-source, expressive, and analyzable policy language — to define who can do what on which resources. Unlike AWS IAM (which controls access to AWS APIs), Verified Permissions is designed to be the externalized authorization engine for your own applications, enabling developers to decouple authorization logic from application code.
- April 2024: Cognito + API Gateway integration launched — secure APIs with fine-grained access control via Quick Start wizard
- August 2024: Expanded OIDC identity provider support for API Gateway authorization
- April 2026: Policy store aliases and named policies/policy templates support added
- May 2026: Multiple namespaces support aligned with Cedar language
- June 2025: Price reduction — single authorization requests reduced by up to 97% to $5 per million
- 2025: avp-local-agent for local policy evaluation with zero network latency
- 2025: ExpressJS integration for Node.js applications
What is Amazon Verified Permissions?
Amazon Verified Permissions serves as a Policy Decision Point (PDP) — a centralized service that evaluates authorization requests against Cedar policies and returns Allow or Deny decisions. Your application acts as the Policy Enforcement Point (PEP), calling Verified Permissions before allowing users to perform actions.
Key Characteristics
- Externalized authorization: Separates “who can do what” logic from application code, making policies auditable and manageable independently
- Cedar policy language: Open-source (Apache 2.0), formally verified, human-readable policy language developed by AWS
- Default deny: All actions are denied unless explicitly permitted — follows the principle of least privilege
- Explicit deny wins: A single
forbidpolicy always overrides any number ofpermitpolicies - Real-time evaluation: Sub-millisecond policy evaluation with single-digit millisecond API latency
- Schema validation: Policies are validated against a schema to catch errors at authoring time
- Supports RBAC and ABAC: Role-based and attribute-based access control models, or a combination of both
- Identity provider agnostic: Works with Amazon Cognito, any OIDC provider, or custom identity solutions
Cedar Policy Language
Cedar is an open-source policy language designed for expressing authorization policies. It is human-readable, formally verified for correctness, and designed for fast evaluation. Cedar policies are built around four core concepts:
Core Concepts
| Concept | Description | Example |
|---|---|---|
| Principal | The entity making the request (user, service, role) | User::"alice", User::"a1b2c3d4-..." |
| Action | The operation being performed | Action::"viewDocument", Action::"deleteOrder" |
| Resource | The target entity being acted upon | Document::"doc-123", Photo::"vacation.jpg" |
| Context | Additional request-time attributes (IP, time, MFA status) | context.ipAddress, context.authentication.usedMFA |
Policy Structure
Every Cedar policy has:
- Effect: Either
permit(allow) orforbid(deny) - Scope: Specifies which principal, action, and resource the policy applies to (mandatory)
- Conditions: Optional
when(must be true) andunless(must be false) clauses - Annotations: Optional key-value metadata (e.g.,
@id,@advice)
Cedar Policy Examples
Example 1: Simple RBAC — Editors Can Edit Documents
|
1 2 3 4 5 6 |
// Allow any user in the "editors" group to view and edit any document permit ( principal in Group::"editors", action in [Action::"viewDocument", Action::"editDocument"], resource ); |
Example 2: ABAC — Owner-Based Access
|
1 2 3 4 5 6 7 8 9 |
// Allow users to delete only documents they own permit ( principal, action == Action::"deleteDocument", resource ) when { resource.owner == principal }; |
Example 3: Context-Based Restriction — MFA Required
|
1 2 3 4 5 6 7 8 9 |
// Deny all actions unless the user has authenticated with MFA forbid ( principal, action, resource ) unless { context.authentication.usedMFA }; |
Example 4: Multi-Tenant SaaS — Tenant Isolation
|
1 2 3 4 5 6 7 8 9 |
// Allow users to access resources only within their own tenant permit ( principal, action, resource ) when { principal.tenantId == resource.tenantId }; |
Example 5: Time-Based and IP Restriction
|
1 2 3 4 5 6 7 8 9 10 11 |
// Allow access only during business hours from corporate network permit ( principal in Group::"employees", action == Action::"accessPayroll", resource == Application::"payroll-system" ) when { context.time.hour >= 9 && context.time.hour < 18 && context.network.ipAddress.isInRange("10.0.0.0/8") }; |
Example 6: Forbid Policy — Block Suspended Users
|
1 2 3 4 5 6 7 8 9 |
// Explicitly deny all access for suspended users forbid ( principal, action, resource ) when { principal.status == "suspended" }; |
Policy Store Architecture
A policy store is the top-level container in Verified Permissions that holds all policies, policy templates, and schema definitions. It is logically isolated from other policy stores.
Key Characteristics
- Logical isolation: Each policy store is independent — policies in one store cannot reference or affect another store
- Application mapping: Typically one policy store per application, or one per tenant in multi-tenant architectures
- Schema enforcement: Each policy store can have a schema that validates policies at creation time
- Namespace support: As of May 2026, Verified Permissions supports multiple namespaces within a policy store (aligned with Cedar)
- Policy store aliases: As of April 2026, you can assign human-readable aliases to policy stores for easier management
- CloudFormation support: Policy stores can be provisioned as infrastructure-as-code
Multi-Tenant Strategies
- Shared policy store: All tenants share one policy store; tenant isolation enforced through
when { principal.tenantId == resource.tenantId }conditions - Per-tenant policy store: Each tenant gets their own policy store — strongest isolation, but more management overhead
- Hybrid: Shared store for common policies, per-tenant stores for custom permissions
Schema Definition
The schema defines the authorization model for your application — entity types, their attributes, valid actions, and which principals can perform which actions on which resources. It serves as a contract that validates policies.
Schema Components
- Entity types: Define principals (e.g.,
User,Group) and resources (e.g.,Document,Folder) with their attributes - Actions: Define valid operations and which principal-resource combinations they apply to
- Common types: Reusable type definitions shared across entity types
- Hierarchy: Define parent-child relationships (e.g., a
DocumentisinaFolder)
Example Schema (JSON format)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
{ "MyApp": { "entityTypes": { "User": { "shape": { "type": "Record", "attributes": { "department": { "type": "String" }, "jobLevel": { "type": "Long" }, "tenantId": { "type": "String" } } }, "memberOfTypes": ["Group"] }, "Group": {}, "Document": { "shape": { "type": "Record", "attributes": { "owner": { "type": "Entity", "name": "User" }, "classification": { "type": "String" }, "tenantId": { "type": "String" } } }, "memberOfTypes": ["Folder"] }, "Folder": { "shape": { "type": "Record", "attributes": { "tenantId": { "type": "String" } } } } }, "actions": { "viewDocument": { "appliesTo": { "principalTypes": ["User"], "resourceTypes": ["Document"] } }, "editDocument": { "appliesTo": { "principalTypes": ["User"], "resourceTypes": ["Document"] } }, "deleteDocument": { "appliesTo": { "principalTypes": ["User"], "resourceTypes": ["Document"] } } } } } |
How Authorization Decisions Work
When your application calls the IsAuthorized or IsAuthorizedWithToken API, Verified Permissions evaluates all relevant policies and returns an Allow or Deny decision.
Evaluation Logic
- Collect relevant policies: Verified Permissions identifies all policies whose scope matches the request (principal, action, resource)
- Evaluate conditions: For each matching policy, evaluate
whenandunlessconditions against the provided context and entity attributes - Determine individual results:
- A
permitpolicy with matching scope and satisfied conditions → Allow - A
forbidpolicy with matching scope and satisfied conditions → Deny
- A
- Combine results:
- If at least one Deny exists → Final decision is DENY (explicit deny always wins)
- If at least one Allow and zero Denys → Final decision is ALLOW
- If no matching policies → Final decision is DENY (implicit deny / default deny)
Key Principles
- Default deny: With an empty policy store (no policies), all requests are denied
- Explicit deny overrides: A single matching
forbidpolicy overrides any number ofpermitpolicies - No ordering dependency: Policy evaluation order does not matter — all policies are evaluated independently
- Determining policies: The API response includes which policies contributed to the decision, enabling debugging and audit
Authorization API Request Example
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
// IsAuthorized API call { "policyStoreId": "ps-abc123def456", "principal": { "entityType": "MyApp::User", "entityId": "user-789" }, "action": { "actionType": "MyApp::Action", "actionId": "editDocument" }, "resource": { "entityType": "MyApp::Document", "entityId": "doc-456" }, "entities": { "entityList": [ { "identifier": { "entityType": "MyApp::User", "entityId": "user-789" }, "attributes": { "department": { "string": "Engineering" }, "jobLevel": { "long": 7 }, "tenantId": { "string": "tenant-A" } }, "parents": [ { "entityType": "MyApp::Group", "entityId": "editors" } ] }, { "identifier": { "entityType": "MyApp::Document", "entityId": "doc-456" }, "attributes": { "owner": { "entityIdentifier": { "entityType": "MyApp::User", "entityId": "user-789" } }, "classification": { "string": "internal" }, "tenantId": { "string": "tenant-A" } } } ] } } |
Integration with Amazon Cognito
Amazon Verified Permissions integrates natively with Amazon Cognito, enabling you to use Cognito tokens directly in authorization decisions without manual token parsing.
How It Works
- Identity source configuration: Connect a Cognito user pool as an identity source in your policy store
- Token-based authorization: Use the
IsAuthorizedWithTokenAPI, passing the Cognito ID token or access token directly - Automatic attribute mapping: Verified Permissions extracts user attributes (groups, custom claims, email) from the token and makes them available in Cedar policies
- Token validation: Verified Permissions validates token signature, expiration, and issuer automatically
- Group membership: Cognito groups are mapped to Cedar group hierarchies for RBAC
Policy Using Cognito Token Attributes
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
// Allow users in Cognito "admin" group to manage all resources permit ( principal in CognitoGroup::"admin", action, resource ); // Allow access based on custom Cognito attribute permit ( principal, action == Action::"viewReport", resource ) when { principal.custom.subscription_tier == "premium" }; |
Integration with API Gateway
Amazon Verified Permissions can secure Amazon API Gateway REST APIs using a Lambda authorizer pattern, with a Quick Start wizard that automates the setup.
Architecture Flow
- Client sends request to API Gateway with authentication token (Cognito JWT or OIDC token)
- API Gateway invokes the Lambda authorizer deployed by the Quick Start wizard
- Lambda authorizer extracts token claims, maps the API method and path to Cedar actions/resources
- Lambda authorizer calls Verified Permissions
IsAuthorizedWithTokenAPI - Verified Permissions evaluates Cedar policies and returns Allow/Deny
- Lambda authorizer translates the response to API Gateway’s expected IAM policy format
- API Gateway allows or denies the request accordingly
Key Features
- Quick Start wizard: Creates the Lambda authorizer, policy store, and sample policies automatically
- RBAC via groups: Control API access based on Cognito groups or OIDC claims
- ABAC via attributes: Fine-grained control using user attributes, request parameters, and context
- OIDC support: Works with any OpenID Connect-compatible identity provider (not just Cognito)
- Caching: Lambda authorizer can cache authorization results to reduce latency and Verified Permissions API calls
Policy Templates
Policy templates are Cedar policies with placeholders for the principal, resource, or both. They enable you to create reusable permission patterns that can be instantiated for specific users and resources.
How Templates Work
- Define once: Create a template with
?principaland/or?resourceplaceholders - Instantiate many: Create template-linked policies by filling in the placeholders with specific entity values
- Centralized updates: Modify the template and all linked policies are updated automatically
- Named templates: As of April 2026, templates can have human-readable names for easier management
Template Example
|
1 2 3 4 5 6 7 |
// Template: Document editor permission // Placeholders: ?principal and ?resource permit ( ?principal, action in [Action::"viewDocument", Action::"editDocument", Action::"commentDocument"], ?resource ); |
When you instantiate this template:
?principal=User::"alice"?resource=Document::"project-plan-2025"
This creates a policy that allows Alice to view, edit, and comment on the specific project plan document.
Use Cases for Templates
- Document sharing: Grant specific users access to specific documents (like Google Docs sharing)
- Resource-specific roles: Assign users as “admin” or “viewer” on individual resources
- Time-limited access: Templates with
when { context.time < expiry }for temporary grants - Onboarding workflows: Automatically create policies when users are assigned to projects
Batch Authorization
The BatchIsAuthorized and BatchIsAuthorizedWithToken APIs allow you to evaluate multiple authorization decisions in a single API call, reducing latency and costs for UI rendering and bulk operations.
Key Features
- Up to 30 requests per batch: Each API call can contain up to 30 individual authorization requests
- Shared principal or resource: Either the principal or the resource must be identical across all requests in a batch
- Single metering: Each batch API call counts as one request for billing (regardless of the number of individual authorizations)
- Individual results: Each authorization within the batch returns its own Allow/Deny decision
Use Cases
- UI permission rendering: Determine which buttons/actions to show a user across multiple resources (e.g., "Can this user edit, delete, share this document?")
- Navigation menus: Check access to multiple pages/features in a single call
- Bulk operations: Verify permissions before processing a batch of items
- Dashboard rendering: Determine which widgets/data a user can see
Local Authorization with avp-local-agent
The avp-local-agent is an open-source Rust-based sidecar that caches policies locally and evaluates authorization decisions within your application, eliminating network round-trips to the Verified Permissions API.
Key Benefits
- Zero network latency: Decisions are made locally using the Cedar evaluation engine
- No authorization API charges: Local evaluations are free — you only pay for policy management (cache refresh) calls
- High throughput: Ideal for latency-sensitive, high-frequency authorization (e.g., financial trading systems)
- Configurable cache refresh: Control how often the agent syncs policies from the Verified Permissions service
- Consistent evaluation: Uses the same Cedar engine as the cloud service, ensuring identical results
Audit Logging
Amazon Verified Permissions integrates with AWS CloudTrail for comprehensive audit logging of all API activity.
What Is Logged
- Management events: Policy store creation/deletion, schema updates, policy creation/modification — logged by default in CloudTrail
- Data events: Authorization requests (
IsAuthorized,BatchIsAuthorized) — can be enabled for detailed authorization auditing - Determining policies: Each authorization response includes the policy IDs that led to the decision
- Request context: Full details of who requested what, when, and the decision made
Audit Capabilities
- Policy querying: APIs to query which policies apply to specific principals or resources
- Compliance reporting: Answer "who has access to what?" and "why was this access granted?" questions
- Security investigation: Trace specific authorization decisions back to the policies that permitted them
- Policy impact analysis: Understand which users/resources would be affected by a policy change before deploying it
Comparison: Verified Permissions vs IAM Policies vs Cognito Groups vs Custom Authorization
| Feature | Verified Permissions | IAM Policies | Cognito Groups | Custom Auth Code |
|---|---|---|---|---|
| Purpose | Application-level authorization | AWS API access control | Coarse-grained user grouping | Application-level authorization |
| Granularity | Fine-grained (RBAC + ABAC) | Fine-grained for AWS resources | Coarse (group membership only) | Custom (depends on implementation) |
| Policy Language | Cedar (human-readable, formally verified) | JSON-based IAM policy language | None (group assignment only) | Code (if/else, switch statements) |
| Scope | Your application's resources | AWS services and resources only | Token-based role hints | Your application's resources |
| Externalized | Yes — policies managed separately from code | Yes — managed via AWS console/CLI | Partially (groups are external) | No — embedded in application code |
| Auditability | High — policies are declarative, queryable | High — IAM Access Analyzer | Limited (group membership only) | Low — requires code review |
| Multi-Tenant | Built-in (per-tenant policy stores) | Not designed for app tenancy | Not designed for multi-tenancy | Must build from scratch |
| Schema Validation | Yes — catches policy errors at authoring time | Yes — policy validation | No | No (unless you build it) |
| Scalability | Fully managed, auto-scaling | Fully managed by AWS | Fully managed by Cognito | Scales with your application |
| Performance | Sub-ms evaluation; local agent option | Evaluated per AWS API call | Token parsed locally (fast) | Depends on implementation |
| Best For | Application permissions at scale | Controlling AWS resource access | Simple role assignment | Simple apps or prototypes |
Use Cases
Multi-Tenant SaaS Applications
- Enforce tenant data isolation using Cedar policies with tenant context
- Per-tenant policy stores for strong isolation or shared stores with tenant-scoped policies
- Tenant administrators can manage their own permissions without affecting other tenants
- Example: A project management SaaS where each company (tenant) has its own roles, projects, and access rules
Role-Based Access Control (RBAC)
- Model roles as Cedar groups (e.g.,
Group::"admin",Group::"editor",Group::"viewer") - Assign users to groups and write policies that permit actions for group members
- Use action groups to bundle related permissions (e.g., "editor" role gets view + edit + comment)
- Policy templates for role-resource assignments
Attribute-Based Access Control (ABAC)
- Make authorization decisions based on attributes of principals, resources, and context
- Examples: department matching, job level thresholds, classification levels, time-of-day restrictions
- Combine with RBAC for layered security: "editors can edit, BUT only documents in their department"
Document-Level Access Control
- Model document sharing like Google Docs — individual users can be granted specific access to specific documents
- Use policy templates: instantiate per user-document pair with specific permissions (view, edit, comment)
- Hierarchical resources: grant access to a folder, and all documents within it inherit that access
- Owner-based access: document creators automatically get full control
Healthcare and Compliance
- PHI/PII access controls with detailed audit trails for HIPAA compliance
- Attribute-based filtering of sensitive data fields
- Break-glass emergency access with logging
Financial Services
- Fine-grained API authorization for payment processing and trade execution
- Segregation of duties enforcement
- Transaction-level authorization with amount thresholds
Pricing
Amazon Verified Permissions follows a pay-per-use model with no upfront or minimum fees. Pricing is the same across all AWS Regions.
| Usage Type | Price | Notes |
|---|---|---|
| Single Authorization (IsAuthorized, IsAuthorizedWithToken) | $0.000005 per request ($5/million) | Per API call |
| Batch Authorization (first 40M/month) | $0.00015 per request ($150/million) | Per batch call (up to 30 authz each) |
| Batch Authorization (next 60M/month) | $0.000075 per request | Volume discount tier |
| Batch Authorization (100M+/month) | $0.00004 per request | Highest volume discount |
| Policy Management (CRUD operations) | $0.00004 per request | Create, Update, Get, List policies |
| Local Agent Evaluation | $0 (free) | Pay only for policy management (cache sync) |
Pricing Example
A SaaS application with 250 vendors making 250,000 API calls/day × 20 working days = 5 million single authorization requests/month = 5M × $0.000005 = $25/month.
AWS Certification Relevance
- AWS Certified Developer – Associate (DVA-C02): Domain 3 — "Implement authentication and/or authorization for applications and AWS services." Understand how to externalize authorization using Verified Permissions with Cognito, API Gateway Lambda authorizers, and Cedar policies for application-level access control.
- AWS Certified Security – Specialty (SCS-C02): Domain 2 — "Security Logging and Monitoring" and Domain 3 — "Infrastructure Security." Understand fine-grained authorization patterns, policy evaluation logic (default deny, explicit deny overrides), integration with identity providers, audit logging via CloudTrail, and when to use Verified Permissions vs IAM vs Cognito groups.
Key Exam Concepts
- Verified Permissions is for application-level authorization (not AWS resource access — that's IAM)
- Cedar uses default deny — explicit
permitrequired; explicitforbidalways wins - Policy stores provide logical isolation between applications or tenants
- Integration with Cognito + API Gateway via Lambda authorizer pattern
- Supports both RBAC (groups/roles) and ABAC (attribute conditions) models
- BatchIsAuthorized for multiple decisions in a single call (up to 30 requests)
- Schema validates policies at authoring time (not runtime)
- Policy templates for reusable permission patterns with placeholders
Practice Questions
Question 1
A SaaS company needs to implement fine-grained access control for their multi-tenant document management application. Each tenant's users should only access documents within their own tenant, and document owners should have full control while team members get read-only access. The solution must be auditable and support real-time policy changes without code redeployment. Which approach best meets these requirements?
- Use IAM policies with condition keys to restrict access based on tenant tags
- Implement authorization logic in application code using if/else statements with Cognito group membership
- Use Amazon Verified Permissions with Cedar policies that evaluate tenant attributes and resource ownership
- Create separate Cognito user pools per tenant with custom Lambda triggers for authorization
Show Answer
Answer: C –
Explanation: Amazon Verified Permissions with Cedar policies is designed for application-level fine-grained authorization. Cedar supports RBAC (owner/team member) and ABAC (tenant isolation via attribute matching), policies are externalized from code (real-time updates without redeployment), and all authorization decisions are auditable via CloudTrail. IAM (A) is for AWS resource access, not application authorization. Embedding auth in code (B) is not auditable and requires redeployment for changes. Separate Cognito pools per tenant (D) adds complexity without solving fine-grained document-level access.
Question 2
A developer is building a Cedar policy in Amazon Verified Permissions. The policy store has: a permit policy allowing users in the "editors" group to edit documents, AND a forbid policy denying all actions when principal.status == "suspended". A user who is in the "editors" group AND has status "suspended" requests to edit a document. What is the authorization decision?
- ALLOW — the permit policy matches and the user is in the editors group
- DENY — the forbid policy takes precedence because explicit deny always overrides permit
- ALLOW — permit policies are evaluated before forbid policies
- Error — conflicting policies cannot exist in the same policy store
Show Answer
Answer: B –
Explanation: In Cedar's policy evaluation logic, an explicit deny (forbid policy) always overrides any number of permit policies. Both policies match the request — the permit matches because the user is in "editors", and the forbid matches because the user's status is "suspended". Since at least one forbid policy matches, the final decision is DENY. Policy evaluation order does not matter (C is wrong), and conflicting policies are perfectly valid (D is wrong).
Question 3
A company's application renders a dashboard where different UI elements (buttons, menus, data widgets) should be shown or hidden based on the user's permissions. The application needs to check 15 different permissions for the current user at page load time. What is the most cost-effective approach using Amazon Verified Permissions?
- Call the
IsAuthorizedAPI 15 times — once for each permission check - Use the
BatchIsAuthorizedAPI to evaluate all 15 authorization requests in a single call - Cache all policies locally and evaluate permissions in the browser using JavaScript
- Use Cognito groups to determine all permissions without calling Verified Permissions
Show Answer
Answer: B –
Explanation: BatchIsAuthorized can evaluate up to 30 authorization requests in a single API call, and is metered as one request for billing. This is both faster (single round-trip) and more cost-effective than 15 individual calls. Individual calls (A) work but cost 15× more. Client-side evaluation (C) exposes policies to the browser — a security risk. Cognito groups (D) only support coarse-grained RBAC, not fine-grained attribute-based decisions.
Question 4
An organization wants to secure their REST APIs in Amazon API Gateway using Amazon Verified Permissions for fine-grained access control based on user attributes from Amazon Cognito. What is the correct architecture to achieve this?
- Configure API Gateway to call Verified Permissions directly as a native authorizer
- Use a Cognito authorizer on API Gateway and pass the authorization decision to Verified Permissions
- Deploy a Lambda authorizer that extracts token claims, calls Verified Permissions IsAuthorizedWithToken API, and returns an IAM policy to API Gateway
- Configure Verified Permissions as an identity source in API Gateway's resource policy
Show Answer
Answer: C –
Explanation: The correct pattern uses a Lambda authorizer as the bridge between API Gateway and Verified Permissions. The Lambda function extracts claims from the Cognito token, calls the IsAuthorizedWithToken API, and translates the response into API Gateway's expected IAM policy format (Allow/Deny). API Gateway does not have native Verified Permissions integration (A, D are wrong). A Cognito authorizer (B) only validates tokens — it doesn't call Verified Permissions for fine-grained decisions.
Question 5
A financial services company needs to authorize 200 million trade decisions per month with the lowest possible latency. Policies change infrequently (updated a few times daily). Which Amazon Verified Permissions deployment pattern minimizes latency while ensuring policies stay current?
- Use the standard
IsAuthorizedAPI for each trade with caching enabled - Deploy the avp-local-agent sidecar configured to refresh policies every few minutes, evaluating all decisions locally
- Use BatchIsAuthorized with 30 trade decisions per batch to reduce API calls
- Implement custom Cedar evaluation in the application code without using Verified Permissions
Show Answer
Answer: B –
Explanation: The avp-local-agent evaluates Cedar policies locally with zero network latency, which is critical for high-frequency trading. Since local evaluations are free ($0), the cost is only for policy management API calls to refresh the cache. With policies changing infrequently, a refresh interval of a few minutes ensures policies stay current. The standard API (A) adds network latency to each decision. BatchIsAuthorized (C) reduces calls but still has network latency. Custom implementation (D) loses the managed service benefits and requires maintaining the Cedar engine yourself.
Frequently Asked Questions
What is Amazon Verified Permissions?
Verified Permissions is a managed authorization service that uses the Cedar policy language to make fine-grained access decisions. It centralizes authorization logic outside your application code, supporting RBAC, ABAC, and relationship-based access control.
What is Cedar policy language?
Cedar is an open-source authorization policy language created by AWS. It uses a simple permit/forbid syntax with principals, actions, resources, and conditions. It's designed to be analyzable, auditable, and performant for real-time authorization decisions.
How does Verified Permissions differ from IAM?
IAM controls access to AWS resources (who can call AWS APIs). Verified Permissions controls access within your application (which users can see/edit which data). Use IAM for infrastructure; Verified Permissions for application-level authorization.
References
- Amazon Verified Permissions — Product Page
- Amazon Verified Permissions — User Guide
- Cedar Policy Language — Reference Guide
- Amazon Verified Permissions — Pricing
- Amazon Verified Permissions — Features
- Authorize API Gateway APIs using Verified Permissions with Cognito
- avp-local-agent — GitHub Repository