[Documentation] Update Private Networking Address Space Recommendation

[AErmie]

⚠️ Problem

The FinOps hub virtual network documentation currently states: "The virtual network should be a /26 (64 IP addresses in size).

If you deploy the FinOps Toolkit, and plan to use the Virtual Network Data Gateway (or a self-hosted/personal data gateway), you need a subnet allocated for that.

It can be a challenge to expand an existing VNet to a larger address space (ie. /24) to accommodate this, especially when IPAM solutions are used.

🛠️ Solution

Please update the documentation, to recommend a /24 address space, to allow sufficient room for additional data connectivity requirements.

🙋‍♀️ Ask for the community

We could use your help:

1. Please vote this issue up (👍) to prioritize it.
2. Leave comments to help us solidify the vision.

[flanakin]

@MSBrett Can you take a look at this?

[MSBrett]

@AErmie - We don't need a full /24 for the toolkit in this scenario.
To support the PBI data gateway scenario one can add an additional /28 subnet to the virtual network and delegate it to the PBI service. We won't touch the subnet during upgrades.

The range assigned to the PBI subnet doesn't even need to be routable outside of the vNet.

More details here

[AErmie]

Thanks @MSBrett, however, the default deployment of the FinOps Toolkit sets the Address prefix to a /26.

The FTK deployment, creates the following subnets within the VNet:

• private-endpoint-subnet /28
• script-subnet /28
• dataExplorer-subnet /27

These subnets consume the entire /26 address space.

However, if someone is using an IPAM solution to manage the CIDR address spaces, and they want to use the PowerBI Data Gateway, but is not aware of it's network space requirements (ie. approximately 5-7 IPs, per the Virtual network (virtual network) data gateway FAQs documentation), then they're in a position where they have to try to expand the existing VNet, or add a secondary address space to the VNet.

[MSBrett]

@AErmie - I'm hesitant to expand the default IP address space. I'd prefer a solution where we can enable public access to Kusto and secure it using conditional access policies so we can do direct query from a pro workspace.

The managed gateway is only available to premium PBI SKUs so the audience is limited and most of those customers already have a gateway deployed elsewhere (so it's more a peering and DNS discussion). If we could deploy the gateway via bicep this would be a no-brainer, but the gateway can't be managed by the toolkit so we prefer it to be deployed to a different vNet where we don't accidentally break it during upgrades. Expanding the vNet address space is doable, but not the preferred approach.