This alert aims to monitor and manage the CPU utilization of Amazon RDS instances to prevent performance degradation and potential service disruption caused by high CPU usage. The alert is activated when the average CPU utilization of an RDS instance exceeds 90% over a specified period. High CPU utilization may indicate that the database instance is under heavy load, possibly due to increased query volume, inefficient queries, or insufficient instance resources. Consistently high CPU usage can lead to slower response times and impact database reliability. Customization Guidance: Threshold: The default threshold is set at 90% CPU utilization. Adjust this threshold lower to provide earlier warnings or higher if the instance handles brief spikes well. Monitoring Period: Consider the normal operation patterns of your RDS instance when setting the monitoring period. Shorter periods may be sensitive to spikes that are normal in regular operation, while longer periods may delay necessary responses. Instance Specificity: Tailor alerts for different instances based on their roles and workload characteristics. Critical production databases might require more stringent monitoring compared to development environments. Notification Frequency: Consider the frequency of this alert to optimize the balance between responsiveness and noise. Adjust according to the criticality of the instances’s performance and uninterrupted operation. Action: Upon triggering, review recent activities and query performances on the RDS instance. Identify inefficient queries or unusual loads that could be optimized. Consider scaling up the instance or adding read replicas to distribute the workload if high CPU usage persists.

This alert is designed to monitor the available memory of an Amazon RDS instance to prevent performance issues or potential outages caused by low memory conditions. The alert is activated when the available memory of the RDS instance drops below 2GB for more than 1 minute. Sustained low memory availability can indicate memory leaks, inefficient memory usage, or inadequate instance sizing. This condition can lead to increased disk I/O as swap usage rises, which in turn can degrade database performance and response times. Customization Guidance: Threshold: The default threshold is set at 2GB of available memory. Depending on the database size and workload, you might adjust this threshold either upward for smaller databases or downward for larger, more memory-intensive databases. Monitoring Period: A 1-minute period is the default for evaluating this condition. If your database experiences frequent, brief dips in memory that do not impact performance, consider extending this period to avoid unnecessary alerts. Instance Specificity: Configure this alert according to the criticality and typical memory usage patterns of each database instance. High-priority instances, particularly those handling critical workloads, may require more aggressive monitoring. Notification Frequency: Consider the frequency of this alert to optimize the balance between responsiveness and noise. Adjust according to the criticality of the instances’s high performance. Action: Should this alert trigger, immediately check for processes or queries that are consuming excessive memory. Review query performance and optimizations, and assess whether the instance needs scaling or if specific queries need to be optimized. Additionally, check for any memory leaks or other application issues that may be affecting memory usage.

This alert is designed to monitor the read latency of an Amazon RDS instance, ensuring that database read operations meet performance expectations and do not negatively impact application responsiveness. The alert is activated when the read latency exceeds 20 milliseconds for a continuous period of 10 minutes. Excessive read latency can indicate issues such as resource contention, suboptimal query performance, or hardware limitations. Prolonged high latency can degrade user experience and reduce application efficiency. Customization Guidance: Threshold: The default threshold is set at 20 milliseconds of read latency. Adjust this threshold based on the performance requirements of your application and historical latency metrics. For highly sensitive applications, a lower threshold may be necessary. Monitoring Period: The default monitoring period is 10 minutes. This period can be adjusted to be shorter if early detection of spikes is critical, or longer for a more averaged view that reduces alert noise from transient spikes. Specificity: Consider setting up different alerts for different types of read operations or tables that are known to be performance-critical or have different performance characteristics. Notification Frequency: Consider the frequency of this alert to optimize the balance between responsiveness and noise. Adjust according to the criticality of the application(s) supported. Action: If this alert triggers, review the performance metrics and logs for the RDS instance to identify slow queries or table scans that could be contributing to high latency. Investigate whether increasing IOPS (Input/Output Operations Per Second) or upgrading instance types might alleviate the latency issues. Additionally, consider optimizing indexes and query performance as needed to reduce read latency.

This alert is aimed at ensuring that the write operations on Amazon RDS instances perform within acceptable latency thresholds to maintain optimal application performance and database integrity. The alert is activated when write latency exceeds 20 milliseconds for a continuous period of 10 minutes. Elevated write latency can indicate bottlenecks in data processing, insufficient database resources, or hardware constraints. Persistent high write latency is particularly concerning as it can lead to data processing delays, transaction log buildups, and potential application timeouts. Customization Guidance: Threshold: The default threshold is set at 20 milliseconds. Depending on your specific application needs and past performance data, this threshold may need adjustment. Applications requiring high transaction rates might need a lower threshold to detect issues earlier. Monitoring Period: A monitoring period of 10 minutes helps filter out transient spikes and focus on sustained latency issues. Adjust this period based on the criticality of write operations and the operational dynamics of your system. Instance Specificity: Tailor alerts for different RDS instances based on their roles in your infrastructure. Critical instances handling high-stakes transactions may warrant more stringent monitoring. Notification Frequency: Consider the frequency of this alert to optimize the balance between responsiveness and noise. Adjust according to the criticality of the application(s) supported. Action: Upon triggering of this alert, immediate actions include reviewing recent database activity for heavy write operations or locking issues. Check for inadequate provisioning of IOPS and consider scaling up resources or optimizing database configurations. Regularly review query performance and indexing strategies to ensure efficient write operations.

This alert is designed to monitor the network receive throughput of an Amazon RDS instance to identify potential communication issues or an unexpected lack of incoming traffic, which could indicate a problem with the network or the applications utilizing the database. The alert is activated when the network receive throughput of the RDS instance remains consistently at zero for a specified duration. A network receive throughput of zero can indicate that the RDS instance is not receiving any data. This situation could be caused by network configuration issues, firewall rules blocking traffic, or simply because no client applications are currently sending data to the database. Customization Guidance: Threshold and Duration: While the threshold for this alert is set at zero throughput, the duration should be carefully chosen based on typical application usage patterns. A prolonged period with zero throughput, such as 5 minutes or more, may be used to avoid false positives during normal brief idle periods. Instance Specificity: Customize this alert for different RDS instances based on their expected traffic patterns. Instances expected to have constant communication might need more sensitive settings. Alert Severity: Determine the severity of alerts based on the criticality of the instance in your infrastructure. High-priority instances might require immediate attention, while lower-priority instances might only need monitoring. Notification Frequency: Consider the frequency of this alert to optimize the balance between responsiveness and noise. Adjust according to criticality of the instances’s high performance and the criticality of the application(s) supported. Action: Upon triggering this alert, first verify network configurations and firewall settings to ensure they are not blocking incoming connections. Check if client applications are operational and configured correctly to connect to the RDS instance. If the issue persists, consider troubleshooting potential AWS network issues or contacting AWS Support for further assistance.

This alert is intended to monitor the network transmit throughput of an Amazon RDS instance to detect and address potential communication issues or an absence of outgoing traffic, which could impact application performance and data integrity. The alert is activated when the network transmit throughput of the RDS instance remains consistently at zero for a predefined duration. A consistent zero in network transmit throughput indicates that the RDS instance is not sending any data. This could be due to a lack of demand from connected applications, network configuration issues, or a failure in the database engine or related services. Customization Guidance: Threshold and Duration: The threshold for this alert is zero throughput. Choose an appropriate duration that reflects normal application behavior to prevent false alarms. For instances typically involved in constant data transmission, a duration as short as a few minutes may be significant. Instance Specificity: Tailor this alert to the operational characteristics of each RDS instance. For instances supporting critical applications where constant data output is expected, more aggressive monitoring is necessary. Alert Severity: Adjust the alert severity based on the role of the RDS instance within your infrastructure. High-priority instances, essential for business operations, should trigger high-severity alerts to prompt immediate investigation. Notification Frequency: Consider the frequency of this alert to optimize the balance between responsiveness and noise. Adjust according to criticality of the instances’s high performance and the criticality of the application(s) supported. Action: Should this alert trigger, begin by examining the network configurations and firewall settings to ensure that outgoing connections are not inadvertently blocked. Review application logs and metrics to verify that they are active and attempting to send data. If the configurations and applications appear normal, further investigation into the RDS instance’s health and operational logs may be necessary. Contact AWS Support if the issue appears to be related to AWS infrastructure.