App Service で個人的に一番重要な機能は Regional VNET Integration だと考えていて、この機能の追加によってマルチテナントの App Service でもセキュアなアプリケーション構成が組めるようになりました。
Regional VNET Integration については既に何回も書いているのですが、リリースから 3 年経過した今では使わないケースの方が少なくなってきました。ほぼ必須の重要な機能となってます。
久し振りに該当のドキュメントを確認していたのですが、以下のように気になる記述を見つけました。これまで Regional VNET Integration は 1 つの App Service Plan に対して 1 つの Subnet への統合しか出来なかったのですが、それが 2 つの Subnet まで統合可能になったようです。
You can't have more than two virtual network integrations per App Service plan. Multiple apps in the same App Service plan can use the same virtual network integration. Currently you can only configure the first integration through Azure portal. The second integration must be created using Azure Resource Manager templates or Azure CLI commands.
Integrate your app with an Azure virtual network - Azure App Service | Microsoft Learn
かなりインパクトの大きいアップデートなので、サイレントではなくしっかり発表して欲しかったです。
これまで 1 つの App Service Plan 当たり 1 つの Subnet という制約によって、設計上 Subnet を分けたい場合には必ず App Service Plan も分ける必要があり、コスト的なインパクトが大きくなりがちでしたが、ドキュメントに書いている通りであれば 1 つの App Service Plan 当たり 2 つの Subnet に統合出来るので、必要な App Service Plan の数を減らしコストダウンが可能です。
確認の難易度が非常に高いのでやる予定もないのですが、恐らくは VMSS Worker のみの対応になるのではないかと考えています。現在 VMSS Worker へのマイグレーションが行われているようなので、将来的には気にする必要は無くなる部分です。
VMSS Worker が必要な場合には、これまで通り Premium V3 を選んで作成してスケールダウンしましょう。
ドキュメントでは Azure Portal では設定できないと書かれていて、構成方法が少し気になったので実際に Premium V3 の App Service Plan を用意して試してみました。
検証のために用意したリソースは以下の通りです。1 つの App Service Plan に対して 3 つの App Service を共存させています。3 つ用意しているのは 3 つ統合する際のエラーを確認するためです。
仮想ネットワークの Subnet 構成はシンプルに App Service 向けに 3 つ用意しただけです。サフィックスを App Service と合わせているので、どの Subnet に統合されているか一目で分かるようにしています。
まずはいつも通り Azure Portal から 1 つ目の App Service に対して Regional VNET Integration を設定します。流石にこれは全く問題なく設定が完了しました。
そして次は 2 つ目の App Service に対して 1 つ目とは別の Subnet に対して Regional VNET Integration を設定します。これまでは設定時にエラーとなっていた構成となりますが、あっさりと成功しました。
ドキュメントでは Azure Portal からは設定できないとありましたが、問題なく完了したので Azure Portal 側のアップデートが行われた可能性もありますね。Bicep や Terraform でも問題なく設定できるはずです。
App Service Plan 側の設定から Regional VNET Integration を状態を確認すると、2/1 というように表示が追いついていない感じがありますが、問題なく設定は完了しています。
この状態で 3 つ目の Subnet への統合を試すと以下のようなエラーとなりました。エラーメッセージからも 2 つまで統合可能というのがよく分かりますね。
これからは Regional VNET Integration の設定が完了した 2 つの App Service を使って状態を確認していきます。まずは Kudu を使って割り当てられている Private IP を確認しました。
割り当てられた Private IP は WEBSITE_PRIVATE_IP という環境変数に入っています。
それぞれの App Service で統合先の Subnet に割り当てられた範囲で Private IP が振られていることが確認出来ました。この Private IP は必ず変化するので、依存するような構成を組むのは NG です。
最後に App Service の Regional VNET Integration を設定する目的の一つである、Service Endpoint を使ったアクセス制限で 2 つの Subnet それぞれで制限を掛けられるかを確認します。
以下のように 2 つの Storage Account を用意して、それぞれで Service Endpoint を使って対応する 1 つの Subnet からのアクセスのみ許可するように構成します。
Service Endpoint の設定が完了したら、Kudu のコンソールから curl で 2 つの Storage Account に対してリクエストを投げてアクセスできるか確認します。分かりやすいように Private IP の値を表示しています。
1 つ目の Subnet に統合した App Service からは 1 つ目の Storage Account にはアクセス出来ましたが、2 つ目にはアクセスできませんでした。想定通りの動作となっていますね。
逆に 2 つ目の Subnet に統合した App Service からは、2 つ目の Storage Account にはアクセス出来ていますが 1 つ目にはアクセス出来ていません。こちらも想定通りの動作です。
今回は Premium V3 の App Service Plan で試しましたが、現時点では Basic でも 2 つまで VNET Integration を追加できました。これまでの傾向から Tier によって制限があるかなと思ったのですが、VMSS Worker であれば Basic でも 2 つまで使えるようです。
VNET Integration は App Service の使い方を大きく変えた機能ですが、これまで 1 つの App Service Plan 当たり 1 つの Subnet という制約がコスト的にそこそこ厳しかったので、そこが改善されたのは嬉しいですね。
