{"id":333,"date":"2026-04-13T16:55:38","date_gmt":"2026-04-13T16:55:38","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/aws-amazon-verified-permissions-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security-identity-and-compliance\/"},"modified":"2026-04-13T16:55:38","modified_gmt":"2026-04-13T16:55:38","slug":"aws-amazon-verified-permissions-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security-identity-and-compliance","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/aws-amazon-verified-permissions-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security-identity-and-compliance\/","title":{"rendered":"AWS Amazon Verified Permissions Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security, identity, and compliance"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Security, identity, and compliance<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What this service is<\/h3>\n\n\n\n<p>Amazon Verified Permissions is an AWS authorization service that helps you define, manage, and evaluate fine-grained permissions for your applications using the Cedar policy language.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">One-paragraph simple explanation<\/h3>\n\n\n\n<p>If your application needs to decide \u201cCan this user perform this action on this resource right now?\u201d, Amazon Verified Permissions gives you a centralized, consistent way to write those rules (policies) and ask AWS to evaluate them at runtime\u2014so you don\u2019t have to scatter authorization logic across microservices, APIs, and codebases.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">One-paragraph technical explanation<\/h3>\n\n\n\n<p>Technically, Amazon Verified Permissions stores authorization policies (written in Cedar) in a <strong>policy store<\/strong>, optionally uses a <strong>schema<\/strong> to validate entities and types, and exposes authorization APIs (for example, <code>IsAuthorized<\/code>) that evaluate a request\u2014<strong>principal<\/strong>, <strong>action<\/strong>, <strong>resource<\/strong>, plus optional <strong>context<\/strong> and <strong>entities<\/strong>\u2014against the policies. The service returns an authorization decision (allow\/deny) and can provide decision details for debugging and analysis.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What problem it solves<\/h3>\n\n\n\n<p>Most teams struggle with authorization as systems grow:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Rules become inconsistent across services (\u201cservice A allows, service B denies\u201d).<\/li>\n<li>Permission checks get duplicated and drift over time.<\/li>\n<li>Fine-grained authorization (ABAC\/ReBAC) becomes too complex to maintain safely.<\/li>\n<li>Auditing and reviewing authorization logic is difficult.<\/li>\n<\/ul>\n\n\n\n<p>Amazon Verified Permissions solves these by centralizing policy evaluation, using a purpose-built policy language (Cedar), and making authorization decisions consistent across your application stack.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Amazon Verified Permissions?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Amazon Verified Permissions is designed to <strong>help developers build and manage application authorization<\/strong> using policies in the <strong>Cedar<\/strong> language, and to <strong>evaluate<\/strong> those policies consistently at runtime.<\/p>\n\n\n\n<p>Official documentation entry point (start here):<br\/>\nhttps:\/\/docs.aws.amazon.com\/verifiedpermissions\/latest\/userguide\/what-is-avp.html (verify the exact path in official docs if it changes)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<p>Key capabilities you typically use in real systems include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Central policy management<\/strong>: store policies in a managed policy store.<\/li>\n<li><strong>Fine-grained authorization<\/strong>: implement ABAC (attribute-based access control) and ReBAC (relationship-based access control) patterns using Cedar.<\/li>\n<li><strong>Runtime policy evaluation<\/strong>: call AWS APIs to get allow\/deny decisions.<\/li>\n<li><strong>Schema support<\/strong>: define entity types, actions, and attributes to validate policies and improve safety.<\/li>\n<li><strong>Identity token integration<\/strong>: evaluate authorization using identity tokens (for example, with Amazon Cognito), when configured (verify supported token sources in the official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Policy store<\/strong>: a container for Cedar policies (and optionally a schema). You query a specific policy store when authorizing requests.<\/li>\n<li><strong>Policies<\/strong>: Cedar <code>permit<\/code> \/ <code>forbid<\/code> rules that express authorization.<\/li>\n<li><strong>Policy templates<\/strong> (if used in your design): reusable patterns to generate policies (verify the latest template features and APIs in the docs).<\/li>\n<li><strong>Schema<\/strong>: definitions of entity types, actions, and attributes, used for validation and safer authoring.<\/li>\n<li><strong>Authorization APIs<\/strong>: API calls to evaluate an authorization decision such as <code>IsAuthorized<\/code> (and related batch\/token-based variants\u2014verify current API names in the AWS SDK\/CLI docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed authorization service<\/strong> (central policy evaluation and storage).<\/li>\n<li>Not an authentication service: it does <strong>not<\/strong> sign users in; it answers \u201cis this allowed?\u201d after you already know \u201cwho is calling?\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional \/ global scope<\/h3>\n\n\n\n<p>Amazon Verified Permissions is implemented as an AWS service with <strong>regional endpoints<\/strong> and regional resources (policy stores are created in a region). Service availability and supported regions can change\u2014<strong>verify current region availability<\/strong> in the AWS documentation or the AWS Regional Services List:\nhttps:\/\/aws.amazon.com\/about-aws\/global-infrastructure\/regional-product-services\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the AWS ecosystem<\/h3>\n\n\n\n<p>Amazon Verified Permissions commonly sits in the authorization layer of your application:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Amazon Cognito<\/strong> (authentication) issues tokens; your app uses those identities with Verified Permissions for authorization.<\/li>\n<li><strong>Amazon API Gateway \/ AWS AppSync \/ ALB + Lambda<\/strong> frontends call your service; your service calls Verified Permissions for decisions.<\/li>\n<li><strong>AWS Lambda \/ Amazon ECS \/ Amazon EKS<\/strong> host your workloads, which call Verified Permissions at runtime.<\/li>\n<li><strong>AWS CloudTrail<\/strong> records API activity for auditing.<\/li>\n<\/ul>\n\n\n\n<p>In the AWS \u201cSecurity, identity, and compliance\u201d category, Verified Permissions complements IAM (AWS resource authorization) by focusing on <strong>application authorization<\/strong>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Amazon Verified Permissions?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster delivery of secure features<\/strong>: policy updates can be made without rewriting authorization logic everywhere.<\/li>\n<li><strong>Consistency reduces risk<\/strong>: one policy source reduces \u201cedge-case\u201d access bugs that become incidents.<\/li>\n<li><strong>Better audit readiness<\/strong>: centralized policies are easier to review than scattered conditional logic.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Fine-grained permissions<\/strong>: model complex rules beyond simple roles (e.g., \u201cdocument owner can edit; auditors can view; external collaborators can comment during project window\u201d).<\/li>\n<li><strong>Separation of concerns<\/strong>: developers build features; security\/platform teams can own policy patterns and guardrails.<\/li>\n<li><strong>Policy language designed for authorization<\/strong>: Cedar is purpose-built to express authorization rules clearly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Centralized change management<\/strong>: versioning and reviewing policies is easier than auditing many repos and services.<\/li>\n<li><strong>Scales across microservices<\/strong>: multiple services can query the same policy store for consistent decisions.<\/li>\n<li><strong>Reduced \u201cpolicy drift\u201d<\/strong>: one authorization decision point minimizes divergence.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Least privilege in the app layer<\/strong>: implement \u201conly what\u2019s necessary\u201d access at the business-object level.<\/li>\n<li><strong>Audit trail<\/strong>: management operations are recorded by AWS APIs (via CloudTrail). For decision logging patterns, you typically log decisions in your app; confirm service-native decision logging options in the docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Central evaluation<\/strong>: avoids rebuilding an authorization engine in every service.<\/li>\n<li><strong>Batch patterns<\/strong>: if you need to authorize many resources\/actions at once, evaluate batch APIs (verify current support and limits in official API references).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Amazon Verified Permissions when:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You need <strong>application-level<\/strong> fine-grained access control (documents, projects, tickets, records).<\/li>\n<li>You need consistent authorization across <strong>multiple services<\/strong> or multiple deployments.<\/li>\n<li>You want policy-as-code with reviewable, testable policies using Cedar.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When they should not choose it<\/h3>\n\n\n\n<p>Avoid or reconsider when:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You only need <strong>AWS resource authorization<\/strong> (S3 bucket policies, IAM policies, KMS key policies). Use IAM for that.<\/li>\n<li>Your app is extremely latency-sensitive and can\u2019t afford an extra network call per request without careful caching and design.<\/li>\n<li>Your authorization needs are trivial and stable (simple admin\/user role) and you don\u2019t expect growth\u2014though even then, centralizing early can help.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Amazon Verified Permissions used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<p>Common fits include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS platforms (B2B, multi-tenant)<\/li>\n<li>Healthcare and life sciences (record-level access control, auditing)<\/li>\n<li>Financial services (entitlements, approvals, segregation of duties)<\/li>\n<li>Education (course content access, staff\/student roles + relationships)<\/li>\n<li>Media and publishing (content permissions, editorial workflows)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams standardizing authorization<\/li>\n<li>Security engineering teams defining access control patterns<\/li>\n<li>Application teams building APIs and UIs that require consistent decisions<\/li>\n<li>DevOps\/SRE teams improving reliability and observability for auth services<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Document\/project management apps<\/li>\n<li>CRM\/ERP-style record systems<\/li>\n<li>Customer support ticketing<\/li>\n<li>Data portals and internal dashboards<\/li>\n<li>Collaboration tools with sharing and invitations<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Microservices where each service needs the same access model<\/li>\n<li>Serverless APIs (API Gateway + Lambda)<\/li>\n<li>GraphQL backends (AWS AppSync) where resolvers need consistent checks<\/li>\n<li>Hybrid setups where some workloads run on-prem but call AWS authorization (network and security considerations apply)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: typically with a rigorous policy review workflow, canary testing, and decision logging patterns.<\/li>\n<li><strong>Dev\/test<\/strong>: separate policy stores per environment (dev\/stage\/prod) to avoid accidental policy changes affecting production.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Amazon Verified Permissions fits well.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Multi-tenant SaaS: tenant isolation + shared admin model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Prevent cross-tenant data access while enabling tenant admins to manage their users.<\/li>\n<li><strong>Why it fits<\/strong>: Cedar can express tenant scoping (e.g., <code>principal.tenantId == resource.tenantId<\/code>) plus admin overrides.<\/li>\n<li><strong>Example<\/strong>: A SaaS project tool where users can only view projects in their tenant; tenant admins can manage billing settings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Document sharing with ownership, editors, and viewers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Complex sharing rules are hard to maintain across UI, API, and background jobs.<\/li>\n<li><strong>Why it fits<\/strong>: ReBAC-style relationships (owner\/editor\/viewer) map cleanly into Cedar entities\/attributes.<\/li>\n<li><strong>Example<\/strong>: A \u201cDocs\u201d app where owners can edit, editors can comment, viewers can read, and access can be time-bound.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Approval workflows with step-based permissions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Who can approve depends on workflow stage and role.<\/li>\n<li><strong>Why it fits<\/strong>: Policies can incorporate context (workflow stage, thresholds) and attributes (role, department).<\/li>\n<li><strong>Example<\/strong>: Purchase request approvals: manager can approve up to $5k; finance can approve beyond.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Customer support access controls (ticket-level authorization)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Agents should only see tickets in assigned queues; supervisors can see all.<\/li>\n<li><strong>Why it fits<\/strong>: Policies encode queue membership and supervisory privileges.<\/li>\n<li><strong>Example<\/strong>: Ticketing system with region-based assignment and escalation rules.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Data portal row-level authorization<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A data portal exposes many datasets; access depends on dataset classification and user clearance.<\/li>\n<li><strong>Why it fits<\/strong>: ABAC rules based on attributes like <code>clearanceLevel<\/code>, <code>dataClassification<\/code>.<\/li>\n<li><strong>Example<\/strong>: Internal analytics portal: \u201cconfidential\u201d datasets require clearance and training completion.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) API authorization across microservices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Each service implements authorization differently; hard to reason about system-wide access.<\/li>\n<li><strong>Why it fits<\/strong>: Standardize policy evaluation via a shared policy store and consistent request patterns.<\/li>\n<li><strong>Example<\/strong>: Orders, shipments, invoices services all call Verified Permissions for consistent \u201ccan user do X?\u201d checks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) B2B partner access with contract-specific permissions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Partners have negotiated entitlements and time windows.<\/li>\n<li><strong>Why it fits<\/strong>: Policies can incorporate contract attributes and context like current date\/time (if provided).<\/li>\n<li><strong>Example<\/strong>: Partner can access only certain product catalogs during contract period.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Feature flagging based on entitlements (authorization-driven)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Feature access depends on plan, add-ons, and internal roles.<\/li>\n<li><strong>Why it fits<\/strong>: Policies can map principals to entitlements and allow actions representing features.<\/li>\n<li><strong>Example<\/strong>: Only \u201cEnterprise\u201d plan users can export audit logs; admins can configure SSO.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Internal admin tools with least privilege<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Admin consoles often become over-permissioned.<\/li>\n<li><strong>Why it fits<\/strong>: Fine-grained actions and resource scoping reduce blast radius.<\/li>\n<li><strong>Example<\/strong>: Ops engineers can restart services but cannot change billing settings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Collaborative resources with relationship graphs (teams, projects, groups)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Users belong to teams; teams own projects; permissions inherit.<\/li>\n<li><strong>Why it fits<\/strong>: ReBAC is a natural match when modeling relationships (membership, ownership, hierarchy).<\/li>\n<li><strong>Example<\/strong>: Users in a team can view team projects; project leads can edit.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Regulated environments needing policy review and traceability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Auditors want clear, reviewable authorization logic.<\/li>\n<li><strong>Why it fits<\/strong>: Centralized policies are easier to review than scattered code.<\/li>\n<li><strong>Example<\/strong>: Healthcare app with role + patient-care-team rules.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Gradual modernization of legacy authorization<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Legacy monolith has complex access logic that\u2019s hard to change.<\/li>\n<li><strong>Why it fits<\/strong>: You can move authorization decisions out of the monolith step-by-step.<\/li>\n<li><strong>Example<\/strong>: Extract document permissions into a Verified Permissions policy store while keeping legacy data access.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Feature availability and exact API names can evolve. Validate against the current AWS docs and SDK references.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">1) Cedar policy language support<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lets you write authorization policies using Cedar (<code>permit<\/code>\/<code>forbid<\/code>) with conditions.<\/li>\n<li><strong>Why it matters<\/strong>: Cedar is designed to be understandable and auditable.<\/li>\n<li><strong>Practical benefit<\/strong>: Policies become reviewable artifacts in change control.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Your team must learn Cedar and establish testing\/review workflows.<\/li>\n<\/ul>\n\n\n\n<p>Cedar docs (language reference): https:\/\/docs.cedarpolicy.com\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2) Managed policy store<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Stores policies centrally in AWS.<\/li>\n<li><strong>Why it matters<\/strong>: Multiple services\/apps can reuse the same authorization model.<\/li>\n<li><strong>Practical benefit<\/strong>: Consistency across microservices and environments.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Policy stores are regional resources; plan for multi-region architecture if needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Authorization decision APIs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Evaluate authorization requests (principal\/action\/resource + optional context\/entities) and return allow\/deny.<\/li>\n<li><strong>Why it matters<\/strong>: Moves decision logic out of your services.<\/li>\n<li><strong>Practical benefit<\/strong>: Application code becomes simpler and consistent.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Adds network dependency and latency; use caching and careful design where appropriate.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Schema-driven validation (recommended)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Defines entity types (principal\/resource), actions, and attributes to validate policies.<\/li>\n<li><strong>Why it matters<\/strong>: Reduces runtime surprises and policy authoring errors.<\/li>\n<li><strong>Practical benefit<\/strong>: Safer refactoring and clearer contracts between app and policy.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: You must keep schema aligned with application data model.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Contextual authorization<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Include request context (e.g., IP range, time window, request flags) in authorization evaluation.<\/li>\n<li><strong>Why it matters<\/strong>: Many real policies depend on runtime context.<\/li>\n<li><strong>Practical benefit<\/strong>: Enables rules like \u201callow export only from corporate network\u201d (if you supply IP in context).<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Context is only as trustworthy as how you compute it\u2014ensure it\u2019s server-derived, not client-supplied.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Relationship-based access modeling (ReBAC patterns)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Express relationships such as owner\/member\/admin and use them in policies.<\/li>\n<li><strong>Why it matters<\/strong>: Sharing and collaboration commonly require relationship graphs.<\/li>\n<li><strong>Practical benefit<\/strong>: Cleaner than role explosion in RBAC-only designs.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: You must decide where relationship data lives (your DB, directory, etc.) and how you pass it for evaluation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Identity token\u2013based authorization (when configured)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Allows authorization requests to be evaluated using identity tokens (commonly JWTs), mapping token claims to principals.<\/li>\n<li><strong>Why it matters<\/strong>: Reduces glue code between authentication and authorization.<\/li>\n<li><strong>Practical benefit<\/strong>: Easier integration with typical web\/mobile authentication flows (for example, Amazon Cognito).<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Validate supported identity sources and claim mappings in the current docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Policy management APIs (create\/update\/list)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Supports programmatic policy lifecycle.<\/li>\n<li><strong>Why it matters<\/strong>: Enables GitOps-style management and automation.<\/li>\n<li><strong>Practical benefit<\/strong>: CI\/CD pipelines can promote policies across environments.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Treat policy changes as security-sensitive deployments; apply approvals and testing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Batch authorization patterns (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Evaluate multiple authorization requests efficiently.<\/li>\n<li><strong>Why it matters<\/strong>: UIs often need \u201cwhich of these 100 items can I see?\u201d<\/li>\n<li><strong>Practical benefit<\/strong>: Reduced application overhead compared to per-item calls.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Confirm request limits, response size limits, and pricing dimensions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) AWS auditability via CloudTrail (management plane)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Captures API calls for creating\/updating policy stores and policies.<\/li>\n<li><strong>Why it matters<\/strong>: Essential for auditing and incident response.<\/li>\n<li><strong>Practical benefit<\/strong>: Security teams can track \u201cwho changed authorization.\u201d<\/li>\n<li><strong>Limitations\/caveats<\/strong>: For decision-level audit trails, you usually implement structured application logs; verify whether the service offers decision logging features in your region.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>Amazon Verified Permissions typically works like this:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Your app authenticates the caller (often using Amazon Cognito or another IdP).<\/li>\n<li>Your API\/service constructs an authorization request:\n   &#8211; <strong>principal<\/strong>: who is calling (user\/entity)\n   &#8211; <strong>action<\/strong>: what they want to do (<code>ReadDocument<\/code>, <code>UpdateDocument<\/code>)\n   &#8211; <strong>resource<\/strong>: what they want to access (<code>Document:123<\/code>)\n   &#8211; <strong>context<\/strong>: runtime facts (optional)\n   &#8211; <strong>entities<\/strong>: relevant attributes\/relationships (optional; can be provided to the API depending on your design)<\/li>\n<li>Your service calls Amazon Verified Permissions.<\/li>\n<li>Verified Permissions evaluates the request against Cedar policies in the policy store.<\/li>\n<li>Verified Permissions returns a decision (allow\/deny) and optional decision information (per API).<\/li>\n<li>Your service enforces the decision (allow proceeds; deny returns 403).<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Request \/ data \/ control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control flow<\/strong>: Application code calls Verified Permissions during request handling (synchronous decision).<\/li>\n<li><strong>Data flow<\/strong>:<\/li>\n<li>Policies are stored in the policy store.<\/li>\n<li>Attributes and relationships are provided to the service according to your model (often from your application database).<\/li>\n<li><strong>Enforcement point<\/strong>: Your service remains the enforcement point (PEP). Verified Permissions is a policy decision point (PDP).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related AWS services<\/h3>\n\n\n\n<p>Common integrations include:\n&#8211; <strong>Amazon Cognito<\/strong> for authentication and token issuance.\n&#8211; <strong>Amazon API Gateway + AWS Lambda<\/strong> for APIs where Lambda calls Verified Permissions.\n&#8211; <strong>AWS AppSync<\/strong> where resolvers call Verified Permissions (directly or through Lambda).\n&#8211; <strong>Amazon ECS \/ Amazon EKS<\/strong> microservices calling Verified Permissions with AWS SDK.\n&#8211; <strong>AWS CloudTrail<\/strong> for auditing configuration changes.\n&#8211; <strong>AWS KMS<\/strong> (service-managed encryption at rest is typical for AWS services; verify specifics in the docs).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Identity and Access Management (<strong>IAM<\/strong>) controls who can administer policy stores and call authorization APIs.<\/li>\n<li>Your identity provider (Cognito or external) for authentication.<\/li>\n<li>Your application data store for resource attributes and relationship facts (for example, DynamoDB\/RDS\/Neptune), depending on your model.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security \/ authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Your workload calls Amazon Verified Permissions using <strong>AWS credentials<\/strong> (IAM role for Lambda\/ECS\/EKS).<\/li>\n<li>Policies determine what the <em>end user<\/em> can do; IAM determines what the <em>service<\/em> can call.<\/li>\n<li>Do not confuse the two layers:<\/li>\n<li>IAM authorizes access to AWS APIs\/resources.<\/li>\n<li>Verified Permissions authorizes access to <strong>your application resources<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Calls to Verified Permissions go to AWS service endpoints.<\/li>\n<li>For private networking (no public internet), evaluate whether the service supports <strong>AWS PrivateLink \/ VPC endpoints<\/strong> in your region; <strong>verify in official docs<\/strong> because not all AWS services support interface endpoints in all regions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring \/ logging \/ governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>CloudTrail<\/strong> to audit policy store and policy changes.<\/li>\n<li>Emit application logs for:<\/li>\n<li>authorization request ID (if available)<\/li>\n<li>principal\/action\/resource<\/li>\n<li>decision<\/li>\n<li>latency<\/li>\n<li>Consider CloudWatch metrics from your application for authorization call rates, error rates, and p95\/p99 latency. If the service provides native CloudWatch metrics, <strong>verify in the docs<\/strong> and enable them.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[User \/ Client] --&gt;|JWT \/ session| A[API (API Gateway \/ ALB)]\n  A --&gt; S[Service (Lambda \/ ECS \/ EKS)]\n  S --&gt; VP[Amazon Verified Permissions&lt;br\/&gt;IsAuthorized]\n  VP --&gt; S\n  S --&gt;|Allow\/Deny enforced| A\n  A --&gt; U\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Client\n    Web[Web\/Mobile Client]\n  end\n\n  subgraph Auth\n    Cog[Amazon Cognito&lt;br\/&gt;User Pool]\n  end\n\n  subgraph Edge\n    APIGW[Amazon API Gateway]\n  end\n\n  subgraph Compute\n    L1[AWS Lambda&lt;br\/&gt;API Handler]\n    L2[AWS Lambda&lt;br\/&gt;Policy Helper\/Client]\n  end\n\n  subgraph Data\n    DB[(Application DB&lt;br\/&gt;DynamoDB\/RDS)]\n  end\n\n  subgraph AuthZ\n    VP[Amazon Verified Permissions&lt;br\/&gt;Policy Store (regional)]\n  end\n\n  subgraph Observability\n    CW[Amazon CloudWatch&lt;br\/&gt;Logs\/Metrics]\n    CT[AWS CloudTrail]\n  end\n\n  Web --&gt;|Sign-in| Cog\n  Web --&gt;|Access token| APIGW\n  APIGW --&gt; L1\n  L1 --&gt; DB\n  L1 --&gt; L2\n  L2 --&gt; VP\n  L1 --&gt; CW\n  L2 --&gt; CW\n  VP --&gt; CT\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An active <strong>AWS account<\/strong> with billing enabled.<\/li>\n<li>Ability to create and manage Amazon Verified Permissions resources in your chosen region.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>For the hands-on lab, you need IAM permissions to:\n&#8211; Create and manage a Verified Permissions policy store, schema, and policies.\n&#8211; Call authorization APIs (<code>IsAuthorized<\/code>).<\/p>\n\n\n\n<p>The simplest approach for a lab:\n&#8211; Use an admin-like role in a sandbox account, or\n&#8211; Create a least-privilege IAM policy (recommended in production). For exact actions, <strong>verify the latest IAM actions<\/strong> for Verified Permissions in the AWS Service Authorization Reference:\nhttps:\/\/docs.aws.amazon.com\/service-authorization\/latest\/reference\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>This is a paid AWS service (request-based pricing is common). You should monitor usage during the lab.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI \/ SDK tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS CLI v2<\/strong> installed and configured:<\/li>\n<li>Install: https:\/\/docs.aws.amazon.com\/cli\/latest\/userguide\/getting-started-install.html<\/li>\n<li>Configure: <code>aws configure<\/code><\/li>\n<li>Optional: a language SDK (Python\/boto3, JavaScript v3, Java, etc.) if you want to integrate from code.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Choose a region where Amazon Verified Permissions is available.<\/li>\n<li>Verify region support: https:\/\/aws.amazon.com\/about-aws\/global-infrastructure\/regional-product-services\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas \/ limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service quotas exist (for example, policies per store, request size, etc.). <strong>Verify current quotas<\/strong> in:<\/li>\n<li>AWS documentation for Verified Permissions, and\/or<\/li>\n<li>Service Quotas console (if quotas are integrated there for the service in your region).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<p>For the CLI-only lab in this tutorial:\n&#8211; No additional AWS services are strictly required.\nFor production-style builds:\n&#8211; Typically Amazon Cognito, API Gateway\/AppSync, and your compute\/database stack.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Amazon Verified Permissions pricing is <strong>usage-based<\/strong>. Exact prices vary by region and can change, so use the official pricing page and AWS Pricing Calculator.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Official pricing page: https:\/\/aws.amazon.com\/verified-permissions\/pricing\/  <\/li>\n<li>AWS Pricing Calculator: https:\/\/calculator.aws\/#\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (verify exact meters)<\/h3>\n\n\n\n<p>Common pricing dimensions for authorization services like Verified Permissions include:\n&#8211; <strong>Number of authorization requests<\/strong> (for example, calls to <code>IsAuthorized<\/code> and any batch\/token variants)\n&#8211; Potentially different pricing for <strong>batch<\/strong> operations or additional features (verify on the pricing page)\n&#8211; Typically, management operations (create\/list\/update) are not the main cost driver, but <strong>verify<\/strong> if they are billed<\/p>\n\n\n\n<p>Because AWS pricing can be nuanced, confirm the exact billed API operations and units on the official pricing page.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<p>Free tier eligibility varies by service and time. <strong>Verify<\/strong> whether Amazon Verified Permissions has a free tier on the pricing page.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers<\/h3>\n\n\n\n<p>Primary drivers:\n&#8211; High request volume (authorization checks per API call, per UI element, per item in a list)\n&#8211; Chatty authorization patterns (calling Verified Permissions multiple times per end-user request)<\/p>\n\n\n\n<p>Secondary\/indirect drivers:\n&#8211; <strong>CloudWatch Logs<\/strong> ingestion and retention for application decision logs\n&#8211; <strong>Data transfer costs<\/strong> if you call the service across regions (avoid cross-region calls when possible)\n&#8211; Compute overhead (Lambda duration, ECS CPU) to assemble entity\/context data for checks<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Over-authorization calls<\/strong>: e.g., authorizing each row in a large list with individual calls.<\/li>\n<li><strong>Excessive decision logging<\/strong>: logging full entity graphs can inflate log costs and increase exposure of sensitive data.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep policy evaluation <strong>in-region<\/strong> with your workload.<\/li>\n<li>Cross-region data transfer can add cost and latency.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Minimize calls per request<\/strong>: design APIs that authorize once per operation, not repeatedly.<\/li>\n<li>Prefer <strong>batch authorization<\/strong> patterns when your UI needs multiple decisions (verify supported batch APIs).<\/li>\n<li>Cache stable decisions carefully (short TTLs, and only if policy\/entity changes won\u2019t create security risk).<\/li>\n<li>Reduce log verbosity in production; log decisions in a structured but minimal form.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (no fabricated numbers)<\/h3>\n\n\n\n<p>A small dev environment might make a few thousand authorization calls per day. Your cost will primarily be:\n&#8211; Authorization requests (per the service\u2019s per-request pricing unit)\n&#8211; Minimal CloudWatch Logs if you log decisions<\/p>\n\n\n\n<p>Use the AWS Pricing Calculator with your expected request counts and region. Do not assume the same price across regions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production, estimate:\n&#8211; Peak authorization QPS (queries per second)\n&#8211; Calls per end-user request (target 1\u20132, not 10+)\n&#8211; Batch usage (if you list many resources)\n&#8211; Logging volume (GB\/day) for decision audits<\/p>\n\n\n\n<p>Run load testing to estimate authorization call volume realistically and calculate cost accordingly.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab is intentionally <strong>CLI-first<\/strong> and avoids building a full web app, so you can learn Amazon Verified Permissions mechanics at low cost and with minimal dependencies. You will:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create a policy store<\/li>\n<li>Add a schema for a small \u201cDocs\u201d authorization model<\/li>\n<li>Create Cedar policies<\/li>\n<li>Call <code>IsAuthorized<\/code> with sample entities to see allow\/deny decisions<\/li>\n<li>Clean up<\/li>\n<\/ul>\n\n\n\n<blockquote>\n<p>Notes:\n&#8211; AWS CLI commands and API shapes can change. If a command fails due to shape differences, consult the latest AWS CLI reference for <code>verifiedpermissions<\/code>.\n&#8211; Some fields (for example, request\/response shapes) are easiest to confirm in the AWS CLI docs or SDK API reference. If you see discrepancies, <strong>follow the current docs<\/strong>.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Implement a simple document authorization model:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>User<\/strong> can <code>Read<\/code> a document if:<\/li>\n<li>they are the <strong>owner<\/strong>, OR<\/li>\n<li>they are in the document\u2019s <strong>readers<\/strong> list<\/li>\n<li>A <strong>User<\/strong> can <code>Update<\/code> a document only if:<\/li>\n<li>they are the <strong>owner<\/strong><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will build:\n&#8211; Policy store: <code>DocsPolicyStore<\/code>\n&#8211; Entity types: <code>User<\/code>, <code>Document<\/code>\n&#8211; Actions: <code>Read<\/code>, <code>Update<\/code>\n&#8211; Policies:\n  &#8211; Permit read for owners and readers\n  &#8211; Permit update for owners only<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set up your environment variables<\/h3>\n\n\n\n<p>Pick a region where Amazon Verified Permissions is available.<\/p>\n\n\n\n<pre><code class=\"language-bash\">export AWS_REGION=\"us-east-1\"\nexport POLICY_STORE_NAME=\"DocsPolicyStore\"\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Your shell has a target region and a friendly name for your policy store.<\/p>\n\n\n\n<p>Verification:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws sts get-caller-identity\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a policy store<\/h3>\n\n\n\n<p>Create the policy store that will contain your Cedar policies and schema.<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws verifiedpermissions create-policy-store \\\n  --region \"$AWS_REGION\" \\\n  --validation-settings mode=STRICT \\\n  --description \"Policy store for docs authorization lab\"\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Command returns details including a <code>policyStoreId<\/code>.<\/p>\n\n\n\n<p>Save it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export POLICY_STORE_ID=\"&lt;PASTE_POLICY_STORE_ID_HERE&gt;\"\n<\/code><\/pre>\n\n\n\n<p>Verification:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws verifiedpermissions get-policy-store \\\n  --region \"$AWS_REGION\" \\\n  --policy-store-id \"$POLICY_STORE_ID\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Define and upload a schema<\/h3>\n\n\n\n<p>A schema helps validate policies and your authorization requests.<\/p>\n\n\n\n<p>Create a file named <code>schema.json<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; schema.json &lt;&lt; 'EOF'\n{\n  \"cedarJson\": {\n    \"User\": {\n      \"entityTypes\": {},\n      \"memberOfTypes\": [],\n      \"shape\": {\n        \"type\": \"Record\",\n        \"attributes\": {\n          \"tenantId\": { \"type\": \"String\", \"required\": true }\n        }\n      }\n    },\n    \"Document\": {\n      \"entityTypes\": {},\n      \"memberOfTypes\": [],\n      \"shape\": {\n        \"type\": \"Record\",\n        \"attributes\": {\n          \"tenantId\": { \"type\": \"String\", \"required\": true },\n          \"owner\": { \"type\": \"Entity\", \"name\": \"User\", \"required\": true },\n          \"readers\": { \"type\": \"Set\", \"element\": { \"type\": \"Entity\", \"name\": \"User\" }, \"required\": false }\n        }\n      }\n    },\n    \"Action\": {\n      \"entityTypes\": {},\n      \"memberOfTypes\": [],\n      \"shape\": {\n        \"type\": \"Record\",\n        \"attributes\": {}\n      }\n    }\n  }\n}\nEOF\n<\/code><\/pre>\n\n\n\n<p>Upload schema:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws verifiedpermissions put-schema \\\n  --region \"$AWS_REGION\" \\\n  --policy-store-id \"$POLICY_STORE_ID\" \\\n  --definition file:\/\/schema.json\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Schema is stored and associated with the policy store.<\/p>\n\n\n\n<p>Verification:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws verifiedpermissions get-schema \\\n  --region \"$AWS_REGION\" \\\n  --policy-store-id \"$POLICY_STORE_ID\"\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>If the schema format differs (AWS may use a specific schema structure for Cedar), adjust it according to the current Verified Permissions schema documentation. Do not force-fit an incorrect schema\u2014schema mismatches are a common early stumbling block.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create Cedar policies<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Policy 1: Permit read for owner or listed readers<\/h4>\n\n\n\n<p>Create <code>policy-read.cedar<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; policy-read.cedar &lt;&lt; 'EOF'\npermit(\n  principal,\n  action == Action::\"Read\",\n  resource\n)\nwhen {\n  resource.owner == principal ||\n  (resource has readers &amp;&amp; principal in resource.readers)\n};\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create the policy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws verifiedpermissions create-policy \\\n  --region \"$AWS_REGION\" \\\n  --policy-store-id \"$POLICY_STORE_ID\" \\\n  --definition \"static={statement=$(cat policy-read.cedar)}\"\n<\/code><\/pre>\n\n\n\n<p>Save the <code>policyId<\/code> output:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export POLICY_READ_ID=\"&lt;PASTE_POLICY_ID_HERE&gt;\"\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; A policy exists in the store allowing reads for owners\/readers.<\/p>\n\n\n\n<p>Verification:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws verifiedpermissions get-policy \\\n  --region \"$AWS_REGION\" \\\n  --policy-store-id \"$POLICY_STORE_ID\" \\\n  --policy-id \"$POLICY_READ_ID\"\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Policy 2: Permit update only for owner<\/h4>\n\n\n\n<p>Create <code>policy-update.cedar<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; policy-update.cedar &lt;&lt; 'EOF'\npermit(\n  principal,\n  action == Action::\"Update\",\n  resource\n)\nwhen {\n  resource.owner == principal\n};\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws verifiedpermissions create-policy \\\n  --region \"$AWS_REGION\" \\\n  --policy-store-id \"$POLICY_STORE_ID\" \\\n  --definition \"static={statement=$(cat policy-update.cedar)}\"\n<\/code><\/pre>\n\n\n\n<p>Save:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export POLICY_UPDATE_ID=\"&lt;PASTE_POLICY_ID_HERE&gt;\"\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; A second policy exists allowing updates only for the document owner.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Call IsAuthorized with sample entities<\/h3>\n\n\n\n<p>Now you\u2019ll simulate authorization decisions. In a real app, entities\/attributes come from your database or directory.<\/p>\n\n\n\n<p>Create a request file <code>authz-request-owner-read.json<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; authz-request-owner-read.json &lt;&lt; 'EOF'\n{\n  \"principal\": { \"entityType\": \"User\", \"entityId\": \"alice\" },\n  \"action\":    { \"actionType\": \"Action\", \"actionId\": \"Read\" },\n  \"resource\":  { \"entityType\": \"Document\", \"entityId\": \"doc1\" },\n  \"entities\": {\n    \"entityList\": [\n      {\n        \"identifier\": { \"entityType\": \"User\", \"entityId\": \"alice\" },\n        \"attributes\": { \"tenantId\": { \"string\": \"t1\" } }\n      },\n      {\n        \"identifier\": { \"entityType\": \"User\", \"entityId\": \"bob\" },\n        \"attributes\": { \"tenantId\": { \"string\": \"t1\" } }\n      },\n      {\n        \"identifier\": { \"entityType\": \"Document\", \"entityId\": \"doc1\" },\n        \"attributes\": {\n          \"tenantId\": { \"string\": \"t1\" },\n          \"owner\": { \"entityIdentifier\": { \"entityType\": \"User\", \"entityId\": \"alice\" } },\n          \"readers\": {\n            \"set\": [\n              { \"entityIdentifier\": { \"entityType\": \"User\", \"entityId\": \"bob\" } }\n            ]\n          }\n        }\n      }\n    ]\n  }\n}\nEOF\n<\/code><\/pre>\n\n\n\n<p>Run the authorization check:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws verifiedpermissions is-authorized \\\n  --region \"$AWS_REGION\" \\\n  --policy-store-id \"$POLICY_STORE_ID\" \\\n  --cli-input-json file:\/\/authz-request-owner-read.json\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Decision should be <strong>ALLOW<\/strong> (Alice is owner).<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Check reader access (Bob reads)<\/h4>\n\n\n\n<p>Create <code>authz-request-reader-read.json<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; authz-request-reader-read.json &lt;&lt; 'EOF'\n{\n  \"principal\": { \"entityType\": \"User\", \"entityId\": \"bob\" },\n  \"action\":    { \"actionType\": \"Action\", \"actionId\": \"Read\" },\n  \"resource\":  { \"entityType\": \"Document\", \"entityId\": \"doc1\" },\n  \"entities\": {\n    \"entityList\": [\n      {\n        \"identifier\": { \"entityType\": \"User\", \"entityId\": \"alice\" },\n        \"attributes\": { \"tenantId\": { \"string\": \"t1\" } }\n      },\n      {\n        \"identifier\": { \"entityType\": \"User\", \"entityId\": \"bob\" },\n        \"attributes\": { \"tenantId\": { \"string\": \"t1\" } }\n      },\n      {\n        \"identifier\": { \"entityType\": \"Document\", \"entityId\": \"doc1\" },\n        \"attributes\": {\n          \"tenantId\": { \"string\": \"t1\" },\n          \"owner\": { \"entityIdentifier\": { \"entityType\": \"User\", \"entityId\": \"alice\" } },\n          \"readers\": {\n            \"set\": [\n              { \"entityIdentifier\": { \"entityType\": \"User\", \"entityId\": \"bob\" } }\n            ]\n          }\n        }\n      }\n    ]\n  }\n}\nEOF\n<\/code><\/pre>\n\n\n\n<pre><code class=\"language-bash\">aws verifiedpermissions is-authorized \\\n  --region \"$AWS_REGION\" \\\n  --policy-store-id \"$POLICY_STORE_ID\" \\\n  --cli-input-json file:\/\/authz-request-reader-read.json\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Decision should be <strong>ALLOW<\/strong> (Bob is in readers set).<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Check reader update (Bob updates)<\/h4>\n\n\n\n<p>Create <code>authz-request-reader-update.json<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; authz-request-reader-update.json &lt;&lt; 'EOF'\n{\n  \"principal\": { \"entityType\": \"User\", \"entityId\": \"bob\" },\n  \"action\":    { \"actionType\": \"Action\", \"actionId\": \"Update\" },\n  \"resource\":  { \"entityType\": \"Document\", \"entityId\": \"doc1\" },\n  \"entities\": {\n    \"entityList\": [\n      {\n        \"identifier\": { \"entityType\": \"User\", \"entityId\": \"alice\" },\n        \"attributes\": { \"tenantId\": { \"string\": \"t1\" } }\n      },\n      {\n        \"identifier\": { \"entityType\": \"User\", \"entityId\": \"bob\" },\n        \"attributes\": { \"tenantId\": { \"string\": \"t1\" } }\n      },\n      {\n        \"identifier\": { \"entityType\": \"Document\", \"entityId\": \"doc1\" },\n        \"attributes\": {\n          \"tenantId\": { \"string\": \"t1\" },\n          \"owner\": { \"entityIdentifier\": { \"entityType\": \"User\", \"entityId\": \"alice\" } },\n          \"readers\": {\n            \"set\": [\n              { \"entityIdentifier\": { \"entityType\": \"User\", \"entityId\": \"bob\" } }\n            ]\n          }\n        }\n      }\n    ]\n  }\n}\nEOF\n<\/code><\/pre>\n\n\n\n<pre><code class=\"language-bash\">aws verifiedpermissions is-authorized \\\n  --region \"$AWS_REGION\" \\\n  --policy-store-id \"$POLICY_STORE_ID\" \\\n  --cli-input-json file:\/\/authz-request-reader-update.json\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Decision should be <strong>DENY<\/strong> (only owner can update).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Confirm the policies are present:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws verifiedpermissions list-policies \\\n  --region \"$AWS_REGION\" \\\n  --policy-store-id \"$POLICY_STORE_ID\"\n<\/code><\/pre>\n\n\n\n<p>Confirm your authorization results:\n&#8211; Owner read: ALLOW\n&#8211; Reader read: ALLOW\n&#8211; Reader update: DENY<\/p>\n\n\n\n<p>If your responses include decision details, review them to understand which policy matched. If decision details are not returned by default, check whether the API supports returning additional debug info (and how to enable it) in your current SDK\/CLI version.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">1) \u201cAccessDeniedException\u201d when calling Verified Permissions<\/h4>\n\n\n\n<p>Cause:\n&#8211; Your IAM identity (user\/role) lacks permissions.<\/p>\n\n\n\n<p>Fix:\n&#8211; Attach the necessary IAM permissions for Verified Permissions. Use the AWS Service Authorization Reference to identify the required actions:\nhttps:\/\/docs.aws.amazon.com\/service-authorization\/latest\/reference\/<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">2) \u201cValidationException\u201d when creating policy or schema<\/h4>\n\n\n\n<p>Cause:\n&#8211; Schema format mismatch or Cedar policy statement not valid.<\/p>\n\n\n\n<p>Fix:\n&#8211; Validate Cedar syntax using Cedar language documentation: https:\/\/docs.cedarpolicy.com\/\n&#8211; Confirm the latest schema JSON structure required by Verified Permissions in the official docs. Schema formats are strict.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">3) Decision is DENY when you expected ALLOW<\/h4>\n\n\n\n<p>Common causes:\n&#8211; Entity identifiers don\u2019t match exactly (entityType\/entityId mismatch).\n&#8211; Action identifier mismatch (<code>Action::\"Read\"<\/code> vs request action ID).\n&#8211; Attributes missing, or you didn\u2019t include the expected entities in the request.<\/p>\n\n\n\n<p>Fix:\n&#8211; Ensure the <code>principal<\/code>, <code>action<\/code>, <code>resource<\/code> IDs match what your Cedar policies reference.\n&#8211; Start with simplest policy and simplest entity set; add complexity gradually.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">4) CLI parameter parsing problems for <code>--definition<\/code><\/h4>\n\n\n\n<p>Cause:\n&#8211; Shell quoting issues when embedding Cedar statements.<\/p>\n\n\n\n<p>Fix:\n&#8211; Prefer a method recommended by the AWS CLI docs for Verified Permissions policy creation.\n&#8211; If needed, use a JSON file for the policy definition (if supported by the CLI) instead of shell substitution.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing costs and clutter, delete policies and the policy store.<\/p>\n\n\n\n<p>Delete policies:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws verifiedpermissions delete-policy \\\n  --region \"$AWS_REGION\" \\\n  --policy-store-id \"$POLICY_STORE_ID\" \\\n  --policy-id \"$POLICY_READ_ID\"\n\naws verifiedpermissions delete-policy \\\n  --region \"$AWS_REGION\" \\\n  --policy-store-id \"$POLICY_STORE_ID\" \\\n  --policy-id \"$POLICY_UPDATE_ID\"\n<\/code><\/pre>\n\n\n\n<p>Delete the policy store:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws verifiedpermissions delete-policy-store \\\n  --region \"$AWS_REGION\" \\\n  --policy-store-id \"$POLICY_STORE_ID\"\n<\/code><\/pre>\n\n\n\n<p>Verification:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws verifiedpermissions get-policy-store \\\n  --region \"$AWS_REGION\" \\\n  --policy-store-id \"$POLICY_STORE_ID\"\n<\/code><\/pre>\n\n\n\n<p>Expected outcome:\n&#8211; Not found \/ resource deleted error.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Centralize decisions, keep enforcement local<\/strong>: Verified Permissions decides; your app enforces.<\/li>\n<li><strong>Design for minimal calls<\/strong>: authorize once per API operation. Avoid authorizing repeatedly in loops.<\/li>\n<li><strong>Model entities intentionally<\/strong>:<\/li>\n<li>ABAC: use stable attributes (department, tenantId, clearance).<\/li>\n<li>ReBAC: use relationships (owner, memberOf, sharedWith).<\/li>\n<li><strong>Separate environments<\/strong>: distinct policy stores for dev\/stage\/prod.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM \/ security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Grant least privilege:<\/li>\n<li>Separate roles for <strong>policy administration<\/strong> (create\/update policies) and <strong>runtime authorization<\/strong> (call <code>IsAuthorized<\/code>).<\/li>\n<li>Protect policy changes:<\/li>\n<li>Require approvals for policy updates.<\/li>\n<li>Use infrastructure-as-code and CI\/CD with review.<\/li>\n<li>Treat context as trusted only if server-derived.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reduce authorization calls:<\/li>\n<li>Use batch evaluation (where supported).<\/li>\n<li>Cache carefully for read-heavy, low-risk checks (short TTL).<\/li>\n<li>Avoid logging high-cardinality entity graphs unless needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep entity payloads small: only include attributes needed for decisions.<\/li>\n<li>Prefer stable identifiers and minimal context.<\/li>\n<li>Measure:<\/li>\n<li>p50\/p95\/p99 latency for authorization calls<\/li>\n<li>error rates (throttling, 5xx)<\/li>\n<li>Implement retries with exponential backoff for transient errors, but avoid retry storms.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Fail closed vs fail open:<\/li>\n<li>For sensitive operations, <strong>fail closed<\/strong> (deny if authorization service is unavailable).<\/li>\n<li>For low-risk read-only operations, some teams choose controlled degradation\u2014but document and approve it.<\/li>\n<li>Implement circuit breakers and timeouts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Log structured authorization events (without leaking sensitive data).<\/li>\n<li>Track policy changes via CloudTrail and alert on unexpected changes.<\/li>\n<li>Maintain a playbook for:<\/li>\n<li>sudden deny spikes<\/li>\n<li>service throttling<\/li>\n<li>policy deployment rollback<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance \/ tagging \/ naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use consistent naming:<\/li>\n<li><code>policy-store-{app}-{env}<\/code><\/li>\n<li>Tag resources (where supported) with:<\/li>\n<li><code>Application<\/code>, <code>Environment<\/code>, <code>Owner<\/code>, <code>CostCenter<\/code>, <code>DataClassification<\/code><\/li>\n<li>Define policy authoring standards:<\/li>\n<li>naming conventions for actions<\/li>\n<li>standard tenant isolation patterns<\/li>\n<li>documented exceptions<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM controls access to Verified Permissions APIs<\/strong>:<\/li>\n<li>Who can create\/update policy stores and policies<\/li>\n<li>Which workloads can call <code>IsAuthorized<\/code><\/li>\n<li><strong>Cedar policies control app permissions<\/strong>:<\/li>\n<li>What end users can do in your app<\/li>\n<\/ul>\n\n\n\n<p>Keep a strict separation:\n&#8211; Devs\/services should only have runtime authorization permissions.\n&#8211; Only a small set of security\/platform administrators should manage policies.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS services typically encrypt data at rest and in transit. Confirm Verified Permissions encryption specifics in the official documentation for your region and compliance needs.<\/li>\n<li>Use TLS (HTTPS) endpoints (default with AWS SDK\/CLI).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Your workload calls a regional AWS endpoint.<\/li>\n<li>For private-only networking, confirm whether a VPC endpoint\/PrivateLink is available for Verified Permissions in your region (<strong>verify in official docs<\/strong>). If not, route via NAT\/egress controls and restrict outbound traffic.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not embed AWS access keys in code.<\/li>\n<li>Use IAM roles for Lambda\/ECS\/EKS.<\/li>\n<li>If you integrate with tokens (Cognito), validate tokens server-side and avoid trusting client-provided claims without verification.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use CloudTrail for management events:<\/li>\n<li>policy create\/update\/delete<\/li>\n<li>schema updates<\/li>\n<li>In your application logs:<\/li>\n<li>record the authorization decision (ALLOW\/DENY)<\/li>\n<li>correlate with request IDs and user IDs<\/li>\n<li>avoid logging sensitive attributes unnecessarily<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<p>For regulated workloads:\n&#8211; Implement change management around policies:\n  &#8211; approvals\n  &#8211; peer review\n  &#8211; evidence collection (PRs, pipeline logs)\n&#8211; Adopt least privilege and segregation of duties:\n  &#8211; policy authors vs deployers vs reviewers<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treating Verified Permissions as authentication (it is not).<\/li>\n<li>Passing client-provided context directly into authorization decisions.<\/li>\n<li>Overusing \u201cadmin overrides\u201d that bypass least privilege.<\/li>\n<li>Not isolating tenants at the policy layer (multi-tenant SaaS).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use separate policy stores per environment and (often) per region.<\/li>\n<li>Implement policy unit tests in CI (test expected allow\/deny for key scenarios).<\/li>\n<li>Use canary rollouts for policy changes:<\/li>\n<li>deploy to staging first<\/li>\n<li>run integration tests<\/li>\n<li>then promote to production<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>Confirm the latest limits and behaviors in official docs; this section highlights common real-world issues.<\/p>\n<\/blockquote>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Regional availability<\/strong>: not all AWS regions may support Amazon Verified Permissions.<\/li>\n<li><strong>Added latency<\/strong>: calling an external authorization service adds latency; design to minimize calls.<\/li>\n<li><strong>Payload limits<\/strong>: entity\/context payload sizes are limited; large relationship graphs can exceed limits.<\/li>\n<li><strong>Policy complexity<\/strong>: very complex policies can be hard to reason about; prefer composable patterns and documented conventions.<\/li>\n<li><strong>Schema drift<\/strong>: schema and app model can diverge; keep them versioned and deployed together.<\/li>\n<li><strong>Operational dependency<\/strong>: if authorization is required for every request, the service becomes part of your critical path\u2014plan for retries\/timeouts and failure mode decisions.<\/li>\n<li><strong>Batch authorization isn\u2019t a silver bullet<\/strong>: batch size limits and response handling can still be complex.<\/li>\n<li><strong>Pricing surprises<\/strong>: high-volume apps can generate large numbers of authorization calls. Instrument and estimate early.<\/li>\n<li><strong>Migration challenges<\/strong>: moving from in-code authorization to Cedar requires careful mapping and thorough testing.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Amazon Verified Permissions is for <strong>application authorization<\/strong>. Alternatives vary depending on whether you want managed services, cloud-native IAM, or self-managed policy engines.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Amazon Verified Permissions<\/strong><\/td>\n<td>Fine-grained application authorization on AWS<\/td>\n<td>Managed policy store; Cedar language; consistent decisions across services<\/td>\n<td>Adds network call\/latency; requires Cedar learning and new workflows<\/td>\n<td>You need centralized, auditable app authorization at scale<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS IAM (identity policies, resource policies)<\/strong><\/td>\n<td>Authorizing access to AWS resources<\/td>\n<td>Deep AWS integration; mature tooling; strong governance<\/td>\n<td>Not designed for app object-level authorization (documents, tickets)<\/td>\n<td>When controlling access to AWS APIs\/resources (S3, DynamoDB, KMS, etc.)<\/td>\n<\/tr>\n<tr>\n<td><strong>Amazon Cognito groups \/ custom claims<\/strong><\/td>\n<td>Simple role-based gating<\/td>\n<td>Easy for small apps; integrates with JWTs<\/td>\n<td>Can become role-explosion; poor fit for ReBAC and complex conditions<\/td>\n<td>When authorization is simple and unlikely to evolve<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Lambda authorizers \/ API Gateway policy logic<\/strong><\/td>\n<td>API-layer checks<\/td>\n<td>Central point at API edge<\/td>\n<td>Still custom code; hard to keep consistent across services<\/td>\n<td>When you want edge enforcement but still need custom logic<\/td>\n<\/tr>\n<tr>\n<td><strong>Open Policy Agent (OPA)<\/strong><\/td>\n<td>Self-managed policy engine<\/td>\n<td>Very flexible; large ecosystem; can run anywhere<\/td>\n<td>You operate it; policy distribution\/versioning is your responsibility<\/td>\n<td>When you need full control or run multi-cloud\/on-prem and accept operational burden<\/td>\n<\/tr>\n<tr>\n<td><strong>OpenFGA \/ Zanzibar-style auth<\/strong><\/td>\n<td>Relationship-based authorization<\/td>\n<td>Strong for ReBAC graphs; proven model<\/td>\n<td>Additional infrastructure; model complexity<\/td>\n<td>When your core need is large-scale relationship graphs and you want a dedicated ReBAC datastore<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure AD \/ Microsoft Entra + app roles<\/strong><\/td>\n<td>Microsoft-centric orgs<\/td>\n<td>Strong enterprise identity<\/td>\n<td>Not AWS-native; app object-level auth still custom<\/td>\n<td>Choose if your enterprise standard is Entra and your needs are simple<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud IAM<\/strong><\/td>\n<td>GCP resource authorization<\/td>\n<td>Strong for GCP resources<\/td>\n<td>Not for AWS app object-level authorization<\/td>\n<td>Choose for GCP resource access, not AWS apps<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: regulated document management platform<\/h3>\n\n\n\n<p><strong>Problem<\/strong><br\/>\nA large enterprise runs a document management system with:\n&#8211; Department-based access\n&#8211; Project-based sharing\n&#8211; Owner\/editor\/viewer permissions\n&#8211; Compliance requirements for change review and audit<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; Amazon Cognito for authentication\n&#8211; API Gateway + Lambda for APIs\n&#8211; DynamoDB (or RDS) for document metadata and sharing relationships\n&#8211; Amazon Verified Permissions as the centralized authorization decision point\n&#8211; CloudTrail + CloudWatch logs for audit evidence<\/p>\n\n\n\n<p><strong>Why this service was chosen<\/strong>\n&#8211; Central, reviewable Cedar policies\n&#8211; Consistent authorization across multiple microservices\n&#8211; Easier audit: policies are centralized instead of embedded in many codebases<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Reduced authorization bugs and inconsistencies\n&#8211; Faster onboarding of new services\n&#8211; Stronger audit posture with centralized policy control and clear change tracking<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Startup \/ small-team example: multi-tenant SaaS project tracker<\/h3>\n\n\n\n<p><strong>Problem<\/strong><br\/>\nA small team is building a B2B SaaS project tracker with:\n&#8211; Tenant isolation\n&#8211; Project membership\n&#8211; Role-based permissions plus \u201cproject owner\u201d overrides<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; Cognito for sign-in\n&#8211; A single backend service (Lambda or ECS)\n&#8211; A policy store per environment (dev\/prod)\n&#8211; Verified Permissions for \u201cCan this user view\/edit this project\/task?\u201d decisions<\/p>\n\n\n\n<p><strong>Why this service was chosen<\/strong>\n&#8211; Avoid writing a custom authorization engine early\n&#8211; Keep authorization logic out of the code as complexity grows\n&#8211; Safer iteration on permissions without rewriting the app<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Cleaner codebase and fewer security regressions\n&#8211; Easier evolution from simple RBAC to ABAC\/ReBAC patterns as features expand<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1) Is Amazon Verified Permissions an authentication service?<\/h3>\n\n\n\n<p>No. It does not log users in or issue credentials. It evaluates authorization (\u201cis allowed?\u201d). Use Amazon Cognito or another IdP for authentication.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2) How is this different from AWS IAM?<\/h3>\n\n\n\n<p>IAM controls access to AWS resources and APIs. Amazon Verified Permissions controls access to <strong>your application resources<\/strong> (documents, projects, tickets) using Cedar policies.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3) Do I have to use a schema?<\/h3>\n\n\n\n<p>You don\u2019t always have to, but schemas are strongly recommended for validation, safer policy authoring, and clearer contracts. Verify current schema requirements in the docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4) What policy language does it use?<\/h3>\n\n\n\n<p>Cedar. See: https:\/\/docs.cedarpolicy.com\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5) What is a policy store?<\/h3>\n\n\n\n<p>A container for your Cedar policies (and schema) that you query when you call authorization APIs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6) Is it regional or global?<\/h3>\n\n\n\n<p>Policy stores are regional resources and you call a regional endpoint. Verify current regional availability in AWS docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">7) What is the default behavior if no policy matches?<\/h3>\n\n\n\n<p>Authorization systems typically default to deny. Confirm the exact behavior in Verified Permissions docs, but you should design with a \u201cdefault deny\u201d mindset.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">8) Can it do RBAC?<\/h3>\n\n\n\n<p>Yes\u2014RBAC can be modeled, but Verified Permissions is particularly useful when RBAC becomes insufficient and you need ABAC\/ReBAC.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">9) Can it do ABAC (attributes)?<\/h3>\n\n\n\n<p>Yes. You can include attributes on principals\/resources and reference them in Cedar conditions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">10) Can it do ReBAC (relationships)?<\/h3>\n\n\n\n<p>Yes. You can model relationships (owner\/member\/sharedWith) as entity attributes or relationships and use them in policies.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">11) How do I integrate it with API Gateway?<\/h3>\n\n\n\n<p>Common pattern: API Gateway \u2192 Lambda \u2192 (call Verified Permissions) \u2192 enforce decision. Some teams also use Lambda authorizers, but you still need to call Verified Permissions from a compute layer you control.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">12) How do I estimate cost?<\/h3>\n\n\n\n<p>Count how many authorization calls you\u2019ll make per request and multiply by traffic. Use the official pricing page and AWS Pricing Calculator:\n&#8211; https:\/\/aws.amazon.com\/verified-permissions\/pricing\/\n&#8211; https:\/\/calculator.aws\/#\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">13) Can I log every authorization decision for audit?<\/h3>\n\n\n\n<p>You can log decisions in your application. CloudTrail records management operations. For any built-in decision logging features, verify current documentation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">14) What happens if the service is unavailable?<\/h3>\n\n\n\n<p>Your app must decide fail-closed or fail-open depending on risk. Most sensitive operations should fail-closed with retries and circuit breakers.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">15) How do I manage policy changes safely?<\/h3>\n\n\n\n<p>Treat them like code:\n&#8211; version control policy text\n&#8211; code review\n&#8211; automated tests for allow\/deny cases\n&#8211; staged rollouts\n&#8211; monitoring for deny spikes after change<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">16) Can I use it for S3 object authorization?<\/h3>\n\n\n\n<p>Not directly. S3 authorization is handled by IAM and S3 policies. Verified Permissions is for application authorization decisions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">17) Should every microservice call Verified Permissions directly?<\/h3>\n\n\n\n<p>Not always. Options:\n&#8211; direct calls from each service for consistency\n&#8211; a shared authorization library\/service wrapper\n&#8211; caching layer (carefully)<br\/>\nChoose based on latency, reliability, and organizational standards.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Amazon Verified Permissions<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official Documentation<\/td>\n<td>Amazon Verified Permissions User Guide<\/td>\n<td>Canonical concepts, APIs, schemas, and best practices: https:\/\/docs.aws.amazon.com\/verifiedpermissions\/<\/td>\n<\/tr>\n<tr>\n<td>Official Pricing<\/td>\n<td>Amazon Verified Permissions Pricing<\/td>\n<td>Accurate pricing dimensions and region specifics: https:\/\/aws.amazon.com\/verified-permissions\/pricing\/<\/td>\n<\/tr>\n<tr>\n<td>AWS Service Authorization Reference<\/td>\n<td>IAM actions for Verified Permissions<\/td>\n<td>Required for least-privilege IAM policies: https:\/\/docs.aws.amazon.com\/service-authorization\/latest\/reference\/<\/td>\n<\/tr>\n<tr>\n<td>Cedar Language Docs<\/td>\n<td>Cedar Policy Language Documentation<\/td>\n<td>Learn syntax, semantics, and examples: https:\/\/docs.cedarpolicy.com\/<\/td>\n<\/tr>\n<tr>\n<td>AWS Global Infrastructure<\/td>\n<td>Regional product availability<\/td>\n<td>Confirm which regions support the service: https:\/\/aws.amazon.com\/about-aws\/global-infrastructure\/regional-product-services\/<\/td>\n<\/tr>\n<tr>\n<td>AWS Pricing Calculator<\/td>\n<td>AWS Pricing Calculator<\/td>\n<td>Estimate request-based costs across services: https:\/\/calculator.aws\/#\/<\/td>\n<\/tr>\n<tr>\n<td>AWS Architecture Center<\/td>\n<td>AWS Architecture Center<\/td>\n<td>Patterns for building secure, scalable AWS apps: https:\/\/aws.amazon.com\/architecture\/<\/td>\n<\/tr>\n<tr>\n<td>Official AWS Videos<\/td>\n<td>AWS YouTube Channel<\/td>\n<td>Look for talks and demos on authorization\/Cedar\/Verified Permissions: https:\/\/www.youtube.com\/@amazonwebservices<\/td>\n<\/tr>\n<tr>\n<td>SDK References<\/td>\n<td>AWS SDK docs (language-specific)<\/td>\n<td>Implement runtime authorization calls from your app (choose your language from AWS SDK docs): https:\/\/docs.aws.amazon.com\/sdkref\/latest\/guide\/<\/td>\n<\/tr>\n<tr>\n<td>Community (reputable)<\/td>\n<td>Cedar examples and discussions<\/td>\n<td>Helps with patterns and testing strategies (validate against official docs): https:\/\/github.com\/cedar-policy (verify official ownership and relevance before adopting)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, cloud engineers, architects<\/td>\n<td>AWS training, DevOps practices, security basics; verify course coverage for Amazon Verified Permissions<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>SCM\/DevOps practitioners, platform teams<\/td>\n<td>DevOps, CI\/CD, cloud tooling; verify if service-specific modules exist<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations teams, SREs<\/td>\n<td>Cloud ops, monitoring, reliability; verify if AWS security services are included<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, ops engineers, reliability leads<\/td>\n<td>SRE practices, observability, incident response; apply to auth service operations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams exploring AIOps<\/td>\n<td>Automation, analytics for ops; can complement monitoring of authorization systems<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>Cloud\/DevOps training and guidance (verify current offerings)<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps-focused training platform (verify service coverage)<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps guidance\/services (treat as a resource platform; verify offerings)<\/td>\n<td>Teams needing hands-on help<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training resource (verify current offerings)<\/td>\n<td>Ops\/DevOps teams<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify current portfolio)<\/td>\n<td>Architecture reviews, implementation support, operationalization<\/td>\n<td>Designing app authorization patterns; CI\/CD for policy deployment; observability for auth decisions<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>Training and consulting (verify current consulting services)<\/td>\n<td>Cloud enablement, DevOps transformation, skills uplift<\/td>\n<td>Implementing centralized authorization; governance and review workflow for Cedar policies<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify current offerings)<\/td>\n<td>CI\/CD, cloud operations, reliability improvements<\/td>\n<td>Building secure deployment pipelines; setting up logging\/monitoring for authorization calls<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before this service<\/h3>\n\n\n\n<p>To use Amazon Verified Permissions effectively, learn:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM fundamentals (roles, policies, least privilege)<\/li>\n<li>Basic application security concepts:<\/li>\n<li>authentication vs authorization<\/li>\n<li>OWASP API Security basics<\/li>\n<li>JWT basics (claims, validation) if integrating with token-based auth<\/li>\n<li>Cloud-native architecture basics (API Gateway\/Lambda\/ECS\/EKS)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after this service<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Advanced Cedar patterns and policy testing strategies<\/li>\n<li>Multi-tenant authorization design (tenant isolation, delegation)<\/li>\n<li>Observability and SRE practices for critical-path dependencies<\/li>\n<li>Security reviews and threat modeling for authorization systems<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud\/solutions architect (designing app authorization)<\/li>\n<li>Security engineer \/ application security engineer<\/li>\n<li>Backend engineer \/ platform engineer<\/li>\n<li>DevOps engineer \/ SRE (operationalizing auth decision points)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>AWS certifications don\u2019t typically certify a single service, but relevant tracks include:\n&#8211; AWS Certified Solutions Architect (Associate\/Professional)\n&#8211; AWS Certified Security \u2013 Specialty<br\/>\nVerify current certification offerings: https:\/\/aws.amazon.com\/certification\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Docs app authorization<\/strong>: extend the lab to support:\n   &#8211; tenant isolation\n   &#8211; document sharing invitations\n   &#8211; time-bound access<\/li>\n<li><strong>Microservice gateway<\/strong>: build two services (Projects and Tasks) using one policy store.<\/li>\n<li><strong>Policy CI<\/strong>: create a test harness that runs allow\/deny tests on every policy change.<\/li>\n<li><strong>Decision logging pipeline<\/strong>: send authorization decisions to CloudWatch Logs and build alarms for deny spikes.<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Authorization<\/strong>: Deciding whether an authenticated principal is allowed to perform an action on a resource.<\/li>\n<li><strong>Authentication<\/strong>: Proving identity (who the user\/service is).<\/li>\n<li><strong>Principal<\/strong>: The entity making the request (often a user).<\/li>\n<li><strong>Resource<\/strong>: The entity being accessed (document, project, ticket).<\/li>\n<li><strong>Action<\/strong>: The operation requested (read, update, delete).<\/li>\n<li><strong>Policy<\/strong>: A rule that permits or forbids actions under certain conditions.<\/li>\n<li><strong>Cedar<\/strong>: A policy language used by Amazon Verified Permissions to express authorization policies.<\/li>\n<li><strong>ABAC (Attribute-Based Access Control)<\/strong>: Authorization based on attributes (department, clearance, tenantId).<\/li>\n<li><strong>RBAC (Role-Based Access Control)<\/strong>: Authorization based on roles (admin, editor, viewer).<\/li>\n<li><strong>ReBAC (Relationship-Based Access Control)<\/strong>: Authorization based on relationships between entities (owner-of, member-of).<\/li>\n<li><strong>PDP (Policy Decision Point)<\/strong>: Component that evaluates policies and returns allow\/deny (Verified Permissions).<\/li>\n<li><strong>PEP (Policy Enforcement Point)<\/strong>: Component that enforces the decision (your API\/service).<\/li>\n<li><strong>Policy store<\/strong>: Verified Permissions resource that contains policies and schema.<\/li>\n<li><strong>Schema<\/strong>: Definitions of entity types and attributes used to validate policies and requests.<\/li>\n<li><strong>CloudTrail<\/strong>: AWS service that logs account activity and API usage for auditing.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Amazon Verified Permissions is an AWS Security, identity, and compliance service for <strong>centralized application authorization<\/strong> using <strong>Cedar policies<\/strong>. It matters because authorization logic tends to sprawl and become inconsistent as systems grow; Verified Permissions centralizes decision-making while your services remain the enforcement point.<\/p>\n\n\n\n<p>Cost is primarily driven by <strong>authorization request volume<\/strong> and your application\u2019s calling patterns\u2014optimize by minimizing repeated checks and using batch approaches where supported. Security depends on strong IAM separation (admins vs runtime callers), careful handling of context data, and disciplined policy change management with testing and approvals.<\/p>\n\n\n\n<p>Use Amazon Verified Permissions when you need fine-grained, consistent, auditable authorization across services and teams. Next, deepen your skills by learning Cedar thoroughly, building a policy testing pipeline, and integrating Verified Permissions into a small API (API Gateway + Lambda + Cognito) with production-grade logging and rollout practices.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Security, identity, and compliance<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,39],"tags":[],"class_list":["post-333","post","type-post","status-publish","format-standard","hentry","category-aws","category-security-identity-and-compliance"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/333","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=333"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/333\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=333"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=333"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=333"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}