← Platform Foundations

▶ Play from here · 195 min

Starts this lesson and continues through 26 more to the end of the course.

The asset hierarchy

Four objects, in one direction

Everything in Quick Sight is built from four objects, in a fixed order:

  DATA SOURCE  ──▶  DATASET  ──▶  ANALYSIS  ──▶  DASHBOARD
  connection        shaped data     the workbench    the published thing
  + credentials     + SPICE/direct   (authors)       (readers)

Most confusion about this product is a confusion about which of those four a thing belongs to. "Can I change this?" has four different answers depending on which object you're standing on.

Data source — the connection, not the data

"Use a data source to access an external data store. Amazon S3 data sources save the manifest file information. In contrast, Salesforce and database data sources save connection information like credentials. In such cases, you can easily create multiple datasets from the data store without having to re-enter information. Connection information isn't saved for text or Microsoft Excel files." — Working with data sources in Amazon Quick Sight (verified 2026-08-09)

So a data source is reusable connection state. Its whole value is that you configure credentials once and build many datasets from it.

⚠️ Uploaded files are the exception, and it's a sharp one. No connection information is saved for text or Excel files. That means an uploaded-file dataset has nothing to reconnect to — which is why Q2's error taxonomy contains S3_UPLOADED_FILE_DELETED. A spreadsheet somebody dragged in is a dead end: it cannot be refreshed from source, because there is no source.

Rule: nothing that matters should originate from a drag-and-dropped file. If it matters, it comes from a data source.

Dataset — where every decision that costs money is made

The dataset is the load-bearing object in the whole product. Per Connecting to data in Amazon Quick Sight:

"After you connect to or import data, you create a dataset to shape and prepare data to share and reuse."

What is decided at the dataset level:

⚠️ Repeat from Q2, lesson 1, because it belongs here structurally: "Any changes you make in an analysis have no effect on the logical size of the data in SPICE. Only changes that are saved in the dataset apply to SPICE capacity."

Hiding a field in a visual saves nothing. Removing it from the dataset saves real money.

⚠️ And from Q2, lesson 3: saving a dataset triggers an ingestion, surfacing as RequestType: EDIT. Editing a dataset is not a free action on a large table.

One dataset, many analyses. That's the design intent — shape and prepare "to share and reuse". The common anti-pattern is a dataset per dashboard, which multiplies SPICE footprint and ingestion calls for no benefit.

Analysis — the authoring surface

The analysis is where authors work: visuals, sheets, parameters, controls, filters, custom actions, themes. Readers do not see analyses.

From the Standard-edition capability list, all of this lives at the analysis level:

• "Add charts, graphs, more datasets, and multiple pages (called sheets) to your data analysis."
• "Make them interactive by using parameters, controls, filters, and custom actions."
• "Create visual appeal with customized formatting and themes."

An analysis can use more than one dataset — that's stated directly ("more datasets"). Useful, and also the usual reason a dashboard is slow: four datasets means four refresh schedules and four sets of quota consumption behind one screen.

Dashboard — the published artefact

"Share the dashboard so other people can use the dashboard, even if they don't use the analysis that it's based on."

That sentence is the whole permission model in miniature. A dashboard is a published snapshot of an analysis's definition, shared independently. Granting dashboard access does not grant analysis access.

Consequences worth holding:

• Readers consume dashboards. Authors build analyses. That maps directly onto the Reader/Author subscriptions in lesson 2 — the object model and the pricing model are the same shape.
• Publishing is an explicit act. Changing an analysis does not change the live dashboard until you publish.
• A dashboard depends on the datasets underneath it, and those dependencies are traceable — AWS documents "Tracking dashboards and analyses that use a dataset". Check that before you delete or restructure a dataset.

Console names vs API names

Same split as lesson 1: read one thing, type another.

⚠️ Note the CLI hyphenation: data-set, not dataset, and data-source, not datasource — while the ARN uses dataset and datasource with no hyphen. That inconsistency is real and it will cost you a typo or two.

# The four "what have I got?" commands. Run these on any account you inherit.
ACC=111122223333; REG=us-east-1
aws quicksight list-data-sources --aws-account-id $ACC --region $REG \
  --query 'DataSources[].{Id:DataSourceId,Name:Name,Type:Type}' --output table
aws quicksight list-data-sets    --aws-account-id $ACC --region $REG \
  --query 'DataSetSummaries[].{Id:DataSetId,Name:Name,Mode:ImportMode}' --output table
aws quicksight list-analyses     --aws-account-id $ACC --region $REG \
  --query 'AnalysisSummaryList[].{Id:AnalysisId,Name:Name,Status:Status}' --output table
aws quicksight list-dashboards   --aws-account-id $ACC --region $REG \
  --query 'DashboardSummaryList[].{Id:DashboardId,Name:Name,Version:PublishedVersionNumber}' --output table

ImportMode on the dataset listing is the single most useful field on an inherited account: it tells you SPICE or DIRECT_QUERY for every dataset, which is your cost and freshness picture in one column.

Two objects that sit alongside the four

• Folders — organisational and permission containers. AWS describes them as a way to "organize your teams' work and help them collaborate using dashboards, analytics, and datasets". Covered properly in Q5.
• Templates — "Script, transfer, and make templates from analyses and dashboards by using API operations." This is the promotion mechanism between environments and Regions. Covered in Q7.

Check yourself

1. Somebody uploaded a spreadsheet and built a dashboard on it. What can't you do?
2. An author hides six fields in every visual to tidy up. What has that saved?
3. You grant a reader access to a dashboard. Can they open the analysis?
4. What single CLI field tells you the cost profile of an inherited account fastest?
5. Why is "one dataset per dashboard" an anti-pattern?

Answers

1. Refresh it from source. Connection information isn't saved for text or Excel files, so there's nothing to reconnect to. If the underlying object goes away you get S3_UPLOADED_FILE_DELETED.
2. Nothing. Only changes saved in the dataset affect SPICE size; changes in an analysis don't.
3. No. A dashboard is shared independently — "even if they don't use the analysis that it's based on". Dashboard access is not analysis access.
4. ImportMode from list-data-sets — SPICE vs DIRECT_QUERY for every dataset in one column.
5. Datasets are designed to be shaped once and reused across analyses. One per dashboard multiplies SPICE footprint and CreateIngestion consumption (32/24h, per Region, not adjustable) for no benefit.

Teaching this section

• Draw the four boxes and one arrow before saying anything else. Then ask, for each of six real decisions, which box it belongs in. Most disagreements about this product dissolve once people agree on that.
• Demo: run the four list-* commands against a real account and read the ImportMode column out. It reliably surprises whoever owns the bill.
• Good discussion: "How many of our datasets are used by exactly one dashboard?" That number is usually embarrassing, and it's the cheapest cost saving available.
• Watch for: the data-set / dataset hyphenation trip-up in the CLI, and the belief that hiding fields in an analysis saves SPICE.
• Timing: 20 min presented, 15 hands-on with the list commands.