はじめに

本記事の記述および検証は、多くの部分を AI（GitHub Copilot CLI）で処理しており、人間チェックは甘めです。誤りを見つけたらコメントで指摘いただけると助かります。

Microsoft (Azure) Foundry の公式 IaC サンプルリポジトリ microsoft-foundry/foundry-samples には、ネットワーク分離パターンが 9 種類 並んでいて、最初に見る人は確実に迷います。

本記事ではその中で 最もミニマムな閉域構成（= BYO リソースを使わず、VNet 注入だけで Agent を守る構成）であるテンプレート 11-private-network-basic-vnet を、

README の Deploy to Azure ボタン をポチっと押すだけでデプロイし
Bastion は使わず、普通の VM を後から追加して Jumpbox にする という現実的な検証パターンで
Foundry Portal の中身（Microsoft 管理側で動いている AI Search や Storage の存在）を覗く

までの一連の流れを記録しました。最後に 他テンプレートとの違い表 も整理しています。

この記事で扱うこと

テンプレ 11（Basic + VNet 注入）の 構成と「何が無い」のか
Deploy to Azure ボタンによる azd / az CLI 不要のデプロイ
デプロイ後に Jumpbox 用サブネットを後付け して VM を追加する手順（Bastion なし）
Defender for Cloud の Just-In-Time (JIT) アクセス で RDP を開ける運用
Foundry Portal から プラットフォーム管理の AI Search / Storage / Cosmos DB が裏で動いていることの確認
テンプレ 11 / 15 / 18 / 40 の 使い分け表

対象読者

Foundry の閉域構成を 触ったことはあるが「どのテンプレを選ぶか」で迷っている エンジニア
BYO で Cosmos DB や AI Search を抱えたくない、プラットフォーム管理のままで OK な検証者
Bastion の月額 ~$140 を払いたくない、Public IP + JIT で十分 という割り切り派

参考資料

テンプレ 11 の立ち位置

foundry-samples の infrastructure-setup-bicep/ 配下にはネットワーク分離系のテンプレが多数あり、README に Decision Guide が載っています。要点だけ抜き出すと次のとおりです。

テンプレ	Agent タイプ	ネットワーク	アイデンティティ	主な用途
11（本記事）	Basic（プラットフォーム管理）	BYO VNet 注入	System Assigned MI	VNet 分離だけ欲しい・BYO リソースは要らない
15	Standard（BYO リソース）	BYO VNet + Private Endpoint	System Assigned MI	E2E 閉域 + BYO Search/Storage/Cosmos
16	Standard	BYO VNet + PE + APIM（preview）	System Assigned MI	15 にプライベート APIM を追加
17	Standard	BYO VNet + PE	User Assigned MI	15 を UAMI 化
18	Standard	Managed VNet（MS 管理）（preview）	System Assigned MI	VNet を自前で持ちたくない
19	Standard	BYO VNet + PE	System Assigned MI	15 + ツール（MCP / OpenAPI / Functions / A2A）も VNet 内
15a	Evaluation only	BYO VNet + PE	System Assigned MI	評価専用、Cosmos / Search / capHost なし
40	Basic	Public	System Assigned MI	一番シンプル、閉域不要
41	Standard	Public	System Assigned MI	BYO リソースは欲しいが閉域は不要

つまり 「閉域は欲しい、でも自分で Search や Cosmos を管理したくない」 という人向けの最小構成が今回のテンプレ 11 です。BYO リソースが要らないので Bicep がコンパクトで、読み始めの 1 本目 としても向いています。

テンプレ 40 との違い: 40 は完全パブリック。テンプレ 11 は VNet 注入と Private Endpoint がある分、Microsoft.Network / Microsoft.App プロバイダー登録など下準備が必要になります。

何がデプロイされるか

テンプレ 11 の Bicep は次のリソースを作ります。BYO の Storage / Cosmos DB / AI Search は一切作らない のがポイント。

リソース	役割
Virtual Network（`agent-vnet-test`）	192.168.0.0/16
`agent-subnet`（192.168.0.0/24）	`Microsoft.App/environments` 委任：Agent コンピュートが注入される
`pe-subnet`（192.168.1.0/24）	Private Endpoint 用
AI Services（kind=AIServices）	Foundry アカウント本体、`publicNetworkAccess: Disabled`
Private Endpoint × 1	AI Services の `account` グループ向け
Private DNS Zone × 3	`privatelink.services.ai.azure.com` / `privatelink.openai.azure.com` / `privatelink.cognitiveservices.azure.com`
AI Foundry Project	サブリソース、System Assigned MI
Capability Host（`caphostproj`）	BYO 接続なしの "空" な caphost（後述）
Model Deployment	既定で `gpt-4.1` / `GlobalStandard` / 30 TPM

実際にデプロイ後の az resource list 抜粋:

rg-foundry11-jpe

$ az resource list -g rg-foundry11-jpe --query "[].name" -o tsv
agent-vnet-test
aiservicesmw47
aiservicesmw47-private-endpoint
aiservicesmw47/projectmw47
privatelink.services.ai.azure.com
privatelink.openai.azure.com
privatelink.cognitiveservices.azure.com
agent-vnet-test-agent-subnet-nsg-japaneast
agent-vnet-test-pe-subnet-nsg-japaneast
# 以下は後から自分で追加したもの（次章）
vm-foundry11-jpe
vm-foundry11-jpe-ip
vm-foundry11-jpe64                 # NIC
agent-vnet-test-vm-subnet-nsg-japaneast

リソース名末尾の mw47 は Bicep が uniqueString(resourceGroup().id, deploymentTimestamp) から作る 4 文字のサフィックスです。uniqueSuffix で毎デプロイ別物になります。

アーキテクチャ図

デプロイ：Deploy to Azure ボタンを押すだけ

azd up も az deployment も使いません。README に貼ってある Deploy to Azure ボタンが ARM テンプレート (main.json) を Azure Portal のカスタムテンプレ画面で開いてくれる ので、その上で値を入れていきます。

ボタンの URL は次のような形（リポジトリの README から取得）です:

https://portal.azure.com/#create/Microsoft.Template/uri/
  https%3A%2F%2Fraw.githubusercontent.com%2Fazure-ai-foundry%2Ffoundry-samples
  %2Frefs%2Fheads%2Fmain%2Finfrastructure%2Finfrastructure-setup-bicep
  %2F11-private-network-basic-vnet%2Fmain.json

⚠️ README の表記上のオーガニゼーション (microsoft-foundry / azure-ai-foundry) はリポジトリのリブランドの過渡期で混在しています。Deploy to Azure ボタンの URL にある azure-ai-foundry/foundry-samples の方が、現時点で生きているリポジトリです。fork で別名を持つ古いリンクもあるので注意。

入力したパラメータ

名前	値
Subscription	検証用サブスク
Resource group	`rg-foundry11-jpe`（新規作成）
Location	`Japan East`
AI Services（base name）	`aiservices`（デフォルト）
Model name	`gpt-4.1`（デフォルト）
Model SKU	`GlobalStandard`
Model capacity	`30`（TPM）
VNet name	`agent-vnet-test`（デフォルト）
Agent subnet	`192.168.0.0/24`（デフォルト）
PE subnet	`192.168.1.0/24`（デフォルト）
Existing VNet	（空） → 新規作成

事前にプロバイダー登録だけしておく

Microsoft.App/environments への委任が必要なので、初回サブスクでは念のため登録しておきます（既に登録済みなら no-op）。

az provider register --namespace Microsoft.CognitiveServices
az provider register --namespace Microsoft.Network
az provider register --namespace Microsoft.App

デプロイ時間

筆者環境（Japan East）で 約 8 分 で完了。内訳の体感は次のとおり。

VNet + サブネット作成: 30 秒
AI Services アカウント（publicNetworkAccess: Disabled + networkInjections）作成: 2〜3 分
Private Endpoint と DNS Zone リンク: 1〜2 分
Model deployment: 30 秒
Capability Host: 2〜3 分（ここが地味に長い）

デプロイ後の構成を確認する

VNet のサブネットとNSG

NGSは名前が違うだけで両方とも規定の規則

VNet と委任

$ az network vnet show -g rg-foundry11-jpe -n agent-vnet-test \
    --query "{addressSpace:addressSpace.addressPrefixes, subnets:subnets[].{name:name,prefix:addressPrefix,delegations:delegations[].serviceName}}" -o json
{
  "addressSpace": ["192.168.0.0/16"],
  "subnets": [
    { "name": "agent-subnet", "prefix": "192.168.0.0/24",
      "delegations": ["Microsoft.App/environments"] },
    { "name": "pe-subnet",    "prefix": "192.168.1.0/24",
      "delegations": [] }
  ]
}

agent-subnet が Microsoft.App/environments に委任されているのが要点。これによって Foundry 側が Container Apps 環境を このサブネットに注入 できるようになります。

AI Services の `networkInjections`

$ az cognitiveservices account show -g rg-foundry11-jpe -n aiservicesmw47 \
    --query "{publicNetworkAccess:properties.publicNetworkAccess, networkInjections:properties.networkInjections}" -o json
{
  "publicNetworkAccess": "Disabled",
  "networkInjections": [
    {
      "scenario": "agent",
      "subnetArmId": ".../virtualNetworks/agent-vnet-test/subnets/agent-subnet",
      "useMicrosoftManagedNetwork": false
    }
  ]
}

publicNetworkAccess: Disabled … 完全閉域
networkInjections[0].scenario: "agent" … Agent 用のコンピュートを VNet に流し込む宣言
useMicrosoftManagedNetwork: false … 今回は BYO VNet なので false（テンプレ 18 だとここが true になり、subnetArmId が不要になる）

Capability Host が "空っぽ" であること

Standard テンプレ（15 など）と一番違うのが caphost の中身です。

$ az rest --method get --uri "https://management.azure.com\
/subscriptions/<sub>/resourceGroups/rg-foundry11-jpe\
/providers/Microsoft.CognitiveServices/accounts/aiservicesmw47\
/projects/projectmw47/capabilityHosts/caphostproj?api-version=2025-04-01-preview"
{
  "name": "caphostproj",
  "properties": {
    "capabilityHostKind": "Agents",
    "aiServicesConnections": null,
    "storageConnections": null,
    "threadStorageConnections": null,
    "vectorStoreConnections": null,
    "provisioningState": "Succeeded"
  }
}

storageConnections も threadStorageConnections も vectorStoreConnections も 全部 null。これが Basic の定義そのものです。

「じゃあスレッドやファイル、ベクトルはどこに保存されるの？」 → Microsoft 側がプラットフォーム管理で用意した AI Search / Cosmos DB / Storage に保存されます。利用者のサブスクには見えませんが、Foundry Portal からは普通にスレッドやファイルが操作できます（後述）。

Private Endpoint と DNS

PE は 1 つだけ（account group）。groupId: "account" に対して 3 つの FQDN がぶら下がるので、Private DNS Zone も 3 種類すべてを用意します。

$ az network private-dns zone list -g rg-foundry11-jpe -o table
Name                                     ResourceGroup
---------------------------------------  ------------------
privatelink.cognitiveservices.azure.com  rg-foundry11-jpe
privatelink.openai.azure.com             rg-foundry11-jpe
privatelink.services.ai.azure.com        rg-foundry11-jpe

3 ゾーンとも VNet にリンクされ、A レコード が PE の NIC 経由で自動登録されます。

privatelink.services.ai.azure.com だけ忘れがち: 古いサンプルだと privatelink.openai.azure.com と privatelink.cognitiveservices.azure.com の 2 つだけしか作らないものがあります。AI Foundry の Agent / Project API は *.services.ai.azure.com を使うため、3 ゾーンセットが必須です。

Jumpbox VM を後から追加する（Bastion なし）

テンプレート 11 自体には Jumpbox も Bastion も含まれません。BYO VNet 経由の Foundry Portal にブラウザでアクセスするには、何らかの方法で VNet 内部からブラウザを起動する必要があります。

費用を抑えたいので Bastion は使わず、Public IP 付きの普通の Windows VM を建てて、Defender for Cloud の Just-In-Time (JIT) アクセス で必要なときだけ RDP を開ける構成にします。

✅ JIT は Defender for Cloud Standard / Defender for Servers Plan 2 が有効なサブスクで使えます。Public IP が直接インターネットに常時さらされないので、Bastion ほど安全ではないものの個人検証には十分。

手順 1: VM 用サブネットを VNet に追加

テンプレートが用意するのは agent-subnet と pe-subnet の 2 つだけなので、VM 用に 3 つ目のサブネット を追加します。192.168.2.0/24 を pe-subnet の隣にしたかったのですが、検証時に空いている 192.168.3.0/24 を使いました（どこでも OK）。

az network vnet subnet create \
  -g rg-foundry11-jpe \
  --vnet-name agent-vnet-test \
  -n vm-subnet \
  --address-prefixes 192.168.3.0/24

手順 2: Windows VM を作成

az vm create \
  -g rg-foundry11-jpe \
  -n vm-foundry11-jpe \
  --image MicrosoftWindowsServer:WindowsServer:2025-datacenter-azure-edition:latest \
  --size Standard_B2als_v2 \
  --vnet-name agent-vnet-test \
  --subnet vm-subnet \
  --public-ip-sku Standard \
  --admin-username azureuser \
  --admin-password '<強いパスワード>' \
  --nsg-rule NONE \
  --tags SecurityControl=Ignore

ポイント:

--size Standard_B2als_v2 … ARM ベースの Bursting VM、東日本で月額 ~$30。検証用 Jumpbox には十分なスペック
--image ...:2025-datacenter-azure-edition:latest … Windows Server 2025 の Azure Edition。Hotpatch などのメリットあり
--public-ip-sku Standard … JIT で開ける Public IP（Standard 必須）
--nsg-rule NONE … NSG ルールは作らない。RDP 開放は JIT に任せる
--tags SecurityControl=Ignore … この検証リポジトリの命名規約（必須タグ）

手順 3: Defender for Cloud で JIT を有効化 → 接続

Portal の [VM] → [接続] → [JIT VM アクセスの構成] でデフォルト設定（RDP 3389、最大 3 時間、ソース IP は要求元のみ）を有効化し、必要な時に [Request access] するだけ。

実際に作られた NSG ルールはこんな感じになります（Microsoft の corp 範囲が source なのは筆者がリクエストした時にそうなったため）:

$ az network nsg show -g rg-foundry11-jpe \
    -n agent-vnet-test-vm-subnet-nsg-japaneast \
    --query "securityRules[].{name:name,src:sourceAddressPrefix,port:destinationPortRange,access:access}" -o table
Name                                                                Src              Port    Access
------------------------------------------------------------------  ---------------  ------  --------
MicrosoftDefenderForCloud-JITRule-...-35E2CC3DC3BF4049993551B30...  167.220.232.36   3389    Allow
MicrosoftDefenderForCloud-JITRule_...-565BE7DF765046238FC18FCA5...  *                3389    Deny
MicrosoftDefenderForCloud-JITRule-...-681E0AF9BF3E4B0EA085A7336...  167.220.233.164  3389    Allow

Allow ルールは JIT 期限が切れると自動的に消え、Deny * だけが残ります。運用ミスで RDP 開けっぱなしになりにくいのが JIT の良いところ。

Bastion を選ばないトレードオフ: JIT は便利ですが、Public IP は VM に常時付与されています（NSG で守られているだけ）。組織ポリシーで Public IP 禁止 が課されているテナントでは Bastion か VPN Gateway を選んでください。

Jumpbox から Foundry Portal の中身を確認する

RDP で VM に入って Microsoft Edge を起動し、https://ai.azure.com にアクセスして、デプロイ済みプロジェクト projectmw47 を開きます。

DNS が VNet 内で閉じている確認

PowerShell で名前解決を一発:

PS C:\Users\azureuser> Resolve-DnsName aiservicesmw47.services.ai.azure.com
Name                            Type   TTL   Section    IPAddress
----                            ----   ---   -------    ---------
aiservicesmw47.services.ai...   A      9     Answer     192.168.1.x

外部 IP ではなく pe-subnet の中の IP (192.168.1.x) が返ってきていれば成功です。同様に aiservicesmw47.openai.azure.com、aiservicesmw47.cognitiveservices.azure.com も Private IP になります。

プラットフォーム管理の Storage / AI Search / Cosmos の存在

「Basic agent setup なんだから Storage も AI Search も無いんでしょ？」と思いきや、Foundry Portal で Threads や Files、Vector store を作ると問題なく保存・検索ができます。

これは Microsoft が裏側で managed な AI Search / Cosmos DB / Storage を確保してくれているためで、Portal の [プロジェクト] → [接続済みリソース] では次のように見えます:

接続済みリソース	表示
Azure OpenAI	`aiservicesmw47`（自分のサブスク内）
AI Search	Microsoft Managed（自分のサブスクには出ない）
Storage	Microsoft Managed
Cosmos DB	Microsoft Managed

実際に テストスレッドを作って、ファイルをアップロードし、エージェントから検索させる ところまで動作することを確認しました。BYO で抱えると Search Basic が ~$70/月、Cosmos DB と Storage を合わせると安くても月 $80 前後乗ってくるので、検証フェーズや小規模 PoC ではテンプレ 11 の方がはるかに身軽 です。

プラットフォーム管理リソースの可視性: Microsoft Managed 側の AI Search や Cosmos DB は、Azure Portal のリソースグループ一覧には現れません。Foundry Portal の中だけで完結する見え方になっています。データ自体は Microsoft 側の責任範囲で管理されるため、バックアップ・暗号化キー・リージョンは Foundry のリージョン（= japaneast）に追従します。

テンプレ 11 を Bicep として読み解く

main.bicep の構造はとてもシンプルで、module が 4 つあるだけです:

main.bicep（抜粋）

// Step 1: VNet & subnets
module vnet 'modules-network-secured/network-agent-vnet.bicep' = {
  params: {
    vnetName: trimVnetName
    agentSubnetName: agentSubnetName
    peSubnetName: peSubnetName
    agentSubnetPrefix: agentSubnetPrefix
    peSubnetPrefix: peSubnetPrefix
    useExistingVnet: existingVnetPassedIn
    ...
  }
}

// Step 2: AI Services with networkInjections + model deployment
module aiAccount 'modules-network-secured/ai-account-identity.bicep' = {
  params: {
    accountName: accountName
    modelName: modelName
    modelSkuName: modelSkuName
    modelCapacity: modelCapacity
    agentSubnetId: vnet.outputs.agentSubnetId   // ← ここで VNet 注入
  }
}

// Step 3: Private Endpoint + 3 DNS zones
module privateEndpointAndDNS 'modules-network-secured/private-endpoint-and-dns.bicep' = {
  params: {
    aiAccountName: aiAccount.outputs.accountName
    vnetName: vnet.outputs.virtualNetworkName
    peSubnetName: vnet.outputs.peSubnetName
    existingDnsZones: existingDnsZones
    ...
  }
}

// Step 4: Project (system-assigned MI, no BYO connections)
resource project 'Microsoft.CognitiveServices/accounts/projects@2025-04-01-preview' = {
  parent: account
  name: projectName
  identity: { type: 'SystemAssigned' }
  dependsOn: [ aiAccount, privateEndpointAndDNS ]
}

// Step 5: Capability host (basic = connections は何も渡さない)
module addProjectCapabilityHost 'modules-network-secured/add-project-capability-host.bicep' = {
  params: {
    accountName: aiAccount.outputs.accountName
    projectName: projectName
    projectCapHost: projectCapHost   // 既定値: 'caphostproj'
  }
  dependsOn: [ project, privateEndpointAndDNS ]
}

Standard 系（テンプレ 15）の Bicep との差分（要約）

Step 0 として ai-search-cosmos-storage モジュールが追加で動く
Step 2 の AI Services モジュールに aiSearchName / cosmosName / storageName の参照が渡る
Step 3 で PE が 4 つ 作られる（AI Services + Storage + Cosmos + AI Search、それぞれ DNS ゾーンも追加）
Step 5 の capability host に storageConnections / threadStorageConnections / vectorStoreConnections が渡る
Step 5.5 として RBAC モジュール が動く（Project MI に Storage Blob Data Owner、Cosmos Data Contributor、AI Search Data Contributor など）

詳細はテンプレ 15 の main.bicep を参照。

他テンプレートとの違い

「結局どのテンプレを選べばいいか」を決めるための比較を 4 本に絞って整理します。

11 vs 15（Basic vs Standard）

観点	11（Basic）	15（Standard）
BYO Storage / Cosmos / Search	なし	あり
月額（VNet 関連除く）	AI Services + Model のみ	+ AI Search Basic ~$70 / Cosmos Serverless ~$5 / Storage ~$1
Private Endpoint 数	1（AI Services）	4（AI Services / Storage / Cosmos / Search）
Private DNS Zone	3	7 程度
RBAC 設計	Project MI → AI Services のみ	Project MI → 4 リソースに条件付きで付与
データの所在	Microsoft 側	自分のサブスク内（監査・バックアップ・暗号化キーを自分で制御可能）
こういう人向け	検証 / 小規模 PoC	本番 / 監査要件あり / カスタマーキー必要

11 vs 18（BYO VNet vs Managed VNet）

観点	11（BYO VNet）	18（Managed VNet, preview）
VNet の所有者	あなた	Microsoft
`useMicrosoftManagedNetwork`	`false`	`true`
VNet ピアリング / オンプレ接続	できる	できない（Microsoft 管理のため）
サブネット委任の自分でやる必要	あり	なし
こういう人向け	オンプレや他 VNet と統合したい	「VNet 分離はしたいけどネットワークを触りたくない」

11 vs 40（閉域 vs パブリック）

観点	11（Basic + VNet）	40（Basic + Public）
`publicNetworkAccess`	`Disabled`	`Enabled`
VNet / Private Endpoint / DNS Zone	必要	不要
Jumpbox / Bastion / VPN	必要	不要
月額の差	+ Private Endpoint ~$7 / VM ~$30 / (Bastion ~$140)	0
こういう人向け	閉域要件あり	動作確認・社内勉強会・ハンズオン

筆者の選定基準: 「閉域要件が固いが、本番じゃない」なら 11、「本番で監査もある」なら 15。15 を最初に建てると Search Basic の月 $70 がチクチク効いてくるので、まずは 11 から始めるのが現実的でした。

既知のハマりどころ

agent-subnet は専有: Microsoft.App/environments への委任は そのサブネットを別用途に使えなくする ため、他のリソースを同居させたくなったら別サブネットを足す。
networkInjections は後付け不可: AI Services アカウント作成時にしか指定できない。VNet を後から繋ぐには アカウント再作成が必要。
削除順序: Capability host を先に消さないと 「Subnet already in use」 で詰まる。テンプレ 15 にある deleteCaphost.sh を借りて先に caphost を消すか、アカウントを Purge すれば自動的に caphost も外れる。
Account の Purge は重要: ただ delete だけだと soft-delete 状態になり、同じサブネットで作り直そうとすると衝突する。Purge a deleted resource を必ず実行する。
3 つの DNS Zone セット: services.ai / openai / cognitiveservices のどれが欠けても Foundry Portal の一部 API がコケる。3 セットで覚える。
テンプレ 11 ↔ 18 の片道: BYO VNet（11）から Managed VNet（18）への切り替えはサポートされていない。Foundry リソースの再デプロイが必要。
リージョン制約: Class A（10.x.x.x）を使えるリージョンは限られる。Japan East は OK だが、念のためデフォルトの 192.168.x.x で進めるのが無難。
モデル容量: gpt-4.1 の GlobalStandard 30 TPM はデフォルトでも、地域によってはクォータ枯渇で失敗する。失敗したら modelCapacity を下げるか別モデル（gpt-4o-mini 等）で試す。

ざっくりコスト

検証 1 か月あたり（Japan East、停止運用なし）の目安:

項目	概算月額 (USD)
AI Services（kind=AIServices, S0）	ほぼ $0（モデル消費課金のみ）
`gpt-4.1` GlobalStandard	使用量次第（30 TPM 上限、低頻度なら数 $）
Private Endpoint × 1	~$7
Private DNS Zone × 3	~$1.5（ゾーン 1 つ ~$0.5）
VNet / NSG	$0
Jumpbox VM (Standard_B2als_v2)	~$30（常時起動時）
Public IP (Standard)	~$4
合計（固定費ベース）	~$45 前後

Bastion 無し の効果がはっきり出ていて、テンプレ 15 + Bastion 構成と比べると 月 $200 以上安いです。VM を使わない時に 割り当て解除 すれば $4 程度まで落とせます。

まとめ

Foundry の閉域テンプレ群で 一番ミニマム なのが 11-private-network-basic-vnet
Bicep で AI Services + Project + caphost を最小構成で組み、agent-subnet への VNet 注入と account グループの Private Endpoint だけで閉域化が成立する
caphost に BYO 接続を渡さないことで Storage / Cosmos / Search は Microsoft 側がプラットフォーム管理 してくれる
Deploy to Azure ボタン → JIT 付き 普通の Windows VM → Foundry Portal の流れで、Bastion なしでも検証が回る
「閉域要件あり、でも本番じゃない」なら 15 を選ばずに 11 から始める のがコスパが良い

本番案件で BYO Storage / Cosmos / Search が必要になったら、テンプレ 15 に移行する想定で進めると無理がありません。15 に関しては BYO VNet で Standard を組んだ別記事で深掘りしているので、必要に応じてそちらも参照してください。

Foundry のネットワーク分離テンプレートは数が多くて最初は圧倒されますが、11 → 15 → 18 の順で触ると、それぞれが「何を引き算 / 足し算しているか」がスッと頭に入ります。これから Foundry の閉域化に取り組む方の参考になれば幸いです。