App Service のネットワーク機能App Service networking features

Azure App Service のアプリケーションは、複数の方法でデプロイできます。Applications in the Azure App Service can be deployed in multiple ways. 既定では、App Service でホストされているアプリはインターネットから直接アクセス可能になっており、到達先はインターネット上でホストされているエンドポイントに限定されています。By default, App Service hosted apps are directly internet accessible and can only reach internet hosted endpoints. しかし、多くのお客様のアプリケーションでは、送受信のネットワーク トラフィックを制御する必要があります。Many customer applications however need to control the inbound and outbound network traffic. このようなニーズに応えるため、App Service にはさまざまな機能が用意されています。There are several features available in the App Service to satisfy those needs. ここで課題となるのは、特定の問題を解決するにあたってどの機能を使用すればよいか把握することです。The challenge is knowing what feature should be used to solve a given problem. このドキュメントでは、いくつかのサンプル ユース ケースに基づいて、お客様が使用すべき機能を判断できるよう説明していきます。This document is intended to help customers determine what feature should be used based on some example use cases.

Azure App Service のデプロイの種類は、主に 2 つあります。There are two primary deployment types for the Azure App Service. 1 つはマルチテナント パブリック サービスであり、Free、Shared、Basic、Standard、Premium、および PremiumV2 の各価格レベルの App Service プランがホストされます。There is the multi-tenant public service, which hosts App Service plans in the Free, Shared, Basic, Standard, Premium, and Premiumv2 pricing SKUs. もう 1 つはシングル テナント型の App Service Environment (ASE) であり、Isolated 価格レベルの App Service プランが Azure Virtual Network (VNet) 内で直接ホストされます。Then there is the single tenant App Service Environment(ASE), which hosts Isolated SKU App Service plans directly in your Azure Virtual Network (VNet). 使用する機能は、ご利用の環境がマルチテナント サービスと ASE のどちらであるかによって異なります。The features you use will vary on if you are in the multi-tenant service or in an ASE.

マルチテナント型 App Service のネットワーク機能Multi-tenant App Service networking features

Azure App Service は分散システムです。The Azure App Service is a distributed system. 受信した HTTP/HTTPS 要求を処理するロールは、フロントエンドと呼ばれます。The roles that handle incoming HTTP/HTTPS requests are called front-ends. お客様のワークロードをホストするロールは、worker と呼ばれます。The roles that host the customer workload are called workers. App Service デプロイのロールはすべて、マルチテナント ネットワーク内に存在します。All of the roles in an App Service deployment exist in a multi-tenant network. 同じ App Service スケール ユニット内に異なるユーザーが多数存在しているので、App Service ネットワークを、お使いのネットワークに直接接続することはできません。Because there are many different customers in the same App Service scale unit, you cannot connect the App Service network directly to your network. ネットワークを接続する代わりに、アプリケーション通信のさまざまな側面を処理する機能が必要になります。Instead of connecting the networks, we need features to handle the different aspects of application communication. アプリに対する要求を処理する機能を、アプリから呼び出しを実行する際の問題解決に使用することはできません。The features that handle requests TO your app can't be used to solve problems when making calls FROM your app. 同様に、アプリからの呼び出しの問題を解決する機能は、アプリに対する呼び出しの問題解決には使用できません。Likewise, the features that solve problems for calls FROM your app can't be used to solve problems TO your app.

受信時の機能Inbound features 送信時の機能Outbound features
アプリに割り当てられたアドレスApp assigned address ハイブリッド接続とHybrid Connections
アクセス制限Access Restrictions ゲートウェイが必要な VNet 統合Gateway required VNet Integration
サービス エンドポイントService Endpoints VNet 統合 (プレビュー)VNet Integration (preview)

特に記載のない限り、これらの機能はすべて併用可能です。Unless otherwise stated, all of the features can be used together. 機能を組み合わせることで、さまざまな問題を解決できます。You can mix the features to solve your various problems.

ユース ケースと機能Use case and features

どのようなユース ケースでも、問題解決の手段はいくつか存在します。For any given use case, there can be a few ways to solve the problem. 時として、使用に適した機能はユース ケース以外の理由から決まるものです。The right feature to use is sometimes due to reasons beyond just the use case itself. 以下の受信のユース ケースでは、App Service のネットワーク機能を使用して、アプリで受信するトラフィックの制御についての問題を解決する方法の案を示します。The following inbound use cases suggest how to use App Service networking features to solve problems around controlling traffic going to your app.

受信のユース ケースInbound use cases 機能Feature
アプリの IP ベース SSL のニーズをサポートするSupport IP-based SSL needs for your app アプリに割り当てられたアドレスapp assigned address
アプリ専用の非共有受信アドレスNot shared, dedicated inbound address for your app アプリに割り当てられたアドレスapp assigned address
アプリへのアクセスを明確に定義された一連のアドレスからのみに制限するRestrict access to your app from a set of well-defined addresses アクセス制限Access Restrictions
アプリを VNet 内の複数のプライベート IP で公開するExpose my app on private IPs in my VNet ILB ASEILB ASE
Application Gateway とサービス エンドポイントの併用Application Gateway with service endpoints
アプリへのアクセスを VNet 内のリソースからのみに制限するRestrict access to my app from resources in a VNet サービス エンドポイントService Endpoints
ILB ASEILB ASE
アプリを VNet 内の 1 つのプライベート IP で公開するExpose my app on a private IP in my VNet ILB ASEILB ASE
Application Gateway 上の受信用プライベート IP とサービス エンドポイントの併用private IP for inbound on an Application Gateway with service endpoints
WAF によりアプリを保護するProtect my app with a WAF Application Gateway + ILB ASEApplication Gateway + ILB ASE
Application Gateway とサービス エンドポイントの併用Application Gateway with service endpoints
Azure Front Door とアクセス制限の併用Azure Front Door with Access Restrictions
アプリへのトラフィックの負荷を複数のリージョンに分散させるLoad balance traffic to my apps in different regions Azure Front Door とアクセス制限の併用Azure Front Door with Access Restrictions
同一リージョン内でトラフィックの負荷を分散させるLoad balance traffic in the same region Application Gateway とサービス エンドポイントの併用Application Gateway with service endpoints

以下の送信のユース ケースでは、App Service のネットワーク機能を使用して、アプリの送信アクセスに関するニーズを解決する方法の案を示します。The following outbound use cases suggest how to use App Service networking features to solve outbound access needs for your app.

送信のユース ケースOutbound use cases 機能Feature
同一リージョン内にある Azure Virtual Network のリソースにアクセスするAccess resources in an Azure Virtual Network in the same region VNet 統合VNet Integration
ASEASE
異なるリージョン内にある Azure Virtual Network のリソースにアクセスするAccess resources in an Azure Virtual Network in a different region ゲートウェイが必要な VNet 統合Gateway required VNet Integration
ASE と VNet ピアリングASE and VNet peering
サービス エンドポイントによって保護されているリソースにアクセスするAccess resources secured with service endpoints VNet 統合VNet Integration
ASEASE
Azure に接続されていないプライベート ネットワーク内にあるリソースにアクセスするAccess resources in a private network not connected to Azure ハイブリッド接続とHybrid Connections
複数の ExpressRoute 回線を越えてリソースにアクセスするAccess resources across ExpressRoute circuits VNet 統合 (現時点では RFC 1918 アドレスのみに制限)VNet Integration (restricted to RFC 1918 addresses for now)
ASEASE

既定のネットワークの動作Default networking behavior

Azure App Service スケール ユニットでは、デプロイごとに多数のお客様をサポートしています。The Azure App Service scale units support many customers in each deployment. Free と Shared の各価格レベルのプランでは、お客様のワークロードはマルチテナント worker 上でホストされます。The Free and Shared SKU plans host customer workloads on multi-tenant workers. Basic 以上のプランでは、1 つの App Service プラン (ASP) 専用となるお客様のワークロードがホストされます。The Basic, and above plans host customer workloads that are dedicated to only one App Service plan (ASP). たとえば、App Service プランが Standard の場合、このプラン内のアプリはすべて同一の worker 上で実行されます。If you had a Standard App Service plan, then all of the apps in that plan will run on the same worker. worker をスケールアウトした場合、その ASP 内にあるアプリはすべて、お使いの ASP 内にある各インスタンスの新規 worker 上にレプリケートされます。If you scale out the worker, then all of the apps in that ASP will be replicated on a new worker for each instance in your ASP. PremiumV2 で使用される worker は、他のプラン用の worker とは異なります。The workers that are used for Premiumv2 are different from the workers used for the other plans. App Service デプロイごとに、その App Service デプロイ内のアプリに対するすべての受信トラフィックに使用される IP アドレスが 1 つ設定されます。Each App Service deployment has one IP address that is used for all of the inbound traffic to the apps in that App Service deployment. 一方、送信呼び出しの実行には、4 から 11 個程度のアドレスが使用されます。There are however anywhere from 4 to 11 addresses used for making outbound calls. これらのアドレスは、該当する App Service デプロイ内にあるすべてのアプリで共有されます。These addresses are shared by all of the apps in that App Service deployment. 送信アドレスは、worker のタイプによって異なります。The outbound addresses are different based on the different worker types. つまり、Free、Shared、Basic、Standard、および Premium の各 ASP で使用されるアドレスは、PremiumV2 ASP からの送信呼び出しに使用されるアドレスとは異なるということです。That means that the addresses used by the Free, Shared, Basic, Standard and Premium ASPs are different than the addresses used for outbound calls from the Premiumv2 ASPs. アプリで使用されている受信アドレスと送信アドレスは、そのアプリのプロパティで確認できます。If you look in the properties for your app, you can see the inbound and outbound addresses that are used by your app. IP ACL との依存関係をロックダウンする必要がある場合は、possibleOutboundAddresses を使用してください。If you need to lock down a dependency with an IP ACL, use the possibleOutboundAddresses.

アプリのプロパティ

App Service には、サービスの管理に使用されるエンドポイントがいくつも存在します。App Service has a number of endpoints that are used to manage the service. これらのアドレスは別のドキュメントで公開されており、AppServiceManagement IP サービス タグにも表示されています。Those addresses are published in a separate document and are also in the AppServiceManagement IP service tag. AppServiceManagement タグは、こうしたトラフィックを許可する必要がある App Service Environment (ASE) でのみ使用されます。The AppServiceManagement tag is only used with an App Service Environment (ASE) where you need to allow such traffic. App Service の受信アドレスは、AppService IP サービス タグで追跡されます。The App Service inbound addresses are tracked in the AppService IP service tag. App Service によって使用される送信アドレスが含まれる IP サービス タグはありません。There is no IP service tag that contains the outbound addresses used by App Service.

App Service の送受信図

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

"アプリに割り当てられたアドレス" 機能は、IP ベースの SSL 機能の副産物であり、アプリに SSL を設定することでアクセスします。The app assigned address feature is an offshoot of the IP-based SSL capability and is accessed by setting up SSL with your app. この機能を使用すると、IP ベースの SSL 呼び出しを行えるだけでなく、アプリに対して、そのアプリ専用のアドレスを付与することもできます。This feature can be used for IP-based SSL calls but it can also be used to give your app an address that only it has.

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

アプリに割り当てられたアドレスを使用する場合でも、トラフィックは引き続き、App Service スケールユニットに対するすべての受信トラフィックを処理するフロントエンド ロールを通過します。When you use an app assigned address, your traffic still goes through the same front-end roles that handle all of the incoming traffic into the App Service scale unit. ただし、アプリに割り当てられたアドレスは、そのアプリのみが使用します。The address that is assigned to your app however, is only used by your app. この機能のユース ケースは次のとおりです。The use cases for this feature are to:

  • アプリの IP ベース SSL のニーズをサポートするSupport IP-based SSL needs for your app
  • 他と共有されない専用アドレスをアプリに設定するSet a dedicated address for your app that is not shared with anything else

アプリにアドレスを設定する方法については、IP ベースの SSL の構成に関するチュートリアルを参照してください。You can learn how to set an address on your app with the tutorial on Configuring IP based SSL.

アクセス制限Access Restrictions

アクセス制限機能を使用すると、送信元の IP アドレスに基づいて受信要求をフィルター処理できます。The Access Restrictions capability lets you filter inbound requests based on the origination IP address. このフィルター処理は、アプリが実行される worker ロールよりも上流にある、フロントエンド ロールで行われます。The filtering action takes place on the front-end roles that are upstream from the worker rolls where your apps are running. フロントエンド ロールが worker よりも上流に存在することから、アクセス制限機能は、ネットワーク レベルでのアプリの保護機能と言えます。Since the front-end roles are upstream from the workers, the Access Restrictions capability can be regarded as network level protection for your apps. この機能では、優先度順に評価されるアドレス ブロックの許可リストと拒否リストを作成できます。The feature allows you to build a list of allow and deny address blocks that are evaluated in priority order. これは、Azure のネットワークにあるネットワーク セキュリティ グループ (NSG) 機能と似ています。It is similar to the Network Security Group (NSG) feature that exists in Azure Networking. この機能は、ASE とマルチテナント サービスのどちらでも使用できます。You can use this feature in an ASE or in the multi-tenant service. ILB ASE で使用する場合は、プライベート アドレス ブロックからのアクセスを制限できます。When used with an ILB ASE, you can restrict access from private address blocks.

アクセス制限

アクセス制限機能は、アプリへの到達のために使用可能な IP アドレスを制限する必要があるシナリオで役立ちます。The Access Restrictions feature helps in scenarios where you want to restrict the IP addresses that can be used to reach your app. この機能の主なユース ケースは次のとおりです。Among the use cases for this feature are:

  • アプリへのアクセスを明確に定義された一連のアドレスからのみに制限するRestrict access to your app from a set of well-defined addresses
  • 負荷分散サービス (Azure Front Door など) 経由の受信アクセスを制限する。Restrict access to coming through a load-balancing service, such as Azure Front Door. たとえば、Azure Front Door への受信トラフィックをロックダウンするには、147.243.0.0/16 と 2a01:111:2050::/44 からのトラフィックを許可するルールを作成します。If you wanted to lock down your inbound traffic to Azure Front Door, create rules to allow traffic from 147.243.0.0/16 and 2a01:111:2050::/44.

アクセス制限と Front Door の併用

Azure Virtual Network (VNet) 内のリソースからのみアプリに到達できるよう、アプリに対するアクセスをロックダウンする場合は、VNet 内のソースによらず、静的パブリック アドレスが必要になります。If you wish to lock down access to your app so that it can only be reached from resources in your Azure Virtual Network (VNet), you need a static public address on whatever your source is in your VNet. リソースにパブリック アドレスが設定されていない場合は、代わりにサービス エンドポイント機能を使用してください。If the resources do not have a public address, you should use the Service Endpoints feature instead. この機能を有効化する方法については、アクセス制限の構成に関するチュートリアルを参照してください。Learn how to enable this feature with the tutorial on Configuring Access Restrictions.

サービス エンドポイントService endpoints

サービス エンドポイントを使用すると、アプリに対する受信アクセスについて、送信元アドレスが選択したサブネット セットからのものであるアクセスのみに限定できます。Service endpoints allows you to lock down inbound access to your app such that the source address must come from a set of subnets that you select. この機能は、IP アクセス制限と連携して動作します。This feature works in conjunction with the IP Access Restrictions. サービス エンドポイントを設定する場合のユーザー エクスペリエンスは、IP アクセス制限の場合と同じです。Service endpoints are set in the same user experience as the IP Access Restrictions. パブリック アドレスおよび VNet 内のサブネットを指定して、許可と拒否のアクセス ルール リストを作成できます。You can build an allow/deny list of access rules that includes public addresses as well as subnets in your VNets. この機能は、次のようなシナリオをサポートしています。This feature supports scenarios such as:

service endpoints

  • アプリに Application Gateway を設定して、アプリに対する受信トラフィックをロックダウンするSetting up an Application Gateway with your app to lock down inbound traffic to your app
  • アプリに対するアクセスを VNet 内のリソースのもののみに制限する。Restricting access to your app to resources in your VNet. この対象には、VM や ASE のほか、VNet 統合を使用するアプリも含めることができます。This can include VMs, ASEs, or even other apps that use VNet Integration

サービス エンドポイントと Application Gateway の併用

アプリでのサービス エンドポイントの構成方法については、サービス エンドポイントとアクセス制限の構成方法に関するチュートリアルを参照してください。You can learn more about configuring service endpoints with your app in the tutorial on Configuring Service Endpoint Access Restrictions

ハイブリッド接続とHybrid Connections

App Service のハイブリッド接続を使用すると、指定した TCP エンドポイントに対してアプリから送信呼び出しを行うことができます。App Service Hybrid Connections enables your apps to make outbound calls to specified TCP endpoints. エンドポイントには、オンプレミス、VNet 内、またはポート 443 で Azure への送信トラフィックを許可する任意の環境内にあるものを指定できます。The endpoint can be on-premises, in a VNet or anywhere that allows outbound traffic to Azure on port 443. この機能を使用するには、ハイブリッド接続マネージャー (HCM) というリレー エージェントを、Windows Server 2012 以降のホストにインストールする必要があります。The feature requires the installation of a relay agent called the Hybrid Connection Manager (HCM) on a Windows Server 2012 or newer host. HCM は、ポート 443 で Azure Relay に到達できる必要があります。The HCM needs to be able to reach Azure Relay at port 443. HCM は、ポータルにある App Service ハイブリッド接続の UI からダウンロードできます。The HCM can be downloaded from the App Service Hybrid Connections UI in the portal.

ハイブリッド接続のネットワーク フロー

App Service のハイブリッド接続機能は、Azure Relay のハイブリッド接続機能を基に構築されています。The App Service Hybrid Connections feature is built on the Azure Relay Hybrid Connections capability. App Service では、アプリからの TCP ホストとポートへの送信呼び出しのみをサポートするようにこの機能を特殊化して使用しています。App Service uses a specialized form of the feature that only supports making outbound calls from your app to a TCP host and port. こうしたホストとポートは、HCM がインストールされているホスト上でのみ解決を行えば済みます。This host and port only need to resolve on the host where the HCM is installed. App Service 内にあるアプリから、ハイブリッド接続で定義されているホストとポートに対して DNS 参照を実施した場合、トラフィックは自動的にリダイレクトされ、ハイブリッド接続を経由してハイブリッド接続マネージャーから送信されます。When the app, in App Service, does a DNS lookup on the host and port defined in your Hybrid Connection, the traffic is automatically redirected to go through the Hybrid Connection and out the Hybrid Connection Manager. ハイブリッド接続の詳細については、App Service のハイブリッド接続に関するドキュメントを参照してください。To learn more about Hybrid Connections, read the documentation on App Service Hybrid Connections

この機能の一般的な使用例は次のとおりです。This feature is commonly used to:

  • Azure に VPN または ExpressRoute で接続されていないプライベート ネットワーク内のリソースにアクセスするAccess resources in private networks that are not connected to Azure with a VPN or ExpressRoute
  • サポート データベースを移動することなく、App Service へのオンプレミス アプリのリフト アンド シフトをサポートするSupport lift and shift of on-premises apps to App Service without needing to also move supporting databases
  • ハイブリッド接続ごとに単一のホストとポートへのアクセスを安全に提供する。Securely provide access to a single host and port per Hybrid Connection. たいていのネットワーク機能ではネットワークへのアクセスが開放されていますが、ハイブリッド接続を使用すれば、到達可能なホストとポートを 1 つに制限できます。Most networking features open access to a network and with Hybrid Connections you only have the single host and port you can reach.
  • 他の送信接続方法が対応していないシナリオに対応するCover scenarios not covered by other outbound connectivity methods
  • オンプレミスのリソースをアプリで容易に活用できる App Service 内においてデプロイを実行するPerform development in App Service where the apps can easily leverage on-premises resources

この機能を使用すると、受信ファイアウォールに穴を開けることなくオンプレミス リソースにアクセスできるため、開発者から高い人気を得ています。Because the feature enables access to on-premises resources without an inbound firewall hole, it is popular with developers. App Service の他の送信ネットワーク機能は、Azure Virtual Networking とのつながりが非常に強くなっています。The other outbound App Service networking features are very Azure Virtual Networking related. ハイブリッド接続には VNet 経由という依存性がないため、より幅広いネットワークのニーズ向けに使用できます。Hybrid Connections does not have a dependency on going through a VNet and can be used for a wider variety of networking needs. ただし、App Service のハイブリッド接続機能では、この接続上での操作は把握されないことに注意してください。It is important to note that the App Service Hybrid Connections feature does not care or know what you are doing on top of it. つまり、この接続は、メインフレーム上にあるデータベースや Web サービス、任意の TCP ソケットへのアクセスに使用できるということです。That is to say that you can use it to access a database, a web service or an arbitrary TCP socket on a mainframe. 本質的には、この機能は TCP パケットをトンネリングするものです。The feature essentially tunnels TCP packets.

ハイブリッド接続は、開発でよく利用されているだけでなく、非常に多くの運用アプリケーションでも使用されています。While Hybrid Connections is popular for development, it is also used in numerous production applications as well. Web サービスやデータベースへのアクセスには適していますが、非常に多くの接続を作成するような状況には向いていません。It is great for accessing a web service or database, but is not appropriate for situations involving creating many connections.

ゲートウェイが必要な VNet 統合Gateway required VNet Integration

App Service の "ゲートウェイが必要な VNet 統合" 機能を使用すると、アプリから Azure 仮想ネットワーク内に対して送信要求を実行できます。The gateway required App Service VNet Integration feature enables your app to make outbound requests into an Azure Virtual Network. この機能では、アプリが実行されているホストと VNet 上にある Virtual Network ゲートウェイが、ポイント対サイト VPN により接続されます。The feature works by connecting the host your app is running on to a Virtual Network gateway on your VNet with a point-to-site VPN. この機能を構成すると、アプリには、各インスタンスに割り当てられているポイント対サイト アドレスのいずれかが付与されます。When you configure the feature, your app gets one of the point-to-site addresses assigned to each instance. この機能では、リージョンを問わず、クラシック VNet と Resource Manager VNet の双方でリソースにアクセスできます。This feature enables you to access resources in either Classic or Resource Manager VNets in any region.

ゲートウェイが必要な VNet 統合

この機能は、他の VNet 内にあるリソースへのアクセスに関する問題を解決するものですが、VNet 経由で他の VNet やオンプレミスに接続する際にも使用できます。This feature solves the problem of accessing resources in other VNets and can even be used to connect through a VNet to either other VNets or even on-premises. ExpressRoute で接続されている VNet には対応していませんが、サイト間 VPN で接続されているネットワークには使用できます。It does not work with ExpressRoute connected VNets but does with Site-to-site VPN connected networks. App Service Environment (ASE) はもとから VNet 内に存在しているので、一般には、この機能を ASE 内のアプリで使用するのは適切ではありません。It is normally inappropriate to use this feature from an app in an App Service Environment (ASE), because the ASE is already in your VNet. この機能により解決できるユース ケースは次のとおりです。The use cases that this feature solves are:

  • Azure 仮想ネットワーク内のプライベート IP 上にあるリソースにアクセスするAccessing resources on private IPs in your Azure virtual networks
  • サイト間 VPN がある場合にオンプレミスのリソースにアクセスするAccessing resources on-premises if there is a site-to-site VPN
  • ピアリングされた VNet 内にあるリソースにアクセスするAccessing resources in peered VNets

この機能が有効な場合、アプリでは、接続先の VNet で構成されている DNS サーバーが使用されます。When this feature is enabled, your app will use the DNS server that the destination VNet is configured with. この機能の詳細については、App Service の VNet 統合に関するドキュメントを参照してください。You can read more on this feature in the documentation on App Service VNet Integration.

VNet 統合VNet Integration

ゲートウェイが必要な VNet 統合機能は非常に有用ですが、この機能でも、ExpressRoute を越えてリソースにアクセスするという課題は解決できません。The gateway required VNet Integration feature is very useful but still does not solve accessing resources across ExpressRoute. ExpressRoute 接続を越えて到達しなければならないことに加え、サービス エンドポイントで保護されたサービスに対して、アプリから呼び出しを実行できる必要もあります。On top of needing to reach across ExpressRoute connections, there is a need for apps to be able to make calls to service endpoint secured services. これら両方のニーズを解決するため、別の VNet 統合機能が追加されました。To solve both of those additional needs, another VNet Integration capability was added. この新しい VNet 統合機能では、アプリのバックエンドを、同じリージョン内にある Resource Manager VNet のサブネットに配置できます。The new VNet Integration feature enables you to place the backend of your app in a subnet in a Resource Manager VNet in the same region. この機能は、もともと VNet 内に存在する App Service Environment からは利用できません。This feature is not available from an App Service Environment, which is already in a VNet. この機能により以下が可能になります。This feature enables:

  • 同じリージョンにある Resource Manager VNet 内のリソースにアクセスするAccessing resources in Resource Manager VNets in the same region
  • サービス エンドポイントで保護されているリソースにアクセスするAccessing resources that are secured with service endpoints
  • ExpressRoute または VPN 接続越しにアクセス可能なリソースにアクセスするAccessing resources that are accessible across ExpressRoute or VPN connections

VNet 統合

この機能はプレビュー段階です。運用環境のワークロードには使用しないでください。This feature is in preview and should not be used for production workloads. この機能の詳細については、App Service の VNet 統合に関するドキュメントを参照してください。To learn more about this feature, read the docs on App Service VNet Integration.

App Service 環境App Service Environment

App Service Environment (ASE) は、VNet 内で実行されるシングル テナント デプロイ版の Azure App Service です。An App Service Environment (ASE) is a single tenant deployment of the Azure App Service that runs in your VNet. ASE は、以下のようなユース ケースに対応しています。The ASE enables use cases such as:

  • VNet 内にあるリソースにアクセスするAccess resources in your VNet
  • ExpressRoute を越えてリソースにアクセスするAccess resources across ExpressRoute
  • VNet 内のプライベート アドレスを使用してアプリを公開するExpose your apps with a private address in your VNet
  • 複数のサービス エンドポイントを越えてリソースにアクセスするAccess resources across service endpoints

ASE を使用する場合、この機能は初めから VNet 内に存在しているので、VNet 統合やサービス エンドポイントなどの機能を使用する必要はありません。With an ASE, you do not need to use features like VNet Integration or service endpoints because the ASE is already in your VNet. サービス エンドポイント越しに SQL や Storage などのリソースにアクセスする必要がある場合は、ASE サブネット上でサービス エンドポイントを有効化してください。If you want to access resources like SQL or Storage over service endpoints, enable service endpoints on the ASE subnet. VNet 内にあるリソースにアクセスする場合、追加の構成は必要ありません。If you want to access resources in the VNet, there is no additional configuration required. ExpressRoute 越しにリソースにアクセスする場合は、初めから VNet 内にいるため、ASE やこの環境内のアプリについて構成を行う必要はありません。If you want to access resources across ExpressRoute, you are already in the VNet and do not need to configure anything on the ASE or the apps inside it.

ILB ASE 内にあるアプリはプライベート IP アドレスで公開可能なので、WAF デバイスを容易に追加して、他のアプリの安全を保ったまま目的のアプリのみをインターネットに公開することができます。Because the apps in an ILB ASE can be exposed on a private IP address, you can easily add WAF devices to expose just the apps that you want to the internet and keep the rest secure. これにより、多層アプリケーションの開発が容易になります。It lends itself to easy development of multi-tier applications.

現状では、ASE 内にあるマルチテナント サービスからでは実現できないユース ケースもあります。There are some things that are not yet possible from the multi-tenant service that are from an ASE. こうしたものの例を次に示します。Those include things like:

  • プライベート IP アドレスでアプリを公開するExpose your apps on a private IP address
  • アプリに搭載されていないネットワーク制御機能を使用して、すべての送信トラフィックを保護するSecure all outbound traffic with network controls that are not a part of your app
  • シングル テナント サービスでアプリをホストするHost your apps in a single tenant service
  • マルチテナント サービスで許容される数を超えてインスタンスをスケールアップするScale up to many more instances than are possible in the multi-tenant service
  • プライベート CA で保護されているエンドポイントを使用して、アプリ用にプライベート CA クライアントの証明書を読み込むLoad private CA client certificates for use by your apps with private CA secured endpoints
  • アプリ レベルでの無効化機能を提供せずに、システムでホストされているアプリすべてに TLS 1.1 を強制的に適用するForce TLS 1.1 across all of the apps hosted in the system without any ability to disable at the app level
  • 顧客と共有していない ASE 内にあるすべてのアプリに対して、専用の送信アドレスを提供するProvide a dedicated outbound address for all of the apps in your ASE that is not shared with any customers

VNet 内の ASE

ASE があれば、専用のアプリを隔離したまま最適にホストできますが、管理上の課題が伴います。The ASE provides the best story around isolated and dedicated app hosting but does come with some management challenges. 運用環境で ASE を使用する前に、以下のことを検討してください。Some things to consider before using an operational ASE are:

  • ASE は VNet 内で実行されますが、VNet の外部と依存関係を持っています。An ASE runs inside your VNet but does have dependencies outside of the VNet. こうした依存関係は許容しなければなりません。Those dependencies must be allowed. App Service Environment のネットワークの考慮事項」を参照してください。Read more in Networking considerations for an App Service Environment
  • ASE には、マルチテナント サービスのような迅速なスケーラビリティはありません。An ASE does not scale immediately like the multi-tenant service. 事後対応的にスケーリングを行うのではなく、スケーリングのニーズを予測する必要があります。You need to anticipate scaling needs rather than reactively scaling.
  • ASE には比較的高い初期費用がかかります。An ASE does have a higher up front cost associated with it. ASE を最大限に活用するために、少量の作業に ASE を利用するのではなく、多量のワークロードを配置するように計画してください。In order to get the most out of your ASE, you should plan on putting many workloads into one ASE rather than have it used for small efforts
  • ASE 内のアプリで、アクセス制限の対象を ASE 内にある一部のアプリとそれ以外のアプリで分けることはできません。The apps in an ASE cannot restrict access to some apps in an ASE and not others.
  • ASE はサブネット内にあるので、ASE で送受信するすべてのトラフィックにあらゆるネットワーク規則が適用されます。The ASE is in a subnet and any networking rules apply to all the traffic to and from that ASE. 1 つのアプリのみに受信トラフィック規則を割り当てる必要がある場合は、アクセス制限を使用してください。If you want to assign inbound traffic rules for just one app, use Access Restrictions.

各種機能の組み合わせCombining features

上述のマルチテナント サービス向け機能を組み合わせて使用することで、さらに複雑なユース ケースにも対応できます。The features noted for the multi-tenant service can be used together to solve more elaborate use cases. ここでは、最も一般的なユース ケースを 2 つ紹介しますが、これらはあくまでも例に過ぎません。Two of the more common use cases are described here but they are just examples. 各種機能の働きを理解すれば、お使いのシステム アーキテクチャのニーズをほぼすべて解決できるでしょう。By understanding what the various features do, you can solve nearly all of your system architecture needs.

VNet 内にアプリを挿入するInject app into a VNet

頻繁にお問い合わせを頂く事項として、VNet 内へのアプリの配置方法があります。A common request is on how to put your app in a VNet. VNet 内にアプリを配置すると、アプリの受信エンドポイントと送信エンドポイントが VNet 内に存在することになります。Putting your app into a VNet means that the inbound and outbound endpoints for an app are within a VNet. この問題の最適な解決策は ASE ですが、各種機能を組み合わせることで、必要な機能のほとんどをマルチテナント サービス内で揃えることができます。The ASE provides the best solution to solve this problem but, you can get most of what is needed with in the multi-tenant service by combining features. たとえば、以下のようにすることで、プライベートの受信アドレスと送信アドレスを設定したイントラネット専用アプリケーションをホストできます。For example, you can host intranet only applications with private inbound and outbound addresses by:

  • プライベートの受信アドレスと送信アドレスを指定してアプリケーション ゲートウェイを作成するCreating an Application Gateway with private inbound and outbound address
  • サービス エンドポイントを使用してアプリに対する受信トラフィックを保護するSecuring inbound traffic to your app with service endpoints
  • 新しい VNet 統合を使用して、アプリのバックエンドを VNet 内に配置するUse the new VNet Integration so the backend of your app is in your VNet

このデプロイ形式では、インターネットへの送信トラフィックに専用アドレスを使用することはできず、またアプリからの送信トラフィックを一切ロック ダウンできません。This deployment style would not give you a dedicated address for outbound traffic to the internet or give you the ability to lock down all outbound traffic from your app. このデプロイ形式では、ASE を使用した場合に利用可能な機能のほとんどを利用できます。This deployment style would give you a much of what you would only otherwise get with an ASE.

多層アプリケーションを作成するCreate multi-tier applications

多層アプリケーションとは、API バックエンド アプリにアクセスできるのがフロントエンド層のみに制限されているアプリケーションのことです。A multi-tier application is an application where the API backend apps can only be accessed from the front-end tier. 多層アプリケーションを作成する方法には、次のものがあります。To create a multi-tier application, you can:

  • VNet 統合を使用して、フロントエンド Web アプリのバックエンドを VNet 内のサブネットと接続するUse VNet Integration to connect the backend of your front-end web app with a subnet in a VNet
  • サービス エンドポイントを使用して、API アプリへの受信トラフィックを、フロントエンド Web アプリで使用するサブネットからのトラフィックのみに制限するUse service endpoints to secure inbound traffic to your API app to only coming from the subnet used by your front-end web app

多層アプリ

別個のフロントエンド アプリで VNet 統合を使用し、サブネットで API アプリからサービス エンドポイントを使用することで、複数のフロントエンド アプリで同じ API アプリを使用できます。You can have multiple front-end apps use the same API app by using VNet Integration from the other front-end apps and service endpoints from the API app with their subnets.