Do we really need Read/Write IOPS CloudWatch alarms for Aurora MySQL (UAT environment)?

For Aurora MySQL in a UAT environment, IOPS alarms are generally less critical than they would be for standard RDS MySQL instances. This is because Aurora's distributed storage architecture automatically scales I/O capacity as needed, without the fixed IOPS limits that traditional RDS instances have.

Your focus on CPU, FreeableMemory, DB connections, and ReplicaLag alarms is a good approach for monitoring the most critical aspects of your Aurora cluster's health. These metrics directly impact application performance and are more likely to require intervention in a UAT environment.

However, monitoring some I/O-related metrics can still provide value:

1. VolumeReadIOPs can help identify when queries are requesting database pages that aren't in the buffer cache and must be loaded from storage. Spikes in this metric might indicate inefficient queries or opportunities to optimize your buffer cache.

2. If your Aurora MySQL cluster uses parallel query, you might see increased VolumeReadIOPS values, as parallel queries don't use the buffer pool.

For a UAT environment where cost optimization is important, your plan to focus on the core metrics (CPU, memory, connections, and replication) is reasonable. You might also consider adding:

• BufferCacheHitRatio: To monitor how effectively your instance is using its memory
• DatabaseConnections: To track connection usage patterns
• CommitLatency: To monitor transaction performance

Amazon CloudWatch alarms should be configured based on your specific application requirements and historical performance data. For a UAT environment, you can set less aggressive thresholds than you would for production, focusing on detecting significant issues rather than minor fluctuations.
Sources
Amazon CloudWatch metrics for Amazon Aurora - Amazon Aurora
Logging and monitoring in Amazon Aurora - Amazon Aurora
Monitoring Amazon Aurora metrics with Amazon CloudWatch - Amazon Aurora