はじめに

前回と前々回で、Azure ML のコンピューティングインスタンスと VS Code for the Web を使って、AWS Cloud9 のようにコンソールから開けるブラウザ IDE を作りました。

今回はそのネットワーク構成を見直しました。やりたかったことは次の3つです。

ローカルの PC やその辺のブラウザからは IDE に入れないようにしたい（認証頼みではなく、経路そのものをなくしたい）
ただし、インスタンスから外へは出られるようにして、pip や apt でのインストールはできるようにしたい
「Studio でインスタンスを起動して、VS Code (Web) ボタンを押すだけ」という使い方は変えたくない

結論を先に書くと、3つ全部を同時に満たすのは無理でした。最初に完全な閉域構成を作ってみたものの、踏み台が必要になって使い方が変わってしまったので、最終的には「マネージド VNet ＋パブリック IP なし」の構成に落ち着いています。

最初の構成の状態

前回までの構成を確認したところ、こうなっていました。

項目	状態
ワークスペースのパブリックアクセス	有効
コンピューティングインスタンス	VNet なし、パブリック IP あり
SSH	無効

インスタンスにパブリック IP が付いているのが一番気になる点です。

試した構成1：完全な閉域構成

まずは素直に、外からの経路を全部閉じる構成を作りました。

自前の VNet を作り、インスタンス用・プライベートエンドポイント用・踏み台用のサブネットに分ける
ワークスペースとストレージ（blob / file）にプライベートエンドポイントを作り、Private DNS ゾーンでプライベート IP に解決させる
ワークスペースのパブリックアクセスを無効にし、ストレージもインターネットからのアクセスを拒否する
インスタンスは VNet 内に、パブリック IP なしで作り直す
外向き通信は NAT Gateway 経由にする（各サブネットの既定の送信アクセスは無効）
中に入るために、パブリック IP なしの踏み台 VM と Azure Bastion（Developer）を置く

検証結果

ローカル PC のブラウザで Studio を開くと、ワークスペースを読み込めなくなりました。

VNet の外にある Cloud Shell から、インスタンスのエンドポイントにトークン付きでアクセスしても 403 でした。ストレージも、アカウントキーを使っても拒否されます。一方、インスタンスからは NAT Gateway 経由で pip・apt・GitHub に出られました。

確認内容	結果
ローカル PC → Studio	表示不可
Cloud Shell（VNet 外）→ インスタンス	403
Cloud Shell → ストレージ	拒否
インスタンス → pip / apt / GitHub	成功（送信元は NAT Gateway の IP）

外からの経路を閉じることはできました。

でも本末転倒だった

この構成だと、IDE を使うには「Azure ポータル → Bastion → 踏み台 VM → その中のブラウザで Studio」という手順になります。「ボタンを押すだけ」とはかけ離れていて、これでは Cloud9 っぽさがなくなってしまいます。

なぜ両立しないのか

Studio も VS Code (Web) も、画面は Azure の中ではなく手元のブラウザで動いています。ボタンを押すと、手元のブラウザが Azure ML の入口に直接つなぎに行きます。

手元のブラウザで使えるなら、その入口はインターネットから見えている
入口を閉じれば、手元のブラウザも入れない

つまり「手元のブラウザでボタンを押すだけ」と「外からの経路をゼロにする」は、仕組み上どちらかしか取れません。

構成2：マネージド VNet ＋パブリック IP なし（採用）

そこで、使い方を優先して「せめてインスタンスにパブリック IP を付けない」方針に切り替えました。自前の VNet・NAT Gateway・踏み台・Bastion はすべて削除し、Azure ML のマネージド仮想ネットワークを使っています。

項目	設定
ワークスペースのパブリックアクセス	有効
マネージド VNet の分離モード	インターネット送信を許可（AllowInternetOutbound）
コンピューティングインスタンス	パブリック IP なし、SSH 無効、作成者に割り当て
自前のネットワークリソース	なし

マネージド VNet は、インスタンスを Microsoft が管理する VNet に置いてくれる機能です。インターネット送信を許可するモードなら、NAT Gateway を自分で用意しなくても外に出られます。このモード自体に追加料金はかかりません。

検証結果

ローカル PC のブラウザで Studio を開くと、前と同じようにインスタンスの一覧と「VS Code (Web)」のリンクが出ます。

ボタンを押すと VS Code (Web) が開き、インスタンスにつながりました。ターミナルで確認すると、インスタンスのアドレスは 10.2.0.4（マネージド VNet 内）で、pip でのダウンロードや GitHub へのアクセスもできています。

インスタンスの情報を API で確認すると、publicIpAddress は null、enableNodePublicIp は false でした。サブスクリプションの中にも、パブリック IP のリソースは残っていません。

3つの構成の比較

項目	最初の構成	閉域構成（不採用）	マネージド VNet（採用）
使い方	ボタンで開く	踏み台経由	ボタンで開く
インスタンスのパブリック IP	あり	なし	なし
ワークスペースの入口	公開	閉じる	公開
外向き通信	直接	NAT Gateway（固定 IP）	Microsoft 管理の出口（IP は固定ではない）
常時かかる追加料金	なし	NAT Gateway・PE の分	なし

わかったこと

アカウントなしでは入れない

認証情報を付けずにインスタンスのエンドポイントにアクセスすると、どれも Microsoft のサインイン画面へ転送されるだけでした。インスタンスは作成者に割り当てられているので、同じワークスペースの権限を持つ別の人がサインインしても入れません（閉域構成のときに、割り当てが違うと 403 になることを確認しています）。

つまり今の構成は、ネットワークではなくアカウント（サインインと割り当て）で守っている状態です。MFA は必ず有効にしておく前提になります。

vscode.dev の URL を直接開いても入れなかったが、これはネットワークのせいではない

Studio を経由せずに vscode.dev の URL を直接開くと、「Azure ML Studio から接続し直してください」というエラーになりました。これは閉域構成でもマネージド VNet でも同じだったので、ネットワークで止まっているわけではありません。Studio から開いたときに付く接続情報が足りないだけのようなので、セキュリティの仕組みとしては当てにしないほうがよさそうです。

ローカルの VS Code からは入れる可能性が高い（未検証）

Azure Machine Learning 拡張機能を入れたローカルの VS Code からは、Studio を通らずにインスタンスへ接続する機能があります。今の構成ではこれを止める仕組みがないので、つながる可能性が高いです。サインインの手前までは確認しましたが、実際に接続できるかはまだ試せていません。

さらに絞るなら

使い方を変えずに絞るなら、次のような手段があります。

ワークスペースの入口を、決まった IP アドレスからだけ受け付ける
Entra ID の条件付きアクセスで、サインインできる端末や場所を限定する
外向き通信を、許可した宛先だけにする（Azure Firewall の料金がかかる）

どれも「Studio から開いたかどうか」ではなく、「どこから・どの端末から」で絞る方法です。

ハマったところ

踏み台 VM のサイズが取れない：Japan East で B2s と F2s_v2 が容量不足で作れず、多くの v5 系もこのサブスクリプションでは使えませんでした。利用可能なサイズを一覧で出して、D2as_v7 で作っています。
Cloud Shell の確認プロンプト：az network bastion は拡張機能が必要で、スクリプトの途中でインストールの確認と削除の確認が出て止まりました。
インスタンスの作り直しで消えるもの：前回入れた Codex CLI と設定ファイルはインスタンスのローカルディスクにあったので、作り直しで消えました。ファイル共有に置いたコードは残っています。

おわりに

「コンソールのボタンだけで使える」と「外から一切入れない」は両立しない、というのが今回わかったことです。結局、インスタンスにパブリック IP を付けないところまでをネットワークで担保して、それ以外はアカウントで守る構成にしました。

本当に閉じたい場合は、閉域構成に VPN を組み合わせるなどして「社内ネットワークの中ではボタンだけで使える」ようにする形になると思います。

参考