AWS Security ChangesHomeSearch

AWS prescriptive-guidance documentation change

Service: prescriptive-guidance · 2025-11-22 · Documentation low

File: prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/alarming-options-cloudwatch.md

Summary

Fixed URL formatting by adding double slashes in documentation links

Security assessment

The changes only correct URL syntax (adding missing slashes in paths) without altering security-related content. No evidence of addressing vulnerabilities or security incidents. The modifications are purely technical corrections to documentation links.

Diff

diff --git a/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/alarming-options-cloudwatch.md b/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/alarming-options-cloudwatch.md
index e9584389f..ac54f34b8 100644
--- a//prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/alarming-options-cloudwatch.md
+++ b//prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/alarming-options-cloudwatch.md
@@ -17 +17 @@ You should also consider how logging and monitoring data is correlated so that y
-You can use [CloudWatch alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) to reduce manual monitoring in your workloads or applications. You should begin by reviewing the metrics that you are capturing for each workload component and determine the appropriate thresholds for each metric. Make sure that you identify which team members must be notified when a threshold is breached. You should establish and target distribution groups, rather than individual team members. 
+You can use [CloudWatch alarms](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) to reduce manual monitoring in your workloads or applications. You should begin by reviewing the metrics that you are capturing for each workload component and determine the appropriate thresholds for each metric. Make sure that you identify which team members must be notified when a threshold is breached. You should establish and target distribution groups, rather than individual team members. 
@@ -21 +21 @@ CloudWatch alarms can integrate with your service management solution to automat
-You can also create multiple alarms for the same metric that have different thresholds and evaluation periods, which helps establish an escalation process. For example, if you have a `OrderQueueDepth` metric that tracks customer orders, you might define a lower threshold over a short one-minute average period that notifies application team members by email or [Slack](https://docs.aws.amazon.com/chatbot/latest/adminguide/related-services.html#cloudwatch). You can also define another alarm for the same metric over a longer 15-minute period at the same threshold and that pages, emails, and notifies the application team and application team's lead. Finally, you can define a third alarm for a hard average threshold over a 30-minute period that notifies upper-management and notifies all team members previously notified. Creating multiple alarms helps you take different actions for different conditions. You can begin with a simple notification process and then adjust and improve it as required.
+You can also create multiple alarms for the same metric that have different thresholds and evaluation periods, which helps establish an escalation process. For example, if you have a `OrderQueueDepth` metric that tracks customer orders, you might define a lower threshold over a short one-minute average period that notifies application team members by email or [Slack](https://docs.aws.amazon.com//chatbot/latest/adminguide/related-services.html#cloudwatch). You can also define another alarm for the same metric over a longer 15-minute period at the same threshold and that pages, emails, and notifies the application team and application team's lead. Finally, you can define a third alarm for a hard average threshold over a 30-minute period that notifies upper-management and notifies all team members previously notified. Creating multiple alarms helps you take different actions for different conditions. You can begin with a simple notification process and then adjust and improve it as required.
@@ -29 +29 @@ For example, you can enable anomaly detection for the `CPUUtilization` metric an
-For more information about this section, see [Creating a CloudWatch alarm based on anomaly detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html) in the CloudWatch documentation.
+For more information about this section, see [Creating a CloudWatch alarm based on anomaly detection](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html) in the CloudWatch documentation.
@@ -41 +41 @@ You should also consider creating standard alarms for each workload that is conf
-Creating a standard set of alarms for your EC2 instances can be time consuming, inconsistent, and error prone. You can accelerate the alarm creation process by using the [ amazon-cloudwatch-auto-alarms](https://github.com/aws-samples/amazon-cloudwatch-auto-alarms) solution to automatically create a standard set of CloudWatch alarms for your EC2 instances and create custom alarms based on EC2 instance tags. The solution removes the need to manually create standard alarms and can be useful during a large-scale migration of EC2 instances that uses tools such as CloudEndure. You can also deploy this solution with CloudFormation StackSets to support multiple Regions and accounts. For more information, see [Use tags to create and maintain Amazon CloudWatch alarms for Amazon EC2 instances](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/) on the AWS Blog.
+Creating a standard set of alarms for your EC2 instances can be time consuming, inconsistent, and error prone. You can accelerate the alarm creation process by using the [ amazon-cloudwatch-auto-alarms](https://github.com/aws-samples/amazon-cloudwatch-auto-alarms) solution to automatically create a standard set of CloudWatch alarms for your EC2 instances and create custom alarms based on EC2 instance tags. The solution removes the need to manually create standard alarms and can be useful during a large-scale migration of EC2 instances that uses tools such as CloudEndure. You can also deploy this solution with CloudFormation StackSets to support multiple Regions and accounts. For more information, see [Use tags to create and maintain Amazon CloudWatch alarms for Amazon EC2 instances](https://aws.amazon.com//blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/) on the AWS Blog.