Foundry StandardエージェントのBYOVNet設計を配備前に固定

Microsoftは、Foundry Standardエージェントを持ち込みVNetへ配置する際、テンプレート実行より前にネットワーク要件を確定する実務ガイドを公開しました。

要点

• エージェント、Privateエンドポイント、API Managementの送信、必要に応じた踏み台を別サブネットへ分けます。
• 本番のエージェント用サブネットは拡張余地を持つ/24を推奨し、/27は小規模用途の下限として扱います。
• Private DNS、UDR、NSG、中央ファイアウォールの許可先を配備前チェックリストで確認します。

今回のブログ記事で語られていること

記事が強調するのは、配備テンプレートより組織上のネットワーク調整の方が時間を要する点です。Foundry Standardエージェントの送信ネットワーク注入やエージェント用サブネットは配備後に変更できず、サブネットもその場で拡張できません。IPAM、ファイアウォール変更、NSG承認、ハブ側Private DNSの担当を後から見つけると、単なる設定変更ではなく再配備になります。そのため、Foundry、モデル、Cosmos DB、Storage、Search、API Managementを原則同一リージョンへ置き、遅延とリージョン間転送を抑える構成を勧めています。

サブネットは役割ごとに分離します。エージェント用サブネットはMicrosoft.App/environmentsへ委任し、Privateエンドポイントを同居させません。PE用サブネットはCosmos DB、Storage、Search、FoundryなどのPrivateエンドポイント用、API Managementの構成によって専用の送信サブネットを用意します。本番のエージェント用サブネットには/24、小規模な検証にはAPIが許す下限の/27という目安が示され、余裕不足による移設を避けます。

中央ファイアウォールを使う場合、Privateエンドポイント向け通信とMicrosoft管理の制御面向け通信を分けて考えます。Private DNSがサービス名を私設IPへ解決し、NSGがエージェント用サブネットからPE用サブネットへの443を許可しているかを先に確認します。Entra認証、管理ID、評価、監視など外向き通信は公式のFQDNまたはサービス・タグに絞り、診断ログで拒否を追います。配備前には踏み台とエージェント側の双方から名前解決を試し、公開IPへ解決されないことを証明する必要があります。

設計書にはCIDRとルール一覧だけでなく、各判断の所有者、申請の所要日数、障害時の確認順序を残します。開発環境で通信できても、本番のハブ、DNS転送、強制トンネル、API ManagementのSKUが異なれば再現しません。配備前チェックを本番相当の経路で自動化し、再配備が必要になる条件を変更管理へ明記することが重要です。

今回のブログ記事が関係する人

Azureのランディングゾーン、ネットワークセキュリティ、Foundryエージェントサービス、API Managementの設計・承認を担うチームに関係します。

結局、今回のブログ記事をどう読むべきか

エージェント機能の紹介ではなく、後戻りしにくいネットワーク判断を配備前の成果物にするガイドです。テンプレートが通ることより、DNS、経路、容量、最小許可を本番条件で検証することが中心です。