When designing Azure environments, one common question is whether resources in one Azure subscription can communicate with resources in another subscription, especially when those subscriptions are placed under different management groups.
The short answer is: yes, they can.
Azure subscriptions, management groups, and Microsoft Entra tenants are governance and identity boundaries, but they do not automatically prevent network connectivity between resources. What matters most is how the network is designed, how permissions are configured, and whether security rules allow the traffic.
Understanding the Azure Hierarchy
A typical Azure hierarchy looks like this:
Microsoft Entra tenant
│
└── Root Management Group
│
├── Management Group: Production
│ └── Subscription: Production
│ └── Resource Groups
│ └── Resources
│
└── Management Group: DR
└── Subscription: Disaster Recovery
└── Resource Groups
└── Resources
The Microsoft Entra tenant is the identity boundary. It contains users, groups, service principals, app registrations, and role assignments.
Management groups are used to organize subscriptions and apply governance at scale.
Subscriptions are containers for Azure resources and billing.
Resource groups organize resources inside a subscription.
Resources are the actual Azure objects, such as virtual machines, virtual networks, storage accounts, databases, and key vaults.
A subscription can belong to only one Microsoft Entra tenant at a time, but one tenant can contain multiple subscriptions. Those subscriptions can be placed under different management groups for governance purposes.
Do Different Management Groups Block Connectivity?
No.
Management groups do not directly control network connectivity. They are mainly used for governance, such as applying Azure Policy and Azure RBAC across multiple subscriptions.
For example:
Microsoft Entra tenant
│
├── Management Group: Production
│ └── Subscription A
│ └── VNet-A
│ └── VM-A
│
└── Management Group: DR
└── Subscription B
└── VNet-B
└── VM-B
Even though Subscription A and Subscription B are under different management groups, VM-A can still communicate with VM-B if the networking is configured correctly.
The management group structure does not automatically isolate them.
What Actually Controls Connectivity?
Connectivity between Azure resources depends on several factors:
Network design
IP address ranges
VNet peering
Routing
NSGs
Firewalls
Azure Policy
Azure RBAC permissions
DNS
Guest operating system firewall
So, even if two resources are in different subscriptions, they can communicate if the network path exists and security rules allow the traffic.
Example 1: VMs in Different Subscriptions Using VNet Peering
The most common way to connect virtual machines in different subscriptions is through Virtual Network Peering.
Example:
Subscription A: Production
VNet: vnet-prod
Address space: 10.10.0.0/16
VM: prod-vm01
Private IP: 10.10.1.4
Subscription B: DR
VNet: vnet-dr
Address space: 10.20.0.0/16
VM: dr-vm01
Private IP: 10.20.1.4
After creating VNet peering between vnet-prod and vnet-dr, the two VMs can communicate using private IP addresses:
prod-vm01 10.10.1.4 ⇄ dr-vm01 10.20.1.4
This communication uses Microsoft’s private backbone network, not the public internet.
However, VNet peering alone is not enough. You also need to make sure that:
- The VNet address spaces do not overlap.
- Network Security Groups allow the required traffic.
- Windows Firewall or Linux firewall allows the required traffic.
- Route tables are not sending traffic to the wrong place.
- DNS is configured if you want to connect by name instead of IP address.
For example, if prod-vm01 needs to connect to SQL Server on dr-vm01, you must allow TCP port 1433 through the relevant NSGs and operating system firewall.
Example 2: Hub-and-Spoke Across Multiple Subscriptions
For enterprise environments, a better design is usually hub-and-spoke networking.
Example:
Microsoft Entra tenant
│
├── Management Group: Platform
│ └── Subscription: Connectivity
│ └── Hub VNet
│ ├── Azure Firewall
│ ├── VPN Gateway
│ └── DNS services
│
├── Management Group: Production
│ └── Subscription: Production
│ └── Prod Spoke VNet
│
└── Management Group: DR
└── Subscription: DR
└── DR Spoke VNet
In this design, the Production VNet and DR VNet do not necessarily connect directly to each other. Instead, both connect to the central Hub VNet.
Prod Spoke VNet ⇄ Hub VNet ⇄ DR Spoke VNet
This allows centralized control for:
Firewall inspection
Routing
VPN connectivity
ExpressRoute connectivity
DNS
Logging
Security monitoring
For example, traffic from a production application server to a DR database server can be routed through Azure Firewall in the hub:
prod-app01
↓
Azure Firewall in Hub VNet
↓
dr-db01
This design is cleaner and more scalable than creating many direct peerings between different VNets.
Example 3: Accessing PaaS Resources Across Subscriptions Using Private Endpoint
Connectivity is not only for VM-to-VM communication. A VM in one subscription can privately access a PaaS service in another subscription using Private Endpoint.
Example:
Subscription A:
VM: app01
VNet: vnet-app
Subscription B:
Storage Account: stprodbackup01
You can create a private endpoint in vnet-app that connects privately to the storage account in Subscription B.
The traffic flow becomes:
app01
↓ private IP
Private Endpoint in vnet-app
↓
Storage Account in Subscription B
This avoids exposing the storage account publicly and keeps traffic private.
The same concept can be used for:
Azure Storage
Azure SQL Database
Azure Key Vault
Azure App Service
Azure Cosmos DB
Other Private Link-supported services
In cross-subscription scenarios, the private endpoint connection may need approval from someone who has permissions on the target resource.
Role of Azure RBAC
Azure RBAC controls who is allowed to create or modify the connectivity.
For example, to create VNet peering between two VNets in different subscriptions, you usually need permissions on both VNets.
Example:
User or admin account
├── Network Contributor on vnet-prod
└── Network Contributor on vnet-dr
If you only have permissions on one side, you may not be able to complete the peering.
This is especially important in larger companies where different teams manage different subscriptions.
Role of Azure Policy
Azure Policy can indirectly affect connectivity.
For example, one management group may have a policy that blocks certain networking actions.
Management Group: Production
└── Policy: Deny VNet peering
└── Subscription: Production
In this case, even though Azure technically supports cross-subscription peering, the policy may prevent you from creating it.
Other policies may restrict:
Allowed regions
Allowed resource types
Public IP creation
Private endpoint creation
VNet peering
Required tags
Allowed VM SKUs
So when connectivity fails or a deployment is blocked, always check whether Azure Policy is denying the action.
Role of NSGs and Firewalls
Even after the network is connected, traffic can still be blocked.
Common blocking points include:
NSG on source subnet
NSG on destination subnet
NSG on source NIC
NSG on destination NIC
Azure Firewall
Network Virtual Appliance
Windows Defender Firewall
Linux firewall
Application-level firewall
For example:
VNet peering status: Connected
NSG blocks TCP 3389
Result: RDP fails
This is why you should not only check whether peering exists. You must also verify the full traffic path.
Role of DNS
Network connectivity does not automatically guarantee name resolution.
For example, this may work:
Test-NetConnection 10.20.1.4 -Port 3389
But this may fail:
Test-NetConnection dr-vm01.domain.local -Port 3389
If you want VMs in different VNets or subscriptions to resolve each other by name, you may need:
Custom DNS servers
Domain controllers reachable across VNets
Azure Private DNS zones
Private DNS zone VNet links
Conditional forwarders
DNS forwarders
DNS is especially important in Active Directory environments, hybrid environments, and Private Endpoint designs.
Direct Peering vs Hub-and-Spoke
For small environments, direct VNet peering may be enough.
Example:
vnet-prod ⇄ vnet-dr
But for larger environments, hub-and-spoke is usually better.
Example:
vnet-prod ⇄ hub-vnet ⇄ vnet-dr
Direct peering is simple, but it can become messy when you have many VNets.
Hub-and-spoke gives you centralized security, routing, and visibility.
Important Design Requirements
Before connecting resources across subscriptions, check the following:
1. Are the subscriptions under the correct tenant?
2. Do you have permissions on both sides?
3. Do the VNet IP ranges overlap?
4. Are the required peerings created?
5. Are route tables configured correctly?
6. Are NSGs allowing the traffic?
7. Are firewalls allowing the traffic?
8. Is DNS configured correctly?
9. Is Azure Policy blocking anything?
10. Are the guest operating system firewalls allowing the traffic?
Most connectivity issues happen because one of these points is missed.
Final Summary
Yes, Azure resources in one subscription can connect to resources in another subscription, even if both subscriptions are under different management groups in the same Microsoft Entra tenant.
Management groups are mainly for governance. They do not automatically block connectivity.
The actual connectivity depends on networking, routing, security rules, DNS, permissions, and policies.
The most common connection methods are:
VNet peering
Hub-and-spoke networking
VPN Gateway
ExpressRoute
Private Endpoint / Private Link
For simple VM-to-VM private communication, VNet peering is usually the easiest option.
For enterprise environments, hub-and-spoke networking is usually the better long-term design because it centralizes firewalling, routing, DNS, and connectivity to on-premises networks.
The best way to think about it is:
Management groups control governance.
Subscriptions contain resources.
VNets provide network connectivity.
NSGs and firewalls control traffic.
DNS controls name resolution.
Azure RBAC controls who can configure it.
Azure Policy controls what is allowed.
Once these pieces are understood, designing cross-subscription connectivity in Azure becomes much easier.