Ingest AWS CloudWatch Metrics into Dynatrace (2026)

AWS CloudWatch metrics can be ingested into Dynatrace, but the real magic is how Dynatrace transforms those raw metrics into actionable insights by correlating them with your application topology and performance.

Let’s see this in action. Imagine you have an EC2 instance running a web server.

// Example CloudWatch Metric (conceptual)
{
  "Namespace": "AWS/EC2",
  "MetricName": "CPUUtilization",
  "Dimensions": [
    {
      "Name": "InstanceId",
      "Value": "i-0123456789abcdef0"
    }
  ],
  "Value": 75.5,
  "Unit": "Percent"
}

When Dynatrace ingests this, it doesn’t just show you a graph of CPU utilization. It links that i-0123456789abcdef0 to the specific EC2 instance entity within Dynatrace, which is then tied to the webserver service running on it, which is part of your production-environment.

Here’s how the ingestion typically works:

1. Dynatrace AWS Integration: You configure Dynatrace to connect to your AWS account. This is usually done via IAM roles or access keys. The integration allows Dynatrace to poll AWS services for metrics and configuration data.
2. CloudWatch Metric Streams (Recommended): For near real-time ingestion, Dynatrace leverages CloudWatch Metric Streams. You create a Metric Stream in CloudWatch that pushes metric data in near real-time to an SQS queue or Kinesis Firehose. Dynatrace then consumes from this stream.
3. API Polling (Fallback/Supplement): Dynatrace also polls CloudWatch APIs directly for metrics that aren’t available via streaming or for specific historical data.

The problem this solves is the "metric silo." CloudWatch has a wealth of operational data, but without context, it’s just numbers. Dynatrace’s value proposition is bringing those numbers into the context of your running applications. You can then set up alerts in Dynatrace that trigger not just on a raw CPU percentage, but on a CPU percentage for a specific instance that is also experiencing high network latency and is part of a critical user-facing service.

Here are the key levers you control:

• Metric Selection: You choose which CloudWatch namespaces and metric names Dynatrace should ingest. This is done within the Dynatrace UI under Settings > Cloud and Edge > AWS > Metrics. You can filter by namespace, metric name, and even dimensions. For example, you might only want CPUUtilization and NetworkIn from AWS/EC2, but not every single metric AWS offers.
• Ingestion Frequency: While Metric Streams are near real-time, the API polling interval can be configured, impacting how quickly Dynatrace picks up changes.
• Dimension Mapping: Dynatrace uses dimensions to identify and correlate metrics with specific entities. For instance, the InstanceId dimension from AWS/EC2 metrics is crucial for linking the metric to the correct EC2 instance entity in Dynatrace. You can influence how Dynatrace interprets these dimensions to ensure accurate entity mapping.
• Alerting Profiles: Once metrics are in Dynatrace, you use these to define alerting conditions. You can combine CloudWatch metrics with Dynatrace’s own metrics (like request errors or response times) for more sophisticated alerts. For example, "Alert if CPUUtilization > 80% AND aws.sqs.messages_visible > 100 for the SQS queue processing these requests."

The power comes from Dynatrace’s Smartscape topology, which automatically discovers and maps your AWS resources. When a CloudWatch metric arrives, Dynatrace looks up the corresponding entity (e.g., an EC2 instance, an RDS database, an S3 bucket) in its Smartscape. If that entity is already part of a discovered service or process, the metric is automatically associated with that higher-level construct. This means you don’t manually tag every metric to a service; the association happens organically based on the topology discovered by Dynatrace.

A common pitfall is misunderstanding how Dynatrace aggregates and displays metrics. While CloudWatch might store raw data points at 1-minute intervals, Dynatrace often processes and stores these at higher granularities (e.g., 10-second for certain metrics, 1-minute for others) and displays them aggregated over longer periods in graphs. You can, however, drill down to see finer-grained data if it’s available and configured for ingestion. It’s not just about getting the data in, but how Dynatrace intelligently uses it.

The next logical step after ingesting metrics is to leverage Dynatrace’s AI, Davis®, to automatically detect anomalies within these ingested metrics and correlate them with other performance indicators.