Try it free

Get started with AWS Organizations

  • Latest Dynatrace
  • Explanation

This is an overview of how to integrate and connect your AWS Organizations to the Dynatrace AWS Platform Monitoring.

Who is this for?

The guide is intended for a Dynatrace Admin and a delegated administrator for AWS Organizations.

High-level setup

AWS Organizations monitoring configuration

The Dynatrace admin uses Settings Settings to create an organization monitoring configuration template, targeted for specific AWS organization id. The configuration acts as the initial monitoring setting blueprint for all newly joined AWS member accounts.

Assets sharing

The Dynatrace admin shares the monitoring configuration metadata as part of a broader set of instructions within the AWS Organizations delegated admin.

Foundational StackSet

From the delegated administrator member account, the AWS Organizations delegated admin creates the foundational StackSet and deploys stack instances into the AWS account hosting the Dynatrace secrets, across each AWS region where member accounts will send logs and/or events to Dynatrace.

Core StackSet

From the delegated administrator member account, the AWS Organizations delegated admin creates the core StackSet, then chooses the scope of deployment (entire Organizations or specific OU/OUs) for the stack instances, and then deploys the StackSet instances.

What does a successful onboarding look like?

  • An immediate deployment of the core CFN stack instances into AWS member accounts.
  • Healthy AWS connection (per AWS member account) in Settings Settings.

The new integration does not deploy or use ActiveGate compute resources in your AWS member accounts to poll or push telemetry.

The experience is transparent and fully managed by the Dynatrace Platform.

Limitations

  • GovCloud and China partitions are not supported.
  • If you plan to enable Amazon EventBridge events ingest, validate the regions you selected during the stack instance deployments support the EventBridge API destinations.

A single Dynatrace environment allows up to 500 connections. If you need to exceed this, please contact Dynatrace support for more information.

General recommendations

  • We don't recommend onboarding AWS accounts that are actively monitored by our classic AWS integration. Onboarding such accounts might increase the likelihood of AWS APIs throttling, potentially resulting in service interruptions.
  • We recommend that the AWS admins review the CFN templates and make sure that potential AWS Service Control Policies (SCPs) does not prevent the stack instances from creating the needed AWS resources.

Concepts

AWS Organizations monitoring configuration

This configuration serves as the baseline monitoring blueprint for every AWS member account that newly joins the organization. When a member account joins, it receives its own copy of the monitoring settings as they exist at that moment.

  • Updates made to monitoring settings in an AWS rganization or organization OU-level configuration template don't automatically propagate to member accounts that have already been onboarded.
  • Each onboarded member account maintains its own dedicated AWS connection, with monitoring configuration mapped individually (instantiated as a copy from the top-level template during successful onboarding).
  • To change monitoring settings for one or more AWS (member) connections, use the REST API or the Settings Settings.
  • We recommend testing changes on non-production AWS connections first—especially when following GitOps practices intended to use the REST API for bulk updates.

Management region

The AWS management region is a Dynatrace setting (StackSets parameter) which is used to enforce a constraint where certain AWS resources will only get deployed within a single region boundary. You set this region and use it during all StackSets creations and stack instances creation.

You have to select/set the same management region during all StackSets creations and stack instances deployments.

Foundational StackSet

The foundational StackSet must be created as the first stack instance.

The foundational StackSet contains AWS resources that, when deployed as a stack instance, allow any member account to resolve the Dynatrace platform tokens shared across the organization via Dynatrace-specific IAM roles (created by the Core StackSet).

The stack instance will deploy the following resources:

  • AWS resources:

    • Customer KMS key
    • AWS Secrets Manager secrets (storing Dynatrace tokens)
    • Secrets Manager resource policies to support secrets access from member accounts

  • Template: Foundational StackSet template

For use cases where member accounts under specific OUs require their own dedicated secrets—separate from those used by accounts under other OUs—consult the step-by-step integration guide, paying close attention to the pDeploymentInstanceIdentifier parameter.

This use case is detailed in the FAQ.

Core StackSet

You can create the core StackSet only after the foundational StackSet deployment has completed successfully.

The core StackSet contains AWS resources that, when deployed as a stack instance, are used to connect and register AWS member accounts to the Dynatrace platform.

Once the stack instance has been successfully deployed inside the AWS member account, the result is a Healthy AWS connection in Settings Settings > Accounts.

The stack instance will deploy the following AWS resources (per an AWS member account):

  • AWS Lambda deployment (management region only)

  • Dynatrace monitoring IAM role

  • IAM service roles

  • Conditional AWS resources (created based on the selected options per AWS member account):

    • Firehose delivery streams (if log ingest was enabled)
    • S3 bucket for failed delivery logs backup (if log ingest was enabled)
    • AWS EventBridge connection (if event ingest was enabled)
    • AWS EventBridge API destination (if event ingest was enabled)

    During the deployment of stack instances, additional AWS resources may be created.

  • Template: Core StackSet template

For use cases where a group of AWS member accounts (under specific OUs) require their own dedicated monitoring configuration—separate from those used by a distinct group of AWS member account under other OUs—consult the step-by-step integration guide, paying close attention to the pMonitoringConfigId parameter. This use-case is detailed in the FAQ.

Next steps

Head over to How to integrate AWS Organizations.

Related tags
Infrastructure Observability