diff --git a/.gitignore b/.gitignore index 198952770..20001eabc 100644 --- a/.gitignore +++ b/.gitignore @@ -384,6 +384,7 @@ env/ # Auto-generated build artifacts src/templates/finops-hub-copilot-studio/knowledge/query-catalog.md .gate/ +.copilot-tracking/ todo/ done/ release/scloud-occurrence-report.md diff --git a/docs-mslearn/toolkit/changelog.md b/docs-mslearn/toolkit/changelog.md index 5628fcb1c..51e938bdb 100644 --- a/docs-mslearn/toolkit/changelog.md +++ b/docs-mslearn/toolkit/changelog.md @@ -3,7 +3,7 @@ title: FinOps toolkit changelog description: Review the latest features and enhancements in the FinOps toolkit, including updates to FinOps hubs, Power BI reports, and more. author: MSBrett ms.author: brettwil -ms.date: 08/19/2026 +ms.date: 08/22/2026 ms.topic: reference ms.service: finops ms.subservice: finops-toolkit @@ -30,6 +30,7 @@ The following section lists features and enhancements that are currently in deve - **Added** - Added VNet and private network modes, including opt-in NAT Gateway support for private mode; NAT Gateway incurs additional cost when enabled ([#2163](https://github.com/microsoft/finops-toolkit/pull/2163)). - **Changed** + - Clarified that the FinOps toolkit exclusively manages the FinOps hub virtual network and documented customer-managed private endpoints as the preferred private-access topology, with virtual network peering as a secondary option ([#2156](https://github.com/microsoft/finops-toolkit/issues/2156)). - Replaced redundant `tolower()` comparisons in hub KQL with case-insensitive operators (`has`, `=~`, `!~`) so the engine can use the term index instead of scanning every row ([#2213](https://github.com/microsoft/finops-toolkit/issues/2213)). - Replaced whole-term `contains` matches with `has` across hub KQL and the query catalog (resource ID paths, licensing phrases, SKU description terms) and added a per-row operator-equivalence regression harness with unit test coverage ([#2220](https://github.com/microsoft/finops-toolkit/pull/2220)). - **Fixed** diff --git a/docs-mslearn/toolkit/hubs/deploy.md b/docs-mslearn/toolkit/hubs/deploy.md index 570c42ff3..3a7e853ab 100644 --- a/docs-mslearn/toolkit/hubs/deploy.md +++ b/docs-mslearn/toolkit/hubs/deploy.md @@ -3,7 +3,7 @@ title: How to create and update FinOps hubs description: This tutorial helps you create a new or update an existing FinOps hubs instance in Azure or Microsoft Fabric. author: flanakin ms.author: micflan -ms.date: 08/13/2026 +ms.date: 08/19/2026 ms.topic: tutorial ms.service: finops ms.subservice: finops-toolkit @@ -84,9 +84,9 @@ Public routing is most common and easiest to use. Resources are reachable from t Do you prefer public or private network routing? - Public routing is most common, easiest to use, and makes resources reachable from the open internet. -- Private routing is most secure, comes with added cost, and makes resources only reachable from peered networks. +- Private routing is most secure, comes with added cost, and makes resources reachable through private connectivity. -Public routing doesn't require configuration. If you opt for private routing, work with your network admin to configure peering and routing so the FinOps hubs isolated network is reachable from your network. Before you decide, learn more about the extra configuration steps required in [Configure private networking](private-networking.md). +Public routing doesn't require configuration. If you opt for private routing, work with your network admin to create private endpoints and DNS in your own virtual network (preferred) or configure virtual network peering and routing (secondary). Before you decide, learn more about the ownership boundaries and configuration steps in [Configure private networking](private-networking.md).
diff --git a/docs-mslearn/toolkit/hubs/media/private-networking/finops-hubs-customer-endpoints.png b/docs-mslearn/toolkit/hubs/media/private-networking/finops-hubs-customer-endpoints.png new file mode 100644 index 000000000..c8b645993 Binary files /dev/null and b/docs-mslearn/toolkit/hubs/media/private-networking/finops-hubs-customer-endpoints.png differ diff --git a/docs-mslearn/toolkit/hubs/media/private-networking/finops-hubs-network-peering.png b/docs-mslearn/toolkit/hubs/media/private-networking/finops-hubs-network-peering.png index 325cbd126..2fdb9ee53 100644 Binary files a/docs-mslearn/toolkit/hubs/media/private-networking/finops-hubs-network-peering.png and b/docs-mslearn/toolkit/hubs/media/private-networking/finops-hubs-network-peering.png differ diff --git a/docs-mslearn/toolkit/hubs/media/private-networking/finops-hubs-private-network.png b/docs-mslearn/toolkit/hubs/media/private-networking/finops-hubs-private-network.png index 58ae9870e..34e49a2e3 100644 Binary files a/docs-mslearn/toolkit/hubs/media/private-networking/finops-hubs-private-network.png and b/docs-mslearn/toolkit/hubs/media/private-networking/finops-hubs-private-network.png differ diff --git a/docs-mslearn/toolkit/hubs/media/private-networking/finops-hubs-public-network.png b/docs-mslearn/toolkit/hubs/media/private-networking/finops-hubs-public-network.png index 957cfa6c2..5ed21f363 100644 Binary files a/docs-mslearn/toolkit/hubs/media/private-networking/finops-hubs-public-network.png and b/docs-mslearn/toolkit/hubs/media/private-networking/finops-hubs-public-network.png differ diff --git a/docs-mslearn/toolkit/hubs/private-networking.md b/docs-mslearn/toolkit/hubs/private-networking.md index d328c8d6e..ad5262035 100644 --- a/docs-mslearn/toolkit/hubs/private-networking.md +++ b/docs-mslearn/toolkit/hubs/private-networking.md @@ -3,7 +3,7 @@ title: Configure private networking in FinOps hubs description: Learn about data access options with FinOps hubs and how to configure secure access to your data with private endpoints. author: flanakin ms.author: micflan -ms.date: 04/01/2026 +ms.date: 08/22/2026 ms.topic: how-to ms.service: finops ms.reviewer: micflan @@ -24,26 +24,58 @@ Public access in FinOps hubs has the following traits: - Storage is accessible via public IP addresses (firewall set to public). - Data Explorer (if deployed) is accessible via public IP addresses (firewall set to public). - Key Vault is accessible via public IP addresses (firewall set to public). -- Azure Data Factory is configured to use the public integration runtime. +- Azure Data Factory uses the default Azure integration runtime. -:::image type="content" source="./media/private-networking/finops-hubs-public-network.png" border="false" alt-text="Screenshot of publicly accessible deployments." lightbox="./media/private-networking/finops-hubs-public-network.png" ::: +The default Azure integration runtime calls Cost Management APIs to create and run exports. Cost Management writes export files to Storage. Data Factory pipelines then process the files and, if deployed, load Data Explorer. Remote hubs use Key Vault for secrets. + +:::image type="content" source="./media/private-networking/finops-hubs-public-network.png" border="false" alt-text="Diagram of public routing between Cost Management, Data Factory, Storage, Data Explorer, and Key Vault." lightbox="./media/private-networking/finops-hubs-public-network.png" :::
## How private access works -Private access is a more secure option that places FinOps hubs resources on an isolated network and limits access via private networking: +Private routing uses service-specific network controls and private endpoints for data access: + +- Storage is accessible through a private IP address. Its public endpoint remains enabled, but the firewall denies access by default and allows trusted Azure services. +- Data Explorer (if deployed) disables public network access and is accessible through a private IP address. +- Key Vault (remote hubs only) is accessible through a private IP address. Its firewall denies access by default and allows trusted Azure services. +- Azure Data Factory uses a managed integration runtime in a separate Data Factory managed virtual network for data-store traffic. The default Azure integration runtime runs Cost Management API activities. +- The FinOps hub virtual network contains Toolkit-managed private endpoints and deployment and runtime subnets. + +:::image type="content" source="./media/private-networking/finops-hubs-private-network.png" border="false" alt-text="Diagram of private routing through FinOps hub and Data Factory managed virtual networks to hub services." lightbox="./media/private-networking/finops-hubs-private-network.png" ::: + +### Security posture + +Private routing separates data-plane traffic from trusted-service and management-plane traffic. Customer access to Storage and Data Explorer uses private endpoints. Data Factory moves pipeline data through managed private endpoints and calls Cost Management APIs through the default Azure integration runtime. The Storage firewall allows trusted Azure services so Cost Management exports can write cost data. Data Factory management remains available in the Azure portal, so operators can author and monitor pipelines without connecting to the FinOps hub virtual network. + +These paths don't provide general internet access to data. Role-based access control, service authentication, and default-deny firewall rules continue to protect access. -- Public network access is disabled by default. -- Storage is accessible via private IP address and trusted Azure services - firewall is set to default deny with bypass for services on trusted list. -- Data Explorer (if deployed) is accessible via private IP address - firewall is set to default deny with no exceptions. -- Key vault is accessible via private IP address and trusted Azure services - firewall is set to default deny with bypass for services on trusted list. -- Azure Data Factory is configured to use the public integration runtime, which helps reduce costs. -- A virtual network is deployed to ensure communication between all components during deployment and at runtime remains private. +The FinOps toolkit exclusively owns and manages the FinOps hub virtual network, its three subnets, private endpoints, private DNS, routing, and related resources. This network supports FinOps hub deployment and operation; it isn't a shared network for customer resources. -:::image type="content" source="./media/private-networking/finops-hubs-private-network.png" border="false" alt-text="Screenshot of privately accessible deployments." lightbox="./media/private-networking/finops-hubs-private-network.png" ::: +Don't add customer workloads, subnets, gateways, endpoints, DNS, route tables, or other configuration inside the Toolkit-managed virtual network. The Toolkit doesn't preserve customer additions during deployment or upgrade operations. -Note that private networking incurs extra cost for networking resources, connectivity, and dedicated compute in Azure Data Factory. For a detailed cost estimate, please refer to the Azure pricing calculator. +Private networking adds costs for networking resources, connectivity, and dedicated compute in Azure Data Factory. For a detailed estimate, see the Azure pricing calculator. + +
+ +## Preferred option: customer-managed private endpoints + +For private access from your network, create and manage private endpoints and DNS in your own virtual network for the FinOps hub Storage and Azure Data Explorer resources. This topology is preferred because it keeps customer networking separate from the Toolkit-managed virtual network. The Toolkit doesn't deploy or manage resources in your network. + +Create the following private endpoints: + +| Resource | Target subresources | DNS configuration | +| --- | --- | --- | +| FinOps hub Storage | `blob` and `dfs` | Link private DNS zones for both subresources | +| Azure Data Explorer (if deployed) | `cluster` | Use the `requiredZoneNames` returned by the cluster's `privateLinkResources` API | + +DNS zone names vary by Azure cloud. Use the values for your cloud in [Azure Private Endpoint private DNS zone values](/azure/private-link/private-endpoint-dns). For more information about the Data Explorer endpoint, see [Create a private endpoint for Azure Data Explorer](/azure/data-explorer/security-network-private-endpoint-create). + +:::image type="content" source="./media/private-networking/finops-hubs-customer-endpoints.png" border="false" alt-text="Diagram of customer-managed Storage and Data Explorer private endpoints, with separate FinOps hub and Data Factory networks." lightbox="./media/private-networking/finops-hubs-customer-endpoints.png" ::: + +The endpoint and DNS symbols in the diagram represent the complete set required for each resource. Azure Private Link connects these endpoints directly to Storage and Azure Data Explorer without entering or peering with the FinOps hub virtual network. The Toolkit-managed virtual network remains deployed for internal connectivity. For configuration guidance, see [Private Endpoint overview](/azure/private-link/private-endpoint-overview) and [Private Endpoint DNS integration](/azure/private-link/private-endpoint-dns-integration). + +If you use a Power BI virtual network data gateway, deploy it in your own virtual network and plan enough subnet address space for the gateway. Don't deploy the gateway in the FinOps hub virtual network. When you connect to Azure Data Explorer, use the fully qualified domain name (FQDN) shown for the cluster in Azure. Don't use an abbreviated cluster name.
@@ -51,13 +83,13 @@ Note that private networking incurs extra cost for networking resources, connect The following table compares the network access options available in FinOps hubs: -| Component | Public | Private | Benefit | -| ------------------- | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | -| Storage | Accessible over the internet¹ | Access restricted to the FinOps hub network, peered networks (for example, corporate vNet), and trusted Azure services | Data only accessible when at work or on the corporate VPN | -| Azure Data Explorer | Accessible over the internet¹ | Access restricted to the FinOps hub network, peered networks (for example, corporate vNet), and trusted Azure services | Data only accessible when at work or on the corporate VPN | -| Key vault | Accessible over the internet¹ | Access restricted to the FinOps hub network, peered networks (for example, corporate vNet), and trusted Azure services | Keys and secrets are never accessible via to the open internet | -| Azure Data Factory | Uses public compute pool | Managed integration runtime in a private network with Data Explorer, storage, and key vault | All data processing happens inside the network | -| Virtual Network | Not used | FinOps hub traffic happens within an isolated vNet | Everything remains private; ideal for regulated environments | +| Component | Public | Private | Benefit | +| ------------------- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | +| Storage | Accessible over the internet¹ | Customer-managed private endpoints in your virtual network (preferred) or customer-managed peering (secondary) | Data access can remain private to your network | +| Azure Data Explorer | Accessible over the internet¹ | Customer-managed private endpoints in your virtual network (preferred) or customer-managed peering (secondary) | Data access can remain private to your network | +| Key Vault (remote hubs only) | Accessible over the internet¹ | Access through Toolkit-managed private endpoints and trusted Azure services | Keys and secrets aren't accessible from the open internet | +| Azure Data Factory | Uses the default Azure integration runtime | Uses the managed integration runtime for data-store traffic and the default Azure integration runtime for management-plane activities | Data-store traffic uses managed private endpoints | +| Virtual Network | Not used | Toolkit-owned FinOps hub virtual network for private endpoints and deployment and runtime subnets | Toolkit networking remains separate from customer resources | _¹ While resources are accessible over the internet, access is still protected by role-based access control (RBAC)._ @@ -69,18 +101,17 @@ To enable private networking when deploying a new or updating an existing FinOps :::image type="content" source="./media/private-networking/finops-hubs-private-deployment.png" alt-text="Screenshot of secure private deployments." lightbox="./media/private-networking/finops-hubs-private-deployment.png" ::: -Before enabling private access, review the networking details on this page to understand the extra configuration required in order to connect to your hub instance. Once enabled, your FinOps hub instance is inaccessible until network access is configured outside of the FinOps hub instance. We recommend sharing this with your network admins to ensure the IP range meets network standards and they understand how to connect your hub instance to the existing network. +Before enabling private access, review the networking details on this page and coordinate with your network admins. Configure customer-managed private endpoints and DNS in your own network (preferred), or use the secondary peering option, before users and systems connect to the hub.
## Removing private networking -If you need to reduce costs or simplify your FinOps hub deployment, you can remove private networking and switch back to public access. This change will: +If you need to reduce costs or simplify your FinOps hub deployment, you can switch back to public access. Redeploying with **Access** set to **Public** configures Storage, Data Explorer (if deployed), and Key Vault to use public access and switches Azure Data Factory back to the default Azure integration runtime. -- Remove the virtual network and associated networking costs -- Disable private endpoints and DNS zones -- Configure storage, Data Explorer, and Key Vault to use public access -- Switch Azure Data Factory back to the public integration runtime +The incremental deployment retains the Toolkit-created virtual network, network security groups, private endpoints, private DNS zones, deployment-script Storage account, Data Factory managed virtual network and private endpoints, managed integration runtime, and optional NAT Gateway and static public IP address. Customer-managed resources in your network are also outside the Toolkit deployment and aren't removed. + +Retained resources don't all have standing charges. Private endpoints, private DNS zones, NAT Gateway, public IP address, and data in the deployment-script Storage account can continue to accrue charges. The managed integration runtime incurs charges only when it runs. > [!WARNING] > Removing private networking is a significant change that will affect how you access your FinOps hub. Ensure all stakeholders understand the security implications before proceeding. @@ -89,9 +120,9 @@ If you need to reduce costs or simplify your FinOps hub deployment, you can remo 1. **Plan the transition**: - - Identify all users and systems currently accessing the hub via private networking - - Coordinate with your network administrators about the change - - Schedule maintenance window as the hub will be temporarily inaccessible during the transition + - Identify all users and systems that access the hub through private networking. + - Coordinate the change with your network administrators. + - Schedule a maintenance window because the hub is temporarily unavailable during the transition. 2. **Update the FinOps hub deployment**: @@ -99,47 +130,39 @@ If you need to reduce costs or simplify your FinOps hub deployment, you can remo **Option 1: Redeploy from existing deployment** - - Navigate to your FinOps hub resource group in the Azure portal - - Go to the **Deployments** tab on the resource group - - Find and open the original FinOps hub deployment - - Click **Redeploy** - - On the **Advanced** tab, set **Access** to **Public** - - Review all other settings to ensure they remain as desired - - Deploy the updated configuration + - In the Azure portal, open the FinOps hub resource group. + - In the resource group menu, select **Deployments**. + - Open the original FinOps hub deployment. + - Select **Redeploy**. + - On the **Advanced** tab, set **Access** to **Public**. + - Review the other settings. + - Deploy the updated configuration. **Option 2: Deploy latest toolkit version** - - Install the latest current version of the FinOps toolkit - - Use the same resource group name, hub name, and Data Explorer cluster name as your existing deployment - - These values can be obtained from the original deployment template or the config.json file in your hub storage account - - On the **Advanced** tab, set **Access** to **Public** - - Deploy with the same configuration to update your existing hub + - Install the latest version of the FinOps toolkit. + - Use the same resource group name, hub name, and Data Explorer cluster name as the existing deployment. + - Get these values from the original deployment template or the `config.json` file in the hub storage account. + - On the **Advanced** tab, set **Access** to **Public**. + - Deploy the same configuration to update the existing hub. 3. **Verify the changes**: - - Confirm that storage accounts, Data Explorer, and Key Vault are accessible via public endpoints - - Test data access from Power BI and other connected systems - - Verify that Azure Data Factory pipelines continue to run successfully + - Confirm that Storage, Data Explorer, and Key Vault are accessible through public endpoints. + - Test data access from Power BI and other connected systems. + - Verify that Azure Data Factory pipelines continue to run successfully. -4. **Clean up networking resources** (optional): +4. **Clean up private networking resources** (optional): - - Once you've confirmed the hub is working correctly with public access, you can delete the networking resources to stop incurring networking costs + - After you confirm the hub works with public access, delete only Toolkit-created resources that you no longer need. - Delete resources in the following order to avoid dependency conflicts: - 1. Private endpoints - 2. Private DNS zones - 3. Virtual network and network security groups (NSGs) - - Be cautious when deleting resources manually - ensure they're not being used by other systems - -5. **Remove Azure Data Factory managed integration runtime** (optional): - - When private networking was enabled, Azure Data Factory may have created a managed integration runtime for secure data processing - - While leaving the managed integration runtime won't break functionality, it does carry ongoing costs - - To remove the managed integration runtime: - 1. Navigate to your Azure Data Factory instance in the Azure portal - 2. Go to **Manage** > **Integration runtimes** - 3. Identify any managed integration runtimes that were created for private networking (typically named with your hub instance) - 4. Stop and delete the managed integration runtime if it's no longer needed - 5. Verify that your data pipelines continue to work with the public integration runtime - - Only remove managed integration runtimes that were specifically created for the FinOps hub private networking setup + 1. Delete the Data Factory managed private endpoints, managed integration runtime, and managed virtual network. + 2. Delete the Toolkit-created private endpoints. + 3. Delete the private DNS zones. + 4. Delete the virtual network and network security groups (NSGs). + 5. Delete the NAT Gateway and static public IP address, if deployed. + 6. Delete the deployment-script Storage account. + - Don't delete customer-managed networking resources as part of the FinOps hub cleanup. > [!NOTE] > After removing private networking, your FinOps hub data will be accessible over the internet, though still protected by role-based access control (RBAC) and transport layer security (TLS). Review your organization's security policies to ensure this meets your requirements. @@ -155,61 +178,61 @@ If you need to reduce costs or simplify your FinOps hub deployment, you can remo ## FinOps hub virtual network -When private access is selected, your FinOps hub instance includes a virtual network to ensure communication between its various components remain private. - -- The virtual network can be any subnet size from **/8** to **/26**, with a minimum of **/26** (64 IP addresses) required. The default is **/26** to conserve IP addresses while providing the minimum required subnet sizes for Container Services (used during deployments for running scripts) and Data Explorer. -- The IP range can be set at the time of deployment and defaults to **10.20.30.0/26**. Choose a larger subnet (like **/24** or smaller) if you need additional address space for services such as Power BI VNet Data Gateway. +When private access is selected, the Toolkit creates and exclusively manages the FinOps hub virtual network, its three subnets, private endpoints, private DNS, routing, and related resources. The network supports private communication between hub components. -If necessary, you can create the virtual network, subnets, and optionally peer it with your hub network before deploying FinOps hubs if you follow these requirements: +- The virtual network address range can be any size from **/8** through **/26**, with a minimum address space of **/26** (64 IP addresses). The default is **/26** to conserve IP addresses while providing the minimum required subnet sizes for Azure Container Instances deployment scripts and Data Explorer. +- The IP range can be set at the time of deployment and defaults to **10.20.30.0/26**. The Toolkit divides the range into three subnets: + - **private-endpoint-subnet** (**/28**) – hosts private endpoints for Storage, deployment-script Storage, and Key Vault (remote hubs only). + - **script-subnet** (**/28**) – delegated to Azure Container Instances for running deployment scripts. + - **dataExplorer-subnet** (**/27**) – hosts the private endpoint for Data Explorer. +- If you use a Power BI virtual network data gateway, plan additional subnet address space in your own virtual network, not in the FinOps hub virtual network. -- The virtual network should be a minimum of **/26** in size (64 IP addresses) but can be any size up to **/8** (16,777,216 IP addresses). -- The name should be `-vNet`. -- The virtual network must be divided into three subnets with the service delegations as specified: - - **private-endpoint-subnet** (**/28**) – no service delegations configured; hosts private endpoints for storage and key vault. - - **script-subnet** (**/28**) – delegated to container services for running scripts during deployment. - - **dataExplorer-subnet** (**/27**) – delegated to Azure Data Explorer. +Don't precreate, extend, or modify the FinOps hub virtual network or its subnets. Don't place customer workloads, subnets, gateways, endpoints, DNS, route tables, or other configuration in this network.
## Private endpoints and DNS -Communication between the various FinOps hub components is encrypted using TLS. For TLS certificate validation to succeed when using private networking, reliable domain name system (DNS) name resolution is required. DNS zones, private endpoints, and DNS entries guarantee name resolution between FinOps hub components. +Communication between the various FinOps hub components is encrypted using TLS. For TLS certificate validation to succeed when using private networking, reliable Domain Name System (DNS) name resolution is required. The Toolkit creates and manages DNS zones, private endpoints, and DNS entries that guarantee name resolution between FinOps hub components. + +The following names apply to Azure Commercial. For other supported clouds, the Toolkit uses the corresponding cloud-specific suffixes. See [Azure Private Endpoint private DNS zone values](/azure/private-link/private-endpoint-dns). -- **privatelink.blob.core.windows.net** – for Data Explorer and storage used by deployment scripts -- **privatelink.dfs.core.windows.net** – for Data Explorer and the data lake hosting the FinOps data and pipeline configuration +- **privatelink.blob.core.windows.net** – for Data Explorer and the data lake +- **privatelink.dfs.core.windows.net** – for the data lake hosting the FinOps data and pipeline configuration +- **privatelink.file.core.windows.net** – for storage used by deployment scripts - **privatelink.table.core.windows.net** – for Data Explorer - **privatelink.queue.core.windows.net** – for Data Explorer -- **privatelink.vaultcore.azure.net** – for Azure Key Vault +- **privatelink.vaultcore.azure.net** – for Azure Key Vault (remote hubs only) - **privatelink.{location}.kusto.windows.net** – for Data Explorer > [!IMPORTANT] -> Altering the DNS configuration of the FinOps hub virtual network isn't recommended. FinOps hub components require reliable name resolution for deployments and upgrades to succeed. Data Factory pipelines also require reliable name resolution between components. +> Don't alter the DNS configuration of the FinOps hub virtual network. FinOps hub components require reliable name resolution for deployments and upgrades to succeed. Data Factory pipelines also require reliable name resolution between components.
## Network peering, routing, and name resolution -When private access is selected, the FinOps hub instance is deployed to an isolated spoke virtual network. Multiple options exist to enable private connectivity to the FinOps hub virtual network including: +Customer-managed private endpoints in your own virtual network are the preferred private-access topology. As a secondary option, you can use virtual network peering to connect your network to the isolated FinOps hub virtual network. Peering doesn't make the FinOps hub virtual network a shared network: don't place customer workloads or networking resources inside it. + +Secondary connectivity options include: + +- Peering the FinOps hub virtual network with another Azure virtual network. +- Connecting the FinOps hub virtual network to an Azure Virtual WAN hub. +- Allowing approved IP ranges through the Storage firewall. Data Explorer's public endpoint remains disabled in private mode. -- Peering the FinOps hub network with another Azure vNet. -- Peering the FinOps hub network with an Azure vWAN hub. -- Extending the FinOps hub network address space and deploying a VPN gateway. -- Extending the FinOps hub network address space and deploying a Power BI data gateway. -- Allowing one's corporate firewall and VPN IP ranges access over the public internet via the storage and Data Explorer firewalls. +To access FinOps hub data from a peered virtual network, configure your DNS solution to resolve each private endpoint FQDN to its private IP address. The Toolkit-managed private DNS zones are linked only to the FinOps hub virtual network and don't resolve names for peered networks. Use the private endpoint's **DNS configuration** page or network interface to get the FQDNs and private IP addresses. -To access FinOps hub data from an existing virtual network, configure **A** records in your existing virtual network to access storage or Data Explorer. **CNAME** records may also be required depending on your DNS solution. +| Resource | Required DNS records | +| --- | --- | +| FinOps hub Storage | Create **A** records for both the `blob` and `dfs` private endpoint FQDNs. | +| Azure Data Explorer (if deployed) | Create **A** records for every FQDN in the private endpoint's DNS configuration. Use every zone returned in the cluster's `requiredZoneNames`. | -| Required | Name | Description | -| ------------ | ------------------------------------------------------------------- | ----------------------------------- | -| **Required** | .privatelink.dfs.core.windows.net | A record to access storage | -| **Optional** | .dfs.core.windows.net | CNAME to the storage A record | -| **Required** | .privatelink..kusto.windows.net | A record to access Data Explorer | -| **Optional** | ..kusto.windows.net | CNAME to the Data Explorer A record | +Your DNS solution might also require **CNAME** records from service FQDNs to private-link FQDNs. DNS suffixes vary by Azure cloud, so use the values from the deployed private endpoints instead of hardcoding Azure Commercial suffixes. > [!IMPORTANT] -> When using private endpoints in conjunction with a Power BI data gateway, make sure to use the fully qualified domain name (FQDN) of the Azure Data Explorer cluster (like `clustername.region.kusto.windows.net`) rather than the abbreviated version (like `clustername.region`). This ensures proper name resolution for the private endpoint functions as expected. +> When you use private endpoints with a Power BI data gateway, use the fully qualified domain name (FQDN) shown for the Data Explorer cluster in Azure. Don't use an abbreviated cluster name.
@@ -217,12 +240,13 @@ To access FinOps hub data from an existing virtual network, configure **A** reco In this example: -- The FinOps hub virtual network is peered to a network hub. -- Azure firewall acts as core the router. -- DNS entries for storage and Data Explorer are added to Azure DNS Resolver to ensure reliable name resolution. -- A route table is attached to the network gateway subnet to ensure traffic from on-premises can route to the peered vNet. +- The FinOps hub virtual network and DNS resolver virtual network are each peered to the connectivity hub virtual network. +- Azure Firewall acts as the core router. +- Customer-managed private DNS zones contain the Storage and Data Explorer records and are linked to the DNS resolver virtual network. +- On-premises DNS forwards Azure service queries to the resolver's inbound endpoint. +- A route table is attached to `GatewaySubnet` so traffic from on-premises can route to the peered virtual network. -:::image type="content" source="./media/private-networking/finops-hubs-network-peering.png" border="false" alt-text="Screenshot of network peering configuration." lightbox="./media/private-networking/finops-hubs-network-peering.png" ::: +:::image type="content" source="./media/private-networking/finops-hubs-network-peering.png" border="false" alt-text="Diagram of peered FinOps hub, DNS resolver, and connectivity hub networks with on-premises routing and DNS forwarding." lightbox="./media/private-networking/finops-hubs-network-peering.png" ::: This network topology follows the Hub-Spoke network architecture guidance outlined in the [Cloud Adoption Framework](/azure/cloud-adoption-framework/ready/azure-best-practices/hub-spoke-network-topology) for Azure and the [Azure Architecture Center](/azure/architecture/networking/architecture/hub-spoke).