CloudWatch metrics

  • Latest Dynatrace
  • Explanation
  • Published Sep 26, 2025

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

CloudWatch metric concepts

Native AWS services

A 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's AWS resources are designed to be linked to the respected Dynatrace 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
  • Amazon API Gateway
  • Amazon AppStream 2.0
  • Amazon Athena
  • Amazon Bedrock Agents
  • Amazon Bedrock Guardrails
  • Amazon CloudFront
  • Amazon CloudWatch Container Insights
  • Amazon CloudWatch Logs
  • Amazon Cognito
  • Amazon Connect
  • Amazon DocumentDB
  • Amazon DynamoDB
  • Amazon DynamoDB Accelerator (DAX)
  • Amazon EBS (Elastic Block Store)
  • Amazon EC2 (Elastic Compute Cloud)
  • Amazon ECR (Elastic Container Registry)
  • Amazon ECS (Elastic Container Service)
  • Amazon ECS Container Insights
  • Amazon ECS Managed Scaling
  • Amazon EFS (Elastic File System)
  • Amazon EKS (Elastic Kubernetes Service)
  • Amazon ElastiCache
  • Amazon EMR (Elastic MapReduce)
  • Amazon EMR Serverless
  • Amazon EventBridge
  • Amazon FSx
  • Amazon Keyspaces (for Apache Cassandra)
  • Amazon Kinesis Data Analytics for Apache Flink
  • Amazon Kinesis Data Firehose
  • Amazon Kinesis Data Streams
  • Amazon MQ
  • Amazon MSK (Managed Streaming for Apache Kafka)
  • Amazon MSK Connect
  • Amazon MWAA (Managed Workflows for Apache Airflow)
  • Amazon Neptune
  • Amazon OpenSearch Serverless
  • Amazon OpenSearch Service
  • Amazon RDS (Relational Database Service)
  • Amazon Redshift
  • Amazon Route 53
  • Amazon S3 (Simple Storage Service)
  • Amazon SageMaker Endpoints
  • Amazon SageMaker Inference Components
  • Amazon SageMaker Invocations
  • Amazon SageMaker Model Building Pipelines
  • Amazon SNS (Simple Notification Service)
  • Amazon SQS (Simple Queue Service)
  • Amazon VPC IP Address Manager (IPAM)
  • Application Load Balancer (ALB)
  • AWS App Runner
  • AWS AppSync
  • AWS Auto Scaling
  • AWS Backup
  • AWS Certificate Manager
  • AWS CloudHSM
  • AWS CloudTrail
  • AWS CodeBuild
  • AWS Database Migration Service
  • AWS DataSync
  • AWS Direct Connect
  • AWS Elastic Beanstalk
  • AWS Global Accelerator
  • AWS Glue
  • AWS Key Management Service (KMS)
  • AWS Lambda
  • AWS NAT Gateway
  • AWS Network Firewall
  • AWS Private Certificate Authority
  • AWS PrivateLink Endpoints
  • AWS PrivateLink Services
  • AWS Site-to-Site VPN
  • AWS Step Functions
  • AWS Storage Gateway
  • AWS Transit Gateway
  • AWS WAF (Web Application Firewall)
  • Elastic Load Balancing (Classic)
  • Gateway Load Balancer
  • Network Load Balancer (NLB)

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 recommended AWS services supported
  • Amazon CloudFront
  • Amazon DynamoDB
  • Amazon EBS (Elastic Block Store)
  • Amazon EC2 (Elastic Compute Cloud)
  • Amazon ECS (Elastic Container Service)
  • Amazon Kinesis Data Firehose
  • Amazon RDS (Relational Database Service)
  • Amazon Route 53
  • Amazon S3 (Simple Storage Service)
  • Amazon SQS (Simple Queue Service)
  • Application Load Balancer (ALB)
  • AWS Auto Scaling
  • AWS Lambda
  • Network Load Balancer (NLB)

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 native supported (service) AWS resources, CloudWatch metrics, dimensions combinations.

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 (for example: AWS tags, AWS Account ID).
    • Linked metrics/logs can be viewed in context to their corresponding AWS resource (entity—node) using Clouds Clouds.

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