Deploying a virtual network in Azure using bicep

Deploying Virtual Networks via Bicep

To secure an app, it's often necessary (or even just preferable) to have your application and all it's associated services talk to each other in private, rather than public, especially if it's opening up unnecessray security risks for api endpoints or services which just simply shouldn't be accessible. Within Azure, the way to do this is to create a virtual network where you can then define whether a service is publically available or is only available on the virtual network. There's a few steps involved to do this,

• Define some variables for our Virtual network
• Create the Virtual network
• Define the Subnets
• Update your services to be on the virtual network
• Think about private endpoints

Lets start with some variables for our virtual network, for the sake of this example, we'll hard code some subnets. We'll assume we've got an api to connect. For real use you would probably want to have these passed in at runtime from a hosting profile. I make a point here of tags, as tagging your infrastruture in azure can become essential fairly quickly for managing your estate.

param tags object = {
  owner: 'alasdair'
  environment: 'dev'
  updatedDate: utcNow('yyyy-MM-dd HH:mm')
}

param environmentSettings object = {
  location: 'UKSouth'
  vnetName: 'myvnet'
  vnetAddressSpace: '10.1.0.0/16'
  appServicesSubnetAddressSpace: '10.1.1.0/24'
}

Now that we've got our variables, lets create our virtual network,

resource vnet 'Microsoft.Network/virtualNetworks@2024-05-01' = {
  name: environmentSettings.vnetName
  location: environmentSettings.location
  tags: tags

  properties: {
    addressSpace: {
      addressPrefixes: [ 
        environmentSettings.vnetAddressSpace
      ]
    }

  }
}

That takes care of creating our most basic virtual network, but you'll notice that we still need to setup some subnets within our virtual network for use with various types of app services. For the subnets, within properties object, lets add a subnets array object with for appServices, you can add these as you need to connect different types of resource, I'm working under the assumption that appServices is an api, maybe you'd have a subnet for private links, one for web sites, maybe one for cosmos instances.

    subnets: [
      {
        name: 'AppServices'
        properties: {
          addressPrefix: environmentSettings.appServicesSubnetAddressSpace
          delegations: [
            {
              id: resourceId('Microsoft.Network/virtualNetworks/subnets', environmentSettings.vnetName, 'AppServices')
              name: 'delegation'
              properties: {
              serviceName: 'Microsoft.Web/serverfarms'
              }
              type: 'Microsoft.Network/virtualNetworks/subnets/delegations'
            }
          ]
        }
      }
    ]

That takes care of defining your virtual network but to actually use it, we'd want to assign it to our app service like so...

resource apiAppService 'Microsoft.Web/sites@2024-04-01' = {
  name: 'myawesomeapi'
  location: environmentSettings.location
  tags: tags
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    ...
    virtualNetworkSubnetId: vnet::appServicesSubnet.id
    ....
  }
}

And that should take care of setting up a basic a virtual network and attaching your api to it! In my next post, I'll look at private endpoints, so we can expose endpoints only through the virtual network.