Automate user-level custom permissions for Amazon Quick Amazon Quick has introduced four architectural patterns to automate user-level custom permissions, enabling fine-grained access control such as restricting financial analysts from exporting raw data and limiting external partners' sharing controls. The patterns include applying permissions at user creation via the RegisterUser API, setting defaults with UpdateAccountCustomPermission and UpdateRoleCustomPermission, using Amazon EventBridge and AWS Lambda for event-driven logic based on group membership, and a Python script for retroactive batch updates. These approaches help maintain the principle of least privilege as Quick environments scale with new AI-powered capabilities. Artificial Intelligence /blogs/machine-learning/ Automate user-level custom permissions for Amazon Quick As Amazon Quick /quick/ environments scale and new AI-powered capabilities expand what users can do, automating user-level custom permissions becomes critical to maintaining the principle of least privilege. To address this, with custom permissions https://docs.aws.amazon.com/quick/latest/userguide/custom-permissions.html in Quick, you can enforce fine-grained access control by toggling specific features on or off for individual users. For example, with custom permissions, you can control access so that financial analysts author reports without exporting raw data, and external partners view dashboards without accessing sharing controls. While Quick provides various options to apply custom permissions at the account, role, and user level, there are scenarios where your organization’s specific permissions need to be applied dynamically. This post walks through four architectural patterns to automate custom permissions assignment at key stages of the user lifecycle. The approaches range from a single API parameter to an event-driven automation, covering new users, future users, group-based logic, and retroactive bulk updates. What we will cover We will explore four scenarios to handle key stages of the user lifecycle: 1. Pre-registered users : If you build custom portals or scripts, we show how to apply custom permissions proactively at the exact moment of user creation using the RegisterUser API. 2. Default account or role permissions: To set default custom permissions at the account or role level, we cover how to use the UpdateAccountCustomPermission and UpdateRoleCustomPermission APIs to enforce a default profile for all existing and future users, no additional automation required. 3. Event-driven custom logic : When you need conditional logic beyond native defaults such as applying different profiles based on group membership we show how to use Amazon EventBridge and AWS Lambda to automatically detect new group memberships and apply permissions dynamically. This supports both native Quick groups and AWS IAM Identity Center IDC groups. 4. Retroactive batch updates : For existing users who were provisioned before automation was in place, we provide a robust Python script to retroactively apply custom permissions to all users in specified Quick groups. Scenario 1: Pre-registered users API and CLI If you have a custom onboarding portal that provisions users using the RegisterUser https://docs.aws.amazon.com/quicksight/latest/APIReference/API RegisterUser.html API, you don’t need complex automation. You can apply custom permissions during the creation of the Quick user by including the --custom-permissions-name parameter in your call. When to use this approach : Your organization controls the user creation process end-to-end through a custom portal or script. This is the most direct path, no event-driven infrastructure required. This is especially common for software as a service SaaS companies embedding Quick across customer accounts. For instance, automatically restricting premium features like paginated reports and GenBI based on a customer’s pricing tier at the moment each user is provisioned. The following example applies a custom permissions profile named Restricted-Author-Profile to Authors in the account, but the same API can be used to apply permissions profiles to any role including Author Pros, Admins, Admin Pros, Readers, and Reader Pros . Scenario 2: Default account or role permissions API and CLI With two native APIs, you can set default custom permission profiles without per-user automation. Note that Quick custom permissions follow a three-level hierarchy account, role, and user where user-level settings override role-level, which override account-level, allowing administrators to implement flexible, layered security policies /blogs/business-intelligence/establishing-enterprise-governance-in-amazon-quick-using-custom-permissions/ . When to use this approach: These APIs cover both current and future use cases with minimal operational overhead. Start here before building custom automation. Move to Scenario 3 only if you need conditional logic beyond what account or role-level defaults support. For example, a 50,000-user enterprise may need all newly launched GenBI features and connectors blocked by default until their security team completes a 60–90-day review. An account-level default enforces that restriction instantly, without requiring any per-user automation and with no provisioning gap. Option A: Account-level default The UpdateAccountCustomPermission https://docs.aws.amazon.com/quicksight/latest/APIReference/API UpdateAccountCustomPermission.html API sets a fallback custom permission profile that Quick applies to any user who doesn’t have an explicit profile assigned, including new users created with Just-In-Time provisioning. Option B: Role-level default With the UpdateRoleCustomPermission https://docs.aws.amazon.com/quicksight/latest/APIReference/API UpdateRoleCustomPermission.html API, you can set a default custom permission profile per Quick role READER, AUTHOR, ADMIN, and PRO roles . Scenario 3: Event-driven custom logic Amazon EventBridge and Lambda This scenario addresses more granular requirements: applying different custom permissions profiles to users based on which Quick or IAM Identity Center group they belong to. For example, a 125,000-employee technology services company needs authors in each business unit to receive distinct permission profiles at the moment of group assignment. This prevents cross-unit asset sharing while granting power-user access only to approved individuals, even though all authors share the same Quick role. Because we don’t have a native API for assigning custom permissions to a Group, we will need an architecture that detects when a user is added to a group that should have specific permissions. Note: We suggest combining this approach with Scenario 2 for a fully layered permissions strategy. Scenarios 2 and 3 are complementary, not alternatives. When a user is provisioned through Just-In-Time federation, there’s an unavoidable window between account creation and the moment an administrator adds them to the appropriate group. Scenario 3 only fires on the group membership event. To keep users from ever being in an unrestricted state, apply Scenario 2 first as a baseline: set an account-level or role-level default that enforces your most restrictive acceptable profile. Then use Scenario 3 to refine permissions once the user is assigned to a group. The user-level override from Scenario 3 will take precedence over the Scenario 2 default, so there is no conflict, only complementary layers of control. Consider a global bank with more than 200,000 users, provisioned through single sign-on SSO , that must block data export the instant an employee joins. Scenario 2 closes that gap immediately with a restrictive account-level default, and Scenario 3 refines permissions once the user is assigned to their compliance group. This prevents employees from downloading sensitive client data during the window between provisioning and group assignment. Quick and IAM Identity Center emit distinct AWS CloudTrail events for group membership changes. Quick emits CreateGroupMembership when a user is added and DeleteGroupMembership when removed. IAM Identity Center emits AddMemberToGroup when a user is added and RemoveMemberFromGroup when removed. The following architecture detects these events to trigger permission updates automatically. We will build this using Amazon EventBridge to detect the event and AWS Lambda to apply the fix . 1. A user is added to a Quick or Identity Center group. 2. Amazon CloudTrail: Captures the CreateGroupMembership or AddMemberToGroup events. 3. Amazon EventBridge: Filters these logs to identify when a user is successfully added to the group. 4. AWS Lambda: Extracts the user details and applies the correct permission profile using the UpdateUserCustomPermission API. Prerequisites Before implementing this solution, confirm you have the following: 1. An AWS account https://signin.aws.amazon.com/signin?redirect uri=https%3A%2F%2Fportal.aws.amazon.com%2Fbilling%2Fsignup%2Fresume&client id=signup with administrative access. 2. AWS Identity and Access Management IAM /iam/ permissions to create and manage AWS resources using AWS CloudFormation. 3. Access to the following AWS services: 1. AWS CloudFormation /cloudformation : deploys and manages the infrastructure stack as code. 2. Amazon Quick /quick/ : the target service where custom permissions are applied. 3. AWS CloudTrail /cloudtrail/ : must be enabled in the target AWS Region. Captures Quick and IDC API events that Amazon EventBridge consumes. 4. Amazon EventBridge /eventbridge/ : filters CloudTrail events to detect group membership changes. 5. AWS Lambda /lambda/ : executes the automation logic that calls the UpdateUserCustomPermission API. 6. AWS IAM Identity Center /iam/ : required only if using IDC group-based triggers. 4. Python 3.9+ and AWS Command Line Interface AWS CLI v2 are required for running the batch update script in Scenario 4. Deploy with CloudFormation You can deploy the full pipeline IAM role, Lambda function, and Amazon EventBridge rule using the provided CloudFormation template. The CloudFormation stack must be deployed in the same AWS Region as your Amazon Quick subscription, since Amazon EventBridge rules only capture events within their own Region. The template accepts the following parameters: | Parameter | Description | | UseIdentityCenter | Set to true if your Quick account uses IAM Identity Center | | TargetGroupName | The name of the group to apply custom permissions to. For Quick groups, this is the Quick group name. For IDC groups, this is the IDC group DisplayName. Important: Each deployment targets either a Quick group or an IDC group, never both. To monitor both group types, deploy separate stacks. | | PermissionProfileName | Name of the Quick custom permissions profile to apply to members of this group. This profile must already exist in your Quick account before deployment. | | QuickNamespace | Quick namespace for user management. | | LambdaFunctionPrefixName | Prefix used for the Lambda function name. | If you prefer to deploy manually, follow these steps: Step 1: Create the IAM role for Lambda Your Lambda function needs permission to interact with Quick. 1. Go to the IAM Console → Policies → Create policy . 2. Switch to the JSON tab and paste this policy: 1. Note : the permissions to IdentityStore are only needed if your Quick account is integrated with IAM Identity Center. 3. Name the policy Quick-Lambda-Policy and choose Create policy . 4. Navigate to Roles → Create role . 5. Select AWS Service and choose Lambda . 6. Choose Next . 7. Search for and select the Quick-Lambda-Policy . 8. Choose Next . 9. Name the Role Quick-Auto-Permissions-Role and select Create role . Step 2: Deploy the Lambda function 1. Go to the Lambda Console → Create function . 2. Function name: Auto-Assign-QS-Permissions . 3. Runtime: Python 3.14 or latest available . 4. Execution role: Use another role → Select Quick-Auto-Permissions-Role . 5. Choose Create function . 6. Under Configuration → General configuration , increase the timeout to 30 seconds. 1. This should be sufficient for single-event processing. If you observe timeouts in Amazon CloudWatch Logs, increase this value accordingly. 7. Set the following environment variables under Configuration → Environment Variables: . | Variable Name | Description | | PERMISSION PROFILE | Exact name of the custom permissions profile created in Quick to apply | | TARGET GROUP NAME | Name of the group to monitor Quick group name or IDC group DisplayName | | NAMESPACE | Quick namespace typically “default” | 1. Navigate back to the Code Source editor and paste the following code: 2. Choose Deploy . Step 3: Create the Amazon EventBridge rule Now we must configure this function so that it runs only when a user is successfully added to a group. 1. Go to the Amazon EventBridge Console . 2. Select Rules → Create rule . 3. Opt out of the Visual rule builder . 4. Under Name enter Quick-Group-Membership-Creation-Rule and choose Next . 5. Select Other under Event source . 6. Paste the following into the JSON editor for Event pattern: .When the Quick account is integrated with IDC, the source of this event will be the IDC identity store whereas the source will be Quick otherwise. Therefore, the Amazon EventBridge rule we will create will depend on the account authentication mechanism: Option A: IAM Identity Center Option B: Other Authentication using Quick Groups 7. Select AWS Service as the Target type . 8. Select Lambda function as the target and choose Auto-Assign-QS-Permissions the function you built in Step 2 . 9. Choose Next and Create rule . Step 4: Add the Amazon EventBridge trigger 1. Return to the Auto-Assign-QS-Permissions Lambda function. 2. Navigate to Configuration → Triggers → Add trigger . 3. Select Amazon EventBridge as the source. 4. Choose Existing rules and select the Quick-Group-Membership-Creation-Rule created in Step 3. 5. Choose Add . Step 5: Verify the setup To test this, add a user to a Group in Quick or IDC: 1. Test: Manually add a new or existing user to the target Group. 2. Monitor: Go to the CloudWatch Logs for your Lambda function. 3. Confirm: You should see a log entry like: Permission profile ‘123’ applied to user ‘XYZ’. 4. Result: When that user logs in, they will be restricted by the profile. Design considerations Group removal: This solution for Scenario 3 already handles removal events. When a user is removed from the target group, the Lambda calls DeleteUserCustomPermission , reverting them to the account or role-level default from Scenario 2. No additional configuration is needed. Multi-group membership: Quick supports only one custom permissions profile per user at a time. If your organization assigns users to multiple groups with different profiles, you can extend the Lambda logic to list all groups the user belongs to, look up the profile mapped to each group, and apply the highest-priority profile for example, the most restrictive profile . This multi-group conflict resolution isn’t included in the provided solution and must be implemented by your team based on your organization’s specific priority rules. Scenario 4: Batch update for existing group members You likely have existing groups for example, “Finance-Readers” or “Marketing-Authors” containing users who need specific restrictions applied retroactively. Because these users were created in the past, the Amazon EventBridge automation Scenario 3 won’t catch them. To fix this, we use a Python script to iterate through a specific Quick Group and apply the custom permission profile to every member. The challenge: Pagination Quick groups can contain thousands of users. The API ListGroupMemberships only returns 100 members at a time . If you write a script without pagination logic, it will stop after the first 100 users, leaving the rest unsecured. The following script handles this automatically using NextToken . Copy the following code. You only need to edit the Configuration Section at the top. Note: The default delay of 0.1 seconds between API calls ~10 requests/second is suitable for most deployments. For large-scale groups over 10,000 members , increase API DELAY SECONDS to avoid API throttling. Monitor for ThrottlingException errors in the output and adjust as needed for your environment. Detailed execution steps 1. Prepare your environment .You can run this locally or in AWS CloudShell directly in your browser, which comes pre-authenticated and has Boto3 installed. - Sign in to the AWS Management Console. - Choose the CloudShell icon terminal icon in the top navigation bar. 2. Create the script file .In the CloudShell terminal, enter the following command to open a text editor: nano update permissions.py - Paste the preceding Python code into the editor. - Edit the AWS ACCOUNT ID and TARGET GROUP NAME variables at the top of the file to match your environment. - Press Ctrl+X, then Y, then Enter to save and exit. 3. Run the script .Execute the script with Python: python3 update permissions.py 4. Verify results . - The script will print “OK” next to every user it successfully updates. - If any users fail, the script writes a failed users {GROUP NAME}.csv file with the username and failure reason for each. Review this file to identify users that need manual follow-up. - If you see “Profile not found,” double-check that you created the Custom Permission Profile in the Amazon Quick console exactly as spelled in the script. - Run aws quicksight describe-user --aws-account-id