QuickSight BI and the End-to-End Lakehouse Capstone

Sixteen lessons built something that produces numbers: bronze on S3, silver and gold as Iceberg tables, a Glue catalog, Step Functions holding the schedule together, Lake Formation deciding who may read which row, Macie finding the personal data, Glue Data Quality refusing the bad batches, and a cost ladder nobody is allowed to skip. None of that is the point of a lakehouse. The point is that a regional manager in Frankfurt opens a link on a Monday morning and sees her regions, her stores, her revenue, in under two seconds, and sees nobody else's.

That is this lesson. The BI layer is where every upstream decision either pays for itself or embarrasses you: a missing Lake Formation grant shows up as an empty dashboard, a SPICE snapshot shows up as a stale one, a text-versus-numeric column choice shows up as row-level security silently not working, and an un-pruned direct query shows up on the Athena bill three weeks later. You will configure QuickSight end to end, then step back and re-draw the whole course as one reference architecture with seventeen layers, plus the 30/60/90-day plan that gets a team there.

By the end of this lesson you will be able to:

• say what changed and what did not when QuickSight became Quick Suite and then Amazon Quick, and price a real deployment line by line;
• choose between SPICE and direct query using the Athena bytes-scanned meter rather than a feeling, and defend the choice with arithmetic;
• size a SPICE dataset from a column list using the logical-size formula, and schedule refreshes that neither collide nor silently go stale;
• wire a lakehouse source correctly: Athena through Lake Formation, an S3 manifest for extracts, Redshift for dense warehouse workloads;
• build the content chain dataset → analysis → dashboard → theme → folder, and pick a visual family on purpose;
• separate the three row-level-security mechanisms and state, for each, who it applies to, what data types it restricts, and what it costs you;
• assemble all seventeen layers into one reference architecture and sequence them across a 30/60/90-day plan;
• read Trustly's published QuickSight outcomes the way a practitioner reads a case: as a customer result with a date, never as a service guarantee.

---

1. Naming the thing you are configuring

Before a single setting: on 2025-10-09 AWS announced that "Amazon QuickSight is evolving into Amazon Quick Suite", with the BI half renamed Quick Sight and "Beyond the familiar BI capabilities (now called Quick Sight), Quick Suite introduces several AI-powered features" (AWS BI Blog, 2025-10-09). The user guide today describes the service as Amazon Quick, which "evolved from Amazon QuickSight. QuickSight continues as Amazon Quick Sight, a feature within Quick" (Quick User Guide, What is Amazon Quick?, accessed 2026-10-11).

The operational half of that announcement is the part you actually need:

"Your entire QuickSight environment, including dashboards, datasets, and analyses, remains unchanged… Your existing API integrations keep working as before, and no data migration is required.": AWS BI Blog, 2025-10-09

and

"All existing QuickSight APIs, SDKs, and integrations continue to work without changes.": Quick User Guide, accessed 2026-10-11

Two consequences for everything below:

1. ARNs and IAM actions still read quicksight. A user ARN is still arn:aws:quicksight:{region}:{account}:user/{namespace}/{username}, the default service role is still aws-quicksight-service-role-v0, and every API you touch in this lesson (CreateIngestion, GenerateEmbedUrlForRegisteredUser, CreateAccountCustomization) keeps its old name (AWS Machine Learning Blog, 2026-06-08; AWS Builder Center, 2026-03-27).
2. Pricing tables moved to the new branding. The rates below were read from the QuickSight pricing page on 2026-10-11, where the Quick Suite panel carries them.

• 📚 Did you know? The shortening from "Quick Suite" to "Amazon Quick" is not dated anywhere in AWS's own documentation. The 2025-10-09 posts say Quick Suite; the user guide simply says Amazon Quick, with no announcement row for the second rename. The defensible statement is "announced as Quick Suite in October 2025; by October 2026 the user guide calls the service Amazon Quick": assigning a precise date to the shortening would be inventing a source.

---

2. Personas, editions and the October 2026 price stack

2.1 The three personas, and why Admins are billed as Authors

Source for every row: QuickSight pricing page and FAQs, accessed 2026-10-11.

The trap in that table is the Admin row: an Admin who "just manages users" is still an Author on the invoice. The second trap is that Readers hold no SPICE at all: SPICE is account property, not user property.

2.2 Two editions, and only one of them does row-level security

Sources: pricing page, Data source quotas, Refreshing SPICE data, Using row-level security, Embedding overview: all accessed 2026-10-11.

2.3 Worked example E1: pricing a real deployment, line by line

A team deploys 3 Authors, 1 Admin, 60 Readers, one 52 GB SPICE dataset, no Pro users, no Q topics, no Dashboard Q&A (us-east-1 list, as of Oct 2026).

Now two changes that look small on a slide:

The infrastructure fee doubled the bill for one feature flag. It applies "if your account has any of the following: At least one Pro user / Q&A enabled via topics / Dashboard Q&A enabled" (pricing page and FAQs, accessed 2026-10-11), and, the part that catches people, deleting the Pro users does not stop it while a Q Topic still exists in any Region of the account (AWS re:Post Knowledge Center, 2026-08-27).

---

3. SPICE: what it is, what it costs, how you fill it

3.1 The engine in one paragraph

SPICE is the Super-fast, Parallel, In-memory Calculation Engine: a refreshable, materialised snapshot of your dataset built from "a combination of columnar storage, in-memory technologies… and machine code generation" (AWS BI Blog, Best practices for Amazon QuickSight SPICE and direct query mode, 2024-07-17). In Enterprise edition the snapshot is encrypted at rest, AWS-managed by default, or a customer managed key in AWS KMS, and encrypted in transit with TLS (same source; Importing data into SPICE, accessed 2026-10-11).

Four properties decide every design choice you will make:

• Capacity is pooled per account per AWS Region, not per user: "SPICE capacity is allocated separately per AWS Region… shared by all the people using QuickSight in a single AWS Region" (Managing SPICE memory capacity, accessed 2026-10-11).
• Auto capacity purchasing is on by default for console-created accounts, and "Auto capacity purchasing doesn't support auto-decrement"; it can grow your pool, never shrink it. Turn it off while over-allocated and the next ingestion or refresh fails.
• You are charged for the source query at ingest, not at view time: "If you use a data source that charges per query, you're charged for querying the data when you first create the dataset and later when you refresh the dataset" (Importing data into SPICE).
• Dashboards keep serving the previous snapshot while a refresh runs, and after a failed one, with no on-canvas staleness banner by default.

3.2 Logical size: the arithmetic that decides your capacity bill

What consumes capacity is not the Parquet file on S3 and not the row count; it is the logical size, computed after type coercion and calculated columns:

Source: Importing data into SPICE, accessed 2026-10-11. "Only changes that are saved in the dataset apply to SPICE capacity."

3.3 Worked example E2: sizing the capstone dataset before you ingest it

The capstone gold table gold.sales holds 40,000,000 rows, about 3 GB of Parquet on S3. The QuickSight dataset uses this custom SQL (note what was dropped):

Per-row logical size:

Two moves made this fit: dropping unused columns in the SQL (a customer_note text column averaging 200 characters would have added 24 + 200 bytes per row: 8.96 GB on its own, which by itself would have exceeded the pool) and truncating the timestamp to a date, the same move that makes incremental refresh and row-level security possible at all.

• 📚 Did you know? The four data-preparation steps Append, Aggregate, Pivot and Unpivot cannot run at query time; they are SPICE-only, meaning QuickSight materialises them into SPICE rather than executing them on every visual load (SPICE-only features, accessed 2026-10-11). That makes them the documented "pre-aggregate to shrink your dataset" lever: an aggregate step applied at authoring time is paid once per refresh instead of on every view.

3.4 Refresh: schedules, quotas and the failure you will not see

Two operational rules follow directly. Stagger the schedules so datasets do not all fire in the same minute (AWS re:Post, 2026-06-26), and treat a failed refresh as an incident, because the dashboard will happily keep rendering yesterday's numbers as if nothing happened.

3.5 SPICE authoring best practices

1. Select columns at authoring time. Every text column you drag into the dataset is billed at 24 + UTF-8 length bytes per row, forever. Deselect what no visual uses.
2. Aggregate before you import. Use the SPICE-only Aggregate step, or aggregate in the gold layer, which is better still, when a dashboard needs measures by day rather than by transaction.
3. Cast the keys you will restrict on. Row-level security works only on text fields, so cast numeric or date region keys to string in the dataset SQL (section 7).
4. Schedule after the ETL, never near it. A daily full refresh at 04:00 that fires before the silver-to-gold job completes imports the wrong snapshot and reports it confidently. Event-driven CreateIngestion from Step Functions after the job is the deterministic version; the schedule is only the floor.
5. One dataset, many dashboards. Consumption across any number of dashboards and users "doesn't incur charges": the meter is capacity GB-months, not views (pricing page, accessed 2026-10-11).

---

4. SPICE versus direct query: the Athena bill is the tie-breaker

4.1 The trade, stated both ways

Sources: Data source quotas (2026-10-11); AWS BI Blog best practices (2024-07-17).

4.2 The AWS-recommended hybrid

AWS's own guidance is not "pick one": use a SPICE landing sheet for aggregated KPIs refreshed daily or incrementally, plus a direct-query detail sheet, and warn the reader about the freshness inconsistency between them (BI Blog, 2024-07-17). The pattern exists because the two failure modes are opposite: SPICE fails by being stale, direct query fails by being slow and expensive.

4.3 Worked example E3: the same dashboard, two meters

Scenario. 200 readers, 4 dashboard views each per day, each view scanning 200 MB of partition-pruned Parquet in direct-query mode, versus the same data imported into a 6 GB SPICE dataset. Athena is $5.00 per TB scanned (Amazon Athena pricing, accessed 2026-10-11).

The break-even is arithmetic, not opinion: SPICE capacity cost equals the Athena cost when

Below roughly 76 views a day, direct query is cheaper and fresher; above it, SPICE wins and keeps winning, because the SPICE line is flat in view count. The un-pruned column is the one that should worry you: the same SQL shape without partition pruning is 15x the bill; which is why lesson 09's reducers are a prerequisite for this lesson rather than an optional extra.

4.4 Worked example E4: the hybrid bill

Same audience, 4,000 views per day: 3,600 land on the SPICE KPI sheet, 400 hit the direct-query detail sheet at 200 MB each.

Add the disclaimer text box on the direct-query sheet, "detail rows are live; KPI tiles refresh daily at 04:00 UTC", and you have the AWS-recommended shape with its cost quantified.

• 📚 Did you know? Athena bills bytes scanned, rounded up to the nearest megabyte, with a 10 MB minimum per query for federated sources, so a dashboard rendering 40 small direct-query visuals can bill 40 minimums instead of one merged scan. Merging filters and issuing fewer, wider queries through dataset parameters is a cost lever as much as a performance one (Amazon Athena pricing, accessed 2026-10-11).

The lines cross at about 2,280 views per month: roughly 76 a day. Left of the crossing, direct query is cheaper and fresher; right of it, SPICE costs the same whether 10 people or 10,000 look. The SPICE line also hides a fixed $0.45/month ingest charge (E3), which moves the crossing only marginally.

---

5. Lakehouse sources: Athena, the S3 manifest, and Redshift

QuickSight supports a long list of sources, Athena, Aurora, the Glue Data Catalog, OpenSearch, Redshift, Redshift Spectrum, S3, S3 Tables, RDS, plus BigQuery, Databricks, Snowflake, Trino and Q Business, with one hard placement rule: "Amazon Redshift clusters, Amazon Athena databases, and Amazon RDS instances must be in AWS" (Supported data sources, accessed 2026-10-11). For this course, three matter.

The decision rule for this course: anything governed lives behind Athena (or Redshift), never behind a manifest. A manifest is a file drop: no catalog entry, no time travel, no Lake Formation grant, no data filter.

A manifest like the one above imports fine and is still the wrong answer for gold.sales: the moment row-level governance, schema evolution or time travel matters, the Athena path is the only one that inherits what lessons 04, 07 and 12 built.

Two wiring details that break silently:

• The QuickSight service role, by default aws-quicksight-service-role-v0, needs its own Lake Formation grants, in addition to the grants given to QuickSight user and group ARNs (Using AWS Lake Formation with Amazon QuickSight, accessed 2026-10-11; AWS Builder Center, 2026-03-27).
• With S3 Tables (managed Iceberg) the catalog is s3tablescatalog, not the default Glue catalog: you need glue:GetCatalog on that catalog ARN, and you must use custom SQL, because the table browser only shows the default catalog (AWS Builder Center, 2026-03-27).

And the ordering rule from AWS's own guide: get the query working in Athena first, then open QuickSight: one step that separates a Lake Formation problem from a QuickSight problem.

---

6. The content model: datasets, analyses, dashboards, themes and folders

Visual families available on an analysis: bars and columns (stacked), heat map, line and area, scatter, pie and donut, treemap, funnel, gauge/KPI, word cloud, box plot, histogram, scatter map, layer map, image component, Highcharts, tables and pivot tables, and autonarrative text widgets (Quick User Guide document history and forecast/insight documentation, accessed 2026-10-11).

Themes. Four starter theme ARNs ship with the service, arn:aws:quicksight:aws:theme/CLASSIC, .../MIDNIGHT, .../SEASIDE, .../RAINIER, and the account or namespace default is set through CreateAccountCustomization / UpdateAccountCustomization with a DefaultTheme, which requires the theme to be shared first (Setting a default theme, accessed 2026-10-11). Embedded dashboards add runtime theming from Embedding SDK 2.5.0 and higher (setTheme, setThemeOverride, up to five preloaded themes).

Folders (Enterprise). Personal folders, shared folders, and shared restricted folders: the restricted kind is created only through the CreateFolder API and forces assets created from its contents to stay inside the folder tree. Read the boundary carefully: it covers analyses, dashboards, datasets, data sources and topics, but not newer surfaces such as chat agents, which can still retrieve details from a dataset inside a restricted folder (Organizing assets into folders, accessed 2026-10-11).

---

7. Row-level security: three mechanisms that are not interchangeable

This is the section that decides whether your capstone dashboard is a governance win or a data leak. There are three row-level mechanisms, they solve different problems, and none of them converts into another automatically.

7.1 Mechanism one: a user or group rules dataset (Enterprise)

A permissions table attached to your dataset: one column for identity (UserName and GroupName, or UserARN and GroupARN) plus one column per restricted field. You attach it with "Grant access to dataset".

Sources: Using row-level security and Using RLS with user-based rules, accessed 2026-10-11.

A broken rules-dataset ingestion therefore leaves the dataset restricted with no selected rules, which means readers see nothing until you attach new rules. Monitor ingestion status and turn on failure email alerts.

7.2 Mechanism two: tag-based rules (anonymous embedding only)

Tag rules map a tag key to a column and inject values at runtime through SessionTags in GenerateEmbedUrlForAnonymousUser, configured via RowLevelPermissionTagConfiguration.TagRules (TagKey, ColumnName, TagMultiValueDelimiter, MatchAllValue). AWS's scope statement is unambiguous: tag-based rules exist when "you are using embedded dashboards and want to secure data for users not provisioned (unregistered users)", and they are supported only for anonymous embedding: not for GenerateEmbedURLForRegisteredUser, not for the legacy GetDashboardEmbedUrl, and not for console identity (Using RLS with tag-based rules, accessed 2026-10-11).

7.3 Mechanism three: Lake Formation at the source, through Athena

Register the S3 location in Lake Formation, revoke IAMAllowedPrincipals, and grant SELECT and DESCRIBE (plus data-filter permissions) to QuickSight user and group ARNs in Enterprise, and to the service role as well. Those filters are applied by Athena at query time, which is the whole problem and the whole opportunity:

• a direct-query dataset honours Lake Formation data filters per user;
• a SPICE dataset does not, because "when using SPICE, data is imported (replicated) and therefore the entitlements at the source can't be used" (AWS Big Data Blog, Automate replication of row-level security from AWS Lake Formation to Amazon QuickSight, 2025-05-07).

AWS documents exactly two bridges across that gap:

1. Trusted identity propagation (TIP). IAM Identity Center only, direct query only: "QuickSight SPICE can't be used with trusted identity propagation". The reader's identity propagates to Athena, to Redshift, and to Lake Formation when Redshift Spectrum is involved, so schema-, table-, row- and column-level permissions are enforced at the source and this "eliminates the need to create additional row-level and column-level security rules in QuickSight" (AWS BI Blog, 2024-05-16; document-history entry "Trusted identity propagation support with Athena data sources", 2025-06-30).
2. Automated replication. A Lambda reads ListDataCellFilters and ListPermissions, transforms the PartiQL predicates into QuickSight rules-dataset rows, and refreshes a QuickSight RLS dataset. It works with SPICE and without Identity Center, but it must be re-run on every Lake Formation change, and the lag window is a risk you own.

• 📚 Did you know? The phrase "tags become RLS" describes two unrelated features. Lake Formation tags drive table and column reach and cannot carry row data filters at all, while QuickSight tag rules drive row-level security only for anonymous embedding. There is no documented AWS feature that maps one onto the other: for registered regional managers you need a user/group rules dataset, full stop (QuickSight and Lake Formation documentation, accessed 2026-10-11).

7.4 Worked example E5; which mechanism for which audience

---

8. Q, ML visuals and embedding: awareness-level map

8.1 Natural language and generative features

The lineage is three generations of one idea: QuickSight Q, then Amazon Q in QuickSight (GA 2024-04-30), then folded into Amazon Quick (2025-10-09). What matters operationally in October 2026:

• Q&A is included in Reader and Author seats, but enabling it costs money. Either create Q Topics (curated semantic models with custom instructions, created by Author Pro) or turn on one-click Dashboard Q&A (available since 2025-01-31, no topic required), and any of those flips on the $250/month per-account infrastructure fee.
• Q Topics are billed and still creatable. No AWS statement deprecating them was found, even though Dashboard Q&A is promoted as the topic-free path.
• Bulk Amazon Q questions capacity exists for embedded and scale scenarios: 500 questions/month for $250, 60,000/year for $18,000, 600,000/year for $120,000 (pricing page, accessed 2026-10-11).
• Pro seats add natural-language dashboard building, executive summaries, generative data stories and scenarios.
• The embedded Q search bar is labelled Classic; AWS's stated replacement is the embedded Generative Q&A experience.

8.2 ML-powered visuals

Sources: Forecasting and what-if scenarios, Insights and anomaly detection, pricing page: all accessed 2026-10-11.

8.3 Embedding, at awareness level

Enterprise only, with two authentication paths: registered users (GenerateEmbedUrlForRegisteredUser, plus one-click copy) and anonymous users (GenerateEmbedUrlForAnonymousUser, session tags for RLS, no user provisioning). Domain allow-lists must use HTTPS and hold up to 100 domains, static plus runtime additions. The amazon-quicksight-embedding-sdk on npm supplies callbacks, control wiring, runtime theming and shared embedded views.

The security note AWS added on 2026-01-27 deserves warning treatment: explicit guidance against AllowedEmbeddingDomains bypass vulnerabilities, plus multi-tenant RLS guidance; because a permissive allow-list combined with tag-based RLS is exactly the combination a multi-tenant portal gets wrong.

Pricing for an embedded audience is either provisioned $3 Readers or reader session capacity: a session is a 30-minute period, 500 sessions cost $250 per month with extra sessions at $0.50, and annual plans run from 50,000/year at $20,000 down to $0.16 per session on the 1.6M/year plan. Annual capacity is also what removes the "Powered by Quick" branding, and capacity pricing is required for programmatic refresh of dashboards.

• 📚 Did you know? Reader pricing is written for manual session interactions only: AWS "reserve[s] the right [to] charge for the reader at the higher monthly author rate" if reader sessions are used for programmatic or automated queries (QuickSight FAQs, accessed 2026-10-11). A wall screen that polls a dashboard on a timer is the documented bill-shock path, and it is precisely the usage that requires capacity pricing rather than seats.

---

9. Capstone worked example: gold sales to SPICE to regional RLS to a manager dashboard

Everything from lessons 01 to 16 now converges on one build. Setup: Iceberg table gold.sales with columns order_id, order_ts, region, store_id, product, qty, revenue, 40,000,000 rows, about 3 GB of Parquet on S3, Lake Formation-registered, Athena workgroup qs-bi.

Step 1: Lake Formation grants. SELECT and DESCRIBE on gold.sales to the QuickSight_Authors group ARN and to aws-quicksight-service-role-v0. Revoke IAMAllowedPrincipals from the registered location.

Step 2: Dataset over Athena, in SPICE mode. Custom SQL with unused columns dropped, order_ts truncated to order_day, region cast to text (RLS needs text). Logical size 5.68 GB (E2), inside the 20 GB included pool.

Step 3, Refresh. Daily full refresh at 04:00 UTC after the silver-to-gold job, plus an event-driven CreateIngestion call from Step Functions when that job completes, the schedule is the floor, the event is the truth. Weekly incremental look-back of 7 days on order_day if the table is append-heavy. Stay under the 32 full on-demand refreshes per 24 hours cap.

Step 4: RLS rules dataset. Create rls_region_rules with columns GroupARN, region; rows map arn:…:group/default/regional-managers-eu to EU and …-us to US; flag it UseAs: RLS_RULES, which is irreversible. Attach it to the dataset with "Grant access to dataset".

Step 5: Verify three ways. The author sees all regions (dataset owners are unrestricted); a member of regional-managers-eu sees only EU; a CSV export respects the same restriction.

Step 6: Build and publish. A KPI sheet (revenue, orders, average order value by region), a trend sheet with a 14-period ML forecast, and an anomaly insight on daily revenue; publish, share with the group as Reader, and subscribe regional managers to a scheduled email report (scheduled email delivery respects RLS).

Step 7: Price it (us-east-1, as of Oct 2026):

What this build proves. Every earlier lesson is load-bearing: without lesson 04 the table is a file pile; without 07 Athena cannot resolve gold.sales; without 12 the manager sees every region; without 15 the dashboard reports bad data confidently; without 16 the direct-query fallback quietly costs more than the entire BI line.

---

10. The capstone: seventeen layers as one reference architecture

Below is the entire course as a single diagram. Read it as a spine running left to right (ingest, store, catalog, transform, query, serve), with control planes wrapped around it (orchestration, governance, privacy, security, quality, cost), and notice that QuickSight is the only node a business user ever touches.

10.1 The seventeen layers, and the decision each one owns

• 📚 Did you know? AWS's own What is a Data Lakehouse? page names the same spine this table describes, ingestion, storage, metadata, API, semantic/consumption, and the semantic layer is where BI tools sit. The seventeen lessons are an expansion of AWS's five published layers into the service-by-service decisions a team actually has to make, which is why the capstone diagram has seventeen boxes but only five columns of flow (AWS What-is pages, accessed 2026-10-11).

---

11. The 30/60/90-day implementation roadmap

A reference architecture is a picture; a roadmap is an order of operations. The rule that governs the sequence is simple: nothing downstream may be built before the thing it depends on exists and has been verified. You cannot grant on an unregistered location, cannot refresh before there is a table, cannot restrict rows on a column that is still numeric.

11.1 Worked example E7: sizing the embedded audience before you buy anything

An ISV embeds a dashboard in a multi-tenant application for 50,000 monthly visitors, averaging 2 sessions of 30 minutes each: 100,000 sessions per month, or 1.2 million per year.

Read this as an exercise in arithmetic, not as an AWS-published formula: AWS publishes no break-even guidance for capacity versus seats, and the 30-minute session definition means one user who reopens a dashboard four times a day consumes four sessions. What the numbers do establish is the direction: at 100,000 sessions a month, per-seat pricing is not a serious option; annual capacity is roughly 2.3x cheaper than monthly capacity for the same volume; and only the annual plan removes the "Powered by Quick" branding and enables programmatic dashboard refresh.

---

2026 Updates (as of October 2026)

---

Real-World Case Studies

Every figure below is a customer result that AWS chose to publish, never an AWS promise. The case-study pages carry no publish date, so what they carry is an access date: accessed October 2026.

Case A, Trustly: insights 4x faster, cost down 50%, users 80 to 300

Reading it like a practitioner. Three separate levers moved here, and they are worth separating: the 15-minute cadence is a SPICE refresh-schedule decision (section 3.4); the user growth at lower cost is a per-seat-versus-capacity economics decision (worked example E8 below); and the 89% accuracy across 15,000 questions is a customer result about a specific question set: not an accuracy guarantee for Amazon Q, and not a claim you may restate as "Amazon Q is 89% accurate".

Case B: two supporting QuickSight outcomes from the same corpus

Both are customer results, not service-level guarantees, and both describe specific migrations, which is the only way this course permits a percentage to be quoted.

Case C: Trustly's break-even, computed from published rates

Take Trustly's published 300 users and the October 2026 rates from section 2, then find the session count where provisioned Readers and reader session capacity cost the same:

This is arithmetic on published rates, not an AWS formula: AWS publishes no break-even guidance, and a "session" is a 30-minute period, so a reader who reopens a dashboard three times in an hour consumes three sessions. The transferable question for any BI deployment is the one this exercise forces: how many 30-minute sessions does a real reader consume per month? Measure it before you commit, because that answer decides whether a 300-reader estate costs $900,$600 or $1,500.

• 📚 Did you know? Trustly's 15-minute dashboard cadence is exactly the minimum schedule interval QuickSight offers: frequencies run "Every 15 minutes, Every 30 minutes, Hourly, Daily, Weekly, or Monthly", and ingestion happens within 10 minutes of the scheduled time (Refreshing SPICE data, accessed 2026-10-11). A "15-minute" dashboard is therefore really a 15-to-25-minute dashboard, which is why a visible "data as of" timestamp on the canvas is standard practice rather than decoration.

---

Practice Questions

Twelve items, all in the lh-17-qN series: one correct response, three or four distractors, with the teardown inside every explanation. Prices are us-east-1 list as of October 2026.