⚠️ Problem
FinOps hubs configured for private networking need to support enterprise network topologies. Requiring every deployment to create a new virtual network prevents organizations from using an existing, centrally managed VNet and its approved subnets, which can block deployments that must comply with network, security, and DNS policies.
This is needed only for organizations that use private networking and already manage their virtual network outside the FinOps hub deployment. Organizations without those requirements should still be able to use the default network deployment experience.
🛠️ Solution
Allow a FinOps hub private-networking deployment to use an existing virtual network and caller-provided subnets for private endpoints and dependent services. The deployment should also support optional controlled outbound access through a NAT Gateway and optional creation of the required private DNS zones, so organizations can either use centrally managed DNS zones or have the hub create them.
The deployment experience should validate the supplied network resource ID and preserve the existing behavior for deployments that create a new VNet or use public networking.
ℹ️ Additional context
The request is intended for hub deployments that need private connectivity while remaining aligned with existing enterprise network ownership and governance. Subnet delegation and private endpoint configuration must remain compatible with the services deployed by the hub.
Making the VNet and DNS zones deployment-owned in every case is not suitable for organizations with centralized networking teams or shared DNS management. Making private networking mandatory would also increase deployment complexity for users who do not need it, so these capabilities should remain optional.
🙋♀️ Ask for the community
We could use your help:
- Please vote this issue up (👍) to prioritize it.
- Leave comments to help us solidify the vision.
FinOps hubs configured for private networking need to support enterprise network topologies. Requiring every deployment to create a new virtual network prevents organizations from using an existing, centrally managed VNet and its approved subnets, which can block deployments that must comply with network, security, and DNS policies.
This is needed only for organizations that use private networking and already manage their virtual network outside the FinOps hub deployment. Organizations without those requirements should still be able to use the default network deployment experience.
🛠️ Solution
Allow a FinOps hub private-networking deployment to use an existing virtual network and caller-provided subnets for private endpoints and dependent services. The deployment should also support optional controlled outbound access through a NAT Gateway and optional creation of the required private DNS zones, so organizations can either use centrally managed DNS zones or have the hub create them.
The deployment experience should validate the supplied network resource ID and preserve the existing behavior for deployments that create a new VNet or use public networking.
ℹ️ Additional context
The request is intended for hub deployments that need private connectivity while remaining aligned with existing enterprise network ownership and governance. Subnet delegation and private endpoint configuration must remain compatible with the services deployed by the hub.
Making the VNet and DNS zones deployment-owned in every case is not suitable for organizations with centralized networking teams or shared DNS management. Making private networking mandatory would also increase deployment complexity for users who do not need it, so these capabilities should remain optional.
🙋♀️ Ask for the community
We could use your help: