Create an AWS connection via API

  • Latest Dynatrace
  • How-to guide
  • Published Aug 29, 2025

Dynatrace is designed to support large and complex AWS environments.

By default, a Dynatrace environment can accommodate up to 3,000 AWS connections (each connection representing a single AWS account).

This is a soft limit. If you plan to exceed this (per Dynatrace environment), we kindly ask you to open a support request so we can proactively increase this limit, ensuring a smooth experience.

Prerequisites

  • An AWS account with the proper IAM permissions and access, examine the CFN templates and least privilige IAM permissions required to deploy the CFN stacks.
  • A bastion EC2 with the latest AWS CLI and attached IAM role which allows you to deploy the CFN stacks.
  • Create settings and ingest platform tokens. The (current) easiest way to create them is to use the new connection (UI) wizard step 3 to generate and download them. There is no need to complete the connection wizard.

Create a new AWS monitoring configuration using REST API

The monitoring configuration is the blueprint that contains all the settings that will be used on initial AWS account onboarding.

Settings can be modified post onboarding.

1. Prepare the request payload

[
{
"scope": "integration-aws",
"value": {
"enabled": false,
"description": "{configuration-name}",
"version": "1.0.0",
"featureSets": [
"ApiGateway_essential",
"ApplicationELB_essential",
"AutoScaling_essential",
"CloudFront_essential",
"DynamoDB_essential",
"EBS_essential",
"EC2_essential",
"ECR_essential",
"ECS_essential",
"EFS_essential",
"ELB_essential",
"ElastiCache_essential",
"Firehose_essential",
"Lambda_essential",
"NATGateway_essential",
"NetworkELB_essential",
"PrivateLinkEndpoints_essential",
"PrivateLinkServices_essential",
"RDS_essential",
"Route53_essential",
"S3_essential",
"SNS_essential",
"SQS_essential"
],
"aws": {
"smartscapeConfiguration": {
"enabled": true
},
"deploymentRegion": "{deployment-region}",
"credentials": [
{
"enabled": false,
"description": "{configuration-name}",
"connectionId": "*",
"accountId": "{aws-account-id}"
}
],
"regionFiltering": [
"{monitored-region-a}",
"{monitored-region-b}",
"{monitored-region-n}"
],
"metricsConfiguration": {
"enabled": true,
"regions": [
"{monitored-region-a}",
"{monitored-region-b}",
"{monitored-region-n}"
]
},
"cloudWatchLogsConfiguration": {
"enabled": false,
"regions": [
"{monitored-region-a}",
"{monitored-region-n}"
]
},
"configurationMode": "QUICK_START",
"deploymentScope": "SINGLE_ACCOUNT",
"deploymentMode": "AUTOMATED",
"manualDeploymentStatus": "NA",
"automatedDeploymentStatus": "NA"
}
}
}
]

Replace placeholder values with:

  • {configuration-name}: Name of new monitoring configuration. A name can contain only letters, numbers, and hyphens and must start with a letter.

  • {aws-account-id}: Numeric ID of the AWS account to be monitored, for example: 123456789012.

  • {deployment-region}: AWS Region in which the onboarding CloudFromation stack will be deployed from, for example: us-east-1.

  • regionFiltering/{monitored-region-a}{monitored-region-n}: Name of the AWS Region(s) that you want to poll CloudWatch metrics and topology from, also known as "monitored regions."

    For example: us-east-1, eu-central-1

  • metricsConfiguration/{monitored-region-a}{monitored-region-n}: This field is used for UI and future compatability. The region list must be always identical to the list set on regionFiltering.

    For example: us-east-1, eu-central-1

    Required
    • For both regionFiltering and metricsConfiguration, the us-east-1 region must always be set as the topology service polls for global AWS resources which only reside on us-east-1.
    • To allow telemetry signals in context and inventory on all relevant regions, the topology service must poll for topology signals on all regions where any signal in ingested or pushed (logs, eventbridge events).
  • cloudWatchLogsConfiguration "enabled": true/false Regions {monitored-region-a}...{monitored-region-n}`: Name of the AWS Region(s) that you want to push logs from (using CloudWatch Logs and Firehose).

Required

Region set for cloudWatchLogsConfiguration must be part of regionFiltering and metricsConfiguration region lists. This will allow supported logs to depict as signal-in-context using Clouds Clouds.

2. Create the submit REST API request

curl -X 'POST' \
'{your-environment-url}/platform/extensions/v1/com.dynatrace.extension.da-aws/monitoring-configuration' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer {your-bearer-token}' \
-d '{monitoring-configuration-payload}'

Replace placeholder values with:

  • {your-bearer-token}: Settings platform token (created as a prerequisite).
  • {monitoring-configuration-payload}: Request payload prepared in step 1.

Successful request will respond with new monitoring configuration ID (in objectId field). Example:

[
{
"objectId": "e4bf05f3-d829-3689-8dd4-a9d2aeab0607",
"code": 200
}
]

Note that the value of objectId field should be used in the next step in the placeholder: {new-monitoring-configuration-id}.

If the API call fails, validate that:

  • You have access to the settings API.
  • Your settings platform token is valid and assigned to the correct Dynatrace environment/account.

3. Deploy the CloudFormation stack

On your EC2 bastion:

wget -O da-aws-activation_v1.0.0.yaml https://dynatrace-data-acquisition.s3.amazonaws.com/aws/deployment/cfn/v1.0.0/da-aws-activation.yaml && \
aws cloudformation deploy \
--region {deployment-region} \
--stack-name {configuration-name} \
--template-file da-aws-activation_v1.0.0.yaml \
--capabilities CAPABILITY_NAMED_IAM \
--parameter-overrides pDynatraceUrl={your-environment-url} pMonitoringConfigId={new-monitoring-configuration-id} pDtApiToken={settings-platform-token} pDtIngestToken={ingest-platform-token} pDtLogsIngestEnabled=TRUE pDtLogsIngestRegions={logs-ingest-regions}

Replace placeholder values with:

  • {configuration-name}: Value specified in step 1.
  • {deployment-region}: Value specified in step 1.
  • {your-environment-url}: Value specified in step 1.
  • {new-monitoring-configuration-id}: Value from API response specified in step 2 (objectId).
  • {settings-platform-token}: Settings platform token (created as a prerequisite).
  • {ingest-platform-token}: Ingest platform token (created as a prerequisite).
  • {logs-ingest-regions}: Comma separated list of regions specified in step 1 (cloudWatchLogsConfiguration).

After successful completion, head over to Settings Settings.

In a few minutes, the newly created connection should be visible and in the Healthy state.

Modify an existing monitoring configuration

To modify an existing monitoring configuration, follow the steps below.

1. Retrieve existing configuration using GET request

curl -X 'GET' \
'{your-environment-url}/platform/extensions/v1/com.dynatrace.extension.da-aws/monitoring-configuration/{existing-monitoring-configuration-id}' \
-H 'accept: application/json' \
-H 'Authorization: Bearer {your-bearer-token}'

2. Modify JSON

Modify the retrieved configuration JSON as needed.

For example, add/remove monitored regions, enable/disable features, and more.

3. Update the configuration using PUT request

curl -X 'PUT' \
'{your-environment-url}/platform/extensions/v1/com.dynatrace.extension.da-aws/monitoring-configuration/{existing-monitoring-configuration-id}' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer {your-bearer-token}' \
-d '{modified-monitoring-configuration-payload}'

Replace placeholder values with:

  • {your-bearer-token}: Settings platform token.
  • {your-environment-url}: URL of you Dynatrace environment, for example: https://abc12345.apps.dynatrace.com.
  • {existing-monitoring-configuration-id}: ID of the monitoring configuration you want to modify.
  • {modified-monitoring-configuration-payload}: Modified configuration JSON from step 2.

4. Successful request

Successful request will respond with updated monitoring configuration ID (in objectId field). Example:

{
"objectId": "e4bf05f3-d829-3689-8dd4-a9d2aeab0607",
"code": 200
}

Delete an existing monitoring configuration

A deleted monitoring configuration does not delete the CFN stacks in AWS.

You must delete these manually to avoid lingering resources which will incur AWS and Dynatrace costs.

Delete the CFN stack using AWS CLI from your EC2 bastion.

aws cloudformation delete-stack --stack-name {StackName} --region {DeployedRegionName}

To delete an existing monitoring configuration, use the following DELETE request:

curl -X 'DELETE' \
'{your-environment-url}/platform/extensions/v1/com.dynatrace.extension.da-aws/monitoring-configuration/{existing-monitoring-configuration-id}' \
-H 'accept: application/json' \
-H 'Authorization: Bearer {your-bearer-token}'

Replace placeholder values with:

  • {your-bearer-token}: Settings platform token
  • {your-environment-url}: URL of you Dynatrace environment, for example: https://abc12345.apps.dynatrace.com
  • {existing-monitoring-configuration-id}: ID of the monitoring configuration you want to delete

Successful request will respond with 204 No Content status, indicating that the configuration has been deleted successfully.

Related tags
Infrastructure Observability