0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@FukuharaYohei(Fukuhara)inMicrosoft

Microsoft Foundry の閉域構成テンプレ 11（Basic + VNet 注入）を Deploy to Azure ボタンで動かして、自前 Jumpbox で中身を眺める

0
Last updated at Posted at 2026-05-19

はじめに

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

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

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

  1. README の Deploy to Azure ボタン をポチっと押すだけでデプロイし
  2. Bastion は使わず、普通の VM を後から追加して Jumpbox にする という現実的な検証パターンで
  3. 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 （空） → 新規作成

image.png

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

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

image.png

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

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 ゾーンセットが必須です。

image.png

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 の方がはるかに身軽 です。

image.png

プラットフォーム管理リソースの可視性: 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 から始めるのが現実的でした。

既知のハマりどころ

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?