Showing results for 
Show  only  | Search instead for 
Did you mean: 
Looking to upgrade from Dynatrace Managed to SaaS? See how

Network Zones in Dynatrace Managed per environment


Hi Guys,

I have Dynatrace Managed Network zones created in my CMC at cluster level.

Now when i login to one specific environment , i have the option to enable network zones within each environment as well.

Can someone please help me understand below points:

1) How is Network zone at Env level different from Cluster level

2) What is a sample use case for N/W zone at each level for understanding


Himanshu Mor


DynaMight Legend
DynaMight Legend

Im pretty sure the use case for managed would be to help compress data and prioritize ActiveGates. So while you can set the zones for what ActiveGate the oneagents, talk to, you can set what ActiveGates talk to what clusters. This could help with bandwidth and infrastructure costs.


Thanks @Chad T. for your quick reply here !

When you say "you can set what ActiveGates talk to what clusters " , do you mean environment active gates here ?

In my environment , we are not using environment AG but only Cluster AG are used.

So in this case where only Cluster AG are being used , can Environment level Network zone serve any purpose or not?

So here is a little diagram I tossed together. I hope this clears things up.

So in Red these are the paths for communication. AS you can see, Synthetics go right into the Cluster AG and then right in to the Cluster.

Now in Yellow you can see that I have a Prod and NONProd environment those of which have an environment AG, Which can also leverage Network Zones so you can have several AG's (As Seen in the Red Box) and say I want Development hosts to communicate to the Development AG and the Load Test hosts to talk to the Load Test AG.

So at the cluster level, you can have Cluster AG's that handles this data. For synthetics and such you MUST have one. For Managed users, the clusters have an internal Cluster AG, so you might not have ones deployed. But, if you do, you can leverage Network Zones to say let one Cluster AG handle the Prod or NonProd Data (As seen in Yellow). Or You could even have one (out of the box with Managed and the built in cluster AG) as seen in Green.

So the Network Zones at the cluster level allows you to determine the amount/contents of what is being passed by each Cluster AG. Some organizations might want to keep Prod and NONProd separated in the event one Cluster AG goes down, it won't affect the other environment. Further more if you need to limit bandwith, you could assign X amount of Environment AG's to designated Cluster AG's.

This is very flexible and also allows for redundancy, So you could in fact conjoin all of these arrows for redundancy, where if an yellow arrow fails, the Environment AG will then try the next as defined in its zone and travel on the green arrow.

I hope I didnt confuse you! Let me know if you need anything else.


Thank You @Chad T. for the detailed diagram and explanation , it definitely clears up most of the doubts !

So we have the complete flexibility to segregate the traffic at each layer : Env layer or Cluster layer based on our specific use case .

Considering the diagram in last comment by @Chad T.,

At Env level , [an example use case where we want some hosts talk to a specific Env AG and some to another Env AG within one Red box(in the diagram)]

we have Env level N/W zones that direct ::

1) Dev Hosts to communicate to Dev Env AG

2) Load Test Hosts to communicate to the Load Test Env AG

At Cluster Level ,

We have cluster level N/W zones that direct

Prod data towards Prod Cluster AG

Non-Prod data towards Non-Prod Cluster AG

Just tell me in case I need correction anywhere above.


Himanshu Mor

@HIMANSHU m. that is exactly correct!

You can make it as broad as you'd like where there is 1 Environment Ag for the hosts (both Prod/NonProd) and one Cluster AG that handles all the Prod/NonProd Oneagent data that is being sent to the cluster.

or more granulated where you have Dev and Load Test going to their own Environment AG's which then report out to their own Cluster AG's which report to the Cluster. Thus allowing a redundancy where if a AG fails, either the Environment or Cluster level, it only affect 1 environment of the entire NonProd platform.

And with the Network Zones you define where the traffic goes for each level of AG's.


Featured Posts