Q2 — SPICE Internals and Data at Scale

Why this module exists

Nearly every serious Amazon Quick Sight problem is a SPICE problem wearing a costume.

"The dashboard is stale" is an ingestion that failed silently at 4am. "The refresh is slow" is a full refresh of two billion rows that should have been incremental. "We can't load our data" is a non-adjustable per-dataset quota that no amount of money will move. And "AWS Support says it's working as intended" usually means the case was opened without the one field that would have proved otherwise.

This module is built so that by the end you can walk into a call with AWS Support, name the quota, name the error enum, and hand over the evidence — instead of describing a symptom and waiting.

The one idea to hold onto

SPICE has two completely separate ceilings, and confusing them wastes weeks.

   ┌──────────────────────────────┐        ┌──────────────────────────────┐
   │  PER-DATASET quota           │        │  ACCOUNT + REGION capacity   │
   │  2 billion rows / 2 TB       │        │  bundled GB + purchased GB   │
   │  (Enterprise)                │        │                              │
   │                              │        │                              │
   │  ❌ NOT adjustable           │        │  ✅ buy more, any time       │
   │  ❌ no support case will     │        │  ✅ auto-purchase available  │
   │     raise it                 │        │                              │
   └──────────────────────────────┘        └──────────────────────────────┘
     hit this → redesign the dataset         hit this → it's a billing decision

One is an engineering problem. The other is a purchase order. Teams routinely open support cases about the first believing it's the second, and lose a fortnight.

There is a third ceiling that catches everyone eventually: you can only call CreateIngestion 32 times per 24 hours on Enterprise, 8 on Standard, and that quota is not adjustable either.

What you'll be able to do

Estimate a dataset's logical SPICE size from its schema, before you build it, using AWS's published formula — and explain why that formula must not be used to size an account.
State every SPICE quota from memory, and say for each one whether it is adjustable.
Read a failed ingestion through the API: status, request type, request source, rows ingested, rows dropped, and the error type enum.
Choose between full and incremental refresh on evidence, and describe exactly what incremental refresh does to the rows already in SPICE.
Decide when SPICE is the wrong answer and direct query is right.
Open an AWS Support case that a support engineer can act on immediately.

Lessons

#	Lesson	Read	Listen
1	What SPICE is, and how it is sized	22 min	9 min
2	The quotas that stop you	26 min	9 min
3	Ingestion mechanics and the failure taxonomy	30 min	10 min
4	Refresh strategy at scale	28 min	9 min
5	When SPICE is the wrong answer — and talking to AWS Support	26 min	9 min

Then: Cheat sheet · Lab · Quiz · Runbook

A note on the docs

Researching this module surfaced three live inconsistencies in AWS's own documentation, all of them consequences of the October 2025 Quick Suite rename. They are flagged where they arise:

The new user guide at /quick/latest/userguide/ links back to old /quicksight/latest/user/ URLs inside the body of the new pages.
editions.html in the new user guide resolves to a page titled "Amazon Quick user types" that describes subscriptions, while the quota and refresh pages continue to gate features on editions (Standard / Enterprise). Both models are documented as current, simultaneously.
The CreateIngestion API page describes the 32-call quota as "manually refresh datasets … 32 times", while the Service Quotas table describes the same quota as "the maximum number of calls to the createIngestion API function". Neither states whether scheduled refreshes consume it. Lesson 3 shows you how to measure the answer in your own account rather than guess it.

Facts verified 2026-08-09 against the pages cited in each lesson.