AWS prescriptive-guidance documentation change
Summary
Updated documentation links, fixed URL formatting, removed trailing spaces, and standardized AWS service naming (e.g., 'CloudFormation' to 'AWS CloudFormation'). Also corrected markdown syntax for a GitHub sample link.
Security assessment
Changes are primarily cosmetic and editorial (link corrections, whitespace removal, branding updates). No security vulnerabilities, incidents, or weaknesses are mentioned or addressed. The content still discusses general monitoring best practices without introducing new security features or addressing specific security gaps.
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 b3500eca6..fc458f12b 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 @@ -5 +5 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Designing and implementing logging and monitoring with Amazon CloudWatch ](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Designing and implementing logging and monitoring with Amazon CloudWatch](introduction.html) @@ -19 +19 @@ 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. @@ -23 +23 @@ 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. @@ -31 +31 @@ 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. @@ -35 +35 @@ For more information about this section, see [Creating a CloudWatch alarm based -Application and workload owners should create application-level alarms for workloads that span multiple Regions. We recommend creating separate alarms within each account and Region that your workload is deployed in. You can simplify and automate this process by using account and Region agnostic CloudFormation StackSets and templates to deploy application resources with the required alarms. templateYou can configure the alarm actions to target a common Amazon Simple Notification Service (Amazon SNS) topic, which means the same notification or remediation action is used regardless of the account or Region. +Application and workload owners should create application-level alarms for workloads that span multiple Regions. We recommend creating separate alarms within each account and Region that your workload is deployed in. You can simplify and automate this process by using account and Region agnostic AWS CloudFormation StackSets and templates to deploy application resources with the required alarms. templateYou can configure the alarm actions to target a common Amazon Simple Notification Service (Amazon SNS) topic, which means the same notification or remediation action is used regardless of the account or Region. @@ -37 +37 @@ Application and workload owners should create application-level alarms for workl -In multi-account and multi-Region environments, we recommend that you create aggregated alarms for your accounts and Regions to monitor account and Regional issues by using CloudFormation StackSets and aggregate metrics, such as average `CPUUtilization` across all EC2 instances. +In multi-account and multi-Region environments, we recommend that you create aggregated alarms for your accounts and Regions to monitor account and Regional issues by using AWS CloudFormation StackSets and aggregate metrics, such as average `CPUUtilization` across all EC2 instances. @@ -43 +43 @@ 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 AWS 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.