Cross-subscription VNet (Shared VNet)
A virtual network that spans subscriptions. Multiple different subscriptions can deploy to the same virtual network in a region.
If you are interested in this feature, please up-vote and add details about your company/scenario.
We appreciate the feedback.
- VNet Team [MSFT]
wagner cecato commented
Any news about this feature request ? AWS and GCP already have it .
This capability would enable a project group (group B) to better automate their subscription provisioning process through the use of a shared VNET that has that has been preconfigured and is managed at a higher level by a separate group (group A) . It would allow the project group to be responsible for carving up or sharing the VNET with sub-project subscriptions used by application groups (group C), while group A remains responsible for the overall configuration and integrity of the shared VNET.
Ditto to "Anonymous" below. For larger implementations, VPC Sharing capabilities as per https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-a-new-approach-to-multiple-accounts-and-vpc-management/, are sorely missed in Azure. Customers want to decentralise ownership of the resources themselves, and enable CICD capabilities for Business Units, while retaining central governance of network core ops, connectivity management and flow governance policy. Very hard to get this mix right in Azure currently, and requires "multiples of" VNETs designed for the same underlying purpose, where a sharing model would not.
One year and nothing, GCP has this feature...
Raakesh Nagarajan commented
Can you please provide an ETA for this? We need this urgently for a customer else they will host in AWS which has VPC Sharing service! Thanks
we have some use for this function too
1.) we like to follow the Microsoft Governance strategie and build team/Produkt oriented Management groups to structure Subscriptions. As an agile comany we will end up with a lot of subscriptions following the strategy and so also a lot of vNets for Produktion, Test and Development. The all will be connected using vNet peering. As you can imagine this will end up in a horrible meshed Network of peered vNets.
It will be much comfortable if we can share a development (Productive, Test) vNet over several Subscriptions. Then we ca use the subscription container to manage the ownership of networking in this vNet, manageing linux plattforms and windows Plattforms in der same vNet etc. You can do it actually by using ressourcegroups but this nice funktion will be use for morte granular ressource aggregations.
Google I can do that!!!!
wagner cecato commented
I have some use for this function.
1. I have some departaments in our company and want to be able to create just one network infrastructure and let then deploy their vms on this shared vnet. The billing for the vm will happen on their subscription and we will have just one network infrastructure with our corporate security rules and communication to on premise network.
2. We can contract some companies to deploy specific services using a specific subscription but connected to our vnet environment with our security rules and connections.
3. We are multinacional company and we have separate operation in many countries and need to have a subscription per unit and a shared vnet where the vms/fuctions will be pluged.