次の方法で共有

App Service のネットワーク機能

  • [アーティクル]

複数の方法で Azure App Service にアプリケーションをデプロイできます。 既定では、App Service でホストされているアプリは、インターネット経由で直接アクセスでき、インターネットでホストされているエンドポイントにのみ到達できます。 しかし、多くのアプリケーションにおいては、送受信のネットワーク トラフィックを制御する必要があります。 App Service には、それらのニーズを満たすのに役立つ機能がいくつかあります。 ここで課題となるのは、特定の問題を解決するために使用する必要がある機能を把握することです。 この記事では、ユース ケースの例を基にして、使用する機能を決定する方法を説明します。

Azure App Service のデプロイには、主に 2 つの種類があります。

  • マルチテナント パブリック サービスは、Free、Shared、Basic、Standard、Premium、PremiumV2、PremiumV3 の各価格 SKU で App Service プランをホストします。
  • シングルテナントの App Service Environment (ASE) を使用すると、Isolated SKU の App Service プランを、Azure 仮想ネットワークで直接ホストできます。

使用する機能は、マルチテナント サービスまたは ASE のどちらを使用しているかによって異なります。

Note

ネットワーク機能は、Azure Arc にデプロイされているアプリでは使用できません。

マルチテナント型 App Service のネットワーク機能

Azure App Service は分散システムです。 受信した HTTP または HTTPS 要求を処理するロールは、"フロントエンド" と呼ばれます。 お客様のワークロードをホストするロールは、"worker" と呼ばれます。 App Service デプロイ内のロールはすべて、マルチテナント ネットワーク内に存在します。 同じ App Service スケール ユニット内に多くのお客様が存在しているので、App Service ネットワークをお使いのネットワークに直接接続することはできません。

ネットワークを接続する代わりに、アプリケーション通信のさまざまな側面を処理する機能が必要になります。 お客様のアプリ "への" 要求を処理する機能を、お客様のアプリ "からの" 呼び出しを行うときの問題を解決するために使用することはできません。 同様に、お客様のアプリからの呼び出しに関する問題を解決する機能を、お客様のアプリに対する問題を解決するために使用することはできません。

受信時の機能 送信時の機能
アプリに割り当てられたアドレス ハイブリッド接続
アクセスの制限 ゲートウェイが必要な仮想ネットワーク統合
サービス エンドポイント 仮想ネットワークの統合
プライベート エンドポイント

明記されている例外を除けば、これらの機能のすべてを一緒に使用できます。 機能を組み合わせることで、問題を解決できます。

ユース ケースと機能

どのようなユース ケースでも、問題を解決する方法がいくつか存在する場合があります。 最適な機能の選択は、ユース ケース自体の範囲を超えることがあります。 以下の受信ユース ケースでは、App Service のネットワーク機能を使用して、アプリで受信するトラフィックの制御についての問題を解決する方法の案を示します。

受信のユース ケース 機能
アプリの IP ベース SSL のニーズをサポートする アプリに割り当てられたアドレス
アプリに対する非共有の専用受信アドレスをサポートする アプリに割り当てられたアドレス
アプリへのアクセスを明確に定義されたアドレス セットだけに制限する アクセスの制限
仮想ネットワーク内のリソースからアプリへのアクセスを制限する サービス エンドポイント
内部ロード バランサー (ILB) ASE
プライベート エンドポイント
アプリを仮想ネットワーク内のプライベート IP で公開する ILB ASE
プライベート エンドポイント
Application Gateway インスタンス上の受信トラフィック用プライベート IP とサービス エンドポイントの併用
Web アプリケーション ファイアウォール (WAF) を使用してアプリを保護する Application Gateway と ILB ASE
Application Gateway とプライベート エンドポイントの併用
Application Gateway とサービス エンドポイントの併用
Azure Front Door とアクセス制限
複数のリージョンのアプリにトラフィックを負荷分散する Azure Front Door とアクセス制限
同一リージョン内でトラフィックの負荷を分散させる Application Gateway とサービス エンドポイントの併用

以下の送信ユース ケースでは、App Service のネットワーク機能を使用して、お使いのアプリの送信アクセスに関するニーズを解決する方法の案を示します。

送信のユース ケース 機能
同じリージョン内にある Azure 仮想ネットワークのリソースにアクセスする 仮想ネットワーク統合
ASE
異なるリージョン内にある Azure 仮想ネットワークのリソースにアクセスする 仮想ネットワーク統合と仮想ネットワーク ピアリング
ゲートウェイが必要な仮想ネットワーク統合
ASE と仮想ネットワーク ピアリング
サービス エンドポイントによって保護されているリソースにアクセスする 仮想ネットワーク統合
ASE
Azure に接続されていないプライベート ネットワーク内のリソースにアクセスする ハイブリッド接続
Azure ExpressRoute 回線を越えてリソースにアクセスする 仮想ネットワーク統合
ASE
Web アプリからの送信トラフィックをセキュリティで保護する 仮想ネットワーク統合とネットワーク セキュリティ グループ
ASE
Web アプリからの送信トラフィックをルーティングする 仮想ネットワーク統合とルート テーブル
ASE

既定のネットワークの動作

Azure App Service スケール ユニットを使用すると、デプロイごとに多数のお客様がサポートされます。 Free と Shared の各価格レベルのプランでは、お客様のワークロードはマルチテナント worker 上でホストされます。 Basic 以上のプランを使用すると、ただ 1 つの App Service プランに専用のお客様のワークロードがホストされます。 App Service プランが Standard の場合、そのプラン内のすべてのアプリが同じ worker 上で実行されます。 worker をスケール アウトした場合、その App Service プラン内にあるすべてのアプリが、App Service プラン内の各インスタンスの新しい worker にレプリケートされます。

送信アドレス

worker VM は、主に App Service プラン別に大きく分けられます。 Free、Shared、Basic、Standard、Premium の各プランで使用される worker VM の種類はすべて同じです。 PremiumV2 プランの場合は、使用される VM の種類が異なります。 PremiumV3 の場合は、さらに別の種類の VM が使用されます。 VM ファミリを変更すると、異なる送信アドレスのセットを受け取ります。 Standard から PremiumV2 にスケーリングすると、送信アドレスが変更されます。 PremiumV2 から PremiumV3 にスケーリングすると、送信アドレスが変更されます。 一部の古いスケール ユニットの場合、Standard から PremiumV2 にスケーリングすると、受信アドレスと送信アドレスの両方が変更されます。

送信呼び出しに使用されるアドレスは多数あります。 送信呼び出しを行うためにアプリによって使用される送信アドレスは、アプリのプロパティで一覧表示されます。 これらのアドレスは、その App Service デプロイ内の同じ worker VM ファミリで実行されているすべてのアプリによって共有されます。 アプリがスケール ユニットで使用する可能性のあるすべてのアドレスを表示するには、その一覧が示される possibleOutboundAddresses というプロパティがあります。

アプリのプロパティを示すスクリーンショット。

App Service には、サービスの管理に使用されるエンドポイントが多数存在します。 それらのアドレスは別のドキュメントで公開されており、AppServiceManagement IP サービス タグにも含まれます。 AppServiceManagement タグは、そのようなトラフィックを許可する必要がある App Service Environment でのみ使用されます。 App Service の受信アドレスは、AppService IP サービス タグで追跡されます。 App Service によって使用される送信アドレスが含まれる IP サービス タグはありません。

App Service の受信トラフィックと送信トラフィックを示す図。

アプリに割り当てられたアドレス

アプリに割り当てられたアドレス機能は、IP ベースの SSL 機能の副産物です。 それにアクセスするには、アプリで SSL を設定します。 IP ベースの SSL の呼び出しに、この機能を使用することができます。 また、それを使用して、お客様のアプリに専用のアドレスを指定することもできます。

アプリに割り当てられたアドレスを示す図。

アプリに割り当てられたアドレスを使用する場合でも、トラフィックは引き続き、App Service スケール ユニットへのすべての受信トラフィックを処理する同じフロントエンド ロールを通過します。 ただし、アプリに割り当てられたアドレスは、そのアプリによってのみ使用されます。 この機能のユース ケースを示します。

  • アプリに対する IP ベースの SSL のニーズをサポートする。
  • 共有されない専用アドレスをアプリに設定する。

アプリにアドレスを設定する方法については、「Azure App Service で TLS/SSL 証明書を追加する」を参照してください。

アクセスの制限

アクセスの制限を使用すると、"受信" 要求をフィルター処理できます。 このフィルター処理は、アプリが実行される worker ロールよりも上流にある、フロントエンド ロールで行われます。 フロントエンド ロールは worker より上流に存在するので、アクセスの制限はアプリに対するネットワーク レベルでの保護と考えることができます。 アクセスの制限の詳細については、アクセスの制限の概要に関する記事を参照してください。

この機能を使用すると、優先順位に従って評価される許可規則と拒否規則のリストを作成できます。 これは、Azure ネットワークのネットワーク セキュリティ グループ (NSG) 機能と似ています。 この機能は、ASE とマルチテナント サービスのどちらでも使用できます。 これを ILB ASE で使用すると、プライベート アドレス ブロックからのアクセスを制限できます。 この機能を有効化する方法については、アクセス制限の構成に関する記事を参照してください。

Note

アプリごとに、最大 512 個のアクセス制限規則を構成できます。

アクセス制限を示す図。

プライベート エンドポイント

プライベート エンドポイントは、Azure Private Link を使用して Web アプリにプライベートかつ安全に接続するネットワーク インターフェイスです。 プライベート エンドポイントにより、お客様の仮想ネットワークからのプライベート IP アドレスを使用して、Web アプリが実質的に仮想ネットワークに取り込まれます。 この機能は、Web アプリへの "受信" フロー専用です。 詳細については、「Azure Web アプリでプライベート エンドポイントを使用する」を参照してください。

この機能のユース ケースをいくつか示します。

  • 仮想ネットワーク内のリソースからアプリへのアクセスを制限する。
  • アプリを仮想ネットワーク内のプライベート IP で公開する。
  • WAF によりアプリを保護する。

プライベート エンドポイントを使用すると、プライベート エンドポイントを超えて到達できるのは、それが構成されているアプリのみであるため、データ流出を防ぐことができます。

ネットワーク セキュリティ境界

Azure ネットワーク セキュリティ境界 (NSP) は、サービスとしてのプラットフォーム (PaaS) サービスの通信にセキュリティで保護された境界を提供するサービスです。 これらの PaaS サービスは、境界内で相互に通信でき、受信と送信のパブリック アクセス規則を使って境界の外側にあるリソースとも通信できます。

NSP ルールの適用では ID ベースのセキュリティが主に使用されますが、これは、ユーザーが独自のコードをデプロイし、ID を使用してプラットフォームを表すことができる App Services や Functions などのプラットフォーム サービスでは完全には適用できません。 NSP の一部である PaaS サービスと通信する必要がある場合は、App Service または Functions インスタンスに仮想ネットワーク統合を追加し、プライベート エンドポイントを使用して PaaS リソースと通信する必要があります。

ハイブリッド接続

App Service のハイブリッド接続を使用すると、指定した TCP エンドポイントに対してアプリから送信呼び出しを行うことができます。 エンドポイントは、オンプレミス、仮想ネットワーク内、またはポート 443 で Azure への送信トラフィックが許可されている任意の場所に設定できます。 この機能を使用するには、ハイブリッド接続マネージャーと呼ばれるリレー エージェントを、Windows Server 2012 以降のホストにインストールする必要があります。 ハイブリッド接続マネージャーは、ポート 443 で Azure Relay に到達できる必要があります。 ハイブリッド接続マネージャーは、ポータルにある App Service ハイブリッド接続の UI からダウンロードできます。

ハイブリッド接続ネットワークのフローを示す図。

App Service のハイブリッド接続は、Azure Relay のハイブリッド接続機能を基に構築されています。 App Service では、アプリからの TCP ホストとポートへの送信呼び出しのみをサポートするようにこの機能を特殊化して使用しています。 このホストとポートは、ハイブリッド接続マネージャーがインストールされているホスト上でのみ解決する必要があります。

App Service 内にあるアプリで、ハイブリッド接続で定義されているホストとポートに対して DNS ルックアップが行われると、トラフィックは自動的にリダイレクトされ、ハイブリッド接続を経由してハイブリッド接続マネージャーから送信されます。 詳細については、App Service からのハイブリッド接続に関する記事を参照してください。

この機能の一般的な使用例は次のとおりです。

  • VPN または ExpressRoute で Azure に接続されていないプライベート ネットワーク内のリソースにアクセスする。
  • サポート データベースを移動する必要なしに、App Service へのオンプレミス アプリの移行をサポートする。
  • ハイブリッド接続ごとに単一のホストとポートへのアクセスのセキュリティを強化する。 ほとんどのネットワーク機能により、ネットワークへのアクセスが開かれます。 ハイブリッド接続を使用すると、到達できるのは 1 つのホストとポートのみになります。
  • 他の送信接続方法で対応されないシナリオに対応する。
  • アプリでオンプレミスのリソースを容易に使用できる方法で、App Service 内の開発を行う。

この機能を使用すると、受信ファイアウォールに穴を開けることなくオンプレミス リソースにアクセスできるため、開発者に人気があります。 App Service の他の送信ネットワーク機能は、Azure Virtual Networking に関連しています。 ハイブリッド接続は、仮想ネットワークを経由することに依存しません。 より広範なネットワーク ニーズのために使用できます。

App Service ハイブリッド接続では、その上で何が行われているかは認識されません。 つまり、それを使用して、メインフレーム上のデータベース、Web サービス、または任意の TCP ソケットにアクセスできます。 本質的には、この機能は TCP パケットをトンネリングするものです。

ハイブリッド接続は、開発でよく利用されるだけでなく、運用アプリケーションでも使用されています。 Web サービスやデータベースへのアクセスには適していますが、多くの接続の作成が含まれる状況には向いていません。

仮想ネットワークの統合

App Service 仮想ネットワーク統合を使用すると、アプリで Azure 仮想ネットワークへの "送信" 要求を行うことができます。

仮想ネットワーク統合機能を使用すると、アプリのバックエンドを、Resource Manager 仮想ネットワークのサブネット内に配置できます。 仮想ネットワークは、アプリと同じリージョンに存在する必要があります。 この機能は、既に仮想ネットワーク内に存在している App Service Environment からは利用できません。 この機能のユース ケースを示します。

  • 同じリージョンにある Resource Manager 仮想ネットワーク内のリソースにアクセスする。
  • リージョン間接続を含む、ピアリングされた仮想ネットワーク内のリソースにアクセスする。
  • サービス エンドポイントで保護されているリソースにアクセスする。
  • ExpressRoute または VPN 接続を経由してアクセスできるリソースにアクセスする。
  • Virtual Network ゲートウェイを使用せず、そのコストをかけずに、プライベート ネットワーク内のリソースにアクセスする。
  • すべての送信トラフィックをセキュリティで保護する。
  • すべての送信トラフィックにトンネルを強制する。

仮想ネットワーク統合を示す図。

詳細については、App Service 仮想ネットワーク統合に関するページを参照してください。

ゲートウェイが必要な仮想ネットワーク統合

ゲートウェイが必要な仮想ネットワーク統合は、App Service における仮想ネットワーク統合の最初のエディションでした。 この機能を使用すると、アプリが実行されているホストが、ポイント対サイト VPN を使用して、仮想ネットワーク上の Virtual Network ゲートウェイに接続されます。 この機能を構成すると、各インスタンスに割り当てられているポイント対サイト アドレスのいずれかがアプリに付与されます。

ゲートウェイが必要な仮想ネットワーク統合を示す図。

ゲートウェイが必要な統合を使用すると、ピアリングなしで別のリージョン内の仮想ネットワークに直接接続したり、クラシック仮想ネットワークに接続したりできます。 この機能は App Service Windows プランに限定されており、ExpressRoute で接続された仮想ネットワークでは機能しません。 リージョンでの仮想ネットワーク統合を使用することをお勧めします。 この機能の詳細については、App Service 仮想ネットワーク統合に関するページを参照してください。

App Service 環境

App Service Environment (ASE) は、仮想ネットワーク内で実行される Azure App Service のシングルテナント デプロイです。 この機能には、次のようなケースがあります。

  • 仮想ネットワーク内のリソースにアクセスする。
  • ExpressRoute を経由してリソースにアクセスする。
  • 仮想ネットワーク内のプライベート アドレスを使用してアプリを公開する。
  • サービス エンドポイントを介してリソースにアクセスする。
  • プライベート エンドポイントを介してリソースにアクセスする。

ASE を使用する場合、ASE は既に仮想ネットワーク内に存在するため、仮想ネットワーク統合を使用する必要がありません。 サービス エンドポイント経由で SQL や Azure Storage などのリソースにアクセスする必要がある場合は、ASE サブネット上でサービス エンドポイントを有効にします。 仮想ネットワークまたは仮想ネットワーク内のプライベート エンドポイント内のリソースにアクセスする場合は、追加の構成を行う必要はありません。 ExpressRoute 経由でリソースにアクセスする場合、ユーザーは既に仮想ネットワーク内にいるため、ASE やその中のアプリについて構成を行う必要はありません。

ILB ASE 内にあるアプリはプライベート IP アドレスで公開できるので、WAF デバイスを容易に追加して、他のアプリの安全を保ったまま目的のアプリのみをインターネットに公開することができます。 この機能は、多層アプリケーションの開発をより簡単にするのに役立ちます。

一部の機能は現在、マルチテナント サービスから使用できませんが、ASE からは使用できます。 次に例をいくつか示します。

  • シングルテナント サービスでアプリをホストする。
  • マルチテナント サービスで可能な数よりはるかに多くのインスタンスにスケールアップする。
  • プライベート CA でセキュリティ保護されているエンドポイントを使用するアプリ用にプライベート CA クライアントの証明書を読み込む。
  • アプリ レベルで無効にできるようにすることなく、システムでホストされているすべてのアプリにわたって TLS 1.2 を適用する。

仮想ネットワーク内の ASE を示す図。

ASE は分離された専用のアプリのホスティングに最適ですが、管理に関するいくつかの課題が伴います。 運用環境で ASE を使用する前に、以下のことを考慮してください:

  • ASE は仮想ネットワーク内で実行されますが、仮想ネットワークの外部に依存関係があります。 こうした依存関係は許容しなければなりません。 詳細については、「App Service Environment のネットワークの考慮事項」を参照してください。
  • ASE では、マルチテナント サービスとは異なり、直ちにはスケーリングされません。 事後対応的にスケーリングを行うのではなく、スケーリングのニーズを予測する必要があります。
  • ASE を使用すると初期費用が高くなります。 ASE を最大限に活用するには、少量の作業に使用するのではなく、多くのワークロードを 1 つの ASE に配置するよう計画する必要があります。
  • ASE 内のアプリによるアクセスを、ASE 内の一部のアプリに選択的に制限して他のアプリを除外することはできません。
  • ASE はサブネット内にあるので、その ASE で送受信されるすべてのトラフィックにあらゆるネットワーク規則が適用されます。 1 つのアプリのみに受信トラフィック規則を割り当てる必要がある場合は、アクセス制限を使用します。

各種機能の組み合わせ

上述のマルチテナント サービス向け機能を組み合わせて使用することで、さらに複雑なユース ケースにも対応できます。 ここでは、より一般的なユース ケースを 2 つ紹介しますが、それはあくまでも例に過ぎません。 さまざまな機能の働きを理解することで、システム アーキテクチャのニーズをほぼすべて満たすことができます。

アプリを仮想ネットワークに配置する

アプリを仮想ネットワークに配置する方法に疑問があるかもしれません。 アプリを仮想ネットワークに配置する場合、アプリの受信エンドポイントと送信エンドポイントは仮想ネットワーク内にあります。 この問題を解決するには、ASE が最善の方法です。 ただし、機能を組み合わせることにより、マルチテナント サービス内でほとんどのニーズを満たすことができます。 たとえば、以下のようにすると、プライベートな受信アドレスと送信アドレスを使用して、イントラネット専用のアプリケーションをホストできます。

  • プライベートの受信アドレスと送信アドレスを指定して、アプリケーション ゲートウェイを作成する。
  • サービス エンドポイントを使用して、アプリへの受信トラフィックをセキュリティで保護する。
  • 仮想ネットワーク統合機能を使用して、アプリのバックエンドが仮想ネットワーク内に存在するようにする。

このデプロイ形式を使用すると、インターネットへの送信トラフィックのための専用アドレス、またはアプリからのすべての送信トラフィックをロックダウンする機能は、提供されません。 ASE を使用した場合に利用可能な機能のほとんどを利用できます。

多層アプリケーションを作成する

多層アプリケーションとは、API バックエンド アプリにフロントエンド層からしかアクセスできないアプリケーションのことです。 多層アプリケーションを作成するには、次の 2 つの方法があります。 どちらもまず、仮想ネットワーク統合を使用して、フロントエンド Web アプリを仮想ネットワーク内のサブネットに接続します。 そうすることで、Web アプリから仮想ネットワークへの呼び出しを行うことができます。 フロントエンド アプリを仮想ネットワークに接続した後、API アプリケーションへのアクセスをロックダウンする方法を決める必要があります。 次のようにすることができます。

  • フロントエンドと API アプリの両方を同じ ILB ASE でホストし、アプリケーション ゲートウェイを使用してフロントエンド アプリをインターネットに公開します。
  • フロント エンドをマルチテナント サービスで、バックエンドを ILB ASE でホストします。
  • フロント エンドと API アプリの両方をマルチテナント サービスでホストします。

多層アプリケーションのフロント エンドと API アプリの両方をホストしている場合は、次のことができます。

  • 仮想ネットワーク内のプライベート エンドポイントを使用して、API アプリケーションを公開します。

    2 層アプリでプライベート エンドポイントを使用する方法を示す図。

  • サービス エンドポイントを使用して、API アプリへの受信トラフィックを、確実にフロントエンド Web アプリによって使用されるサブネットからのものだけに制限します。

    アプリをセキュリティで保護するためのサービス エンドポイントの使用方法を示す図。

使用する方法を決定するときに役立ついくつかの考慮事項を次に示します。

  • サービス エンドポイントを使用するときは、API アプリへのトラフィックを統合サブネットに限定するだけで済みます。 サービス エンドポイントは API アプリのセキュリティ保護に役立ちますが、その場合でも、フロントエンド アプリから App Service 内の他のアプリにデータが流出する可能性があります。
  • プライベート エンドポイントを使用するときは、2 つのサブネットを使用するので、複雑さが増します。 また、プライベート エンドポイントは最上位のリソースであり、管理のオーバーヘッドが増えます。 プライベート エンドポイントを使用する利点は、データ流出のおそれがないことです。

どちらの方法も、複数のフロントエンドで機能します。 小規模な場合、フロントエンド統合サブネットで API アプリに対してサービス エンドポイントを有効にするだけであるため、サービス エンドポイントの方が使いやすくなります。 フロントエンド アプリをさらに追加する場合は、すべての API アプリを調整して、統合サブネットを使用してサービス エンドポイントを組み込む必要があります。 プライベート エンドポイントを使用すると、より複雑になりますが、プライベート エンドポイントを設定した後に API アプリで何も変更する必要はありません。

基幹業務アプリケーション

基幹業務 (LOB) アプリケーションは、通常はインターネットからアクセスできるように公開されていない内部アプリケーションです。 これらのアプリケーションは、アクセスを厳密に制御できる企業ネットワーク内から呼び出されます。 ILB ASE を使用する場合、基幹業務アプリケーションを簡単にホストできます。 マルチテナント サービスを使用する場合は、プライベート エンドポイントを使用するか、またはサービス エンドポイントをアプリケーション ゲートウェイと組み合わせて使用できます。 プライベート エンドポイントを使用する代わりに、サービス エンドポイントでアプリケーション ゲートウェイを使用する理由は 2 つあります。

  • LOB アプリで WAF 保護が必要である。
  • LOB アプリの複数のインスタンスに負荷を分散する必要がある。

どちらも必要ない場合は、プライベート エンドポイントを使用することをお勧めします。 App Service で使用可能なプライベート エンドポイントの場合、仮想ネットワーク内のプライベート アドレスでアプリを公開できます。 仮想ネットワークに配置したプライベート エンドポイントには、ExpressRoute および VPN 接続を介して到達できます。

プライベート エンドポイントを構成すると、プライベート アドレスでアプリが公開されますが、オンプレミスからそのアドレスに到達するように DNS を構成する必要があります。 この構成を機能させるには、プライベート エンドポイントが含まれる Azure DNS プライベート ゾーンを、オンプレミスの DNS サーバーに転送する必要があります。 Azure DNS プライベート ゾーンではゾーンの転送はサポートされていませんが、Azure DNS Private Resolver を使用すれば、ゾーンの転送をサポートできます。

App Service ポート

App Service をスキャンすると、受信接続用に公開されているいくつかのポートが見つかります。 マルチテナント サービスでこれらのポートへのアクセスをブロックまたは制御する方法はありません。 公開されるポートの一覧を次に示します。

用途 ポート
HTTP/HTTPS 80、443
管理 454、455
FTP/FTPS 21、990、10001-10300
Visual Studio リモート デバッグ 4020、4022、4024
Web 配置サービス 8172
インフラストラクチャの使用 7654、1221