What is AQUA in Amazon Redshift, and which kinds of queries does it help?

## The problem AQUA addresses In an RA3 cluster the durable data lives in Redshift Managed Storage and compute nodes cache hot blocks on local SSD. When a query scans far more data than it ultimately returns — a huge fact table filtered down to a small slice, or a pattern match over a wide text column — the naive path moves a lot of bytes from storage to compute only for most of them to be discarded microseconds later. Network bandwidth between storage and compute becomes the limiting resource, not the compute nodes' CPUs. **AQUA (Advanced Query Accelerator)** attacks that path. It is a layer of accelerated nodes positioned close to managed storage that can evaluate certain scan-time work — predicate filtering and some aggregation — before data reaches the cluster's compute nodes. The compute nodes then receive a much smaller stream and finish the query normally. The general idea is the familiar one of pushing computation down to the data rather than pulling data up to the computation; AQUA is Redshift's hardware-assisted implementation of it. ## What it accelerates, and what it does not AQUA helps queries whose cost is dominated by scanning a lot of data and discarding most of it: - large scans with **selective predicates**, where a small fraction of rows survive; - **string matching** predicates over large text columns, which are expensive to evaluate row by row on the compute nodes; - **simple aggregations** over very large inputs. It does not help: - small queries, where the scan is not the bottleneck at all; - **join-heavy** plans, where the cost lives in redistributing and hashing rows between compute nodes rather than in the scan; - queries whose data is already resident in the local SSD cache and whose result is small; - anything served from the result cache, which never executes. ## Where it fits in the architecture It is useful to place AQUA alongside the other layers of an RA3 cluster: the leader node plans and merges; compute nodes hold slices and execute plan segments; managed storage holds the durable blocks; local SSD caches the hot ones; and AQUA sits on the path between managed storage and compute, doing early filtering. Nothing about slices, distribution style, sort order or zone-map pruning changes because AQUA exists — pruning still avoids reading blocks entirely, which is strictly better than filtering them quickly. That ordering matters for an interview answer. The best way to move less data is not to read it: good sort-key design and predicates that let Redshift skip blocks outright dominate any scan-time acceleration. AQUA reduces the cost of the data you *do* read. ## Availability and configuration AQUA applies to eligible RA3 node types — the larger ones — and its availability has varied by region. Its enablement story has also changed over time: it was once an explicit cluster setting, and AWS later moved to applying it automatically where it is beneficial, removing the knob. Because of that history, the safe interview answer states the mechanism confidently and treats the configuration surface as version-dependent: check the current documentation for whether there is anything to turn on for your node type and region. ## Why it is a differentiator question, not a core one Nobody should fail a Redshift interview for not knowing AQUA. It is a background accelerator with no schema or query implications, and it is not something you tune. It appears in interviews as a probe: does the candidate know the RA3 storage path well enough to say where such a layer would even sit, and are they honest about the fact that it does not substitute for distribution, sort-key or query design? A candidate who claims AQUA makes tuning unnecessary, or who attributes it to DC2 clusters or to serverless capacity, has revealed a shakier grasp of the architecture than one who simply says "it is scan-side acceleration on RA3, and I have never had to configure it."