App Service Environment のネットワークの考慮事項
重要
この記事は、Isolated App Service プランで使用される App Service Environment v2 に関するものです。 App Service Environment v1 と v2 は、2024 年 8 月 31 日の時点で廃止されます。 より強力なインフラストラクチャ上で実行できる、使いやすい新しいバージョンの App Service Environment があります。 新しいバージョンの詳細については、App Service Environment の概要に関するページから始めてください。 現在 App Service Environment v1 を使用している場合は、この記事の手順に従って新しいバージョンに移行ください。
2024 年 8 月 31 日の時点で、App Service Environment v1 および v2 は廃止された製品になるため、これらのワークロードに対してはサービス レベル アグリーメント (SLA) とサービス クレジットが適用されなくなります。 App Service Environment v1 および v2 ハードウェアの廃止が開始されており、これが使用中のアプリやデータの可用性とパフォーマンスに影響を及ぼす場合があります。
お客様は、App Service Environment v3 への移行を迅速に完了する必要があります。これを行わないと、アプリとリソースが削除される場合があります。 Microsoft では、インプレース移行機能を使用して、残っている App Service Environment v1 と v2 の自動移行をベストエフォートで試みますが、自動移行後のアプリケーションの可用性については、いかなる主張および保証も行いません。 移行を完了し、ニーズに合わせて最適な App Service プラン SKU を選択するには、手動による構成が必要になる場合があります。 自動移行を実行できない場合、使用中のリソースと関連するアプリ データは削除されます。 これらの極端なシナリオを両方とも回避するために、今すぐ対処することを強くお勧めします。
時間的猶予が必要な場合は、移行を完了するための一回限りの 30 日間の猶予期間を設定することができます。 この猶予期間の詳細と要求方法について、猶予期間の概要に関する記事を確認した後、Azure portal にアクセスして、各 App Service Environment の [移行] ブレードに移動してください。
App Service Environment v1/v2 の廃止に関する最新情報については、App Service Environment v1 と v2 の廃止に関する更新情報を参照してください。
App Service Environment は、Azure 仮想ネットワーク内のサブネットへの Azure App Service のデプロイです。 App Service Environment には、次の 2 種類のデプロイがあります。
- 外部: このタイプのデプロイでは、ホストされたアプリが、インターネットでアクセス可能な IP アドレスを使用して公開されます。 詳細については、「外部 App Service 環境の作成」を参照してください。
- 内部ロード バランサー: このタイプのデプロイでは、ホストされたアプリが、仮想ネットワーク内の IP アドレスで公開されます。 内部エンドポイントは、内部ロード バランサーです。 詳細については、「App Service Environment で内部ロード バランサーを作成して使用する」を参照してください。
Note
この記事は、Isolated App Service プランで使用される App Service Environment v2 に関するものです。
デプロイの種類に関係なく、すべての App Service Environment にはパブリックな仮想 IP (VIP) があります。 この VIP は、インバウンドの管理トラフィックに使用されるほか、App Service Environment からインターネットへの呼び出しを実行する際のアドレスとしても使用されます。 このような呼び出しは、App Service Environment に割り当て済みの VIP 経由で仮想ネットワークから出ていきます。
アプリが仮想ネットワーク内のリソースまたは VPN 全体にわたるリソースへの呼び出しを行う場合、サブネット内にあるいずれかの IP がソース IP になります。 App Service Environment は仮想ネットワーク内にあるため、仮想ネットワーク内のリソースには、追加の構成をしなくてもアクセスできます。 仮想ネットワークがオンプレミスのネットワークに接続されている場合、追加の構成なしでアプリもそこにあるリソースにアクセスできます。
外部デプロイの App Service Environment を使用する場合、パブリック VIP は、アプリが次の情報を解決するときのエンドポイントとしても使用されます。
- HTTP/S
- FTP/S
- Web デプロイ
- リモート デバッグ
内部ロード バランサー デプロイの App Service Environment を使用する場合、内部アドレスが HTTP/S、FTP/S、Web デプロイ、リモート デバッグのエンドポイントになります。
サブネットのサイズ
App Service Environment のデプロイ後は、そのホストとして使用するサブネットのサイズを変更できません。 App Service Environment では、インフラストラクチャのロールごと、および独立した App Service プラン インスタンスごとにアドレスが使用されます。 加えて、Azure ネットワークでは、作成された各サブネットにつき 5 つのアドレスが使用されます。
App Service プランがない状態の App Service Environment では、アプリを作成する前の段階で 12 個のアドレスが使用されます。 内部ロード バランサー デプロイを使用する場合は、アプリの作成前の時点で 13 個のアドレスが使用されます。 スケールアウトすると、App Service プラン インスタンスの 15 および 20 の倍数ごとにインフラストラクチャ ロールが追加されます。
重要
サブネットに App Service Environment 以外のものは配置できません。 将来の拡張を考慮に入れたアドレス空間を選択するようにしてください。 この設定を後で変更することはできません。 推奨されるサイズは、256 のアドレスを持つ /24 です。
スケールアップまたはスケールダウンすると、適切なサイズの新しいロールが追加されてから、ワークロードが現在のサイズからターゲット サイズに移行されます。 元の VM は、ワークロードが移行された後にのみ削除されます。 たとえば、App Service プラン インスタンスを 100 個含む App Service Environment がある場合、VM の数を 2 倍にしなければならない期間があります。
インバウンドおよびアウトバウンドの依存関係
以降のセクションでは、App Service Environment に関して知っておくべき依存関係について取り上げます。 さらに別のセクションでは、DNS 設定について説明します。
インバウンドの依存関係
単に App Service Environment が動作するだけでも、次のポートが開放されている必要があります。
| 用途 | ソース | ターゲット |
|---|---|---|
| 管理 | App Service の管理アドレス | App Service Environment のサブネット: 454、455 |
| App Service Environment の内部通信 | App Service Environment のサブネット: 全ポート | App Service Environment のサブネット: 全ポート |
| Azure Load Balancer の着信を許可 | Azure Load Balancer | App Service Environment のサブネット: 16001 |
ポート スキャンでは、ポート 7564 および 1221 が開放されているように表示される場合があります。 それらは、IP アドレスのみで応答します。 必要に応じて、ブロックしてもかまいません。
インバウンド管理トラフィックでは、システムの監視に加え、App Service Environment のコマンドと制御が提供されます。 このトラフィックのソース アドレスは、「App Service Environment の管理アドレス」に記載されています。 ネットワーク セキュリティ構成では、ポート 454 および 455 上の App Service Environment 管理アドレスからのアクセスを許可する必要があります。 これらのアドレスからのアクセスをブロックすると、App Service Environment が正常でなくなり、中断されます。 ポート 454 と 455 に入ってくる TCP トラフィックは同じ VIP から出ていく必要があります。そうしないと、非対称ルーティングの問題が発生します。
サブネット内には、内部コンポーネントの通信に使用されるポートが多数あり、それらのポートは変更可能です。 そのためには、サブネットのすべてのポートにサブネットからアクセスできる必要があります。
Azure Load Balancer と App Service Environment サブネット間の通信では、最低限開く必要のあるポートは 454、455、16001 です。 内部ロードバランサー デプロイを使用する場合は、454、455、16001 ポートのみにトラフィックをロック ダウンできます。 外部デプロイを使用する場合は、通常のアプリのアクセス ポートを考慮する必要があります。 具体的には、次のようなものがあります。
| 用途 | Port |
|---|---|
| HTTP/HTTPS | 80、443 |
| FTP/FTPS | 21、990、10001-10020 |
| Visual Studio リモート デバッグ | 4020、4022、4024 |
| Web デプロイ サービス | 8172 |
アプリケーション ポートをブロックしても、App Service Environment は引き続き機能しますが、アプリは機能しなくなる可能性があります。 外部デプロイでアプリに割り当てられた IP アドレスを使用している場合は、ご使用のアプリに割り当てられている IP からサブネットへのトラフィックを許可する必要があります。 どのポートからのトラフィックを許可すべきかは、App Service Environment ポータルから [IP アドレス] にアクセスして確認できます。
アウトバウンドの依存関係
App Service Environment は、アウトバウンド アクセスに関して複数の外部システムに依存します。 こうしたシステム依存関係の多くは DNS 名で定義されており、固定された IP アドレス群にはマップされていません。 そのため App Service Environment には、さまざまなポートにまたがるすべての外部 IP に対し、サブネットからのアウトバウンド アクセスが必要となります。
App Service Environment は、次のポートでインターネット アクセス可能なアドレスと通信します。
| 用途 | Port |
|---|---|
| DNS | 53 |
| NTP | 123 |
| CRL、Windows 更新プログラム、Linux の依存関係、Azure サービス | 80/443 |
| Azure SQL | 1433 |
| 監視 | 12000 |
アウトバウンドの依存関係は、「App Service Environment をロックする」に掲載されています。 その依存関係へのアクセスが失われた場合、App Service Environment は機能しなくなり、 それがしばらく続くと中断されます。
顧客 DNS
仮想ネットワークに、顧客が定義した DNS サーバーが構成されている場合、テナント ワークロードはそれを使用します。 App Service Environment は管理目的で Azure DNS を使用します。 顧客が選択した DNS サーバーで仮想ネットワークが構成されている場合は、サブネットからその DNS サーバーに到達できる必要があります。
Note
App Service Environment v2 でのストレージマウントやコンテナー イメージのプルでは、顧客によって定義された DNS を仮想ネットワークや WEBSITE_DNS_SERVER アプリ設定で使用することはできません。
Web アプリから DNS の解決をテストする場合は、コンソール コマンドの nameresolver を使用できます。 ご利用のアプリ用の scm サイトにあるデバッグ ウィンドウに移動するか、ポータルのアプリに移動してコンソールを選択します。 シェル プロンプトから、検索する DNS 名と共に nameresolver コマンドを実行できます。 返される結果は、同じ検索を行ったときにアプリで得られる内容と同じです。 nslookup を使用する場合は、代わりに Azure DNS を使って検索します。
ご利用の App Service Environment が含まれる仮想ネットワークの DNS 設定を変更する場合は、再起動が必要となります。 再起動を回避するために、App Service Environment を作成する前に、仮想ネットワークの DNS 設定を構成することをお勧めします。
ポータルの依存関係
前のセクションで取り上げた依存関係に加え、ポータルのエクスペリエンスに関連して別途注意すべき考慮事項がいくつかあります。 Azure portal の一部の機能は、ソース管理マネージャー (SCM) サイトへの直接アクセスに依存しています。 Azure App Service 内のどのアプリにも 2 つの URL が存在します。 1 つ目の URL はアプリにアクセスするためのものです。 2 つ目の URL は SCM サイト (Kudu コンソール とも呼ばれます) にアクセスするためのものです。 SCM サイトを使用する機能には、次のものが含まれます。
- Web ジョブ
- 関数
- ログ ストリーミング
- Kudu
- 拡張機能
- プロセス エクスプローラー
- コンソール
内部ロード バランサーを使用する場合、SCM サイトは仮想ネットワークの外部からアクセスできません。 一部の機能は、アプリの SCM サイトへのアクセスが必要なため、アプリ ポータルからは機能しません。 ポータルを使用するのではなく、SCM サイトに直接接続してください。
内部ロード バランサーが contoso.appserviceenvironment.net というドメイン名で、アプリ名が contoso.appserviceenvironment.net である場合、そのアプリには testapp.contoso.appserviceenvironment.net でアクセスします。 関連する SCM サイトには testapp.scm.contoso.appserviceenvironment.net でアクセスします。
IP アドレス
An App Service Environment には、把握しておくべき IP アドレスがいくつかあります。 これらは次のとおりです。
- パブリック インバウンド IP アドレス: 外部デプロイにおけるアプリのトラフィックのほか、内部デプロイと外部デプロイの両方における管理トラフィックに使用されます。
- アウトバウンド パブリック IP: 仮想ネットワークから出ていくアウトバウンド接続の "発信元" IP として使用されます。 これらの接続は VPN 経由ではルーティングされません。
- 内部ロード バランサーの IP アドレス: このアドレスが存在するのは、内部デプロイのみです。
- アプリに割り当てられた IP ベースの TLS/SSL アドレス: 外部デプロイで、なおかつ IP ベースの TLS/SSL バインディングが構成されている場合にのみ存在します。
Azure portal には、これらすべての IP アドレスが、App Service Environment の UI から表示されます。 内部デプロイを使用している場合は、内部ロードバランサーの IP が一覧表示されます。
Note
App Service Environment が実行されている限り、これらの IP アドレスは変化しません。 App Service Environment が中断後、復旧した場合、使用されるアドレスが変化します。 インバウンド管理アクセスをブロックしているか、依存関係へのアクセスをブロックしていることが、中断の原因であることが一般的です。
アプリに割り当てられた IP アドレス
外部デプロイでは、個々のアプリに IP アドレスを割り当てることができます。 これを内部デプロイで行うことはできません。 独自の IP アドレスを持つようにアプリを構成する方法の詳細については、「Azure App Service で TLS/SSL バインドを使用してカスタム DNS 名をセキュリティで保護する」をご覧ください。
アプリに独自の IP ベースの SSL アドレスがある場合、App Service Environment はその IP アドレスにマップするために 2 つのポートを予約します。 1 つのポートは HTTP トラフィック用であり、もう 1 つのポートは HTTPS 用です。 これらのポートは、App Service Environment ポータルの [IP アドレス] セクションに一覧表示されます。 トラフィックは、VIP からこれらのポートに到達できる必要があります。 そうしないと、アプリにアクセスできません。 この要件は、ネットワーク セキュリティ グループ (NSG) を構成するときに注意する必要があります。
ネットワーク セキュリティ グループ
NSG では、仮想ネットワーク内のネットワーク アクセスを制御する機能が提供されます。 ポータルを使用するとき、最も低い優先順位に、すべてを拒否する暗黙的な "拒否規則" が存在します。 皆さんは、"許可規則" を作成することになります。
App Service Environment 自体のホストとして使用される VM にアクセスすることはできません。 これらは、Microsoft によって管理されるサブスクリプションに含まれています。 アプリへのアクセスを制限したい場合は、サブネットに NSG を設定します。 そのときは、依存関係に十分注意してください。 1 つでも依存関係をブロックすると、App Service Environment が機能しなくなります。
NSG は、Azure portal または PowerShell を使用して構成できます。 ここにある情報は、Azure Portal を示しています。 ポータルで NSG を [ネットワーク] の下の最上位のリソースとして作成して管理します。
NSG に必要なエントリは、トラフィックの許可です。
受信
- IP サービス タグ
AppServiceManagementからの TCP (ポート 454、455) - ロード バランサーからの TCP (ポート 16001)
- App Service Environment サブネットから App Service Environment サブネット (すべてのポート)
Outbound
- すべての IP への UDP (ポート 53)
- すべての IP への UDP (ポート 123)
- すべての IP への TCP (ポート 80、443)
- IP サービス タグの
Sqlへの TCP(ポート 1433) - すべての IP への TCP (ポート 12000)
- App Service Environment サブネットへ (すべてのポート)
これらのポートには、アプリを正常に使用するために必要なポートは含まれていません。 たとえば、アプリがポート 3306 の MySQL サーバーを呼び出す必要があるとします。 ポート 123 のネットワーク タイム プロトコル (NTP) は、オペレーティング システムで使用される時刻同期プロトコルです。 NTP エンドポイントは、App Service 固有のものではなく、オペレーティング システムによって異なる場合があり、適切に定義されたアドレスの一覧には含まれていません。 時刻の同期の問題を回避するには、ポート 123 のすべてのアドレスに対して UDP トラフィックを許可する必要があります。 送信 TCP からポート 12000 へのトラフィックは、システムのサポートと分析のためのものです。 エンドポイントは動的であり、適切に定義されたアドレスのセットには含まれていません。
通常のアプリのアクセス ポートは次のとおりです。
| 用途 | Port |
|---|---|
| HTTP/HTTPS | 80、443 |
| FTP/FTPS | 21、990、10001-10020 |
| Visual Studio リモート デバッグ | 4020、4022、4024 |
| Web 配置サービス | 8172 |
既定の規則を使用すると、仮想ネットワーク内の IP はサブネットにアクセスできます。 別の既定の規則を使用すると、ロード バランサー (パブリック VIP とも呼ばれます) は App Service Environment と通信できます。 既定の規則を確認するには、[追加] アイコンの横にある [既定の規則] を選択します。
既定の規則の前に "他のすべてを拒否" する規則を設定すると、VIP と App Service Environment の間のトラフィックが妨げられます。 仮想ネットワークの内部からトラフィックが来ないようにするには、受信を許可するための独自の規則を追加します。 AzureLoadBalancer の宛先と * のポート範囲が含まれた AzureLoadBalancer に等しいソースを使用します。 NSG 規則はサブネットに適用されるため、宛先を限定する必要はありません。
アプリに IP アドレスを割り当てた場合は、必ずポートを開いたままにしてください。 ポートを確認するには、[App Service 環境]>[IP アドレス] を選択します。
NSG が定義されたら、それをサブネットに割り当てます。 仮想ネットワークまたはサブネットを覚えていない場合は、App Service Environment のポータル ページから確認できます。 NSG をサブネットに割り当てるには、サブネット UI に移動して、NSG を選択します。
ルート
アウトバウンド トラフィックがインターネットに直接向かうことのないよう、仮想ネットワークのルートを設定することを "強制トンネリング" といいます。 このときトラフィックは、ExpressRoute ゲートウェイや仮想アプライアンスなど他の場所に向かいます。 App Service Environment をこのように構成する必要がある場合は、「強制トンネリングを使用した App Service Environment の構成」を参照してください。
ポータルで App Service Environment を作成すると、サブネットには一連のルート テーブルが自動的に作成されます。 これらのルートでは、単純に送信トラフィックを直接インターネットに送信します。
同じルートを手動で作成するには、次の手順に従います。
Azure portal に移動し、[ネットワーク]>[ルート テーブル] を選択します。
仮想ネットワークと同じリージョン内に新しいルート テーブルを作成します。
ルート テーブル UI 内から、[ルート]>[追加] を選択します。
[次ホップの種類] を [インターネット] に、[アドレス プレフィックス] を [0.0.0.0/0] に設定します。 [保存] を選択します。
次のような内容が表示されます。
新しいルート テーブルを作成したら、サブネットに移動します。 ポータルで一覧からルート テーブルを選択します。 変更を保存すると、指定した NSG とルートがサブネットと共に表示されます。
サービス エンドポイント
サービス エンドポイントを設けることで、マルチテナント サービスへのアクセスを、一連の Azure 仮想ネットワークとサブネットに制限することができます。 詳細については、「仮想ネットワーク サービス エンドポイント」を参照してください。
リソースに対するサービス エンドポイントを有効にすると、他のどのルートよりも高い優先度でルートが作成されます。 強制トンネリングされた App Service Environment とのサービス エンドポイントを Azure サービスに使用しても、それらのサービスへのトラフィックは強制トンネリングされません。
サブネットに対し、Azure SQL インスタンスとのサービス エンドポイントを有効にするときは、そのサブネットから接続されるすべての Azure SQL インスタンスのサービス エンドポイントを有効にする必要があります。 同じサブネットから複数の Azure SQL インスタンスにアクセスする場合に、サービス エンドポイントの有効と無効を Azure SQL インスタンスごとに分けることはできません。 他の Azure サービスは、サービス エンドポイントに関して Azure SQL のように動作しません。 Azure Storage とのサービス エンドポイントを有効にした場合、そのリソースには、自分のサブネットからしかアクセスできないようロックされます。 その場合でも、他の Azure Storage アカウントには、サービス エンドポイントが有効になっていなくても引き続きアクセスすることができます。
