What Is Aurora Monitoring
Monitoring Amazon Aurora is the practice of collecting, visualizing, and acting upon operational data from your Aurora database clusters. This data spans multiple layers: the database engine itself (MySQL-compatible or PostgreSQL-compatible), the underlying host, network throughput, replication lag for read replicas, and the storage subsystem that Aurora's architecture decouples from compute. Aurora surfaces metrics through several channels: Amazon CloudWatch (both standard and Performance Insights), Enhanced Monitoring (granular OS-level metrics), and the RDS Data API for programmatic inspection. Together these form a comprehensive observability surface that tells you exactly how your database is behaving at any moment.
Key Metric Categories
Metrics fall into four broad buckets:
- Compute metrics – CPU utilization, memory consumption, and DB engine-level counters like connection count or query throughput
- Storage metrics – Aurora's storage subsystem reports volume utilization, read/write IOPS, and latency independent of compute
- Replication metrics – Aurora Replicas expose replication lag (both in time and bytes behind) and replica write throughput
- Transaction and lock metrics – Deadlocks, lock waits, transaction log usage, and commit latency
Why Monitoring Matters
Aurora abstracts away much of the operational heavy lifting—storage scaling, automated backups, and patching—but that abstraction creates a dangerous illusion that everything is self-managing. Without monitoring, you risk:
- Unbounded storage growth – Aurora volumes auto-scale but never shrink; a runaway table bloat can silently increase costs
- Replication lag drift – Read replicas falling behind can cause stale data serving without any visible error
- Connection exhaustion – Hitting the max connections limit causes cascading application failures that are preventable with early alerting
- Performance cliff detection – Gradual degradation (index bloat, query plan regression) needs trend analysis, not just threshold-based alarms
- Cost attribution – I/O charges and instance-hour costs need monitoring to attribute spend per workload or environment
A robust monitoring posture turns these risks into managed, observable signals. The goal is to detect anomalies before users notice, to trend capacity for forecasting, and to have forensic data ready when incidents occur.
Setting Up CloudWatch Metrics for Aurora
Aurora automatically publishes metrics to CloudWatch under the AWS/RDS namespace. These include CPUUtilization, DatabaseConnections, FreeableMemory, ReadIOPS, WriteIOPS, NetworkReceiveThroughput, NetworkTransmitThroughput, and the critical ReplicaLag (reported per replica). You pay nothing extra for these—they're included with the service—but they aggregate at one-minute granularity by default.
Enabling Enhanced Monitoring
Enhanced Monitoring provides per-second OS metrics by running a small agent on the underlying host. It exposes process list details, CPU steal time, memory swap, and disk-level metrics that standard CloudWatch doesn't capture. You enable it per instance via the RDS API, CLI, or console. Here's how to enable it with the AWS CLI when modifying an existing instance:
aws rds modify-db-instance \
--db-instance-identifier my-aurora-instance \
--monitoring-interval 60 \
--monitoring-role-arn arn:aws:iam::123456789012:role/EM_CloudWatch_Role \
--apply-immediatelyThe monitoring interval can be 1, 5, 10, 15, 30, or 60 seconds (lower intervals incur additional CloudWatch Logs costs). The IAM role must have rds:EnhancedMonitoring permissions. Once enabled, metrics appear under the RDS/EnhancedMonitoring log group in CloudWatch Logs as structured JSON blobs.
Enabling Performance Insights
Performance Insights is Amazon's database performance tuning tool that shows query throughput and wait events visualized as a layered graph. It identifies which SQL statements, users, or hosts consume resources. Enable it with:
aws rds modify-db-instance \
--db-instance-identifier my-aurora-instance \
--enable-performance-insights \
--performance-insights-kms-key-id alias/aws/rds \
--performance-insights-retention-period 7 \
--apply-immediatelyPerformance Insights data is stored for 7 days by default (free) or up to 24 months (paid). The KMS key encrypts the sensitive query text; use the default AWS-managed key unless compliance requires a customer-managed key. Once active, query the Performance Insights API to extract top SQL by load:
aws rds describe-db-instances \
--db-instance-identifier my-aurora-instance \
--query "DBInstances[0].PerformanceInsightsEnabled"Building CloudWatch Alarms
Alarms translate metric thresholds into actionable notifications. A well-designed alarm architecture layers severity—warning versus critical—and targets different response channels: Slack, PagerDuty, email, or automated remediation via Lambda.
High CPU Utilization Alarm
CPU spikes can indicate query storms, missing indexes, or workload surges. The alarm below triggers when CPU exceeds 80% for 5 consecutive minutes, with a warning threshold at 65%:
aws cloudwatch put-metric-alarm \
--alarm-name "Aurora-High-CPU-Critical" \
--alarm-description "CPU exceeds 80% for 5 min" \
--namespace "AWS/RDS" \
--metric-name "CPUUtilization" \
--dimensions "Name=DBInstanceIdentifier,Value=my-aurora-instance" \
--statistic "Average" \
--period 300 \
--evaluation-periods 1 \
--datapoints-to-alarm 1 \
--threshold 80 \
--comparison-operator "GreaterThanThreshold" \
--treat-missing-data "missing" \
--alarm-actions "arn:aws:sns:us-east-1:123456789012:ops-critical"Key parameters explained:
--period 300– 5-minute aggregation window smooths transient spikes--evaluation-periods 1– alarm fires after a single violating period--datapoints-to-alarm 1– how many points within the evaluation must breach; M out of N logic--treat-missing-data– set tomissingto hold the current alarm state rather than firing incorrectly
Replication Lag Alarm
For read replicas, replication lag is the most critical signal. Aurora's storage-layer replication is typically sub-second, but engine-level replication (binary log apply) can drift under heavy write loads. This alarm monitors the ReplicaLag metric:
aws cloudwatch put-metric-alarm \
--alarm-name "Aurora-ReplicaLag-Warning" \
--alarm-description "Replica lag exceeds 30 seconds" \
--namespace "AWS/RDS" \
--metric-name "ReplicaLag" \
--dimensions "Name=DBInstanceIdentifier,Value=my-aurora-replica" \
--statistic "Maximum" \
--period 60 \
--evaluation-periods 3 \
--threshold 30 \
--comparison-operator "GreaterThanThreshold" \
--treat-missing-data "notBreaching" \
--alarm-actions "arn:aws:sns:us-east-1:123456789012:ops-warning"Notice --statistic Maximum rather than Average—a brief lag spike is exactly what you want to catch. The notBreaching treatment for missing data avoids false positives during maintenance windows.
Connection Count Alarm
Running out of connections causes immediate application errors. The alarm thresholds should account for your instance class's max_connections limit, which varies with instance size:
aws cloudwatch put-metric-alarm \
--alarm-name "Aurora-Connection-Count-High" \
--namespace "AWS/RDS" \
--metric-name "DatabaseConnections" \
--dimensions "Name=DBInstanceIdentifier,Value=my-aurora-instance" \
--statistic "Average" \
--period 300 \
--evaluation-periods 3 \
--threshold 1500 \
--comparison-operator "GreaterThanThreshold" \
--treat-missing-data "missing" \
--alarm-actions "arn:aws:sns:us-east-1:123456789012:ops-critical"Composite Alarms for Noise Reduction
Individual alarms can generate alert storms during correlated failures. Composite alarms let you combine multiple metrics into a single evaluation—for example, triggering only when both CPU is high and connection count is elevated, indicating a true workload surge rather than a background maintenance task:
aws cloudwatch put-composite-alarm \
--alarm-name "Aurora-Overload-Composite" \
--alarm-description "CPU AND connections both elevated" \
--alarm-rule "ALARM(Aurora-High-CPU-Critical) AND ALARM(Aurora-Connection-Count-High)" \
--alarm-actions "arn:aws:sns:us-east-1:123456789012:ops-critical"Querying Metrics Programmatically
Beyond alarms, you often need to fetch metric time series for dashboards, automation, or cost reporting. The CloudWatch GetMetricData API is the workhorse here.
Fetching CPU Utilization History with AWS CLI
aws cloudwatch get-metric-data \
--metric-data-queries '[
{
"Id": "cpu",
"MetricStat": {
"Metric": {
"Namespace": "AWS/RDS",
"MetricName": "CPUUtilization",
"Dimensions": [
{"Name": "DBInstanceIdentifier", "Value": "my-aurora-instance"}
]
},
"Period": 300,
"Stat": "Average"
},
"ReturnData": true
}
]' \
--start-time "$(date -d '1 hour ago' -u +%Y-%m-%dT%H:%M:%SZ)" \
--end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
--query "MetricDataResults[0].Values" \
--output textPython Boto3 Example: Aggregating Multiple Instances
When you run a cluster with multiple instances (writer plus several replicas), aggregate their metrics to understand total cluster behavior:
import boto3
from datetime import datetime, timedelta
def get_cluster_total_connections(cluster_identifier, minutes=15):
"""Sum DatabaseConnections across all instances in an Aurora cluster."""
rds_client = boto3.client('rds')
cw_client = boto3.client('cloudwatch')
# Discover instances in the cluster
instances = rds_client.describe_db_instances(
Filters=[{
'Name': 'db-cluster-id',
'Values': [cluster_identifier]
}]
)['DBInstances']
instance_ids = [inst['DBInstanceIdentifier'] for inst in instances]
# Build metric queries for each instance
queries = []
for i, instance_id in enumerate(instance_ids):
queries.append({
'Id': f'conn_{i}',
'MetricStat': {
'Metric': {
'Namespace': 'AWS/RDS',
'MetricName': 'DatabaseConnections',
'Dimensions': [
{'Name': 'DBInstanceIdentifier', 'Value': instance_id}
]
},
'Period': 300,
'Stat': 'Average'
},
'ReturnData': True
})
# Single API call for all instances
end_time = datetime.utcnow()
start_time = end_time - timedelta(minutes=minutes)
response = cw_client.get_metric_data(
MetricDataQueries=queries,
StartTime=start_time,
EndTime=end_time
)
# Sum the latest values
total = 0
for result in response['MetricDataResults']:
if result['Values']:
total += result['Values'][-1]
return total
print(get_cluster_total_connections('my-aurora-cluster'))Creating Dashboards
CloudWatch Dashboards provide a drag-and-drop canvas for metric graphs, but programmatic creation ensures consistency across environments and enables infrastructure-as-code management.
Dashboard JSON Structure
A dashboard is a JSON document containing widgets arranged on a grid. Each widget specifies its position, size, and content. The core widget types: metric (time-series graph), alarm (alarm status), text (Markdown annotations), and single-value (latest value display).
Building an Aurora Dashboard with the CLI
aws cloudwatch put-dashboard \
--dashboard-name "Aurora-Cluster-Monitoring" \
--dashboard-body '{
"widgets": [
{
"type": "text",
"x": 0, "y": 0,
"width": 24, "height": 2,
"properties": {
"markdown": "## Aurora Cluster: my-cluster\n**Writer**: my-aurora-instance | **Replicas**: my-aurora-replica-1, my-aurora-replica-2\n\nLast updated: ${datetime}"
}
},
{
"type": "metric",
"x": 0, "y": 2,
"width": 8, "height": 6,
"properties": {
"view": "timeSeries",
"stacked": false,
"title": "CPU Utilization (%)",
"metrics": [
["AWS/RDS", "CPUUtilization", "DBInstanceIdentifier", "my-aurora-instance", {"stat": "Average", "period": 60}],
["AWS/RDS", "CPUUtilization", "DBInstanceIdentifier", "my-aurora-replica-1", {"stat": "Average", "period": 60}],
["AWS/RDS", "CPUUtilization", "DBInstanceIdentifier", "my-aurora-replica-2", {"stat": "Average", "period": 60}]
],
"yAxis": {"left": {"min": 0, "max": 100, "label": "%"}},
"annotations": {
"horizontal": [{"value": 80, "label": "Alarm threshold", "color": "#d13212"}]
}
}
},
{
"type": "metric",
"x": 8, "y": 2,
"width": 8, "height": 6,
"properties": {
"view": "timeSeries",
"stacked": false,
"title": "Database Connections",
"metrics": [
["AWS/RDS", "DatabaseConnections", "DBInstanceIdentifier", "my-aurora-instance", {"stat": "Average", "period": 60}],
["AWS/RDS", "DatabaseConnections", "DBInstanceIdentifier", "my-aurora-replica-1", {"stat": "Average", "period": 60}]
],
"yAxis": {"left": {"min": 0, "label": "Connections"}}
}
},
{
"type": "metric",
"x": 16, "y": 2,
"width": 8, "height": 6,
"properties": {
"view": "timeSeries",
"stacked": false,
"title": "Replication Lag (seconds)",
"metrics": [
["AWS/RDS", "ReplicaLag", "DBInstanceIdentifier", "my-aurora-replica-1", {"stat": "Maximum", "period": 60}],
["AWS/RDS", "ReplicaLag", "DBInstanceIdentifier", "my-aurora-replica-2", {"stat": "Maximum", "period": 60}]
],
"yAxis": {"left": {"min": 0, "label": "Seconds"}},
"annotations": {
"horizontal": [{"value": 30, "label": "Warning", "color": "#ff9900"}]
}
}
},
{
"type": "metric",
"x": 0, "y": 8,
"width": 8, "height": 6,
"properties": {
"view": "timeSeries",
"stacked": false,
"title": "Read/Write IOPS",
"metrics": [
["AWS/RDS", "ReadIOPS", "DBInstanceIdentifier", "my-aurora-instance", {"stat": "Sum", "period": 60}],
["AWS/RDS", "WriteIOPS", "DBInstanceIdentifier", "my-aurora-instance", {"stat": "Sum", "period": 60}]
],
"yAxis": {"left": {"min": 0, "label": "IOPS"}}
}
},
{
"type": "metric",
"x": 8, "y": 8,
"width": 8, "height": 6,
"properties": {
"view": "timeSeries",
"stacked": false,
"title": "Network Throughput (bytes/sec)",
"metrics": [
["AWS/RDS", "NetworkReceiveThroughput", "DBInstanceIdentifier", "my-aurora-instance", {"stat": "Average", "period": 60}],
["AWS/RDS", "NetworkTransmitThroughput", "DBInstanceIdentifier", "my-aurora-instance", {"stat": "Average", "period": 60}]
],
"yAxis": {"left": {"min": 0, "label": "Bytes/sec"}}
}
},
{
"type": "metric",
"x": 16, "y": 8,
"width": 8, "height": 6,
"properties": {
"view": "singleValue",
"title": "Free Memory (GB)",
"metrics": [
["AWS/RDS", "FreeableMemory", "DBInstanceIdentifier", "my-aurora-instance", {"stat": "Average", "period": 300}]
],
"sparkline": true,
"yAxis": {"left": {"min": 0}}
}
},
{
"type": "alarm",
"x": 0, "y": 14,
"width": 24, "height": 4,
"properties": {
"title": "Active Alarms",
"alarms": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:Aurora-High-CPU-Critical",
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:Aurora-ReplicaLag-Warning",
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:Aurora-Connection-Count-High"
]
}
}
]
}'Infrastructure-as-Code with Terraform
Managing dashboards via the console doesn't scale. Here's a Terraform snippet that defines the same dashboard, making it repeatable across environments:
resource "aws_cloudwatch_dashboard" "aurora_cluster" {
dashboard_name = "${var.cluster_identifier}-monitoring"
dashboard_body = jsonencode({
widgets = [
{
type = "text"
x = 0
y = 0
width = 24
height = 2
properties = {
markdown = "## Aurora Cluster: ${var.cluster_identifier}\n\n**Writer**: ${var.writer_instance_id}"
}
},
{
type = "metric"
x = 0
y = 2
width = 12
height = 6
properties = {
view = "timeSeries"
stacked = false
title = "CPU Utilization (%)"
metrics = [
["AWS/RDS", "CPUUtilization", "DBInstanceIdentifier", var.writer_instance_id, { stat = "Average", period = 60 }],
["AWS/RDS", "CPUUtilization", "DBInstanceIdentifier", var.replica_instance_id, { stat = "Average", period = 60 }]
]
yAxis = {
left = { min = 0, max = 100, label = "%" }
}
annotations = {
horizontal = [{ value = 80, label = "Threshold", color = "#d13212" }]
}
}
},
{
type = "metric"
x = 12
y = 2
width = 12
height = 6
properties = {
view = "timeSeries"
stacked = false
title = "Replication Lag (seconds)"
metrics = [
["AWS/RDS", "ReplicaLag", "DBInstanceIdentifier", var.replica_instance_id, { stat = "Maximum", period = 60 }]
]
yAxis = {
left = { min = 0, label = "Seconds" }
}
}
},
{
type = "alarm"
x = 0
y = 8
width = 24
height = 4
properties = {
title = "Active Alarms"
alarms = [
aws_cloudwatch_metric_alarm.high_cpu.arn,
aws_cloudwatch_metric_alarm.replica_lag.arn,
aws_cloudwatch_metric_alarm.connection_count.arn
]
}
}
]
})
}Using Performance Insights for Deep Diagnostics
While CloudWatch metrics tell you that something is wrong, Performance Insights tells you why. It exposes two key views: top SQL by load and active wait events. You query it via the GetResourceMetrics API.
Fetching Top SQL by CPU Load
aws pi get-resource-metrics \
--service-type RDS \
--identifier "db-ANIDFTVKBKFQWSSXGZ5VGVH4ZA" \
--start-time "$(date -d '1 hour ago' -u +%s)" \
--end-time "$(date -u +%s)" \
--period-in-seconds 3600 \
--metric-queries '[
{
"Metric": "db.sql.tokenized.stats.cpu_total",
"GroupBy": {
"Group": "db.sql_tokenized",
"Keys": ["db.sql_tokenized.statement"]
},
"Filter": {
"Key": "db.sql_tokenized.statement",
"Value": "SELECT"
}
}
]' \
--query "MetricResults[0].KeyValues[].[Key, Value]" \
--output text | sort -k2 -nr | head -5This returns the top five tokenized SQL statements consuming CPU in the last hour. The DBA identifier (the long string starting with db-ANID...) is the Performance Insights resource ID, which differs from the instance identifier. You retrieve it with:
aws rds describe-db-instances \
--db-instance-identifier my-aurora-instance \
--query "DBInstances[0].DbiResourceId" \
--output textPython Script: Automated Wait Event Analysis
Wait events reveal where the database engine spends non-CPU time—disk I/O waits, lock contention, network latency. The following script periodically polls Performance Insights and logs the top wait events:
import boto3
import time
from datetime import datetime, timedelta
def poll_top_wait_events(dbi_resource_id, duration_minutes=5, interval_seconds=60):
"""Continuously poll top wait events from Performance Insights."""
pi_client = boto3.client('pi')
while True:
end_time = datetime.utcnow()
start_time = end_time - timedelta(minutes=duration_minutes)
response = pi_client.get_resource_metrics(
ServiceType='RDS',
Identifier=dbi_resource_id,
StartTime=start_time,
EndTime=end_time,
PeriodInSeconds=300,
MetricQueries=[{
'Metric': 'db.wait_event.summary',
'GroupBy': {
'Group': 'db.wait_event',
'Keys': ['db.wait_event.name']
}
}]
)
print(f"\n=== Top Wait Events at {end_time.isoformat()} ===")
for result in response.get('MetricResults', []):
for key_value in result.get('KeyValues', []):
wait_name = key_value.get('Key', 'unknown')
total_time_ms = key_value.get('Value', 0)
print(f" {wait_name}: {total_time_ms:.2f} ms")
time.sleep(interval_seconds)
# Run with your instance's DBI resource ID
poll_top_wait_events('db-ANIDFTVKBKFQWSSXGZ5VGVH4ZA')Custom Metrics and Log-Based Monitoring
Not all signals come from built-in metrics. Aurora writes logs—error logs, slow query logs, general logs—that you can mine for custom metrics using CloudWatch Logs metric filters. This is especially valuable for detecting specific error patterns or tracking application-level queries.
Creating a Metric Filter for Deadlock Events
Deadlocks appear in the MySQL error log or PostgreSQL log as specific messages. You can create a metric filter that counts these occurrences:
aws logs put-metric-filter \
--log-group-name "/aws/rds/instance/my-aurora-instance/error" \
--filter-name "DeadlockCounter" \
--filter-pattern "Deadlock found when trying to get lock" \
--metric-transformations '[
{
"metricName": "AuroraDeadlockCount",
"metricNamespace": "Aurora/Custom",
"metricValue": "1",
"defaultValue": 0
}
]'Now you can alarm on this custom metric just like any CloudWatch metric:
aws cloudwatch put-metric-alarm \
--alarm-name "Aurora-Deadlock-Rate-High" \
--namespace "Aurora/Custom" \
--metric-name "AuroraDeadlockCount" \
--statistic "Sum" \
--period 300 \
--evaluation-periods 1 \
--threshold 5 \
--comparison-operator "GreaterThanThreshold" \
--alarm-actions "arn:aws:sns:us-east-1:123456789012:ops-critical"Slow Query Log Analysis with Metric Filters
For MySQL-compatible Aurora, enable slow query logs and create a metric filter on query execution time:
aws logs put-metric-filter \
--log-group-name "/aws/rds/instance/my-aurora-instance/slowquery" \
--filter-name "SlowQueryThresholdExceeded" \
--filter-pattern "[query_time>=5.0]" \
--metric-transformations '[
{
"metricName": "SlowQueriesAbove5s",
"metricNamespace": "Aurora/Custom",
"metricValue": "1",
"defaultValue": 0
}
]'This assumes your slow query log captures execution times. You may need to adjust the filter pattern based on the log format (MySQL vs. MariaDB audit plugin format). Test patterns with aws logs filter-log-events before committing to a metric filter.
Best Practices for Aurora Monitoring
1. Layer Your Alarms by Severity and Response Path
A three-tier alarm model works well:
- Warning (Tier 1) – Slack or email notification for on-call awareness; e.g., CPU > 65% for 10 minutes
- Critical (Tier 2) – PagerDuty or Opsgenie alert; e.g., replication lag > 60 seconds, connection count > 90% of max
- Automated (Tier 3) – Lambda-based remediation; e.g., auto-scaling read replicas via a Lambda that modifies the cluster
2. Monitor the Storage Layer Separately
Aurora's storage isn't coupled to compute. Use the VolumeBytesUsed and VolumeReadIOPs / VolumeWriteIOPs metrics (under AWS/RDS with the cluster identifier, not instance identifier) to track storage growth. Storage charges are a common cost surprise—trend this metric monthly and set a forecast alarm:
aws cloudwatch put-metric-alarm \
--alarm-name "Aurora-Storage-Growth-Forecast" \
--namespace "AWS/RDS" \
--metric-name "VolumeBytesUsed" \
--dimensions "Name=DBClusterIdentifier,Value=my-aurora-cluster" \
--statistic "Average" \
--period 86400 \
--evaluation-periods 1 \
--threshold 5000000000000 \
--comparison-operator "GreaterThanThreshold" \
--treat-missing-data "missing" \
--alarm-actions "arn:aws:sns:us-east-1:123456789012:ops-warning"3. Use Composite Alarms to Reduce Noise
Individual metric alarms fire independently. During a known maintenance window or deployment, you might see CPU, connection, and IOPS alarms all trigger simultaneously. Composite alarms that combine conditions with AND logic reduce alert fatigue. For example, alert on high CPU only when both CPU > 80% and write IOPS are above baseline, indicating real workload rather than background vacuuming.
4. Version-Control Your Dashboard Definitions
Store dashboard JSON or Terraform/CDK definitions in the same repository as your application code. This ensures dashboards evolve with your schema and workload. Use CI/CD to deploy dashboard updates alongside application changes. A dashboard that's manually edited in the console drifts and becomes stale.
5. Implement Cross-Account Metric Collection
In multi-account AWS organizations, centralize Aurora metrics into a monitoring account using cross-account CloudWatch subscriptions or by pushing custom metrics via PutMetricData with a cross-account IAM role. This gives your central observability team a single pane of glass without bouncing between accounts.
6. Set Up Anomaly Detection on Key Metrics
Static thresholds work poorly for workloads with diurnal patterns. CloudWatch Anomaly Detection learns the metric's baseline and alerts on deviations. Enable it on DatabaseConnections and WriteIOPS:
aws cloudwatch put-anomaly-detector \
--namespace "AWS/RDS" \
--metric-name "DatabaseConnections" \
--dimensions "Name=DBInstanceIdentifier,Value=my-aurora-instance" \
--stat "Average" \
--configuration '{
"ExcludedTimeRanges": [],
"AnomalyDetectorType": "HIGHER_THAN_EXPECTED"
}'Then create an anomaly-based alarm that triggers when the metric exceeds two standard deviations above the learned band.
7. Correlate Application and Database Metrics
The database doesn't exist in isolation. Instrument your application to emit custom metrics (request latency, error rate) and plot them alongside Aurora metrics on the same dashboard. When application latency spikes coincide with increased ReplicaLag or WriteIOPS, you can pinpoint root cause in seconds rather than hours.
8. Retain Performance Insights Data for Longitudinal Analysis
The free 7-day retention for Performance Insights is insufficient for month-over-month trend analysis. Pay for 1–2 months of retention (the cost is modest—typically under $10/month for most workloads) and build weekly review rituals where DBAs examine top SQL and wait event trends. This proactive approach catches query plan regressions before they become outages.
Conclusion
Monitoring Aurora effectively means moving beyond default CloudWatch metrics into a layered observability strategy. Enable Enhanced Monitoring for OS-level granularity, activate Performance Insights for query-level forensics, and build alarms that reflect your actual SLOs rather than arbitrary thresholds. Treat dashboards as code—version them, deploy them, and iterate on them. The goal is not to collect every possible metric but to surface the signals that matter: the ones that predict capacity exhaustion, replication drift, or query regression before they impact users. With the practical CLI examples, Terraform snippets, and Python scripts covered here, you have the building blocks to instrument any Aurora deployment for reliability, cost awareness, and rapid incident response.