Quicksight Reports - StartDashboardSnapshotJob fails with S3_DESTINATION_ACCESS_DENIED despite all permissions in place

Hello,
We’re using StartDashboardSnapshotJob with AnonymousUsers to generate PDF reports and store them in S3. A Lambda acts as the QuickSight client. The job starts successfully but consistently fails at the S3 write step.

Environment:

  • QuickSight Enterprise

  • S3 bucket (same account, same region)

Error from DescribeDashboardSnapshotJobResult:

{
  "ErrorType": "S3_DESTINATION_ACCESS_DENIED",
  "ErrorMessage": "You do not have access to the specified S3 destination"
}

What we’ve tried:

  • Bucket policy granting quicksight.amazonaws.com full write access — with and without aws:SourceAccount condition

  • Bucket policy explicitly granting arn:aws:iam::<account>:role/service-role/aws-quicksight-service-role-v0

  • aws-quicksight-service-role-v0 has AWSQuickSightS3Policy an inline s3:* policy — no permission boundary, no explicit denies

  • Bucket is checked in Manage account → AWS resources → S3 allowlist

  • SSE-S3 encryption (no KMS), no VPC connections, no SCPs or RCPs at org level

Everything looks correct but the error persists. We noticed aws-quicksight-service-role-v0 was last used 3 months ago, suggesting snapshot jobs don’t use it — yet the service principal in the bucket policy also doesn’t work.

What principal does StartDashboardSnapshotJob actually use when writing to S3, and is there any additional configuration required specifically for snapshot jobs with AnonymousUsers? Or do you have any other idea?

BTW - we are using AWS Identity center users - not native QuickSight users.

Thanks

Hi @InbalK,

I believe StartDashboardSnapshotJob does not utilize “aws-quicksight-service-role-v0” for S3 writing. This process is instead handled by an internal QuickSight service.

In your bucket policy, I would ensure that “s3:GetBucketLocation” is added as one of your Actions (which should verify the bucket region). Also, since you are using AnonymousUsers, I would also recommend to specify a specific namespace ARN instead with the right permissions to ensure that it will at least work for one user.

If none of these workarounds help or guide you in the right direction, please let us know and we can explore other workarounds!

Hi @InbalK,

Just checking back in since this thread hasn’t received a response in a while. Was my most recent reply helpful to you and/or were you able to find a solution yourself in the meantime? Please help the community by marking this answer as “Solution” or following up in general within the next 3 business days!

Thanks!

Hi @InbalK,

Since I haven’t received any further updates from you, I’ll treat this inquiry as complete for now. If you have any additional questions, feel free to create a new post in the community and link this discussion for context.

Thank you!