Try it free

Update AWS connections

  • Latest Dynatrace
  • How-to guide
AWS connection

A foundational link between Dynatrace and your AWS account. It authenticates through a dedicated AWS IAM monitoring role that Dynatrace SaaS assumes; if the role is assumed successfully, the connection state is Healthy. When you deploy a connection with the Dynatrace IaC stacks (CloudFormation), the monitoring role is created automatically.

Monitoring Configuration

The blueprint that governs all monitoring settings for a connection, such as which AWS metrics to poll and which regions to poll from.

Each connection maps to a single AWS account ID and is paired one-to-one with a single monitoring configuration.

Both are created automatically when you onboard through the new connection wizard or deploy the Dynatrace IaC stacks (CLI or GitOps).

If you create a connection manually, you must also create its paired monitoring configuration yourself. For more information, see Create your first AWS connection.

Updating an AWS connection to the latest version involves two steps, which must be performed in this order:

  1. Update the Dynatrace IAM monitoring role (prerequisite).
  2. Update all or selected monitoring configurations.

Update an AWS connection

Step 1: Keep your Dynatrace IAM monitoring role up to date

Dynatrace regularly adds topology support for more AWS resource types, which requires additional AWS API calls to collect their data. Each release note lists the newly supported resources and, often, entirely new AWS services.

Following AWS IAM least-privilege practice, the IAM policy of the Dynatrace IAM monitoring role grants only the permissions currently required. Therefore, you need to update the role periodically to pick up new permissions.

Each release note shall include the updated resources, see an example of such release notes.

How to update

How you update the role depends on how your AWS connection was created.

How your connection was createdManaged by IaC?How to update the IAM monitoring roleWho is responsible

Settings Settings app (UI wizard)

Yes (CloudFormation)

Update your CloudFormation stack to the latest template version.

You deploy the update. Dynatrace publishes the new template and release notes.

API and AWS CLI

Yes (CloudFormation)

Re-deploy or update your CloudFormation stack using the latest template version.

You deploy the update. Dynatrace publishes the new template and release notes.

AWS Organizations

Yes (CloudFormation StackSets)

Update both the Foundational and Core StackSets to the latest template version. The change then rolls out to all member account stack instances.

Your AWS Organizations delegated administrator runs the StackSet updates.

API only (manually created role)

No

Add the new permissions to the DynatraceMonitoringPolicy and DynatraceMonitoringPolicy-2 managed policies so they match the latest policy definitions in the Dynatrace documentation.

You. Monitor Dynatrace release notes for changes and apply them through your own IaC/GitOps processes.

Custom deployment (Customized IaC templates)

Customer-managed

Pull the latest Dynatrace templates, re-apply your customizations, and redeploy. If you maintain your own definitions, diff them against the latest documented policies and add the new permissions.

You. Dynatrace can't update deployments it doesn't control, so monitor release notes and fold the changes into your own IaC/GitOps processes.

What to do

  • Monitor the Dynatrace SaaS release notes, under "Infrastructure Observability", and review each one. It lists newly supported resources and their (new or existing) AWS services, and links to this page for the new CFN template set versions.

  • Connections deployed with the standard Dynatrace CloudFormation templates: update your stacks/stacksets to the latest version to receive topology data for all supported resources and services and to stay current with the latest integration experience.

    See standalone update to update the CFN stack for a standalone connection, or AWS Org update to update AWS Organizations member accounts.

  • Connections created outside the supported Dynatrace IaC, for example, custom templates: We can't update a role we didn't deploy as-is and we don't support this deployment model. Compare the documented policies with those in your account, and add any changes to your IaC or GitOps pipelines so the role doesn't drift out of date. If you host copies of the templates in your own S3 bucket, refresh them with each release.

Until the role is updated, topology data for newly supported resources and services isn't collected. Existing data is unaffected.

Step 2: Update monitoring configurations

Monitoring configurations are versioned. Dynatrace periodically introduces new features, support for additional AWS services to poll metrics from, support for new AWS regions, and more. We recommend upgrading periodically to keep your connections current with new features and improvements.

What to do

  • Monitor the Dynatrace SaaS release notes on the What's new page, under "Infrastructure Observability", and review each one. It describes new features, services, and improvements, and states whether a monitoring configuration upgrade is needed.

  • Review the detailed release notes of the new monitoring configuration version: In Dynatrace, open the hub and select "AWS Cloud Monitoring". Deep link: https://<environment-ID>.apps.dynatrace.com/ui/apps/dynatrace.hub/browse/all?search=AWS+Cloud+Monitoring&sortCapabilitiesBy=most-relevant Open the "Release Notes" tab and review the latest detailed release notes.

  • Upgrade a monitoring configuration (manual; use this to evaluate the changes in a single connection)

Open Settings app > Collect and capture > Cloud and virtualization > AWS. Open the connection, select "Manage", and then select "Save". You don't need to change any settings. Saving automatically upgrades the configuration to the latest version.

  • Upgrade all monitoring configurations at once (manual bulk upgrade for all connections)

In Dynatrace, open the hub and select "AWS Cloud Monitoring": https://<environment-ID>.apps.dynatrace.com/ui/apps/dynatrace.hub/browse/all?search=AWS+Cloud+Monitoring&sortCapabilitiesBy=most-relevant

Select the "Configure ->" action button in the top-right corner of the window. Open the "Monitoring Configuration" tab, select "Upgrade all configurations", and confirm the "Upgrade monitoring configurations" dialog. Expected result: all monitoring configurations (see the version column) are upgraded to the latest active (supported) version. The latest active version is shown below the "AWS Cloud Monitoring" title and AWS logo, for example, "Active Version: 1.2.1". After a successful upgrade, the "Upgrade all configurations" button is hidden. It reappears when a newer active version is available.

FAQ

Does the upgrade order matter, and what is the correct order?

Yes. For topology to collect new resources, update the IAM monitoring role first, across all connections within the affected environment. Once the IAM role is updated successfully (across all connections), upgrade the monitoring configurations.

What is the impact if I upgraded the monitoring configurations (for example, in bulk) before updating the IAM monitoring role?

Newly supported or updated AWS resources fail to be collected and aren't reflected in topology as entities (nodes). If the new resources emit entity-linkable CloudWatch metrics or other telemetry (logs, events, traces), the telemetry is still ingested but isn't linked to entities or enriched with cloud metadata. You should also see a message on the connection's "Health" tab similar to this one:

2/10, 08:25:32.858 am WARN aws-smartscape-poller Authorization error: could not perform IAM Action for AWS::Bedrock::GuardRail (Forbidden).

Collection of these resources resumes once the IAM monitoring role is updated.

Is it safe to upgrade monitoring configurations, for a single connection or in bulk? Will it change my monitoring settings or automatically opt me in to new features?

Upgrading monitoring configurations, for a single connection or in bulk, is a fully supported platform feature for monitoring configuration versions 1.x.x. It is designed not to change any existing setting and not to automatically opt you in to new features.

I updated the IAM monitoring role to the latest version. Should I expect additional cost?

Not directly. Ingesting these new resources into your Dynatrace environment does not add cost. At present, the Dynatrace topology feature does not bear direct cost.

Do you support the upgrade of monitoring configuration using REST API or IaC?

No this is not suppored, currently the only supported methods are depicted here. Managing monitoring configuration lifecycle via the REST API is detailed on this page.

I use the AWS Organizations Dynatrace onboarding integration. Are the upgrade instructions different from the standalone onboarding model?

Yes, but only for the CFN StackSet update, which follows a different path with the same end result: all member account IAM monitoring roles are updated. See (#cfn-org-upd). The monitoring configuration update follows the same instructions as for standalone connections.

I customized the verbatim CFN template sets published by Dynatrace. Does that change the upgrade instructions?

Yes. Do not follow the CFN upgrade, to avoid a state mismatch. See the table to learn more. Upgrading the monitoring configurations follows the same instructions.

I am following the monitoring configuration upgrade (bulk) explain here, Yet the "Upgrade All Configurations" button does not appear, while SaaS release notes state new monitoring confuguration updates

There could be few reasons why this is happening, the common would be that the environment Monitoring configuration "Active version" has not been updated (Environment level) by Dynatrace as of yet. The settings app is set to check for a new active version (upon launching the app), and update to the latest supported without any action required. Start by re-launching the settings app and re-visiting the "AWS Cloud Monitoring" in the Hub. If the above does not solve the issue, kindly raise a ticket to Dynatrace support.

I manage large scale of AWS Connections, how can I make sure that connections are not affected by AWS IAM monitoring role authorization issues

Autherization errors are logged on the connection level as events (See the "connection logs" on the connection's "Health" Tab), the pattern look like this:

2/10, 08:25:32.858 am WARN aws-smartscape-poller Authorization error: could not perform IAM Action for AWS::Bedrock::GuardRail (Forbidden).

You can use this DQL example to query for those events:

fetch dt.system.events, from:now()-1d
| filter event.kind == "DATA_ACQUISITION_EVENT"
| filter contains(da.clouds.content, "authorization error", caseSensitive:false)
| sort timestamp desc
| limit 100

Standalone (single) AWS accounts

Latest template set: v1.0.18

Core CFN stacks

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack

CloudFormation template set major versions

v0.x.x: Introduced with the AWS Platform Monitoring Preview Program. No longer supported.

v1.x.x: v1 is a long-term supported version and the default for all new AWS connections since the General Availability of the new AWS Cloud Platform Monitoring.

How do I get the template set version?

  1. Open the CloudFormation console https://awsRegion.console.aws.amazon.com/cloudformation/home?region=awsRegion#/stacks.

    Replace awsRegion with the region where your connection's CloudFormation stacks are deployed.

  2. Locate the root stack. Its name is identical to the connection name, for example, MyEastProd3Account.

  3. Select the Template tab, locate Metadata/Version/Number, and examine the value, for example, v1.0.0.

    AWS connections deployed with template set version v0.x.x are no longer supported and don't support an in-place upgrade. In those cases, delete the connection and recreate it. The new connection uses the current latest version.

Release notes (standalone AWS accounts CFN template sets)

Template set version 1.0.18

Core CFN stacks v1.0.18

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.18

Changelog: Removed unnecessary IAM permissions for IoT, SWF, Service Catalog, Inspector, and SageMaker jobs.

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.17

Core CFN stacks v1.0.17

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.17

Changelog: Fixed missing permissions required to subscribe a log group to an encrypted Firehose delivery stream.

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.16

Core CFN stacks v1.0.16

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.16

Changelog: Added support for AWS::SWF::Domain.

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.15

Core CFN stacks v1.0.15

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.15

Changelog: Added support for AWS::KinesisVideo::Stream.

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.14

Core CFN stacks v1.0.14

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.14

Changelog: Added support for AWS::InspectorV2::Filter.

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.13

Core CFN stacks v1.0.13

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.13

Changelog: Added support for AWS::Transfer::Server.

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.12

Core CFN stacks v1.0.12

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.12

Changelog: Added support for AWS::DataSync::Agent.

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.11

Core CFN stacks v1.0.11

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.11

Changelog: Added support for AWS::Workspaces.

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.10

Core CFN stacks v1.0.10

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.10

Changelog: Fixed a bug with custom EventBridge event buses.

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.9

Core CFN stacks v1.0.9

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.9

Changelog: Fixed missing violation details in Lambda function error outputs.

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.8

Core CFN stacks v1.0.8

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.8

Changelog: Added support for deploying the Firehose logs and EventBridge templates as standalone CloudFormation stacks (supported only for the standalone AWS account deployment model).

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.7

Core CFN stacks v1.0.7

Fixed a bug that left KMS permissions insufficient for the Firehose logs integration.

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.7

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.6

Core CFN stacks v1.0.6

Fixed an issue where the stack failed to roll back due to an invalid settings token.

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.6

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.5

Core CFN stacks v1.0.5

Removed unused IAM permissions.

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.5

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.4

Core CFN stacks v1.0.4

Removed unused IAM permissions.

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.4

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.3

Added URL validation in Lambda function.

Core CFN stacks v1.0.3

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.3

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.2

Updated parameter description.

Core CFN stacks v1.0.2

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.2

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.1

Changed the Dynatrace monitoring configuration API to v2.

Core CFN stacks v1.0.1

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.1

Deployed based on user opt-in during onboarding.

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack
Template set version 1.0.0

Changes:

  • General Availability version, cleaned up and secured.

  • Renamed resources, conditions, and outputs.

  • Scoped down deployment permissions.

  • Added IAM permissions for CloudTrail API calls to track topology changes for the following AWS resources:

    AWS::Route53::HostedZone
    AWS::Route53::HealthCheck
    AWS::ApiGateway::Stage
    AWS::ApiGatewayV2::Stage
    AWS::EFS::FileSystem
    AWS::EFS::AccessPoint
    AWS::EFS::MountTarget
    AWS::ECR::Repository
    AWS::ElastiCache::CacheCluster
    AWS::ElastiCache::ServerlessCache
    AWS::ElastiCache::ReplicationGroup
    AWS::ElastiCache::SubnetGroup
    AWS::MSK::Configuration
    AWS::MSK::VpcConnection
    AWS::SNS::Topic
    AWS::SQS::Queue
    AWS::ElasticBeanstalk::Environment
    AWS::Firehose::DeliveryStream
    AWS::Logs::LogGroup
    AWS::ElasticBeanstalk::Application
    AWS::S3::Bucket

Core CFN stacks v1.0.0

  • Main deployment stack
    • Nested API client stack
    • Nested integration stack
    • Nested Monitoring IAM role stack

Conditional (nested) CFN stacks v1.0.0

Deployed based on user opt-in during onboarding

  • Nested StackSet roles
  • Nested Firehose Log streams stack
  • Nested AWS EventBridge integration stack

Update the CloudFormation stack

If you have adjusted the provided templates to align with internal standards or policies (changed the CloudFormation code), do not follow this update. See FAQ.

  1. In the AWS CloudFormation console, locate the root stack in the deployment region. The root stack name follows the connection name, for example: MyEastProd3Account.

  2. Follow a direct update.

    Update a non-business-critical connection first, then gradually update the rest. We also recommend following AWS best practices for CFN direct updates.

  3. In Replace existing template, choose the latest 1.x.x version. If the update fails, see the AWS CloudFormation troubleshooting guide.

AWS Organizations

Latest template set v1.0.18

Foundational

Latest

Core

Latest

CloudFormation template set major versions

v1.x.x: v1 is a long-term supported version.

How do I get the template set version?

  1. Locate the StackSet.
  2. Select the Template tab, locate Metadata/Version/Number, and examine the value, for example, v1.0.2.

Version history (AWS Organization CFN template sets)

Use the single (standalone) account release notes to track changes.

Template set version 1.0.18

Foundational Core

Template set version 1.0.17

Foundational Core

Template set version 1.0.16

Foundational Core

Template set version 1.0.15

Foundational Core

Template set version 1.0.14

Foundational Core

Template set version 1.0.13

Foundational Core

Template set version 1.0.12

Foundational Core

Template set version 1.0.11

Foundational Core

Template set version 1.0.10

Foundational Core

Template set version 1.0.9

Foundational Core

Template set version 1.0.8

Foundational Core

Template set version 1.0.7

Foundational Core

Template set version 1.0.6

Foundational Core

Template set version 1.0.5

Foundational Core

Template set version 1.0.4

Foundational Core

Template set version 1.0.3

Foundational Core

Template set version 1.0.2

Foundational Core

Template set version 1.0.1

Foundational Core

Template set version 1.0.0

Foundational Core

Update the CloudFormation StackSets

If you have adjusted the provided templates to align with internal standards or policies (changed the CloudFormation code), do not follow this update. See FAQ.

We always release new versions of the foundational and core StackSets together to keep updates consistent. Updating both StackSets is required, and updating only one is not supported.

Update (and deploy) the foundational StackSet

  1. From the delegated administrator member account, locate the foundational StackSet and initiate an update.

  2. In Replace existing template, choose the latest 1.x.x version.

  3. In Deployment Targets, keep the existing target account ID.

If you have created multiple foundational StackSets (which must always target the same AWS account to support secret-duty separation use cases), make sure to update all of them.

Do not update the core StackSet if the foundational StackSet update was not successful.

Update (and deploy) the core StackSet

  1. From the delegated administrator member account, locate the core StackSet and initiate an update.

  2. In Replace existing template, choose the latest 1.x.x version.

  3. In Deployment Targets, choose the target AWS accounts/OUs.

We recommend first evaluating the update with dev/test/non-business-critical OU(s) as the initial Deployment Targets.

If you have created multiple core StackSets (targeting different account IDs to support multiple monitoring configurations), make sure to update all of them.

FAQ

I modified the official Dynatrace template(s) to meet internal organizational policies. Does Dynatrace support my modified templates, and can I still update to a newer version?

We understand that adjusting the provided templates to align with your organization's internal standards or policies is sometimes a requirement rather than a choice.

However, there are two important implications once a template has been customized:

1. Version updates

Customized templates follow a custom update path, which falls outside the standard (Dynatrace-curated) vetted process.

Because modifications alter the underlying CloudFormation (known) state, applying a newer template version on top of a customized one may lead to unexpected behavior, including service interruptions.

2. Dynatrace Support

Custom update paths are not supported by Dynatrace.

Our support team's ability to assist with customized templates is limited, because we cannot account for the impact of changes made outside the official template structure. You can log a support ticket, and our team will investigate the Dynatrace SaaS API side only. As part of troubleshooting, you may be asked to revert to a supported template version.

For tailored assistance, contact your Dynatrace Account Team. They can walk you through the available Professional Services offerings and help determine the best path forward for your setup, including custom update paths.

I am following a custom update path. How can I learn which changes were released in new template versions?

Each release has detailed release notes outlining its changes and enhancements. Review them and selectively incorporate the relevant changes into your customized templates as part of your own update process.

Can I upgrade directly to the latest version?

Yes. Within a major version, always upgrade to latest; you can skip intermediate versions. For example, a deployment on 1.0.1 can upgrade directly to latest.

Only the IAM stack changed in a release. Can I update just that stack directly?

No. Updating individual nested stacks directly is not supported. Every update must be done from the root stack, regardless of what actually changed.

Related tags
Infrastructure Observability