CloudWatch metrics

  • Latest Dynatrace
  • Explanation
  • Published Sep 26, 2025
  • Preview

Metrics 360°

Dynatrace AWS Cloud Platform Monitoring is ultimately designed to allow the ingestion of any CloudWatch metric from any AWS service (a service that sends metrics to a CloudWatch namespace).

Our metric ingest strategy allows you to quickly onboard with our recommended set of services and metrics.

At the same time, customization using advanced settings is possible during the onboarding process and after.

Metric ingest methods

Dynatrace AWS Cloud Platform Monitoring is designed to support two CloudWatch metrics ingest methods:

  • Poll-based (available in Preview): This is a primary (default) metrics ingest method, where Dynatrace calls the CloudWatch GetMetricData and ListMetrics APIs to validate, poll, and persist metrics.

    Dynatrace authenticates and authorizes by assuming the created IAM monitoring role in the AWS account (cross-account role assumption). The IAM monitoring role is created inside your account during connection creation. The role uses external ID and a trust policy that is de-scoped to Dynatrace account following the AWS security best practices.

    Metric polling is scheduled every 5 minutes, evaluating a 5-minute window with a 7-minute delay. This means that a metric polling job that started at 9:00 AM will evaluate the data points for 8:48 AM-8:53 AM (7-minute delay + a 5-minute window). The evaluation delay is necessary, as CloudWatch is an eventually consistent metrics API, and CloudWatch takes a few minutes to aggregate data points in order to produce statistics.

  • Push-based (not available in Preview): Amazon CloudWatch Metric Streams will be introduced in the future as a secondary metric ingest method. Metric Streams is a good choice if the monitoring use case is (very) latency-sensitive. Additional use cases could be centralized monitoring architectures or organizational policies, which may prefer this mode. In this mode, services and metrics monitoring settings are fully managed by the user using the AWS Console.

    Throughout this document, metric polling features refer only to poll-based ingest method unless stated otherwise.

Metric strategy

Our metric strategy consists of the following key elements.

Native AWS services

A native AWS service is a first-class citizen service across our entire platform.

  • The service is backed by one or more purpose-built entities.
  • The service entity is enriched with rich cloud metadata.
  • The service and its related key cloud resources are represented as nodes and edges in the Dynatrace topology service.
  • Telemetry signals (metrics, logs, events, topology) related to the service resource are designed to be linked to the service entities. Linked telemetry means that a Clouds Clouds resource with its linked telemetry is viewed as a single unified unit in context.
  • Application Load Balancer (ALB)
  • Amazon EC2 (EC2)
  • Amazon Elastic Block Store (EBS)
  • EC2 Auto Scaling
  • Amazon Elastic Container Service (ECS)
  • AWS Lambda
  • Amazon RDS
  • Amazon DynamoDB
  • Amazon Data Firehose
  • Network Load Balancer (NLB)
  • Amazon Route53
  • Amazon S3
  • Amazon Simple Queue Service (SQS)
  • Amazon CloudFront
  • Amazon API Gateway
  • EC2 Auto Scaling
  • Amazon ECS/Managed Scaling
  • Amazon Elastic File system (EFS)
  • Amazon ElastiCache
  • Gateway Load Balancer
  • Amazon MSK
  • Amazon VPC/NAT Gateway
  • AWS Privatelink
  • AWS Privatelink Endpoints
  • Amazon Simple Notification Service (SNS)
  • ECS Container Insights

Default recommended AWS services

Default recommended AWS services represent a logical group of Dynatrace opinionated native AWS services, and their corresponding recommended metrics.

When onboarding an AWS account following the Recommended flow, the essential services are enabled for metric polling by default.

  • Application Load Balancer (ALB)
  • Amazon EC2 (EC2)
  • Amazon Elastic Block Store (EBS)
  • EC2 Auto Scaling
  • Amazon Elastic Container Service (ECS)
  • AWS Lambda
  • Amazon RDS
  • Amazon DynamoDB
  • Amazon Data Firehose
  • Network Load Balancer
  • Amazon Route53
  • Amazon S3
  • Amazon Simple Queue Service
  • Amazon CloudFront

The services list is constantly evaluated based on customer feedback and AWS innovation; we may change the list to reflect user feedback or to keep up with the AWS innovation. Any changes are designed not to introduce breaking changes for exiting AWS connections.

Metric collection sets

A metric collection set (MCS) is a group of metrics assigned to a native service. Once assigned, all metrics in this MCS will be scheduled for polling.

Only a single MCS can be assigned to a service at any given time (1:1).

Metric collection set types

  • Recommended (available in Preview)
    • An immutable list of opinionated Dynatrace metrics list (per cloud native service). An optimal starting point.

To view the most updated list of metrics that the Recommended (formerly known as Essential) MCS will ingest (per AWS Native Service):

  1. Go to Dynatrace Hub Hub.
  2. In search, type preview and select the AWS Cloud Monitoring (Preview) tile.
  3. Scroll down and, in the Feature Sets section, search metrics using this pattern: [Service Name]_essential (for example, s3_essential).
  • Auto-Discovery (available in Preview)
    • All key metrics for a specific AWS service are auto discovered and marked for polling (This MCS has a potential to generate elevated CloudWatch and Dynatrace cost)
  • Recommended+Custom (formerly known as Essential+)
    • All Recommended MCS metrics plus the ability to add specific AWS metrics that are not included in the Recommended MCS

Metrics that are part of any MCS are designed to support our prinicple of signals in context, allowing the following upstream use cases:

  • Clouds Clouds metrics in-context view (view the metrics, related to the AWS resource)
  • Enrichment of those metrics with cloud extended metadata as attributes (aws.account.id, aws.region, aws.tag, aws.tag.TagKeyName:value), allowing advanced filtering use cases

Advanced metric ingest use cases

Any AWS metric

In certain use cases, it might be necessary to choose a fine-grained metrics ingest approach to cover use cases such as:

  • A requirment to ingest only specific metrics for a particular service (example, only two metrics for Amazon EBS are needed)
  • Ingest of any CloudWatch metrics from an AWS service that Dynatrace is yet to have added to its native AWS service list
  • Ingest of CloudWatch metrics that are not representing an AWS Service (for example, AWS/Usage)

In the connection monitoring settings, turn on Ingest any AWS metrics and provide the required inputs.

To determine the namespace and metric names, see the AWS documentation.

Custom (user instrumented) CloudWatch metrics

In certain use cases, it is required to ingest CloudWatch custom metrics instrumented by the AWS SDKs.

In the connection monitoring settings, turn on Ingest custom (user instrumented) metrics and provide the required inputs.

CloudWatch metrics ingested via Ingest any AWS metrics or Ingest custom (user instrumented) metrics:

  • Do not follow the metrics-in-context principle (are not linked to entities, as entities are not created to represent their resources)
  • Will not be visible in Clouds Clouds
  • Will not be visible as nodes nor edges in AWS Topology (those custom Resources are not represented as Dynatrace entities)

However, the following use cases will be supported for those metrics:

  • Depict in custom dashboards
  • Define custom notification alerts based on the metric result

When possible, we highly recommend enabling our native AWS services with our built-in Metrics Collection Sets for metric ingest. They are closely maintained and curated by Dynatrace dedicated Cloud teams to maximize the platform experience.

Limitations

  • During Preview, our native AWS services and metrics list will increment in stages.
  • CloudWatch Metric Streams is not a supported ingest method at this milestone (Preview).
  • Telemetry signals enrichment with metadata (such as AWS tags) is only possible for signals that were successfully linked to an entity (AWS resource).
  • The maximum number of user-provided AWS tags for enrichment is 20.
  • The maximum number of tag-based filtering is up to 5 for include and 5 for exclude.
Related tags
Infrastructure Observability