App Service Environment のネットワーク
App Service Environment は、Windows および Linux のコンテナー、Web アプリ、API アプリ、ロジック アプリ、および関数アプリがホストされる Azure App Service のシングル テナント デプロイです。 App Service Environment をインストールするときに、デプロイする Azure 仮想ネットワークを選択します。 すべての受信および送信アプリケーション トラフィックは、指定した仮想ネットワーク内に配置されます。 仮想ネットワーク内の 1 つのサブネットにデプロイしたら、そのサブネットには他に何もデプロイできません。
Note
この記事では、Isolated v2 App Service プランで使用される App Service Environment v3 について説明します。
サブネットの要件
App Service Environment が存在するサブネットの要件の最小セットを次に示します。
- サブネットは、
Microsoft.Web/hostingEnvironmentsに委任する必要があります。 - サブネットは空でなければなりません。
- サブネットの
addressPrefixプロパティは、配列ではなく文字列として書式設定する必要があります。
サブネットのサイズが、App Service Environment 内の App Service プラン インスタンスのスケーリング制限に影響を与える場合があります。 運用環境のスケールでは、サブネットの /24 アドレス空間 (256 アドレス) をお勧めします。 App Service Environment で最大 200 インスタンスのほぼ最大容量をスケーリングする予定で、頻繁なスケールアップ/スケールダウン操作を計画している場合は、サブネットの /23 アドレス空間 (512 アドレス) をお勧めします。
より小さいサブネットを使用する場合は、次の制限事項に注意してください。
- 特定のどのサブネットにも、管理のために予約されている 5 つのアドレスがあります。 管理アドレスに加えて、App Service Environment はサポート インフラストラクチャを動的にスケーリングし、構成と負荷に応じて 7 から 27 個のアドレスを使用します。 残りのアドレスは、App Service プランのインスタンスに使用できます。 サブネットの最小サイズは
/27アドレス空間 (32 アドレス) です。 - I1v2 Windows などの App Service Environment で使用されるApp Serviceプランの OS/SKU の組み合わせでは、 20 個 のアクティブなインスタンスごとに 1 つのスタンバイ インスタンスが作成されます。 スタンバイ インスタンスには IP アドレスも必要です。
- App Service Environment でApp Service プラン をスケールアップ/スケールダウンすると、スケール操作の完了時に App Service プランで使用される IP アドレスの量が一時的に 2 倍になります。 既存のインスタンスのプロビジョニングを解除する前に、新しいインスタンスを完全に動作させる必要があります。
- プラットフォームのアップグレードでは、送信トラフィックを中断せずにアップグレードできるようにするために、空き IP アドレスが必要です。
- スケール アップ、スケール ダウン、または操作の完了後に、IP アドレスが解放されるまでに少し時間がかかることがあります。 まれに、この操作に最大で 12 時間かかる場合があります。
- サブネット内のアドレスを使い切った場合、App Service Environment で App Service プランのスケールアウトが制限される場合があります。 もう 1 つの可能性として、Microsoft がサポート インフラストラクチャをスケーリングできない場合に、集中的なトラフィック負荷の発生中に待機時間が長くなる可能性があります。
Note
Windows Containerは、各 App Service プラン インスタンスについてアプリごとに追加の IP アドレスを使用するため、それに応じてサブネットのサイズを設定する必要があります。 たとえば、App Service Environment に 2 つの Windows Container App Service プランがあり、それぞれに 25 個のインスタンスがあり、それぞれに 5 個のアプリが実行されている場合、水平 (イン/アウト) スケールをサポートするには、300 個の IP アドレスと追加のアドレスが必要になります。
計算の例:
App Service プラン インスタンスごとに、次が必要です: 5 つの Windows コンテナー アプリ = 5 つの IP アドレス App Serviceプラン インスタンス ごとに 1 つの IP アドレス 5 + 1 = 6 つの IP アドレス
25 インスタンスの場合: 6 x 25 = App Service プランごとに 150 個の IP アドレス
2 つの App Service プランがあるため、2 x 150 = 300 個の IP アドレス。
アドレス
App Service Environment には、作成時に次のネットワーク情報が含まれます。
| アドレスの種類 | 説明 |
|---|---|
| App Service Environment 仮想ネットワーク | デプロイされた仮想ネットワーク。 |
| App Service Environment のサブネット | デプロイされたサブネット。 |
| ［ドメイン サフィックス］ | アプリによって使用される既定のドメイン サフィックス。 |
| カスタム ドメイン サフィックス | (省略可能) アプリで使用されるカスタム ドメイン サフィックス。 |
| 仮想 IP (VIP) | 使用される VIP の種類。 有効な値は、内部と外部の 2 つです。 |
| 受信アドレス | 受信アドレスは、アプリがアクセスされるときに使用されるアドレスです。 内部 VIP がある場合は、App Service Environment サブネット内のアドレスです。 アドレスが外部の場合は、パブリックに公開されるアドレスです。 |
| worker の送信アドレス | アプリは、インターネットへの送信時に、このアドレス (複数可) を使用します。 |
| プラットフォームの送信アドレス | プラットフォームは、インターネットへの送信時にこのアドレスを使用します。 たとえば、プライベート エンドポイントが使用されていない場合に、Key Vault からカスタム ドメイン サフィックスの証明書をプルするなどです。 |
次のスクリーンショットに示すように、ポータルの [IP アドレス] 部分で詳細を確認できます。
App Service Environment で App Service プランをスケーリングする際には、サブネットのアドレスをより多く使用することになります。 使用されるアドレスの数は、使用している App Service プランのインスタンス数と、どれだけのトラフィックがあるかに基づいて変動します。 App Service Environment 内のアプリには、サブネット内に専用のアドレスがありません。 サブネット内でアプリによって使用される実際のアドレスは、時間の経過と共に変化します。
独自の受信アドレスを持ち込む
App Service Environment に独自の受信アドレスを持ち込むことができます。 社内の仮想 IP を使用して App Service Environment を作成する場合は、サブネットに静的 IP アドレスを指定できます。 社外の仮想 IP を使用して App Service Environment を作成する場合は、パブリック IP アドレスのリソース ID を指定することで、独自の Azure パブリック IP アドレスを使用できます。 独自の受信アドレスを持ち込む場合の制限事項を次に示します。
- 社外の仮想 IP を使用する App Service Environment の場合、Azure パブリック IP アドレス リソースは App Service Environment と同じサブスクリプション内に存在する必要があります。
- App Service Environment が作成されると、受信アドレスは変更できません。
ポートとネットワークの制限
アプリがトラフィックを受信できるようにするには、受信ネットワーク セキュリティ グループ (NSG) ルールで App Service Environment サブネットが必要なポートからトラフィックを受信できるようにする必要があります。 トラフィックを受信するポートに加えて、Azure Load Balancer がポート 80 でサブネットに接続できることを確認する必要があります。 このポートは、内部仮想マシンの正常性チェックに使用されます。 その場合でも、仮想ネットワークからサブネットへのポート 80 のトラフィックを制御できます。
Note
NSG ルールの変更は、HTTP 接続の永続性により、反映されるまでに最大 14 日かかる場合があります。 プラットフォーム/管理トラフィックをブロックするような変更を行った場合、影響が現れるまでに最大 14 日かかる可能性があります。
次の受信 NSG 規則を構成することをお勧めします。
| ソース / ターゲット ポート | Direction | source | 到着地 | 目的 |
|---|---|---|---|---|
| * / 80,443 | 受信 | VirtualNetwork | App Service Environment のサブネット範囲 | アプリのトラフィックと内部正常性 ping トラフィックを許可する |
App Service Environment を運用するための最小要件は次のとおりです。
| ソース / ターゲット ポート | Direction | source | 到着地 | 目的 |
|---|---|---|---|---|
| * / 80 | 受信 | AzureLoadBalancer | App Service Environment のサブネット範囲 | 内部正常性 ping トラフィックを許可する |
最低限必要な規則を使用する場合は、アプリケーション トラフィックに対して 1 つ以上のルールが必要になる場合があります。 デプロイ オプションまたはデバッグ オプションを使用している場合は、このトラフィックを App Service Environment サブネットに対して許可する必要もあります。 これらのルールのソースは、仮想ネットワーク、または 1 つ以上の特定のクライアント IP または IP 範囲にすることができます。 宛先は、常に App Service Environment のサブネット範囲です。
ポート 80 の内部正常性 ping トラフィックは、ロード バランサーと内部サーバーの間で分離されています。 外部のトラフィックは正常性 ping エンドポイントに到達できません。
通常のアプリの受信アクセス ポートは次のとおりです。
| 用途 | Port |
|---|---|
| HTTP/HTTPS | 80、443 |
| FTP/FTPS | 21、990、10001-10020 |
| Visual Studio リモート デバッグ | 4022、4024、4026 |
| Web 配置サービス | 8172 |
注意
FTP アクセスの場合、ポート 21 で標準 FTP を禁止する場合でも、LoadBalancer からポート 21 の App Service Environment サブネット範囲へのトラフィックを許可する必要があります。これは、具体的には FTP サービスの内部正常性 ping トラフィックに使用されるためです。
ネットワーク ルーティング
制限なしでルート テーブルを設定できます。 App Service Environment から、Azure Firewall などのエグレス ファイアウォール デバイスへのすべての送信アプリケーション トラフィックをトンネリングできます。 このシナリオで心配する必要があるのは、アプリケーションの依存関係のみです。
アプリケーションの依存関係には、実行時にアプリに必要なエンドポイントが含まれます。 アプリが呼び出している API とサービスの他に、証明書失効リスト (CRL) チェック エンドポイントや ID/認証エンドポイント (Microsoft Entra ID など) のような派生エンドポイントに依存している場合もあります。 App Service で継続的デプロイを使用している場合は、型と言語に応じてエンドポイントを許可する必要がある場合もあります。 特に Linux の継続的デプロイの場合は、oryx-cdn.microsoft.io:443 を許可する必要があります。
受信トラフィックの前に、Azure Application Gateway などの Web アプリケーション ファイアウォール デバイスを設定できます。 そうすることで、その App Service Environment 上の特定のアプリを公開することができます。
そのアプリケーションには、パブリック エンドポイントへのエ出力 トラフィックに使用される既定の発信 アドレスのいずれかが使用されます。 App Service Environment でアプリケーションの送信アドレスをカスタマイズする場合は、サブネットに NAT ゲートウェイを追加できます。
注意
送信 SMTP 接続 (port 25) は App Service Environment v3 でサポートされています。 ただし、サポートが可能かどうかは、仮想ネットワークがデプロイされているサブスクリプションの設定によって決まります。 2022 年 8 月 1 日より前に作成された仮想ネットワークまたはサブネットでは、 サブスクリプションから設定を同期するために、仮想ネットワークまたはサブネットへの一時的な構成変更を開始する必要があります。 たとえば、一時的なサブネットの追加、NSG の一時的な関連付けと関連付け解除、サービス エンドポイントの一時的な構成などを行います。 詳細およびトラブルシューティングについては、「Azure でのアウトバウンド SMTP 接続に関する問題のトラブルシューティング」を参照してください。
プライベート エンドポイント
App Service Environment でホストされているアプリのプライベート エンドポイントを有効にするには、まず、この機能を App Service Environment レベルで有効にする必要があります。
Azure portal でアクティブにすることができます。 App Service Environment の構成ウィンドウで、設定 Allow new private endpoints をオンにします。
または、次の CLI で有効にすることもできます。
az appservice ase update --name myasename --allow-new-private-endpoint-connections true
プライベート エンドポイントと Web アプリの詳細については、Azure Web アプリのプライベート エンドポイントに関する記事を参照してください
DNS
以下のセクションでは、App Service Environment との間の受信および送信に該当する DNS の考慮事項と構成について説明します。 例では、Azure Public Cloud のドメイン サフィックス appserviceenvironment.net を使用しています。 Azure Government などの他のクラウドを使用している場合は、それぞれのドメイン サフィックスを使用する必要があります。 App Service Environment ドメインの場合、DNS 制限のため、サイト名は 40 文字で切り捨てられます。 スロットがある場合、スロット名は 19 文字で切り捨てられます。
App Service Environment の DNS 構成
App Service Environment が外部 VIP を使用して作成されている場合、アプリは自動的にパブリック DNS に入れられます。 App Service Environment が内部 VIP で作成されている場合、App Service Environment を作成するときに 2 つのオプションがあります。 Azure DNS Private Zones が自動的に構成されることを選択した場合、DNS は仮想ネットワーク内で構成されます。 DNS を手動で構成するように選択する場合、独自の DNS サーバーを使用するか、Azure DNS プライベート ゾーンを構成する必要があります。 受信アドレスを見つけるには、App Service Environment ポータルに移動して、[IP アドレス] を選択します。
独自の DNS サーバーを使用する場合は、以下のレコードを追加します。
<App Service Environment-name>.appserviceenvironment.netのゾーンを作成します。- そのゾーン内で、* に App Service Environment で使用される受信 IP アドレスを指し示す A レコードを作成します。
- そのゾーン内で、@ に App Service Environment で使用される受信 IP アドレスを指し示す A レコードを作成します。
scmという名前のゾーンを<App Service Environment-name>.appserviceenvironment.netに作成します。scmゾーン内で、* に App Service Environment のプライベート エンドポイントで使用される IP アドレスを指し示す A レコードを作成します。
Azure DNS プライベート ゾーンで DNS を構成するには、次の操作を行ってください。
<App Service Environment-name>.appserviceenvironment.netという名前の Azure DNS プライベート ゾーンを作成します。- そのゾーン内で、* に受信 IP アドレスを指し示す A レコードを作成します。
- そのゾーン内で、@ に受信 IP アドレスを指し示す A レコードを作成します。
- そのゾーン内で、*.scm に受信 IP アドレスを指し示す A レコードを作成します。
アプリの作成時に提供される既定のドメインに加えて、カスタム ドメインをアプリに追加することもできます。 アプリの検証なしでカスタム ドメイン名を設定できます。 カスタム ドメインを使用している場合は、DNS レコードがそれらに構成されていることを確認する必要があります。 前述のガイダンスに従って、既定のドメイン名をカスタム ドメイン名に置き換え、カスタム ドメイン名の DNS ゾーンとレコードを構成できます。 カスタム ドメイン名はアプリ要求に対して機能しますが、scm サイトでは使用できません。 scm サイトは、<appname>.scm.<asename>.appserviceenvironment.net でのみ使用できます。
FTP アクセス用の DNS 構成
特に内部ロード バランサー (ILB) App Service Environment v3 に対する FTP アクセスの場合、DNS が構成されている必要があります。 次の設定で Azure DNS プライベート ゾーンまたは同等のカスタム DNS を構成します。
ftp.appserviceenvironment.netという名前の Azure DNS プライベート ゾーンを作成します。- そのゾーン内に、
<App Service Environment-name>で受信 IP アドレスを指す A レコードを作成します。
DNS の設定に加えて、App Service Environment の構成とアプリ レベルでも、それを有効にする必要があります。
App Service Environment からの DNS 構成
App Service Environment 内のアプリは、仮想ネットワークの構成で使用されている DNS を使用します。 一部のアプリで、異なる DNS サーバーを使用するようにしたい場合は、アプリ設定 WEBSITE_DNS_SERVER と WEBSITE_DNS_ALT_SERVER を使用して、アプリごとに手動でそれを設定できます。 WEBSITE_DNS_ALT_SERVER は、セカンダリ DNS サーバーを構成します。 セカンダリ DNS サーバーは、プライマリ DNS サーバーからの応答がない場合にのみ使用されます。