Troubleshooting
Articles about how to solve the most common problems
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Arif-Talukder
Dynatrace Participant
Dynatrace Participant

Summary

Dynatrace AWS monitoring relies on AWS APIs and Amazon CloudWatch to discover AWS resources and collect monitoring data.

AWS monitoring can fail even when the Dynatrace IAM role has the expected permissions. AWS Organizations can still block required API actions through a Service Control Policy, also known as an SCP.

This article explains how to identify an SCP-related authorization failure, verify the restriction in AWS, and validate Dynatrace AWS monitoring after the restriction is corrected.

 

 

Problem

Dynatrace AWS monitoring data is missing or incomplete even though:

  • The Dynatrace IAM role appears to have the required permissions.
  • The monitoring role can be assumed successfully.
  • The AWS monitoring connection appears to be configured correctly.
  • Monitoring works in one AWS Region but fails in another.
  • Some AWS services are discovered while others are missing.
  • CloudWatch metrics are available from some Regions but missing from others.
  • Integration health warnings appear for specific services or Regions.

Depending on the denied AWS API action, the issue can affect AWS resource discovery, CloudWatch metrics, integration health, or other AWS monitoring data.

The following are sanitized examples of errors that can occur. The exact error message may vary:

An error occurred (AccessDenied) when calling the DescribeInstances operation:

 User:
arn:aws:sts::123456789012:assumed-role/DynatraceMonitoringRole

 is not authorized to perform:

ec2:DescribeInstances

 with an explicit deny in a service control policy

Another example:

Access denied - explicit deny in SCP

 Action:

cloudwatch:GetMetricData

 Status:

Denied by Organizations policy

If the error references Service Control Policy, SCP, explicit deny, or AWS Organizations, the request may be blocked by AWS Organizations before Dynatrace can collect the required monitoring data.

 

 

Troubleshooting steps

  1. Review the complete authorization error

Identify and record:

  • The affected AWS account.
  • The affected AWS Region.
  • The affected AWS service.
  • The assumed monitoring role.
  • The denied AWS API action.
  • The exact authorization error.

Confirm whether the error contains any of the following:

Service Control Policy

SCP

explicit deny

AWS Organizations

  1. Review AWS CloudTrail

Review AWS CloudTrail Event history for related AccessDenied events.

Confirm:

  • The exact API action that was denied.
  • The AWS identity or role that made the request.
  • The AWS Region where the request was processed.
  • Whether the error indicates an explicit denial from an SCP.

The AWS re:Post article Troubleshoot SCPs explicit deny errors in AWS Organizations recommends using AWS CloudTrail Event history to confirm whether an SCP denied the request.

  1. Review the applicable Service Control Policies

Work with the AWS administration, cloud-governance, or security team to review:

  • SCPs attached directly to the affected AWS account.
  • SCPs inherited from a parent Organizational Unit.
  • SCPs applied at the organization root.
  • Restrictions for the affected AWS service.
  • Restrictions for the affected AWS Region.
  • Policies that deny the required AWS API action.

IAM permissions are only part of the authorization path. An IAM role may have the expected permissions, but AWS can still deny the request if an applicable SCP blocks the required action.

  1. Check for regional restrictions

If monitoring works in one AWS Region but fails in another, verify:

  • Whether the affected Region is allowed by organizational policies.
  • Whether the required AWS services are allowed in that Region.
  • Whether the required API actions are allowed in that Region.
  • Whether Region-based SCP restrictions exist at the account or Organizational Unit level.
  • Whether each required Region is included in the Dynatrace AWS monitoring configuration.

  1. Confirm that the monitoring role can be assumed

Verify that Dynatrace can assume the configured AWS monitoring role successfully.

If role assumption succeeds but a later AWS API request receives an explicit SCP denial, investigate the applicable Service Control Policies rather than only reviewing the role’s IAM permissions.

 

Resolution

Service Control Policies are managed through AWS Organizations. If the required AWS API action is denied by an SCP, the policy must be reviewed and corrected by the AWS administration, cloud-governance, or security team.

Dynatrace cannot modify or override policies enforced by AWS Organizations.

After the AWS team reviews and corrects the restriction:

  • Run or reproduce the affected AWS API request.
  • Confirm that CloudTrail no longer reports an SCP-related denial.
  • Review the Dynatrace AWS integration health.
  • Confirm that the affected AWS entities and metrics are available.
  • Verify monitoring in every configured AWS Region.

Classic AWS monitoring with ActiveGate

For Classic AWS monitoring environments that rely on ActiveGate configuration, verify that the required AWS monitoring configuration is present in the custom.properties file. Regions are delineated by semicolons, no spaces are needed.

Example:

.properties

[aws_monitoring]

aws_monitoring_enabled = true

aws_client_regions = "us-east-1;us-east-2"

 

Settings stored in custom.properties override the corresponding settings in config.properties.

If custom.properties is updated, restart the affected ActiveGate service so that the configuration can be reloaded.

New AWS Monitoring Connections

For new AWS Monitoring Connections, confirm that all required AWS Regions are included during connection setup.

If a Region is omitted from the monitoring connection or restricted through an SCP, Dynatrace may not be able to collect monitoring data from resources in that Region.

 



What's next

If CloudTrail continues to report SCP-related AccessDenied events, work with the internal AWS administration team or engage AWS Support.

This may be necessary when:

  • The account inherits policies from multiple Organizational Units.
  • The denied action appears to be blocked by a higher-level SCP.
  • Regional restrictions are suspected.
  • The AWS team needs help identifying which SCP statement is responsible.

If the AWS-side SCP restrictions have been reviewed or corrected and monitoring still does not work as expected, create a chat or open a Dynatrace Support case.

Mention that you reviewed this article and include:

  • The affected AWS account.
  • The affected AWS Region.
  • The affected AWS service.
  • The exact error message.
  • The denied AWS API action.
  • Relevant AWS CloudTrail events.
  • Related AWS CloudFormation deployment events, if applicable.
  • The current Dynatrace AWS integration health status.
  • Confirmation that applicable SCP restrictions were reviewed or corrected.
  • The current custom.properties AWS monitoring configuration for Classic AWS monitoring, if applicable.
  • A newly collected ActiveGate support archive, if ActiveGate is involved.

Providing this information helps separate an AWS authorization restriction from a remaining Dynatrace configuration or data-collection issue.


Related reading


📖  Service control policies (SCPs) - AWS Organizations

📖  SCP evaluation - AWS Organizations

📖  Troubleshoot SCPs explicit deny errors in AWS Organizations | AWS re:Post

📖  Troubleshoot explicit deny errors in AWS Organizations | AWS re:Post

📖  Amazon Web Services monitoring — Dynatrace Docs

Monitor Amazon Web Services with CloudWatch metrics — Dynatrace Docs

Configuration properties and parameters of ActiveGate — Dynatrace Docs
AWS: How can we configure a single AWS account to use two ActiveGates to monitor separate regions?

 

Version history
Last update:
‎08 Oct 2026 03:32 PM
Updated by: