App Service Environment バージョンの比較
App Service Environment には 3 つのバージョンがあります。 App Service Environment v3 が最新バージョンで、以前のバージョンとは異なる特長と機能が備わっています。
重要
この記事は、App Service Environment v1 および 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 日間の猶予期間を 1 回だけ要求することができます。 この猶予期間の詳細と要求方法については、猶予期間の概要を確認した後、Azure portal に移動し、お使いの各 App Service Environment の [移行] ブレードにアクセスしてください。
App Service Environment v1/v2 の提供終了に関する最新情報については、App Service Environment v1 と v2 の提供終了に関する更新情報の記事を参照してください。
バージョン間の比較
デプロイ
機能 | App Service Environment v1 | App Service Environment v2 | App Service Environment v3 |
---|---|---|---|
ハードウェア | Cloud Services (クラシック) | Cloud Services (クラシック) | Virtual Machine Scale Sets |
利用可能な SKU | P1、P2、P3、P4 | I1、I2、I3 | I1v2、I2v2、I3v2、I4v2、I5v2、I6v2 |
CPU | 物理コア | 物理コア | 仮想 CPU (vCPU) |
最大インスタンス数 | 55 ホスト (既定のフロントエンド + ワーカー) | App Service プランごとに 100 インスタンス。 すべてのプランで最大 200 インスタンス。 | App Service プランごとに 100 インスタンス。 すべてのプランで最大 200 インスタンス。 |
ゾーン冗長性 | いいえ | いいえ - 1 つのゾーンにピン留めするゾーンを使用できます | はい |
専用ホスト グループ | いいえ | いいえ | はい (ゾーン冗長と互換性がありません) |
計画メンテナンスのアップグレードの優先順位 | いいえ | 番号 | はい |
FTPS | はい | はい | はい、明示的に有効にする必要があります。 カスタム ドメイン サフィックスを使用した FTPS エンドポイントへのアクセスはサポートされていません。 |
FTPS エンドポイントの構造 | ftps://APP-NAME.ASE-NAME.appserviceenvironment.net | ftps://APP-NAME.ASE-NAME.appserviceenvironment.net - カスタム ドメイン サフィックスは、App Service Environment の名前と既定のドメイン サフィックスをカスタム ドメイン サフィックスに置き換えることで構成されている場合にサポートされます。 | ftps://ASE-NAME.ftp.appserviceenvironment.net/site/wwwroot - カスタム ドメイン サフィックスはサポートされていません。 同じ App Service Environment v3 上の各アプリは同じ FTPS エンドポイントを使用しますが、認証には独自のアプリケーション スコープ資格情報を持っています。 |
リモート デバッグ | はい | はい | はい、明示的に有効にする必要があります |
Azure 仮想ネットワーク (クラシック) のサポート | はい | いいえ | いいえ |
ネットワーク
機能 | App Service Environment v1 | App Service Environment v2 | App Service Environment v3 |
---|---|---|---|
ネットワーク関連の依存関係 | すべての受信トラフィックと送信トラフィックを管理する必要があります。 ネットワーク セキュリティ グループでは、管理トラフィックを許可する必要があります。 | すべての受信トラフィックと送信トラフィックを管理する必要があります。 ネットワーク セキュリティ グループでは、管理トラフィックを許可する必要があります。 Azure Load Balancer がポート 16001 のサブネットに接続できることを確認します。 | お客様の仮想ネットワークにネットワーキング関連の依存関係がありません。 Azure Load Balancer がポート 80 のサブネットに接続できることを確認します。 |
プライベート エンドポイントのサポート | いいえ | いいえ | はい、明示的に有効にする必要があります |
内部 VIP の App Service Environment 内のアプリに、グローバル ピアリングによりアクセスできます | いいえ | 番号 | はい |
SMTP トラフィック | はい | イエス | はい |
トラフィックを監視するためのネットワーク ウォッチャーまたは NSG フロー ログ | はい | イエス | はい |
サブネットの委任 | 必要なし | 必要なし | Microsoft.Web/hostingEnvironments に委任する必要があります |
サブネットのサイズ | App Service プランがない状態の App Service Environment v1 では、アプリを作成する前の段階で 12 個のアドレスが使用されます。 ILB App Service Environment v1 を使用する場合、アプリを作成する前に 13 個のアドレスが使用されます。 スケールアウトすると、App Service プラン インスタンスの 15 および 20 の倍数ごとにインフラストラクチャ ロールが追加されます。 | App Service プランがない状態の App Service Environment v2 では、アプリを作成する前の段階で 12 個のアドレスが使用されます。 ILB App Service Environment v2 を使用する場合、アプリを作成する前に 13 個のアドレスが使用されます。 スケールアウトすると、App Service プラン インスタンスの 15 および 20 の倍数ごとにインフラストラクチャ ロールが追加されます。 | 特定のどのサブネットにも、管理のために予約されている 5 つのアドレスがあります。 管理アドレスに加えて、App Service Environment v3 はサポート インフラストラクチャを動的にスケーリングし、構成と負荷に応じて 4 から 27 個のアドレスを使用します。 残りのアドレスは、App Service プランのインスタンスに使用できます。 サブネットの最小サイズは /27 アドレス空間 (32 アドレス) です。 |
DNS フォールバック | Azure DNS | Azure DNS | パブリック DNS へのフォワーダーがあることを確認するか、カスタム DNS サーバーの一覧に Azure DNS を含めます |
スケーリング
App Service Environment v3 は、最新の Virtual Machine Scale Sets インフラストラクチャで実行され、App Service Environment v1 と v2 は Cloud Services (クラシック) で実行されます。 このため、App Service Environment v3 では、すべてのバージョンで最高のパフォーマンスと最速のスケーリング時間が実現します。
機能 | App Service Environment v1 | App Service Environment v2 | App Service Environment v3 |
---|---|---|---|
フロントエンドのスケーリング管理 | 手動 | 手動 | プラットフォームによる管理 |
スケーリング操作 | 他のスケーリング操作をブロックする | 他のスケーリング操作をブロックする | 他のスケール操作をブロックしない |
証明書とドメイン
機能 | App Service Environment v1 | App Service Environment v2 | App Service Environment v3 |
---|---|---|---|
アプリを使用した、IP ベースのトランスポート層セキュリティ (TLS) または Secure Sockets Layer (SSL) バインド | はい | はい | いいえ |
カスタム ドメイン サフィックス | はい (SNI ベースの TLS 接続が必要です) | はい (特定の API バージョンでのみサポートされます) | はい |
既定のホスト名 | カスタム ドメイン サフィックスがある場合、既定のホスト名にはカスタム ドメイン サフィックスが含まれており、APP-NAME.internal.contoso.com 形式になります。 | カスタム ドメイン サフィックスがある場合、既定のホスト名にはカスタム ドメイン サフィックスが含まれており、APP-NAME.internal.contoso.com 形式になります。 | 既定のホスト名は常に App Service Environment の既定のドメイン サフィックスを使用し、APP-NAME.ASE-NAME.appserviceenvironment.net の形式になります。 App Service Environment v3 では、ユーザーがカスタム ドメイン サフィックスを追加したときに既定のドメイン サフィックスが維持されます。 カスタム ドメイン サフィックスを追加する場合、カスタム ドメイン サフィックスの構成は customDnsSuffixConfiguration プロパティの下にあります。 |
App Service マネージド証明書のサポート | いいえ | 番号 | いいえ |
バックアップと復元
機能 | App Service Environment v1 | App Service Environment v2 | App Service Environment v3 |
---|---|---|---|
ファイアウォールの背後にあるストレージ アカウントでのバックアップおよび復元操作の実行 | はい | はい | いいえ |
ログ記録と監視
機能 | App Service Environment v1 | App Service Environment v2 | App Service Environment v3 |
---|---|---|---|
仮想ネットワーク経由のストレージ アカウントへのアプリケーション ログ | はい | はい | いいえ。 代わりに診断ログの使用をお勧めします。 ログ ストレージ アカウントにファイアウォールを使用する必要がある場合は、ストレージ アカウントが別のリージョンに存在し、規則で App Service Environment の送信パブリック アドレスを使用する必要があります。 詳細については、「ネットワークに関する考慮事項」を参照してください。 |
Azure Policy の統合 | はい | イエス | はい |
Azure Advisor の統合 | はい | イエス | はい |
価格
App Service Environment v3 は、スタンプ料金の廃止やインスタンス サイズの拡大により、以前のバージョンよりも安くなることがよくあります。 App Service Environment v3 への移行がコストに与える影響についての詳細とシナリオ例については、移行価格のサンプルと、「App Service Environment v3 に移行してコスト削減を見積もる」を参照してください。
機能 | App Service Environment v1 | App Service Environment v2 | App Service Environment v3 |
---|---|---|---|
価格 | 各 vCPU に対する支払い | スタンプ料金と Isolated インスタンスあたりのコスト、スタンプ料金の予約が可能 | スタンプ料金はかからず、Isolated v2 レートには 1 年から 3 年の予約インスタンスの価格があります。 Azure Savings Plans for Compute も利用できます。 |
よくある質問
- App Service Environment v1、v2、v3 で使用できる SKU は何ですか?
- 「お客様の仮想ネットワークにネットワーキング関連の依存関係がありません」とはどういう意味ですか?
- App Service Environment v3 でファイアウォールの背後にあるストレージ アカウントへのバックアップと復元がサポートされないのはなぜですか?
- カスタム ドメイン サフィックスとは何ですか?
- 各バージョンの対応リージョンはどこですか?
App Service Environment v1、v2、v3 で使用できる SKU は何ですか?
App Service Environment v1 では Premium SKU を使用し、App Service Environment v2 では Isolated SKU を使用します。 App Service Environment v3 では Isolated v2 を使用します。 次の表に、各 SKU で使用可能なインスタンスと、それぞれのコア数および RAM を一覧表示します。 Isolated v2 と Isolated の間の対応するインスタンスでは、コアと RAM が 2 倍になります。 Isolated または Premium から App Service Environment v3 に移行するときにこの容量の増加を確認し、過剰プロビジョニングされていないことを確認する必要があります。
App Service Environment v3 (Isolated v2):
Isolated v2 | コア | RAM (GB) |
---|---|---|
I1v2 | 2 | 8 |
I2v2 | 4 | 16 |
I3v2 | 8 | 32 |
I4v2 | 16 | 64 |
I5v2 | 32 | 128 |
I6v2 | 64 | 256 |
App Service Environment v2 (Isolated):
Isolated | コア | RAM (GB) |
---|---|---|
I1 | 1 | 3.5 |
i2 | 2 | 7 |
I3 | 4 | 14 |
App Service Environment v1 (Premium):
Premium | コア | RAM (GB) |
---|---|---|
P1 | 1 | 1.75 |
P2 | 2 | 3.5 |
P3 | 4 | 7 |
P4 | 8 | 14 |
「お客様の仮想ネットワークにネットワーキング関連の依存関係がありません」とはどういう意味ですか?
App Service Environment v3 では、管理トラフィックと依存関係トラフィックのインバウンド規則とアウトバウンド規則を設定する必要はありません。 App Service Environment v3 では、管理トラフィックと依存関係トラフィックが仮想ネットワークではなく Azure バックボーン内に留まるように設計されています。 仮想ネットワークを通過するトラフィックは、アプリ間のアプリケーション トラフィックのみです。
App Service Environment v3 を運用するための最小要件は次のとおりです。
ソース / ターゲット ポート | Direction | source | 到着地 | 目的 |
---|---|---|---|---|
* / 80 | 受信 | AzureLoadBalancer | App Service Environment のサブネット範囲 | 内部正常性 ping トラフィックを許可する |
App Service Environment v3 のネットワーク関連の依存関係の詳細については、「ポートとネットワークの制限」を参照してください。
App Service Environment v2 では、管理する必要があるインバウンド要件とアウトバウンド要件が多数あります。 これらの規則を変更すると、環境が不健全な状態になる可能性があります。
- 受信
- IP サービス タグ AppServiceManagement からの TCP (ポート 454、455)
- ロード バランサーからの TCP (ポート 16001)
- App Service Environment サブネットから App Service Environment サブネット (すべてのポート)
- 送信
- すべての IP への UDP (ポート 53)
- すべての IP への UDP (ポート 123)
- すべての IP への TCP (ポート 80、443)
- IP サービス タグ Sql への TCP (ポート 1433)
- すべての IP への TCP (ポート 12000)
- App Service Environment サブネットへ (すべてのポート)
App Service Environment v2 のネットワーク関連の依存関係については、「インバウンドおよびアウトバウンドの依存関係」を参照してください。
App Service Environment v3 でファイアウォールの背後にあるストレージ アカウントへのバックアップと復元がサポートされないのはなぜですか?
この制限は、App Service Environment v3 に対して実装された、基になるインフラストラクチャの変更の結果です。 バックアップと復元は管理操作であり、すべての管理トラフィックは顧客の仮想ネットワークの外部で分離されるため、これらの操作は Azure バックボーン ネットワークを介して行う必要があります。 そのため、お客様はストレージ アカウントのファイアウォールを介してこのトラフィックを明示的に許可することはできません。
カスタム ドメイン サフィックスとは何ですか?
カスタム ドメイン サフィックスは App Service Environment 用です。 App Service Environment v1 と v3 で使用できますが、App Service Environment v2 から削除されました。
これは、App Service のカスタム ドメイン バインドとは異なります。 カスタム ドメイン サフィックスは、App Service Environment が使用できるルート ドメインを定義します。 Azure App Service のパブリック版では、すべての Web アプリの既定のルート ドメインは azurewebsites.netです。 ILB App Service Environment の場合、既定のルート ドメインは appserviceenvironment.net です。 ただし、ILB App Service Environment はお客様の仮想ネットワークの内部にあるため、お客様は会社の内部仮想ネットワーク内で使用するのに適した既定のドメインに加えて、ルート ドメインを使用できます。 たとえば、Contoso Corporation という架空の企業では、Contoso の仮想ネットワーク内でのみ解決およびアクセス可能になるよう設計されたアプリに対して、internal.contoso.com という既定のルート ドメインが使用されます。 この仮想ネットワーク内のアプリにアクセスするには、APP-NAME.internal.contoso.com にアクセスします。
カスタム ドメイン サフィックスの詳細については、「App Service のカスタム ドメイン サフィックス」を参照してください。
各バージョンの対応リージョンはどこですか?
バージョン間のハードウェアの変更により、App Service Environment v1/v2 はサポートされるが、App Service Environment v3 がサポートされないリージョンがあります。 サポートされているリージョンの一覧は、最新の可用性で継続的に更新されます。