Allow a VM's NIC to use a VNET\Subnet from another Subscription
Given that the syntax of json deployment templates allows referencing resources by a unique resourceid which includes the guid of the subscription, I would like to create a VM in subscription 'A', whose NIC references a subnet that is part of a VNET in subscription 'B'.
The reason for this is two-fold:
1) This would allow a corporate networking function to securely manage all the networking infrastructure in a corporate IT-owned and managed subscription, but allow it to be consumed by line-of-business units, whose subscriptions are restricted (via ARM policies) to not allow the creation of VNETs.
2) This would eliminate the need to create a regional VNET (and therefore IP address space) per line-of-business subscription, allowing for sharing of (and therefore more efficient use of) IP address spaces.
Carving up of IP address spaces in a large organisation such as ours presents administrative challenges. It would be far nicer if all Azure networking could be managed centrally and more effectively by the corporate networking function, rather than having to be managed across all subscriptions.
John Wildes commented
Planned since 2017...sounds like it's not really planned.
Brad Younge commented
This is a critical need for all sorts of compliance and regulation reasons. Without this ability, permission management across a large cloud infrastructure with several product teams developing cloud based products becomes unmanageable.
Mike O'Shaughnessy commented
Looking for a status update on this one as well.
Matt Pound commented
Any news on this please ? It would make the deployment of large numbers of machines (VDI for instance) a lot easier.
How is the status of this improvement?
"Each NIC attached to a VM must exist in the same location and subscription as the VM. Each NIC must be connected to a VNet that exists in the same Azure location and subscription as the NIC. You can change the subnet a VM is connected to after it's created, but you cannot change the VNet."
=> It would be great for billing purposes as well, if the NIC and VM can be located in different subscriptions than the VNET.
I can't agree more.