Add BYO-VNet support and standardized resource naming for FinOps hubs

[fatimataayeb]

Add BYO-VNet support and standardized resource naming for FinOps hubs

Summary

Enables FinOps hub deployments into existing customer VNets (hub-and-spoke scenarios) and applies a standardized, deterministic resource naming convention that aligns with the Cloud Adoption Framework (CAF) and customer governance policies.

Motivation

Today the FinOps hub template:

1. Always creates a brand-new VNet (vnet-{hubName}) and subnets — incompatible with hub-and-spoke topologies where private connectivity is centralized in a hub VNet owned by the network team
2. Uses non-deterministic / hash-suffixed resource names (e.g. finopshub-c3orenemzlnm6) — fails customer naming standards, breaks Azure Policy naming rules, and makes resources hard to identify in shared subscriptions

These two limitations have blocked enterprise deployments at multiple regulated customers (banking, public sector) where:

• A hub-and-spoke network architecture is mandated and private endpoints must land in pre-existing subnets
• A resource naming policy is enforced via Azure Policy and deployments are denied if names don't match

Note: These changes may break future updates, do it at your own risk

What's changed

1. BYO-VNet support

New optional parameters on main.bicep:

Parameter	Description	Default
existingVNetName	Name of the customer's existing VNet	'' (creates new VNet)
existingVNetResourceGroupName	RG of the existing VNet (supports cross-RG)	''
peSubnetName	Subnet for private endpoints	snet-finops-pe-01
scriptSubnetName	Subnet for deployment scripts (ACI)	snet-finops-script-01
dataExplorerSubnetName	Subnet for ADX (if used)	snet-finops-adx-01

When existingVNetResourceGroupName is provided (or networkName does not start with vnet-finops-), the template skips creating NSG/VNet/subnets and uses cross-RG resourceId(...) references. All private endpoints and ACI containers land in the customer's existing subnets.

2. CAF-aligned resource naming

All resource names follow {abbreviation}-finops-{hubName} (storage follows stgfinops{hubName}{instance}):

Resource	Old	New
Data Factory	finopshub-<hash>	adf-finops-{hubName}
Key Vault	finopshubkv<hash>	kv-finops-{hubName}
Storage (data lake)	finopshubstg<hash>	stgfinops{hubName}01
Storage (script)	finopshubstg<hash>script	stgfinops{hubName}02
NSG	finopshub-nsg-<hash>	nsg-finops-{hubName}
VNet	finopshub-vnet-<hash>	vnet-finops-{hubName}
Managed Identity	finopshub-mi-<hash>	id-finops-{hubName}
Event Grid System Topic	(implicit on trigger start)	evg-finops-{hubName}
PE (blob)	finopshub-pep-<hash>	pep-finops-stgblob-{hubName}
PE (DFS)	finopshub-pep-<hash>	pep-finops-stgdfs-{hubName}
PE (KV)	finopshub-pep-<hash>	pep-finops-kv-{hubName}

All names respect per-resource character limits via take() in hub-types.bicep.

3. Explicit Event Grid system topic

evg-finops-{hubName} is now declared in Bicep, sourced from the hub data lake. Previously this was implicitly created when the storage event trigger was activated, making RBAC/tagging policies harder to apply. Explicit declaration gives customers IaC control.

Files changed (5)

• src/templates/finops-hub/main.bicep — new BYO-VNet parameters
• src/templates/finops-hub/modules/hub.bicep — forwards new parameters
• src/templates/finops-hub/modules/fx/hub-types.bicep — HubRoutingProperties extended; newHub/newApp apply naming
• src/templates/finops-hub/modules/fx/hub-app.bicep — PE naming + Event Grid topic
• src/templates/finops-hub/modules/Microsoft.FinOpsHubs/Core/infrastructure.bicep — BYO-VNet aware (gates resource creation, cross-RG references)

Benefits

Persona	Benefit
Enterprise architect	Deploy into existing hub-and-spoke topology without exception requests
Network admin	No new VNets, no peering, no IP planning — PEs land in pre-approved subnets
Cloud governance	Resource names pass Azure Policy naming rules out of the box
FinOps practitioner	Resources immediately identifiable in shared subscriptions (no random suffixes)
Toolkit maintainer	Backwards compatible — all new parameters optional with sensible defaults

Backwards compatibility

• All new parameters are optional with defaults that reproduce current behavior
• When BYO-VNet parameters are not specified, the template creates a VNet exactly as today
• Existing deployments would need resource recreation to pick up the new naming (Azure does not support most resource renames)

Testing

• ✅ Bicep compiles cleanly (az bicep build)
• ✅ ARM template validation passes (az deployment group validate) for both BYO-VNet and create-new-VNet scenarios
• ✅ End-to-end deployed at a banking customer in qatarcentral into pre-existing hub-and-spoke subnets, using customer-mandated naming convention
• ✅ FOCUS Cost ingestion validated end-to-end: exports → msexports → ETL pipelines → ingestion container → Power BI

[fatimataayeb]

@microsoft-github-policy-service agree