QuickSight Author user role permission denied
| Service | Amazon QuickSight |
|---|---|
| Cloud | Amazon Web Services (AWS) |
| Guide type | Procedure |
| Skill level | Intermediate to advanced |
| Time | 15 - 60 minutes depending on account size |
Engineers running Amazon QuickSight hit QuickSight Author user role permission denied often enough that there is a stable fix pattern. This page captures it in the order AWS support would run it during a real incident.
What quicksight author user role permission denied actually involves on Amazon QuickSight
This task on Amazon QuickSight is one of the more searched operational topics on AWS in the last 12 months. The procedure below is the path that works in a current AWS account with default IAM and standard VPC config.
The rest of this page is the structured fix path. Start with diagnose, then remediation, then the automation options so you do not have to do this by hand the next time it surfaces. Verify and safety sections at the end are the discipline that keeps the fix from regressing in production.
Spot the symptom
Check the AWS Health Dashboard at health.aws.amazon.com for ongoing service events in your region. About one in ten user-reported outages turn out to be region-scoped AWS service degradation already being tracked. AWS Health also exposes an API and EventBridge events, so you can wire a Lambda hook that pages on-call only when the failure correlates with an active AWS Health event in the same region and service.
Check CloudWatch Logs for the calling service. Lambda, ECS, EKS, Step Functions, API Gateway, and most managed services write detailed traces to CloudWatch Logs under predictable log group names. Use CloudWatch Logs Insights with fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 50 to surface the most recent failures.
Reproduce the failure with the AWS CLI in --debug mode. The full SigV4 request payload it emits, plus the exact endpoint URL it resolved to, is what AWS Support uses to verify policy, region, or parameter issues without you having to share IAM credentials. Save the debug output to a file with aws ... --debug 2> debug.log and you can search it for the failed aws.request entry.
Solution-focused remediation path
If networking is suspect, use VPC Reachability Analyzer. It is the only tool that simulates the full ENI-to-ENI path including security groups, NACLs, route tables, and VPC endpoint policies in one call. Manual trace is slower and misses transitive issues. The analyzer charges $0.10 per analysis - cheaper than a 30-minute call with your network team.
When the failure happens in production but not in dev, do not just compare the IAM policy. Compare the SCP / RCP at the OU level, the permission boundary on the role, and the resource-based policy on the target. One of those is almost always different between accounts. AWS Config conformance packs make this comparison routine.
For IAM and STS issues, the timing matters. STS sessions can take up to 60 seconds to propagate after creation. The first call right after assume-role can fail with a permission error even when the policy is correct. Add a small retry with backoff before treating the first failure as definitive.
Automate this fix so you do not do it twice
Automate the fix with the AWS CLI
The CLI one-liner pattern for Amazon QuickSight operations is roughly: aws quicksight describe-... --query ... to read state, aws quicksight modify-... --no-dry-run to apply the change, and aws quicksight describe-... --query ... again to verify. Wrap it in a shell script that sets a region variable at the top and exits on first error with set -euo pipefail so a partial run does not leave the account in a half-fixed state.
# Template - replace placeholders with your account specifics
export AWS_REGION=us-east-1
export AWS_PROFILE=prod
aws quicksight describe-... --query 'Resources[?Status==`FAILED`].[Id,Reason]' --output table
aws quicksight modify-... --resource-id RESOURCE_ID --no-dry-run
aws quicksight describe-... --resource-id RESOURCE_ID --query 'Status'Automate the fix with Python and boto3
For anything you do more than twice, write a small Python script. The boto3 pattern below uses paginators (so it does not blow up on accounts with thousands of resources), explicit region binding, and a dry-run flag that defaults to True. Keep the script under 100 lines; if it grows beyond that, you are building a tool and should put it behind a Lambda with proper logging.
import boto3, sys
DRY_RUN = '--apply' not in sys.argv
client = boto3.client('quicksight', region_name='us-east-1')
paginator = client.get_paginator('describe_...')
for page in paginator.paginate(): for item in page.get('Items', []): if item.get('Status') == 'FAILED': if DRY_RUN: print(f'[dry-run] would fix {item["Id"]}') else: client.modify_...(ResourceId=item['Id']) print(f'fixed {item["Id"]}')Add a Systems Manager Automation runbook
For multi-step fixes that include a manual approval, use SSM Automation. Document the fix as a runbook with aws:approve steps where a human signs off and aws:executeAwsApi steps where the runbook calls the AWS API. Approvers are notified by SNS; the runbook execution shows up in CloudTrail with the approver's identity attached. This makes audit trails easy and stops production fixes from being one-person operations.
Pitfalls
A subtle pitfall on Amazon QuickSight is that the AWS Console and the SDK can disagree about resource state during a configuration change. Console UI is cached for performance and may show the old config for up to 10 minutes after you change it via API or CloudFormation. Always confirm with describe-* CLI calls during a change window, not with screenshots from the Console.
The other pitfall: assuming that an automated remediation is correct because it succeeded. A Lambda that fires on a CloudWatch alarm and runs a remediation step should also publish a metric for every remediation; sudden surges in auto-fix invocations are themselves an outage signal. Otherwise you can hide a slow-burn regression behind a quiet remediation loop for weeks.
Full fix path
- Reproduce the original symptom path. If it still surfaces in any account or region or IAM role, you have not fixed it.
- Watch for 24 to 48 hours. AWS metrics and policy systems can mask issues with cached health for 6 to 12 hours, especially CloudFront and Route 53.
- Run a smoke test under realistic load. Happy-path tests miss race conditions and IAM session-cache issues.
- Capture the new state in a runbook so the next person on call does not have to rediscover this. Push it to Confluence or your team wiki, not into Slack.
- If the fix involved a permission change, run IAM Access Analyzer one more time to confirm you did not open a separate hole while closing this one.
Safety, rollback, blast radius
- Test in a non-production account if your environment has Control Tower or AWS Organizations. The cost of one sandbox account is cheaper than one rollback meeting.
- Export the existing config before changing it. Most Amazon QuickSight resources support describe + export to JSON via CLI - capture that to source control before you start.
- Know your rollback path. Some Amazon QuickSight operations are one-way (region migration, account-level feature opt-in, KMS key deletion past pending window). Confirm reversibility on the AWS doc before you commit.
- Be aware of cross-service impact. IAM role changes ripple to every service trusting that role. KMS key changes break every workload depending on that key. VPC endpoint changes affect every VPC consumer of that endpoint.
- Maintenance window discipline: if the change touches DNS, certificate rotation, or anything that emits TLS handshakes, line up a window with stakeholder notification, not a heroic mid-day swap.
FAQ
aws quicksight describe-... first, then commit it before you change anything. A few operations are one-way (KMS key deletion past the pending window, region migration, account closure). Check the AWS doc for the specific API before you commit.aws CLI or SDK calls - those almost always still work.References
- docs.aws.amazon.com - official documentation for Amazon QuickSight
- AWS re:Post (formerly forums) - community Q&A with AWS-staff-verified answers
- AWS Health Dashboard at health.aws.amazon.com
- AWS Service Quotas console and AWS Well-Architected Tool
Related fixes
Related guides worth a look while you sort this one out:
- QuickSight SPICE refresh failed PERMISSION_DENIED IAM role
- How to fix ECS task IAM role permission denied for S3 or DynamoDB
- How to fix Permission denied (publickey) when SSHing to EC2
- EventBridge cross-account event bus permission denied
- Polly output S3 bucket key prefix permission denied
- QuickSight SPICE refresh failed FAILURE_TO_ASSUME_ROLE