Trying Out CloudWatch Database Insights, Now Supported by Amazon Aurora DSQL
This page has been translated by machine translation. View original
Introduction
On August 20, 2026, an update was announced that adds Amazon CloudWatch Database Insights support to Amazon Aurora DSQL.
DSQL Active Session History (DASH) automatically collects database load information at 1-minute intervals, and you can view it from the console at no additional charge.
In this article, using a running Aurora DSQL cluster, I checked the Database Insights console display, retrieval of standard CloudWatch metrics, and retrieval of DASH data via the PromQL API.
What I Verified
Console Display
In the CloudWatch console, there is a Database Insights item under Infrastructure Monitoring in the left navigation. Just by creating an Aurora DSQL cluster, you can access DASH data from here.
When you open the Database Instance Dashboard, a Database load chart is displayed at the top. The breakdown of Average active sessions can be switched between Waits and SQL Text, and you can choose Bar or Line for the graph.
The DB Load Analysis section at the bottom has Top SQL and Top waits tabs. In the Top SQL tab, the AAS for each SQL statement is displayed as Load by waits (AAS), and a list of SQL statements is also displayed. When you select a SQL statement, the full query text and Query ID are displayed in SQL text at the bottom. The Engine field showed Aurora DSQL.
The Database Telemetry tab has 10 metric widgets lined up.
| Widget | Metrics | Unit |
|---|---|---|
| Transactions | TotalTransactions, ReadOnlyTransactions | Count |
| Query timeouts | QueryTimeouts | Count |
| OCC conflicts | OccConflicts | Count |
| Commit latency | CommitLatency | Milliseconds |
| I/O throughput | BytesRead, BytesWritten | Bytes |
| Compute time | ComputeTime | Milliseconds |
| Cluster storage size | ClusterStorageSize | Bytes |
| DPU usage | ReadDPU, WriteDPU, ComputeDPU, TotalDPU, MultiRegionWriteDPU | Units |
| Established connections | ResourceCount | Count |
| Connection attempts | CallCount (by DbConnectAdmin / DbConnect) | Count |
Retrieving Standard Metrics
I checked whether the metrics listed in the console's Database Telemetry can be retrieved from the CloudWatch metrics API.
aws cloudwatch list-metrics --namespace AWS/AuroraDSQL --region us-east-1
{
"Metrics": [
{
"Namespace": "AWS/AuroraDSQL",
"MetricName": "OccConflicts",
"Dimensions": [{"Name": "ClusterId", "Value": "<cluster-id>"}]
},
{
"Namespace": "AWS/AuroraDSQL",
"MetricName": "ClusterStorageSize",
"Dimensions": [{"Name": "ClusterId", "Value": "<cluster-id>"}]
},
{
"Namespace": "AWS/AuroraDSQL",
"MetricName": "ComputeTime",
"Dimensions": [{"Name": "ClusterId", "Value": "<cluster-id>"}]
},
{
"Namespace": "AWS/AuroraDSQL",
"MetricName": "TotalTransactions",
"Dimensions": [{"Name": "ClusterId", "Value": "<cluster-id>"}]
},
{
"Namespace": "AWS/AuroraDSQL",
"MetricName": "ComputeDPU",
"Dimensions": [{"Name": "ClusterId", "Value": "<cluster-id>"}]
},
{
"Namespace": "AWS/AuroraDSQL",
"MetricName": "ReadDPU",
"Dimensions": [{"Name": "ClusterId", "Value": "<cluster-id>"}]
},
{
"Namespace": "AWS/AuroraDSQL",
"MetricName": "WriteDPU",
"Dimensions": [{"Name": "ClusterId", "Value": "<cluster-id>"}]
},
{
"Namespace": "AWS/AuroraDSQL",
"MetricName": "ReadOnlyTransactions",
"Dimensions": [{"Name": "ClusterId", "Value": "<cluster-id>"}]
},
{
"Namespace": "AWS/AuroraDSQL",
"MetricName": "BytesWritten",
"Dimensions": [{"Name": "ClusterId", "Value": "<cluster-id>"}]
},
{
"Namespace": "AWS/AuroraDSQL",
"MetricName": "BytesRead",
"Dimensions": [{"Name": "ClusterId", "Value": "<cluster-id>"}]
},
{
"Namespace": "AWS/AuroraDSQL",
"MetricName": "TotalDPU",
"Dimensions": [{"Name": "ClusterId", "Value": "<cluster-id>"}]
},
{
"Namespace": "AWS/AuroraDSQL",
"MetricName": "CommitLatency",
"Dimensions": [{"Name": "ClusterId", "Value": "<cluster-id>"}]
}
]
}
Twelve metrics were returned, and the only dimension was ClusterId. QueryTimeouts, MultiRegionWriteDPU, ResourceCount, and CallCount, which were listed in the console's Database Telemetry, do not appear in this list. By specification, metrics with no data points in the last 2 weeks are not included in the list. Since QueryTimeouts has never occurred, it is expected that it does not appear in the list.
I specified the time window when the daily data ingestion job was running and retrieved DPU consumption at 5-minute intervals.
aws cloudwatch get-metric-statistics \
--namespace AWS/AuroraDSQL \
--metric-name TotalDPU \
--dimensions Name=ClusterId,Value=<cluster-id> \
--start-time 2026-08-23T07:00:00Z \
--end-time 2026-08-23T11:00:00Z \
--period 300 \
--statistics Sum Maximum \
--region us-east-1
Here are excerpts of the data points from the time windows where values were confirmed in the output.
{
"Label": "TotalDPU",
"Datapoints": [
{
"Timestamp": "2026-08-23T18:40:00+09:00",
"Sum": 286.66901874707025,
"Maximum": 40.81532766992188,
"Unit": "None"
},
{
"Timestamp": "2026-08-23T19:20:00+09:00",
"Sum": 257.6313710976563,
"Maximum": 18.65125854589844,
"Unit": "None"
},
{
"Timestamp": "2026-08-23T19:15:00+09:00",
"Sum": 113.22324524414063,
"Maximum": 71.276387875,
"Unit": "None"
}
]
}
Standard metrics, unlike DASH, can be retrieved from the AWS CLI. I also retrieved the number of transactions for the same time window.
aws cloudwatch get-metric-statistics \
--namespace AWS/AuroraDSQL \
--metric-name TotalTransactions \
--dimensions Name=ClusterId,Value=<cluster-id> \
--start-time 2026-08-23T07:00:00Z \
--end-time 2026-08-23T11:00:00Z \
--period 300 \
--statistics Sum Average \
--region us-east-1
{
"Label": "TotalTransactions",
"Datapoints": [
{
"Timestamp": "2026-08-23T18:40:00+09:00",
"Average": 1.0,
"Sum": 727.0,
"Unit": "None"
},
{
"Timestamp": "2026-08-23T19:20:00+09:00",
"Average": 1.0,
"Sum": 717.0,
"Unit": "None"
}
]
}
In both of the time windows where DPU increased, around 700 transactions were processed in 5 minutes. I also retrieved commit latency.
CommitLatency retrieval command and output
aws cloudwatch get-metric-statistics \
--namespace AWS/AuroraDSQL \
--metric-name CommitLatency \
--dimensions Name=ClusterId,Value=<cluster-id> \
--start-time 2026-08-23T07:00:00Z \
--end-time 2026-08-23T11:00:00Z \
--period 300 \
--statistics Average Maximum \
--region us-east-1
{
"Label": "CommitLatency",
"Datapoints": [
{
"Timestamp": "2026-08-23T19:15:00+09:00",
"Average": 8.602227272727273,
"Maximum": 189.249,
"Unit": "Milliseconds"
},
{
"Timestamp": "2026-08-23T17:20:00+09:00",
"Average": 8.161930232558138,
"Maximum": 104.103,
"Unit": "Milliseconds"
}
]
}
The unit is Milliseconds; the maximum at 19:15 JST was 189.2 ms, and the maximum at 17:20 JST was 104.1 ms.
Retrieval via the PromQL API
The DASH data itself, which provides the breakdown of DB Load and wait events, takes a different route from standard metrics. db.active_sessions.avg can only be accessed via PromQL, and the QueryMetrics API used for queries has no corresponding CLI subcommand. In AWS CLI 2.36.29, it was not accepted as a subcommand.
aws: [ERROR]: An error occurred (ParamValidation): argument operation: Found invalid choice 'query-metrics'
QueryMetrics is provided as a Prometheus-compatible REST endpoint (https://monitoring.<region>.amazonaws.com/api/v1/query and /api/v1/query_range). You need to send HTTP requests signed with Signature Version 4 directly. The PromQL querying page in the official documentation also explicitly states that requests must be signed with Signature Version 4 using monitoring as the service name.
So I installed version 0.33 of awscurl, a third-party OSS tool that handles SigV4 signing and sends HTTP requests, with pip install awscurl, and retrieved AAS by wait event.
awscurl --service monitoring --region us-east-1 \
-X POST 'https://monitoring.us-east-1.amazonaws.com/api/v1/query_range' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'query=avg by ("db.wait.event") ({"db.active_sessions.avg", "@resource.aws.auroradsql.cluster_id"="<cluster-id>"})&start=2026-08-23T09:00:00Z&end=2026-08-23T11:00:00Z&step=1m'
{
"status": "success",
"data": {
"resultType": "matrix",
"result": [
{
"metric": {"db.wait.event": "Commit"},
"values": [[1787478060.0, "0.06666666666666667"], [1787478120.0, "0.06666666666666667"]]
},
{
"metric": {"db.wait.event": "OnCpu"},
"values": [[1787478000.0, "0.016666666666666666"], [1787478060.0, "0.016666666666666666"]]
},
{
"metric": {"db.wait.event": "SequentialScanRead"},
"values": [[1787478000.0, "0.016666666666666666"], [1787478060.0, "0.016666666666666666"]]
}
]
}
}
I POSTed the PromQL query in the request body. Six types of wait events were retrieved: ClientRead, Commit, OnCpu, ScatteredBatchRead, SequentialScanRead, and UniqueConstraintCheck.
The response has a structure with status and data, unlike the MetricDataResults array returned by the regular CloudWatch GetMetricData. It is the same format as the Prometheus query API.
Next, I retrieved the per-SQL breakdown. This is the result of grouping by normalized SQL statement as the label and narrowing down to the top 5 by AAS.
awscurl --service monitoring --region us-east-1 \
-X POST 'https://monitoring.us-east-1.amazonaws.com/api/v1/query_range' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'query=topk(5, avg by ("db.query.normalized_text") ({"db.active_sessions.avg", "@resource.aws.auroradsql.cluster_id"="<cluster-id>"}))&start=2026-08-23T09:00:00Z&end=2026-08-23T11:00:00Z&step=1m'
{
"status": "success",
"data": {
"resultType": "matrix",
"result": [
{
"metric": {"db.query.normalized_text": "BEGIN"},
"values": [[1787478060.0, "0.03333333333333333"], [1787480340.0, "0.05"]]
},
{
"metric": {"db.query.normalized_text": "COMMIT"},
"values": [[1787478060.0, "0.06666666666666667"], [1787480340.0, "0.06666666666666667"]]
},
{
"metric": {"db.query.normalized_text": "DELETE FROM public.sample_activity"},
"values": [[1787480340.0, "0.016666666666666666"]]
}
]
}
}
AAS was returned for each normalized SQL statement, such as BEGIN, COMMIT, DELETE FROM ..., and INSERT INTO .... The same kind of information as the console's Top SQL tab could also be retrieved via the API.
IAM permissions required to call the PromQL API
To execute PromQL queries, you need both cloudwatch:GetMetricData and cloudwatch:ListMetrics permissions.
Enablement and Cost
In the verification so far, I have not changed any settings on the cluster side. The official documentation also explicitly states that no setup is required.
You don't need to set up DASH. It is automatically enabled for every Aurora DSQL cluster, and per-minute aggregated data is available through Amazon CloudWatch Database Insights and through Prometheus Query Language (PromQL) queries run against CloudWatch OTel metrics at no additional cost.
Pricing is described on the CloudWatch pricing page.
Upto 15 months of per-minute standard database metrics are included at no additional cost.
Querying OpenTelemetry metrics via the PromQL API is charged at $0.01 per million samples scanned. A sample is one data point for one metric series at one timestamp. Queries executed through the CloudWatch console, including dashboards, are free of charge.
Standard metrics are retained for 15 months at no additional charge. As for running queries, those via the console are free, but queries via the PromQL API are charged according to the number of samples scanned.
Summary
Database Insights, now supported by DSQL, is useful for understanding the operational state of a database, just like Database Insights (formerly Performance Insights) for Aurora (RDS).
DASH is enabled without any additional setup. Checking load from the console incurs no additional cost, so if you use Aurora DSQL, please open Database Insights at least once.
What I checked this time was the load during normal operation, with the daily data ingestion running. I did not apply an overload such as a load test. If I get a chance to run a load test on a workload using DSQL, I would like to share the results in a separate article.
