【Bicep/Azure-実践編2】既存リソースの参照 (existing)

はじめに

本記事は、Azure 開発を Bicep で始めようとしている初学者の方向けの解説記事です。
前回はパラメーターファイル (.bicepparam) による環境切替方法をご紹介しました。
今回は既存リソースを参照する方法をご紹介します。

1. existingとは

Bicep ファイル内でデプロイされていない (既に Azure 上に存在する) リソースを参照するには、 existing を使用します。
また、モジュール間でこれから作成される予定のリソースを参照する際にも活用されます。
なお、existing を使ってリソースを参照しても、リソースは再びデプロイ (上書きや初期化) されません。

主な用途は以下の二点です。

1. モジュールを分けてデプロイするとき、別モジュールで作成されたリソースを参照したい場合
2. 既存システムに既に存在しているリソースを参照したい場合

2. 同一スコープの場合

実務では、同一のデプロイの中でネットワーク基盤を新規作成し、その直後に別モジュールから existing で参照してアプリケーション用設定を追加するパターンが多用されます。
これにより、ネットワーク基盤側のコードとアプリケーション側のコードを完全に分離できます。(Hub & Spoke 構成時に活用できます。)

2-1. サンプルコード

サンプルコードは、Virtual Network を作成して、別モジュールから existing で参照し、Subnet を構築する例です。

ディレクトリ構成

├── main.bicep              # メインの処理 (Virtual Network作成 → Subnet作成の順序を制御)
└── modules/
    ├── vnet.bicep          # Virtual Network を新規作成する基盤モジュール
    └── subnet.bicep        # existing で Virtual Network を参照し、Subnet を追加するアプリモジュール

modules/vnet.bicep

param vnetName string
param location string

// Virtual Network の新規作成
resource vnet 'Microsoft.Network/virtualNetworks@2025-07-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.0.0.0/16'
      ]
    }
  }
}

modules/subnet.bicep

param vnetName string
param subnetName string
param subnetPrefix string

// これから作成される Virtual Network を existing で参照
resource existingVnet 'Microsoft.Network/virtualNetworks@2025-07-01' existing = {
  name: vnetName
}

// 参照した Virtual Network の子リソースとしてサブネットを作成
resource newSubnet 'Microsoft.Network/virtualNetworks/subnets@2025-07-01' = {
  parent: existingVnet // existing で取得した親リソースを指定
  name: subnetName
  properties: {
    addressPrefix: subnetPrefix
  }
}

main.bicep

targetScope = 'resourceGroup'

param location string = resourceGroup().location
var targetVnetName = 'vnet-shared-001'

// 1. Virtual Network を新規作成する
module vnetModule 'modules/vnet.bicep' = {
  name: 'deploy-vnet'
  params: {
    vnetName: targetVnetName
    location: location
  }
}

// 2. 作成した Virtual Network を existing で参照し、Subnet を追加する
module subnetModule 'modules/subnet.bicep' = {
  name: 'deploy-subnet'
  params: {
    vnetName: targetVnetName
    subnetName: 'snet-app-001'
    subnetPrefix: '10.0.1.0/24'
  }
  // Virtual Network の作成完了を待ってから実行する
  dependsOn: [
    vnetModule
  ]
}

実務での Virtual Network と Subnet の管理スコープについて
サンプルコードでは、Virtual Network と Subnet を別モジュールで構築する構成としていますが、これはあくまで existing と parent の親子関係を分かりやすく解説するためです。
実際のプロジェクトでは、Virtual Network と Subnet を含めたネットワーク周りはネットワーク基盤チームが一元管理し、Web App 等はアプリケーションチームが管理するといったパターンが一般的です。
既存の Subnet を existing で参照し、そこに Web App や Private Endpoint を配置するといった使い方をすることが多いです。

3. 別スコープの場合

別のサブスクリプションまたはリソースグループにある既存リソースを使用する場合は、scope を指定することで参照することができます。

3-1. サンプルコード

このサンプルコードは、別のリソースグループで作成した Log Analytics のリソース情報を読み込んで、今回新規作成する Key Vault の診断ログを送信先とするコードです。
Azure 上にリソースがあれば、別ファイルからの output 等がなくてもプロパティ (ID等) を参照することができる仕組みです。

main.bicep

targetScope = 'resourceGroup'

@description('共通基盤のリソースグループ名')
param sharedRgName string = 'rg-shared-core'

@description('共通の Log Analytics ワークスペース名')
param sharedLawName string = 'law-shared-common'

// ==========================================
// 1. 別スコープの既存リソースを参照
// ==========================================
// resourceGroup() 関数を使って、別のリソースグループをスコープに指定します
resource sharedLaw 'Microsoft.OperationalInsights/workspaces@2025-07-01' existing = {
  name: sharedLawName
  scope: resourceGroup(sharedRgName) // 現在のデプロイ先とは別のリソースグループを指定
}

// ==========================================
// 2. 現在のスコープ（アプリ用 リソースグループ）に新規リソースを作成
// ==========================================
resource appKeyVault 'Microsoft.KeyVault/vaults@2026-02-01' = {
  name: 'kv-app-${uniqueString(resourceGroup().id)}'
  location: resourceGroup().location
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: subscription().tenantId
    accessPolicies: [] // サンプルのため空
  }
}

// ==========================================
// 3. 取得した既存リソースの値を利用して設定を追加
// ==========================================
// 作成した Key Vault の診断ログを、共通基盤の Log Analytics に送る設定
resource kvDiagnostics 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
  name: 'diag-send-to-shared-law'
  scope: appKeyVault
  properties: {
    // ここで別リソースグループから取得した既存リソースのID (sharedLaw.id) を利用
    workspaceId: sharedLaw.id 
    logs: [
      {
        categoryGroup: 'audit'
        enabled: true
      }
    ]
  }
}

別サブスクリプションの参照について
大規模な環境では、サブスクリプション自体が分かれていることもあります。
その場合は、scope: resourceGroup('<サブスクリプションID>', '<リソースグループ名>') と2つの引数を渡すことで、クロスサブスクリプションでの参照が可能です。

おわりに

今回は existing を使った既存リソースの参照方法について解説しました。
この機能を使うことで、例えば他チームが管理している既存の共通基盤リソースを参照し、それに依存するリソースをデプロイすることができます。
ネットワーク基盤とアプリケーション基盤で管理を分けている環境等では必須の機能となりますので活用してみてください。