Problem Statement: My team manages 100+ dashboards in AmazonBI QuickSight, and we currently lack a lineage approach to maintain them effectively. We have no way to see end-to-end which tables are used within datasets or to trace the full dependency chain of a dashboard.
Current State:
-
Only dataset links are available via CloudTrail logs
-
No native visibility into what tables/sources are inside each dataset
-
No automated way to map upstream and downstream dependencies
Desired Outcome: I want to build a lineage application that traces the full path of a dashboard from start to end:
Dashboard → Analysis → Dataset → DataSource → Andes Tables → Cradle/ETLM Profiles
Questions:
-
Beyond CloudTrail, is there another way to programmatically identify the tables and sources used within QuickSight datasets?
-
Is it possible to build this full lineage path using QuickSight APIs or other available tools?
-
Has anyone successfully implemented a similar lineage/dependency mapping solution for QuickSight dashboards at scale?
Use Case: Dashboard maintenance, impact analysis for upstream table changes, and deprecation planning across 100+ dashboards.
Hi @burdula and welcome to the Quick Community!
Based on my research, there are a few AWS documented resources that I think address what you’re looking to build.
I would highly recommend checking this resource out first, Guidance for Understanding Your Data Lineage on Amazon QuickSight, it’s a deployable CloudFormation stack that wires up Lambda + S3 + Athena + QuickSight to map your full dependency chain (Dashboard → Analysis → Dataset → DataSource). It auto-updates via EventBridge when resources change.
Related but felt worth mentioning that if you need column-level granularity, this blog and Terraform-based repo go deeper: Enhance data governance through column-level lineage in Amazon QuickSight (GitHub: aws-samples/column-level-lineage-for-amazon-quicksight).
There’s also an older but still relevant walkthrough that covers the API logic more hands-on and includes permissions tracking: Centrally tracking dashboard lineage with QuickSight administrative dashboards.
Last;y, something else I thought was worth mentioning (Andes Tables → Cradle/ETLM), the QuickSight APIs get you as far as the physical table names via the PhysicalTableMap in DescribeDataSet. From there you’d need to join against your internal catalog to trace back to upstream ETL. And one thing I wanted to make you aware is CloudTrail is helpful for audit tracking, but the dependency graph itself comes from the QuickSight describe APIs rather than CloudTrail events.
Hope that helps!
Thank you Jacob for the detailed reply — this is truly helpful!
Unfortunately, my challenge is specific to the AmazonBI QuickSight account (shared account), which is very restrictive. We don’t have access to the AWS or QuickSight APIs or Athena, so the CloudFormation-based solutions and API-driven approaches you mentioned aren’t feasible in our environment.
The only resource available to us is a CloudTrail dataset provided by the AmazonBI team, which we currently use to track dashboard adoption. However, it’s very limited for lineage purposes — it only exposes dataset names and IDs, with no visibility into what tables or data sources are inside those datasets.
That said, I’ll definitely keep your recommendations in mind for other QS enterprise accounts where we have full admin access — especially the column-level lineage repo and the EventBridge-based approach.
Thank you again for taking the time!