Identify and resolve overlapping Azure subscription monitoring

• Latest Dynatrace
• How-to guide
• Published Sep 08, 2026

An Azure subscription should be monitored by exactly one Azure connection. When two or more connections monitor the same subscription, each one polls and ingests it independently—so you pay for the same monitoring more than once, and the duplicated data can be unreliable.

This page explains how overlap happens, how to find it, and how to resolve it.

How overlap happens

Each Azure connection monitors every subscription that its service principal can read. Because every connection has its own dedicated service principal, overlap occurs when two different service principals are both granted access to the same subscription.

A subscription belongs to only one management group, but it inherits role assignments from every management group above it. Overlap therefore usually happens when connection scopes nest, for example:

Overlap affects you in two ways:

Higher costs, in two places

Dynatrace ingests the same telemetry once per connection, which inflates your Dynatrace ingest costs. On the Azure side, Azure Monitor metric queries and log export and query operations are billed by volume, so each additional connection multiplies those charges too.

Less reliable data and monitoring

Duplicate ingestion can produce double-counted or conflicting data. Duplicate polling also consumes your Azure API rate limits faster, increasing the risk of throttling that delays or interrupts monitoring.

Find overlapping subscriptions

Dynatrace detects overlap automatically. When any subscription is shared, the Azure connections page in Settings > Cloud and virtualization > Azure displays the warning "Some connections have subscriptions which are also monitored in others. This may create unnecessary costs and data errors."

Select View subscriptions in the warning to list every shared subscription together with the connections that monitor it. To open a connection directly, select its name in the list. Overlap is independent of connection health, so the connections listed can be Healthy or Unhealthy.

If you're already working in a single connection, a warning icon on its Subscriptions tab and a banner at the top of the connection signal overlap. On the Subscriptions tab, a shared subscription has the status Monitored in multiple connections. Select the status to see how many other connections monitor it.

Decide which connection keeps each subscription

For each shared subscription, choose the one connection that should keep monitoring it. Each connection has its own monitoring configuration—enabled services, monitored regions, filters, and tag enrichment—so the connection you keep determines how the subscription is monitored from then on.

Choose how to resolve the overlap

After you decide, remove each shared subscription from every connection except the one that keeps it. You can make that change in Azure or in Dynatrace.

Resolve the overlap in Azure

Changing the service principal's role assignments stops the connection from discovering the subscription at all. Without access, Dynatrace can no longer poll the subscription's metrics, topology, or logs through that connection. How you change them depends on where the access comes from: a role assignment made directly on the subscription, or one inherited from a management group above it. Start by finding where the access comes from—the result tells you which one of the sections that follow applies.

Before you start, open the connection that should no longer monitor the subscription in Dynatrace, and note these properties on its Overview tab:

If Principal (object) ID shows Not Provided, retrieve it from the Application (client) ID with the Azure CLI:

az ad sp show --id "<APPLICATION_ID>" --query id --output tsv

In the Azure portal, you can search for the service principal by its display name or object ID. If you don't know either, search for the Application (client) ID in Microsoft Entra ID > App registrations.

To change role assignments, you need the Owner or User Access Administrator role at the scope where the assignment was made.

Find where the access comes from

Onboarding assigns the Monitoring Reader role, but any role that lets the service principal read the subscription gives the connection access—for example, Reader, Contributor, or Owner. Check every role assigned to the service principal, not only Monitoring Reader.

What you find determines the next step:

Note the name of each role you find. The commands in the following sections use it as <ROLE_NAME>.

If the service principal holds more than one role, or holds a role at more than one level, each assignment grants access on its own, so address every one. If a management group ID matches your Microsoft Entra tenant ID, the assignment is at the tenant root group and covers every subscription in the tenant.

If you find no role assignment for the service principal, it may have access through membership of a Microsoft Entra group. Group assignments are listed under the group's name rather than the service principal's, so check the role assignments of any group the service principal belongs to.

Change a management group assignment

A connection deployed at Management Group scope inherits access to every subscription beneath that management group. Azure doesn't let you remove an inherited role assignment at the subscription level, only at the management group where it was created, so you need to change how the access is granted instead.

Use the hierarchy you found to choose between the two options below, which are listed in order of preference. If neither fits, assign the role per subscription instead. In every option, grant the new access before you remove the old assignment, so the subscriptions that the connection should keep monitoring aren't interrupted.

Assign the role at a lower management group Recommended

If a management group lower in your hierarchy already contains only the subscriptions this connection should monitor, move the connection's scope down to it. Assign the Monitoring Reader role to the connection's service principal at the lower management group, then remove its assignment at the broader management group. Nothing in your hierarchy changes, and new subscriptions created beneath the lower management group are still picked up automatically.

Make sure no other connection is assigned anywhere within the lower management group's subtree.

Restructure the management group hierarchy

If no existing management group matches the boundary you need, change your management group hierarchy so that one does. Typically, that means creating a management group for the subscriptions this connection should monitor, and moving those subscriptions beneath it.

When the restructured management group, including everything beneath it, holds only the subscriptions this connection should monitor, and no other connection is assigned anywhere within that subtree, assign the role there and remove the broader assignment, as described in Assign the role at a lower management group. New subscriptions created beneath it are still picked up automatically.

Change subscription-level assignments

Role assignments made directly on a subscription give you precise control over which subscriptions a connection monitors. Use this section to remove the role from a shared subscription, or to assign the role per subscription in place of an inherited management group assignment when no management group fits.

Remove the role from the subscription

If the role is assigned directly on the shared subscription, remove the role from that subscription.

az role assignment delete --assignee-object-id "<OBJECT_ID>" --role "<ROLE_NAME>" --scope "/subscriptions/<SUBSCRIPTION_ID>"

Assign the role per subscription

If the connection's access is inherited and no suitable management group boundary exists, replace the management group assignment with direct assignments on each subscription the connection should monitor. This gives precise control, but new subscriptions are no longer picked up automatically—you must assign the role on each one yourself.

If none of these options is practical, exclude the subscription with a filter instead.

Resolve the overlap in Dynatrace

You can also resolve overlap without changing anything in Azure, either by removing a connection that's entirely redundant, or by filtering the shared subscriptions out of a connection.

Remove a redundant connection

If one connection's entire scope is covered by another, and the other connection's monitoring settings suit all of its subscriptions, the narrower connection is redundant. Delete it, or disable it to suspend its poll-based ingest while keeping its configuration.

Deleting a connection in Dynatrace doesn't remove its service principal, role assignments, or other Azure resources. For the full cleanup, see Delete a connection.

Exclude the subscription with a filter

A subscription filter tells a connection to ignore specific subscriptions without changing anything in Azure. Apply the filter only to the connections that should stop monitoring the subscription; the connection you keep continues to monitor it as before.

To apply filters to many connections at once, set the subscriptionFiltering and subscriptionFilteringMode fields of each monitoring configuration through the API, or apply a YAML manifest with dtctl apply through the CLI. For all filter options, see Subscription filters.

Verify the fix

Overlap detection is based on your Azure topology, so any fix on this page—changing role assignments, removing or disabling a connection, or applying a subscription filter—is reflected only after the next full topology scan. A full scan runs every hour; for details, see Topology data freshness.

After the next full scan, refresh the Azure connections page. Once no subscription is shared:

If the warning is still shown after a full scan has run, something still grants another connection access to the subscription. Find where the access comes from again, and check for a second role, an assignment at another level, or a third connection that monitors the same subscription.

Prevent overlap

For the full set of recommendations and limitations, see Create your first Azure connection.