How can I adapt an existing resource with Azure Bicep?

Question

I'm currently porting some infrastructure as code scripts from Azure CLI to Azure Bicep. Among many other things, the Bicep files should create a subnet and allow access from this subnet to an existing Azure SQL Server and an existing Storage Account.

For the SQL Server, this is simple - I can reference the existing server resource and declare a child resource representing the VNET rule:

resource azureSqlServer 'Microsoft.Sql/servers@2021-05-01-preview' existing = {
  name: azureSqlServerName
  
  resource vnetRule 'virtualNetworkRules' = {
    name: azureSqlServerVnetRuleName
    properties: {
      virtualNetworkSubnetId: subnetId
    }
  }
}

However, with the Storage Account, the network rules are not child resources, but a property of the Storage Account resource (properties.networkAcls.virtualNetworkRules). I cannot declare all the details of the Storage Account in my Bicep file because that resource is way out of scope from the deployment I'm currently working on. In essence, I want to adapt the existing resource, just ensuring a single rule is present.

The following does not work because existing cannot be combined with properties:

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' existing = {
  name: storageAccountName

  properties: {
    networkAcls: {
      virtualNetworkRules: [
        {
          id: subnetId
          action: 'Allow'
        }
      ]
    }
  }
}

Is there any way I can adapt just a tiny bit of an existing resource using Bicep?

Answer 1

The existing keyword in bicep is used to tell bicep that the resource already exists and you just want a symbolic reference to that resource in the code. If the resource doesn't exist it's likely that the the deployment will fail in some way.

Your first snippet is equivalent to:

resource vnetRule 'Microsoft.Sql/servers/virtualNetworkRules@2021-05-01-preview' = {
  name: '${azureSqlServerName}/${azureSqlServerVnetRuleName}'
  properties: {
    virtualNetworkSubnetId: subnetId
  }
}

In your second snippet since you want to update properties you have to provide the complete declaration of the resource, IOW you have to define and deploy the storageAccount. This isn't unique to bicep, it's the way the declarative model in Azure works.

That said, if you want to deploy to another scope in bicep, you can use a module with the scope property. E.g.

module updateStorage 'storage.bicep' = {
  scope: resourceGroup(storageResourceGroupName)
  name: 'updateStorage'
}

The downside is that you need to make sure you define/declare all the properties need for that storageAccount which is not ideal. There are some ways you can author around that, but if the storageAccount doesn't exist, the deployment is guaranteed to fail. For example, you could assert the storageAccount exists, fetch its properties and then union or modify the properties in the module. You might be able to make that work (depending on the extent of your changes) but it's a bit of an anti-pattern in a declarative model.

That help?