Amazon CloudWatch FAQs

Q: What is Amazon CloudWatch Contributor Insights?

Amazon CloudWatch now includes Contributor Insights, which analyzes time-series data to provide a view of the top contributors influencing system performance. Once set up, Contributor Insights runs continuously without needing additional user intervention. This helps developers and operators more quickly isolate, diagnose, and remediate issues during an operational event.

Q: How can I get started with CloudWatch Contributor Insights?

It is easy to get started with Contributor Insights. In the CloudWatch console, go to Contributor Insights in the navigation pane to create a Contributor Insights rule. You can also enable Contributor Insights using the Amazon CLI, Amazon SDKs, or Amazon CloudFormation templates. To learn more, please visit the documentation on CloudWatch Contributor Insights.

Q: What is CloudWatch Lambda Insights?

CloudWatch Lambda Insights is a feature for monitoring, troubleshooting, and optimizing the performance and cost of your Lambda functions. Lambda Insights simplifies the isolation and analysis of performance issues impacting your Lambda environments. DevOps and systems engineers have access to automatic dashboards in the CloudWatch console, giving them end-to-end operational visibility of metrics, logs, and traces summarizing the performance and health of their Amazon Lambda functions.

Q: How can I get started with CloudWatch Lambda Insights?

You can get started collecting detailed performance metrics, logs, and metadata from your Lambda functions by following these steps in the CloudWatch Lambda Insights documentation.

Q: How is CloudWatch Lambda Insights priced?

CloudWatch Lambda Insights automatically collects custom metrics from performance events ingested as CloudWatch logs from your Lambda functions. More details on pricing is available on the CloudWatch pricing page.

Q: What types of CloudWatch Alarms can be created?

You can create an alarm to monitor any Amazon CloudWatch metric in your account. For example, you can create alarms on an Amazon EC2 instance CPU utilization, Amazon ELB request latency, Amazon DynamoDB table throughput, Amazon SQS queue length, or even the charges on your Amazon Web Services bill.

You can also create an alarm on custom metrics that are specific to your custom applications or infrastructure. If the custom metric is a high-resolution metric, you have the option of creating high-resolution alarms that alert as soon as 10-second or 30-second periods.

With composite alarms, you can combine multiple alarms into alarm hierarchies. This reduces alarm noise by triggering just once when multiple alarms fire at the same time. You can provide an overall state for a grouping of resources like an application, Amazon Web Services Region, or Availability Zone.

Please reference the CloudWatch pricing page to learn more.

Q: What actions can I take from a CloudWatch Alarm?

When you create an alarm, you can configure it to perform one or more automated actions when the metric you chose to monitor exceeds a threshold you define. For example, you can set an alarm that sends you an email, publishes to an SQS queue, stops or terminates an Amazon EC2 instance, or executes an Auto Scaling policy. Since Amazon CloudWatch alarms are integrated with Amazon Simple Notification Service, you can also use any notification type supported by SNS. You can use the Amazon Web Services Systems Manager OpsCenter action to automatically create an OpsItem when an alarm enters the ALARM state. This helps you to quickly diagnose and remediate issues with Amazon Web Services resources from a single console.

Q: My CloudWatch Alarm is constantly in the Alarm state, what did I do wrong?

Alarms continue to evaluate metrics against your chosen threshold, even after they have already triggered. This allows you to view its current up-to-date state at any time. You may notice that one of your alarms stays in the ALARM state for a long time. If your metric value is still in breach of your threshold, the alarm will remain in the ALARM state until it no longer breaches the threshold. This is normal behavior. If you want your alarm to treat this new level as OK, you can adjust the alarm threshold accordingly.

Q: How long can I view my Alarm history?

Alarm history is available for 14 days. To view your alarm history, log in to CloudWatch in the Amazon Web Services Management Console, choose Alarms from the menu at left, select your alarm, and click the History tab in the lower panel. There you will find a history of any state changes to the alarm as well as any modifications to the alarm configuration.

Q: What is CloudWatch Metric Streams?

CloudWatch Metric Streams is a feature that enables you to continuously stream CloudWatch metrics to a destination of your choice with minimal setup and configuration. It is a fully managed solution, and doesn’t require you to write any code or maintain any infrastructure. With a few clicks, you can configure a metric stream to destinations like Amazon Simple Storage Service (S3). You can also send your metrics to a selection of Amazon Web Services Partner solutions to keep your operational dashboards up to date.

Q: Why should I use CloudWatch Metric Streams?

Metric Streams provides an alternative way of obtaining metrics data from CloudWatch without the need to poll APIs. You can create a metric stream with just a few clicks, and your metrics data will start to flow to your destination. You can easily direct your metrics to your data lake on Amazon Web Services such as on Amazon S3, and start analyzing usage or performance with tools such as Amazon Athena. Metrics Streams also makes it easier to send CloudWatch metrics to Amazon Web Services Partner solutions using an Amazon Kinesis Data Firehose HTTP endpoint. You can create a continuous, scalable stream including the most up-to-date CloudWatch metrics data to power dashboards, alarms, and other tools that rely on accurate and timely metric data.

Q: How can I create and manage CloudWatch Metric Streams?

You can create and manage Metric Streams through the CloudWatch Console or programmatically through the CloudWatch API, SDK, CLI, or Amazon CloudFormation to provision and configure Metric Streams. For more information, see the documentation on CloudWatch Metric Streams.

Q: Can I manage metrics to be included in my CloudWatch Metric Stream?

Yes. It is possible to choose to send all metrics by default, or create filter rules to include and exclude groups of metrics defined by namespace. Metric Streams automatically detects new metrics matching filter rules and includes metric updates in the stream. When resources are terminated, Metric Streams will automatically stop sending updates for the inactive metrics.

Q: What formats does CloudWatch Metric Streams support?

Metric Streams can output in either OpenTelemetry or JSON format. You can select the output format when creating or managing metric streams.

Q: Can I monitor the cost and volume of data delivered by CloudWatch Metric Streams?

Yes. You can visit the monitoring section of the Metric Streams console page. You will see automatic dashboards for the volume of metric updates over time. These metrics are also available under the Amazon CloudWatch namespace and can be used to create alarms to send notifications in the case of an unusual spike in volume.

Q: What is cross-account observability in Amazon CloudWatch?

Cross-account observability in Amazon CloudWatch lets you monitor and troubleshoot applications that span across multiple accounts within a region. Using cross-account observability, you can seamlessly search, visualize, and analyze your metrics, logs, and traces, without having to worry about account boundaries. You can start with an aggregated cross-account view of your application to visually identify the resources exhibiting errors and dive deep into correlated traces, metrics, and logs to root cause the issue. The seamless cross-account data access and navigation enabled by cross-account monitoring helps you reduce the manual effort required to troubleshoot issues and save valuable time in resolution. Cross-account observability is an addition to CloudWatch’s unified observability capability.

Q: How do I get started with cross-account observability?

Cross-account observability introduces two new account concepts. “Monitoring account” is a central Amazon Web Services account that can view and interact with observability data generated across other accounts. A “source account” is an individual Amazon Web Services account that generates observability data for the resources that reside in it. Once you identify your monitoring and source accounts, you complete your cross-account monitoring configuration by selecting which telemetry data to share with your monitoring account. Within minutes, you can easily setup central monitoring accounts from which you have a complete view of the health and performance of your applications deployed across many related accounts or an entire Amazon organization. With cross-account observability in CloudWatch, you can get a birds-eye view of your cross-application dependencies that can impact service availability, and you can pinpoint issues proactively and troubleshoot with reduced mean time to resolution.

Q: What CloudWatch monitoring features can I use across multiple Amazon Web Services accounts?

Using cross-account observability, you can search for log groups stored across multiple accounts from a central view, run cross-account Logs Insights queries, and create Contributor Insights rules across accounts to identify top-N contributors generating log entries. You can use metrics search to visualize metrics from many accounts in a consolidated view, create alarms that evaluate metrics from other accounts to be notified of anomalies and trending issues, and visualize them on centralized dashboards. You can also use this capability to set up a single, cross-account metric stream to include metrics that span multiple Amazon accounts within an Amazon Web Services Region. With cross-account observability, you can also view an interactive map of your cross-account applications using ServiceLens with one-click drill downs to relevant metrics, logs, and traces.

Q: Can I still use CloudWatch cross-account, cross-Region features on my console?

Both cross-account monitoring in CloudWatch and the cross-account, cross-Region features will be available on the CloudWatch console. The cross-account, cross-Region drop-down menus will be removed from the console when you set up cross-account observability in CloudWatch. Note that the cross-account observability experience in CloudWatch is available in one Region at a time. The cross-account, cross-Region feature allows access to organization-wide telemetry through IAM roles. Cross-account observability in CloudWatch uses the Observability Access Manager API to define access policies. Learn more in our documentation.