TL;DR: SPICE — the in-memory engine that makes QuickSight dashboards feel instant — is sold in 10 GB blocks at ~$0.38/GB-month and bills on what you allocated, not what you loaded. Allocations get bumped for big ingests and never lowered, so year-old deployments routinely pay for 40–60% empty space. The audit is 15 minutes: delete unused datasets, trim SELECT * imports to the columns dashboards use, pre-aggregate fact tables, then lower the allocation.
The numbers
$0.38/GB-month (Enterprise), 10 GB included per Author; 800 GB allocated with 220 GB used = **$220/month for empty memory**- Field example: 18 months of drift to 1.2 TB allocated ($410/month) → deleted 18 stale datasets, trimmed three
SELECT *imports (410 GB holding60 GB of used columns), pre-aggregated a 240 GB history table to 8 GB → **$140/month**, no visible change to any dashboard - The pre-aggregation trophy: a 180M-row shipments table (140 GB SPICE) whose dashboards only ever grouped by day/region/carrier became an 8,500-row rollup — 1.5 GB, refreshes in 12 seconds instead of 45 minutes, charts 15× faster
Do this
-
Check Allocated vs Used (Manage QuickSight → SPICE Capacity). The gap is money; note it before touching anything.
-
Sort datasets by SPICE size, audit the top five:
- Untouched in 60–90 days → delete.
- Wide import? Trim to dashboard-needed columns at the dataset level (filtering in the analysis doesn't help — the bytes are already imported).
- Dashboards always aggregate it? Build the rollup table in the warehouse and point SPICE at that.
- Queried monthly at most? Flip to Direct Query and stop storing it.
-
Lower the allocation — the step everyone forgets; cleanup without it saves nothing. Come down in 10–20% steps, keep ~20% headroom (a ~95%-full allocation can break refreshes).
-
Stagger refresh schedules (50 datasets at midnight hammers the warehouse) and use incremental refresh where the source supports it — that's a source-side query-cost saving on top.
-
Calendar a quarterly repeat. Allocations only drift one direction without it.
Gotchas
- Allocation ≠ usage is the whole game — AWS lets you decrease, but only to current-usage-plus-buffer, and never does it for you.
- SPICE compresses 2–5× on ingest — size against the console's post-compression number, not the warehouse table size.
- Direct Query isn't free either: it shifts cost to per-query charges and warehouse load; the 80/20 split (SPICE for interactive, Direct Query for rare/real-time) is the usual sweet spot.
- Real-time needs (< ~15 min freshness) can't use SPICE regardless of cost.
- Very large single datasets (500M+ rows) fight the platform — the fix is pre-aggregation, not more capacity.
Skip this if
- Total usage sits under the Authors' included allocation — nothing to optimize.
- The deployment is new — do this at month 6, not week 1.
- Readers dominate the bill — do reader pricing first; SPICE is usually line two.