Amazon Redshift Monitoring: Query Performance, Concurrency Scaling Costs, and RA3 Node Sizing

Amazon Redshift is a powerful data warehouse, but its performance and cost can degrade quickly without proper monitoring. A slow query that worked fine at 50GB can throttle the entire cluster at 500GB. Concurrency scaling that looked free for weeks can spike your bill by thousands of dollars overnight when query volume jumps. And RA3 node sizing decisions made at initial setup often become cost bottlenecks as data scales into petabytes.

This guide covers how to monitor Redshift effectively like tracking query performance at the statement level, controlling concurrency scaling spend before it compounds, and sizing RA3 nodes based on actual workload patterns rather than vendor recommendations.

What Is Amazon Redshift Monitoring

Amazon Redshift monitoring is the practice of continuously tracking query execution, cluster resource utilization, storage consumption, and operational costs to maintain performance, prevent bottlenecks, and control spend as data warehouse workloads scale.

Unlike transactional databases where monitoring focuses on row level locks and replication lag, Redshift monitoring centers on columnar scan efficiency, WLM queue wait times, disk based query execution, and the cost impact of auto scaling features like concurrency scaling and managed storage growth.

Redshift’s architecture layers compute, storage, and network in ways that create hidden bottlenecks. A query that scans uncompressed columns can consume 10x more disk I/O than an identical query with proper encoding. WLM queue configurations that work at 20 concurrent queries fail at 50. And Redshift Managed Storage automatically offloads cold data to S3, which adds retrieval latency that does not surface in CloudWatch’s default metrics.

The purpose of Redshift monitoring is to surface these issues before they cascade. A properly monitored Redshift cluster identifies slow queries by exact SQL statement, tracks which WLM queues are saturated, measures the cost of concurrency scaling usage by hour, and alerts when RA3 node storage approaches the local SSD threshold that triggers S3 offload.

How Amazon Redshift Monitoring Works

Redshift monitoring operates across three telemetry layers — system tables that log query execution history, CloudWatch metrics that track cluster level resource consumption, and query execution logs that capture statement level performance data.

System Tables and Query History

Redshift maintains system tables in each cluster that log every query executed, including STL_QUERY, STL_WLM_QUERY, SVL_QLOG, and STV_RECENTS. These tables record query start time, execution duration, queue assignment, disk spill events, and whether the query was offloaded to a concurrency scaling cluster.

The STL_QUERY table stores the full SQL text of every query along with execution metadata. STL_WLM_QUERY adds workload management context, showing which WLM queue a query ran in, how long it waited in the queue before execution, and whether it hit memory or CPU limits. SVL_QLOG surfaces query compilation time, plan node execution, and rows returned versus rows scanned, which is critical for identifying inefficient queries that scan far more data than they return.

These system tables are queryable via SQL, which means monitoring tools can join query execution data with cluster metadata to build dashboards showing top queries by duration, most frequent queue wait events, and queries that spilled to disk due to insufficient memory.

CloudWatch Metrics for Cluster Health

Amazon CloudWatch collects aggregate metrics for each Redshift cluster every minute. Key metrics include CPUUtilization, PercentageDiskSpaceUsed, DatabaseConnections, NetworkThroughput, and ReadLatency. These metrics surface cluster level resource saturation but do not identify which specific queries or users are consuming resources.

A spike in CPUUtilization indicates the cluster is executing compute heavy queries, but CloudWatch alone will not tell you which query or which user triggered it. You have to correlate the CloudWatch timestamp with system table queries to find the root cause.

CloudWatch also tracks concurrency scaling usage via ConcurrencyScalingActiveClusters, which shows how many additional clusters Redshift spun up to handle overflow queries. This metric is critical for cost monitoring because concurrency scaling charges accrue at $0.00935 per second per active cluster, which compounds to $33.66 per hour if a concurrency scaling cluster runs continuously.

Query Execution Plans and Performance Diagnostics

Redshift’s EXPLAIN command generates query execution plans that show how the query planner intends to process a statement — which tables will be scanned, which joins will be executed, and whether distribution keys or sort keys will be used effectively. The EXPLAIN output includes cost estimates for each plan node, but these are relative units, not actual execution times.

To measure real execution behavior, you run EXPLAIN with the ANALYZE option, which executes the query and returns actual row counts, execution times, and disk spill events for each plan node. This is the most precise way to diagnose why a specific query is slow.

Queries that show high “rows emitted” versus “rows filtered” in the EXPLAIN ANALYZE output are scanning too much data. Queries with “disk based” markers in the plan output spilled to disk because WLM allocated insufficient memory. And queries with “network” plan nodes indicate data is being shuffled across nodes due to poor distribution key choices.

Workload Management Queues

WLM queues control how Redshift allocates memory and concurrency slots to different query types. Each queue has a defined memory percentage, concurrency limit, and timeout threshold. Queries are routed to queues based on user group or query group labels.

Monitoring WLM queue performance requires tracking queue depth (how many queries are waiting), queue execution time (how long queries spend running in the queue), and queue timeout events (queries that exceeded the queue’s time limit and were terminated). High queue depth with low execution time indicates insufficient concurrency slots. High execution time with normal queue depth indicates memory or CPU bottlenecks within the queue.

WLM queue saturation is the most common cause of Redshift performance complaints. A cluster with 50% CPU utilization can still deliver slow query performance if WLM queues are misconfigured and queries are waiting in queue rather than executing.

Query Performance Monitoring in Redshift

Query performance in Redshift is measured by execution duration, queue wait time, rows scanned versus rows returned, and whether the query spilled to disk or executed entirely in memory. A well performing query returns results in under one second for interactive dashboards or under 60 seconds for analytic reports. Queries that take longer are either scanning too much data, waiting in WLM queues, or executing inefficiently due to poor table design.

Identifying Slow Queries

The first step in query performance monitoring is identifying which queries are slow. The STL_QUERY system table logs every query with its execution duration. A simple query surfaces the top 20 slowest queries in the past 24 hours:

SELECT 
  query,
  TRIM(querytxt) AS sql_text,
  starttime,
  endtime,
  DATEDIFF(second, starttime, endtime) AS duration_seconds
FROM stl_query
WHERE starttime >= DATEADD(day, -1, GETDATE())
  AND aborted = 0
ORDER BY duration_seconds DESC
LIMIT 20;

This query returns the full SQL text and execution time for each slow query. Once you identify a problem query, you run EXPLAIN ANALYZE on it to see the execution plan and identify bottlenecks.

Queue Wait Time

Queue wait time is the duration a query spends waiting in a WLM queue before execution begins. High queue wait time indicates WLM misconfiguration or insufficient concurrency slots. The STL_WLM_QUERY table tracks queue assignment and wait duration:

SELECT 
  query,
  service_class,
  queue_start_time,
  queue_end_time,
  DATEDIFF(second, queue_start_time, queue_end_time) AS queue_wait_seconds,
  exec_start_time,
  exec_end_time,
  DATEDIFF(second, exec_start_time, exec_end_time) AS exec_duration_seconds
FROM stl_wlm_query
WHERE queue_start_time >= DATEADD(day, -1, GETDATE())
ORDER BY queue_wait_seconds DESC
LIMIT 20;

If queue wait time exceeds 30 seconds regularly, the WLM queue is undersized. Solutions include increasing the concurrency limit for that queue, reducing the memory allocation to allow more concurrent queries, or enabling concurrency scaling to offload overflow queries to additional clusters.

Disk Spill Events

Disk spill occurs when a query requires more memory than WLM allocated to its queue. Redshift writes intermediate query results to disk, which is far slower than in memory execution. Queries that spill to disk can take 10x longer than queries that execute entirely in memory.

The SVL_QUERY_SUMMARY table logs disk spill events:

SELECT 
  query,
  step,
  rows,
  bytes,
  is_diskbased
FROM svl_query_summary
WHERE is_diskbased = 't'
  AND query IN (
    SELECT query FROM stl_query 
    WHERE starttime >= DATEADD(day, -1, GETDATE())
  )
ORDER BY query, step;

If disk spill events are frequent, increase the memory allocation for the affected WLM queue or reduce the concurrency limit to give each query more memory.

Rows Scanned vs. Rows Returned

Efficient queries scan only the rows needed to satisfy the WHERE clause. Inefficient queries scan entire tables and filter rows after retrieval. The ratio of rows scanned to rows returned is visible in SVL_QLOG:

SELECT 
  query,
  rows,
  rows_pre_filter,
  CASE 
    WHEN rows > 0 THEN (rows_pre_filter::FLOAT / rows::FLOAT)
    ELSE 0
  END AS scan_ratio
FROM svl_qlog
WHERE query IN (
  SELECT query FROM stl_query 
  WHERE starttime >= DATEADD(day, -1, GETDATE())
)
ORDER BY scan_ratio DESC
LIMIT 20;

A scan ratio above 10 indicates the query is scanning 10x more rows than it returns. This happens when tables lack sort keys or when queries do not leverage distribution keys effectively. Adding sort keys on frequently filtered columns or redesigning distribution keys can reduce scan ratios from 100:1 to 1:1.

Query Compilation Time

Redshift compiles query plans before execution. First time queries take longer because the plan must be compiled and cached. Subsequent executions use the cached plan and execute faster. The SVL_QLOG table includes compilation time:

SELECT 
  query,
  compile,
  DATEDIFF(millisecond, 0, compile) AS compile_ms
FROM svl_qlog
WHERE compile IS NOT NULL
ORDER BY compile_ms DESC
LIMIT 20;

If compilation time exceeds one second regularly, the cluster may be under memory pressure or the query is unusually complex. Simplifying subqueries or breaking complex CTEs into temporary tables can reduce compilation overhead.

Concurrency Scaling Cost Monitoring

Concurrency scaling allows Redshift to automatically spin up additional clusters to handle query overflow when the main cluster’s WLM queues are saturated. Each Redshift cluster earns one hour of free concurrency scaling credits per day, which covers most workloads. Usage beyond the free hour is billed at $0.00935 per second, which equals $33.66 per hour per active concurrency scaling cluster.

This pricing can escalate quickly. A workload that triggers three concurrent scaling clusters for six hours in a single day will incur $605.88 in concurrency scaling charges before the month ends. Over a full month, if this pattern repeats daily, the concurrency scaling bill reaches $18,176.40.

Tracking Concurrency Scaling Usage

The SYS_SERVERLESS_USAGE system view logs concurrency scaling usage by hour:

SELECT 
  DATE_TRUNC('hour', start_time) AS hour,
  SUM(charged_seconds) AS total_charged_seconds,
  SUM(charged_seconds) * 0.00935 AS estimated_cost_usd
FROM sys_serverless_usage
WHERE start_time >= DATEADD(day, -7, GETDATE())
GROUP BY hour
ORDER BY hour DESC;

This query shows exactly how much concurrency scaling usage occurred each hour and the associated cost. If you see charges appearing outside of expected traffic spikes, investigate which queries are being offloaded to concurrency scaling clusters via STL_QUERY:

SELECT 
  query,
  TRIM(querytxt) AS sql_text,
  starttime,
  endtime,
  concurrency_scaling_status
FROM stl_query
WHERE concurrency_scaling_status = 1
  AND starttime >= DATEADD(day, -1, GETDATE())
ORDER BY starttime DESC;

Queries with concurrency_scaling_status = 1 ran on a concurrency scaling cluster rather than the main cluster. If the same query appears repeatedly in concurrency scaling logs, optimize it or move it to a dedicated WLM queue with higher memory allocation.

Setting Concurrency Scaling Usage Limits

Redshift allows you to set daily, weekly, or monthly usage limits for concurrency scaling to prevent runaway costs. Usage limits are configured per cluster via the Redshift console or CLI:

aws redshift modify-cluster \
  --cluster-identifier my-cluster \
  --max-concurrency-scaling-clusters 3

This command caps concurrency scaling at three additional clusters. Once the limit is reached, queries queue on the main cluster instead of triggering additional concurrency scaling clusters. This trades query performance for cost predictability.

Usage alerts can be configured via CloudWatch to fire when concurrency scaling usage exceeds a defined threshold. A typical alert fires when concurrency scaling seconds in a single hour exceed 1,800 (30 minutes of concurrency scaling cluster runtime), which indicates sustained overflow rather than a brief spike.

Cost Scenarios for Concurrency Scaling

Small team scenario (10 users, occasional spikes) Typical workload uses 30 minutes of concurrency scaling per day beyond the free hour. Monthly concurrency scaling cost: $0.00935 per second × 1,800 seconds per day × 30 days = $505.35 per month.

Mid-market scenario (50 users, daily peak hours) Workload uses 3 hours of concurrency scaling per day beyond the free hour. Monthly concurrency scaling cost: $0.00935 per second × 10,800 seconds per day × 30 days = $3,031.80 per month.

Enterprise scenario (200 users, sustained high concurrency) Workload uses 8 hours of concurrency scaling per day across multiple clusters. Monthly concurrency scaling cost: $0.00935 per second × 28,800 seconds per day × 30 days = $8,078.40 per month.

These scenarios assume a single concurrency scaling cluster. If Redshift spins up multiple clusters simultaneously, costs multiply accordingly.

RA3 Node Sizing and Cost Optimization

RA3 nodes decouple compute and storage in Redshift by using managed storage (RMS) that automatically tiers data between local NVMe SSDs and Amazon S3. Each RA3 node includes a fixed amount of local SSD capacity. When data exceeds this threshold, Redshift offloads cold data to S3, which adds retrieval latency for queries that scan offloaded blocks.

RA3 node types and their local SSD capacity:

• ra3.xlplus: 32 TB managed storage per node, 4 vCPUs
• ra3.4xlarge: 128 TB managed storage per node, 12 vCPUs
• ra3.16xlarge: 128 TB managed storage per node, 48 vCPUs

Pricing as of April 2026 in us-east-1:

• ra3.xlplus: $1.086 per hour
• ra3.4xlarge: $3.26 per hour
• ra3.16xlarge: $13.04 per hour

Managed storage is billed separately at $0.024 per GB per month in us-east-1.

How Managed Storage Impacts Query Performance

Local SSD storage on RA3 nodes delivers sub-millisecond access times. S3 based storage adds 10–50ms retrieval latency per block. If a query scans data that has been offloaded to S3, every scanned block incurs this latency penalty, which compounds across large scans.

The percentage of data stored locally versus offloaded to S3 directly impacts query performance. A cluster with 80% of its active dataset in local SSD will perform far better than a cluster with only 20% local.

Redshift automatically manages this tiering based on access patterns. Frequently queried data stays in local SSD. Infrequently queried data moves to S3. But if your workload changes, for example, a new dashboard suddenly queries historical data that was previously cold, query performance degrades until Redshift retrieves the data back from S3 to local SSD.

You can monitor managed storage distribution via the STV_BLOCKLIST and SVL_S3LOG system tables, though Redshift does not expose a direct “local vs. S3” percentage in CloudWatch.

Right Sizing RA3 Nodes

RA3 node sizing depends on three factors: total data volume, active working set size, and query concurrency. Under sizing nodes forces more data into S3, which degrades query performance. Over sizing nodes wastes compute capacity that sits idle.

Total data volume is the sum of all table data in the cluster. If you have 200 TB of data, you need at least two ra3.16xlarge nodes (128 TB each = 256 TB total capacity).

Active working set is the subset of data queried regularly. If your total data is 200 TB but only 50 TB is queried in a typical day, sizing nodes to keep 50 TB in local SSD maintains performance without over provisioning.

Query concurrency determines CPU and memory requirements. A cluster that runs 10 concurrent queries needs fewer vCPUs than a cluster running 100 concurrent queries. WLM queue depth and average query duration inform this calculation.

A common sizing mistake is provisioning based on total data volume alone. A 200 TB cluster sized for 200 TB of local SSD capacity (using ra3.16xlarge nodes) will overspend if only 50 TB is actively queried. A better approach is provisioning for 60–70 TB of local capacity (to include headroom for growth) and allowing cold data to tier to S3.

Monitoring RA3 Storage Utilization

The STV_PARTITIONS table shows how much storage each table consumes:

SELECT 
  TRIM(name) AS table_name,
  SUM(capacity) / 1024.0 / 1024.0 AS size_gb
FROM stv_partitions
GROUP BY table_name
ORDER BY size_gb DESC
LIMIT 20;

This query identifies the largest tables in the cluster. If a table has grown unexpectedly, it may be pushing the cluster past its local SSD threshold, forcing more S3 offload and slower queries.

CloudWatch’s PercentageDiskSpaceUsed metric tracks overall cluster storage utilization. If this metric exceeds 80%, you are nearing the local SSD limit and should consider adding nodes or archiving cold data.

Cost Comparison for RA3 Sizing

Scenario: 100 TB total data, 30 TB active working set, 50 concurrent queries

Node configuration	Monthly compute cost	Monthly storage cost	Total monthly cost	Notes
2x ra3.16xlarge	$18,787	$2,400	$21,187	Over provisioned compute
4x ra3.4xlarge	$18,787	$2,400	$21,187	Balanced compute, same cost
8x ra3.xlplus	$6,261	$2,400	$8,661	Under provisioned CPU for 50 queries

Compute cost calculated as hourly rate × 730 hours. Storage cost is 100 TB × $0.024/GB.

The optimal configuration for this scenario is 4x ra3.4xlarge, which balances vCPU capacity for 50 concurrent queries with sufficient local SSD to keep the 30 TB working set in fast storage. The 2x ra3.16xlarge configuration wastes vCPUs, while 8x ra3.xlplus under provisions CPU and will queue queries frequently.

Best Practices for Redshift Monitoring

Effective Redshift monitoring requires tracking both operational health and cost drivers. These practices prevent performance degradation and cost overruns before they impact production.

Set Query Timeout Thresholds

Configure WLM queues with timeout values that match expected query durations. Interactive dashboards should timeout at 30 seconds. Long running analytic queries should timeout at 30 minutes. Queries that exceed these thresholds are either poorly written or executing against misdesigned tables. Timeouts prevent runaway queries from consuming cluster resources indefinitely.

Monitor Queue Depth Hourly

WLM queue depth shows how many queries are waiting to execute. Track this metric every hour via CloudWatch or system table queries. If queue depth exceeds 10 for more than five minutes, investigate which queries are queuing and why. High queue depth with low CPU utilization indicates WLM misconfiguration. High queue depth with high CPU utilization indicates the cluster is under provisioned.

Audit Concurrency Scaling Usage Weekly

Review concurrency scaling logs every week to identify patterns. If concurrency scaling usage is concentrated in specific hours, adjust WLM queue concurrency limits or shift workload timing to spread query load. If specific queries trigger concurrency scaling repeatedly, optimize those queries or move them to dedicated queues with higher memory allocation.

Track Disk Spill Rates

Disk spill events degrade query performance by 10x. Monitor the percentage of queries that spill to disk daily. If more than 5% of queries spill, increase WLM memory allocation or reduce queue concurrency to give each query more memory.

Review Table Statistics Monthly

Redshift’s query planner relies on table statistics to generate efficient execution plans. Stale statistics cause the planner to generate suboptimal plans, which slows queries. Run ANALYZE on all tables monthly to refresh statistics:

ANALYZE;

This command updates statistics for all tables in the cluster. For large tables, use ANALYZE COMPRESSION to also refresh encoding statistics, which optimizes columnar compression and reduces storage.

Alert on Storage Utilization Above 80%

When RA3 node storage exceeds 80% of local SSD capacity, Redshift begins offloading more data to S3, which adds query latency. Set CloudWatch alarms to fire when PercentageDiskSpaceUsed exceeds 80%. When alerted, archive infrequently queried data or add nodes to increase local SSD capacity.

Tools for Redshift Monitoring

Several tools monitor Redshift at different abstraction layers — from native AWS tools to third party platforms that unify Redshift telemetry with broader infrastructure observability.

Amazon CloudWatch

CloudWatch is AWS’s native monitoring service and collects cluster level metrics for Redshift every minute. It tracks CPU utilization, disk space, network throughput, and concurrency scaling usage. CloudWatch alone does not capture query level detail or WLM queue performance, but it provides a baseline for cluster health monitoring.

CloudWatch Logs Insights can query Redshift audit logs to surface query patterns, but this requires enabling audit logging and incurs additional log storage costs.

AWS Performance Insights

Performance Insights is a managed service that provides deeper visibility into Redshift query performance. It surfaces top SQL statements by execution time, wait events, and resource consumption. Performance Insights correlates query execution with WLM queue wait time and shows which queries are waiting in queues versus executing.

Performance Insights is available for RG and RA3 node types and incurs no additional cost for the first seven days of retention.

CubeAPM

CubeAPM provides full stack observability for Redshift clusters by ingesting CloudWatch metrics, system table queries, and query execution logs into a unified monitoring platform. It correlates Redshift query performance with upstream application traces to show exactly which API call triggered a slow query and how that query’s latency propagated through the application stack.

CubeAPM’s Redshift monitoring tracks query execution time, queue wait time, disk spill events, and concurrency scaling usage in real time. It generates alerts when query latency exceeds defined thresholds and provides drill down views showing the exact SQL statement, execution plan, and rows scanned for every slow query.

Deployment is self hosted, which keeps telemetry data within your infrastructure and avoids AWS egress fees. Pricing is $0.15/GB of telemetry data ingested, which includes Redshift metrics, application traces, logs, and infrastructure metrics in a single bill.

Third Party APM Platforms

Datadog, New Relic, and Dynatrace offer Redshift monitoring integrations that collect CloudWatch metrics and query logs. These platforms excel at correlating Redshift performance with application layer observability, showing how database latency impacts end user experience.

Datadog’s Redshift integration tracks cluster metrics, query performance, and concurrency scaling usage. It requires installing the Datadog agent on an EC2 instance with network access to the Redshift cluster and granting the agent IAM permissions to query Redshift system tables. Pricing starts at $31 per host per month for infrastructure monitoring plus $0.10 per GB ingested for logs.

New Relic’s Redshift integration uses the New Relic Infrastructure agent to collect CloudWatch metrics and query system tables. Pricing follows New Relic’s data ingest model at $0.35 per GB beyond the free tier. For a 50-node cluster generating 10 GB of telemetry daily, monthly cost reaches $1,050 before adding APM or log ingestion.

Dynatrace monitors Redshift via its OneAgent, which auto discovers Redshift clusters and instruments query execution. Pricing is host based starting at $0.08 per GB per hour for full stack monitoring, which includes infrastructure, logs, and traces.

Open Source Monitoring Tools

Prometheus and Grafana can monitor Redshift by scraping CloudWatch metrics via the CloudWatch Exporter and querying Redshift system tables via custom exporters. This approach requires building and maintaining custom dashboards and alert rules, but it avoids vendor lock-in and SaaS costs.

The CloudWatch Exporter for Prometheus collects Redshift metrics and exposes them in Prometheus format. You configure Prometheus to scrape the exporter every 60 seconds and build Grafana dashboards to visualize cluster health. Query level monitoring requires writing custom SQL scripts that query system tables and export results to Prometheus.

This setup works well for teams already running Prometheus and Grafana for broader infrastructure monitoring, but it adds operational overhead compared to managed platforms.

Conclusion

Amazon Redshift monitoring is the practice of continuously tracking query execution, cluster resource utilization, storage consumption, and operational costs to maintain performance and control spend. Effective monitoring surfaces slow queries before they degrade user experience, identifies concurrency scaling cost spikes before they compound, and ensures RA3 node sizing matches actual workload patterns.

The three critical areas query performance, concurrency scaling costs, and RA3 node sizing interact directly. Under sized RA3 nodes force data offload to S3, which slows queries and increases concurrency scaling usage as more queries queue. Over sized RA3 nodes waste compute capacity that could be allocated to additional WLM concurrency slots or memory. And poorly configured WLM queues cause queries to wait in queues or spill to disk, which triggers concurrency scaling and drives up costs.

Monitoring these areas requires combining CloudWatch metrics, Redshift system table queries, and query execution analysis into a unified view. Tools like infrastructure monitoring platforms correlate Redshift telemetry with broader application and infrastructure observability to show exactly how database performance impacts end user experience.

Disclaimer: The information in this article reflects the latest details available at the time of publication and may change as technologies and products evolve. Features, pricing, and plan limits can change over time. Always verify the latest information directly with the vendor before making purchasing or deployment decisions.

Frequently Asked Questions