You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Citizen developers using the Microsoft [Power Platform](https://powerplatform.microsoft.com) often need to reach the business capabilities that are developed by professional developers and deployed in Azure. [Azure API Management](https://aka.ms/apimrocks) enables professional developers to publish their backend service as APIs, and easily export these APIs to the Power Platform ([Power Apps](/powerapps/powerapps-overview) and [Power Automate](/power-automate/getting-started)) as custom connectors for discovery and consumption by citizen developers.
18
+
Citizen developers using the Microsoft [Power Platform](https://powerplatform.microsoft.com) often need to reach the business capabilities that are developed by professional developers and deployed in Azure. [Azure API Management](https://aka.ms/apimrocks) enables professional developers to publish their backend service as APIs, and easily export these APIs to the Power Platform ([Copilot Studio](/microsoft-copilot-studio/fundamentals-what-is-copilot-studio), [Power Apps](/powerapps/powerapps-overview) and [Power Automate](/power-automate/getting-started)) as custom connectors for discovery and consumption by citizen developers.
19
19
20
20
This article walks through the steps in the Azure portal to create a Power Platform [custom connector](/connectors/custom-connectors/) to an API in API Management. With this capability, citizen developers can use the Power Platform to create and distribute apps that are based on internal and external APIs managed by API Management.
Copy file name to clipboardExpand all lines: articles/azure-resource-manager/bicep/scenarios-virtual-networks.md
+15-84Lines changed: 15 additions & 84 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ title: Create virtual network resources by using Bicep
3
3
description: Describes how to create virtual networks, network security groups, and route tables by using Bicep.
4
4
ms.topic: conceptual
5
5
ms.custom: devx-track-bicep
6
-
ms.date: 03/17/2025
6
+
ms.date: 04/25/2025
7
7
---
8
8
9
9
# Create virtual network resources by using Bicep
@@ -16,69 +16,12 @@ Define your virtual networks by creating a resource with the type [`Microsoft.Ne
16
16
17
17
### Configure subnets by using the subnets property
18
18
19
-
Virtual networks contain subnets, which are logical groups of IP addresses within the virtual network. There are two ways to define subnets in Bicep: by using the `subnets` property on the virtual network resource, and by creating a [child resource](child-resource-name-type.md) with type `Microsoft.Network/virtualNetworks/subnets`.
19
+
Virtual networks contain subnets, which are logical groupings of IP addresses within the network. Subnets should always be managed as child resources, and the **subnets** property should never be defined within the virtual network resource. This approach ensures a safe and independent lifecycle for both resource types.
20
20
21
-
> [!WARNING]
22
-
> Avoid defining subnets as child resources. This approach can result in downtime for your resources during subsequent deployments, or failed deployments.
21
+
> [!NOTE]
22
+
> The Azure Virtual Network API is updated to allow modifications to virtual networks without requiring the inclusion of the subnet property in PUT requests. Previously, omitting the subnet property would result in the deletion of existing subnets. With the new behavior, if the subnet property isn't included in a PUT request, the existing subnets remain unchanged. Explicitly setting the subnet property to an empty value deletes all existing subnets, while providing specific subnet configurations creates or updates subnets accordingly. This change simplifies virtual network management by preventing unintended subnet deletions during updates. For more information, see [Azure Virtual Network now supports updates without subnet property](https://techcommunity.microsoft.com/blog/azurenetworkingblog/azure-virtual-network-now-supports-updates-without-subnet-property/4067952).
23
23
24
-
It's best to define your subnets within the virtual network definition, as in this example:
25
-
26
-
> The following example is part of a larger example. For a Bicep file that you can deploy, [see the complete file](https://raw.githubusercontent.com/Azure/azure-docs-bicep-samples/main/samples/scenarios-virtual-networks/vnet.bicep).
Although both approaches enable you to define and create your subnets, there is an important difference. When you define subnets by using child resources, the first time your Bicep file is deployed, the virtual network is deployed. Then, after the virtual network deployment is complete, each subnet is deployed. This sequencing occurs because Azure Resource Manager deploys each individual resource separately.
74
-
75
-
When you redeploy the same Bicep file, the same deployment sequence occurs. However, the virtual network is deployed without any subnets configured on it because the `subnets` property is effectively empty. Then, after the virtual network is reconfigured, the subnet resources are redeployed, which re-establishes each subnet. In some situations, this behavior causes the resources within your virtual network to lose connectivity during your deployment. In other situations, Azure prevents you from modifying the virtual network and your deployment fails.
76
-
77
-
### Access subnet resource IDs
78
-
79
-
You often need to refer to a subnet's resource ID. When you use the `subnets` property to define your subnet, [you can use the `existing` keyword](existing-resource.md) to also obtain a strongly typed reference to the subnet, and then access the subnet's `id` property:
80
-
81
-
> The following example is part of a larger example. For a Bicep file that you can deploy, [see the complete file](https://raw.githubusercontent.com/Azure/azure-docs-bicep-samples/main/samples/scenarios-virtual-networks/vnet.bicep).
24
+
It's best to define your subnets as [child resources](./child-resource-name-type.md#within-parent-resource), as in this example:
82
25
83
26
```bicep
84
27
param location string = resourceGroup().location
@@ -87,7 +30,7 @@ var virtualNetworkName = 'my-vnet'
Because this example uses the `existing` keyword to access the subnet resource, instead of defining the complete subnet resource, it doesn't have the risks outlined in the previous section.
129
-
130
-
You can also combine the `existing` and `scope` keywords to refer to a virtual network or subnet resource in another resource group.
62
+
To reference a nested resource outside the parent resource, it must be qualified with the containing resource name and the :: operator as shown in the preceding example.
131
63
132
64
## Network security groups
133
65
@@ -148,4 +80,3 @@ Private endpoint approval is an operation, so you can't perform it directly with
148
80
- Quickstart templates
149
81
-[Create a Virtual Network with two Subnets](https://azure.microsoft.com/resources/templates/vnet-two-subnets/)
150
82
-[Virtual Network with diagnostic logs](https://github.com/Azure/azure-quickstart-templates/tree/master/quickstarts/microsoft.network/vnet-create-with-diagnostic-logs)
0 commit comments