CloudWatch metrics

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

Dynatrace AWS Cloud Platform Monitoring allows the ingestion of any CloudWatch metric from any AWS 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.

Ingest methods

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

API polling (poll-based)

This is a default metric ingest method, where Dynatrace calls the CloudWatch ListMetrics and GetMetricData 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 an external ID and a trust policy that is descoped to the Dynatrace account following the AWS security best practices.

Poller scheduling

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 (a 7-minute delay + a 5-minute window). The evaluation delay is necessary, as CloudWatch is an eventually consistent metrics API, and it takes a few minutes to aggregate data points in order to produce statistics.

Poller architecture

The Dynatrace metric poller was efficiently designed to poll metrics in the following two stages:

  • After a metric list is compiled, the poller removes duplicate metrics from the list.

  • After the list of unique metrics is ready for polling, it calls the *ListMetrics* API. Only metrics returning correctly are considered for polling.

To minimize calls to the *GetMetrics* API, *GetMetrics* is called only if metrics exist.

Streaming (push-based) (coming soon)

Amazon CloudWatch Metric Streams will be introduced in the future as a secondary metric ingest method. Choose the Metric Streams method if your monitoring use case is very sensitive to latency. Additional use cases could be centralized monitoring architectures or organizational policies, which may prefer this mode.

In this mode, service and metric monitoring settings are fully managed by the user using the AWS Console.

Metric strategy

Our metric strategy consists of a few key elements.

Native AWS services

The Dynatrace 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, and topology) related to the service resource are designed to be linked to the service entities.

    "Linked" means that a Clouds Clouds resource with its linked telemetry is viewed as a single unified unit in context.

See the list of native AWS services supported in Preview
  • 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
  • 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

The 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 following services are enabled for metric polling by default.

See the current list of native essential AWS services supported in Preview
  • 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 Simple Storage Service (S3)
  • Amazon Simple Queue Service (SQS)
  • Amazon CloudFront

The recommended services list is constantly evaluated based on customer feedback and AWS innovation; we may change the list to reflect user feedback or to keep pace with AWS innovation. Any changes are designed not to introduce breaking changes for existing 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.

Metric collection set types

  • Recommended

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

  • Recommended+Custom

    • All Recommended MCS metrics plus the ability to add specific (user-defined) AWS metrics that are not included in the Recommended set type.

  • Auto-Discovery

    • 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.

Browse the detailed, dynamic, auto-generated native supported AWS services and their metric collection sets (including the metrics and dimensions lists).

Metrics that are part of any MCS are designed to support our signals-in-context principle, 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 Dynatrace Platform use-cases such as:

    • Dashboard with Metrics/Logs filtered by any support attribute as dimension (AWS Tags, AWS Account ID)
    • Linked Metrics Logs can be viewed in context to their corresponding AWS Resource (Entity, Smartscape on Grail Node) using the Clouds App

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 requirement to ingest only specific metrics for a particular service (example, only two metrics for Amazon EBS are required)
  • 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 associated with 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)
  • Will not be visible in Clouds Clouds
  • Will not be visible as nodes nor edges in AWS Topology

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

  • 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