Azure Application Gateway v2 は、アプリケーション レイヤーで動作する Web トラフィック ロード バランサーです。 Application Gateway は、HTTP 要求の属性に基づいて Web アプリケーションへのトラフィックを管理します。 高度なルーティング機能を備え、セキュリティとスケーラビリティを強化する必要があるシナリオには、Application Gateway を使用します。
この記事では、アーキテクトとして ネットワーク オプションを 確認し、ワークロードの Web トラフィック ロード バランサーとして Application Gateway を選択していることを前提としています。 この記事のガイダンスでは、Well-Architected Framework の柱の原則にマップされるアーキテクチャに関する推奨事項を示します。
重要
このガイドの使用方法
各セクションには、設計チェックリスト があり、テクノロジ スコープにローカライズされた設計戦略と共に、関心のあるアーキテクチャ領域が示されています。
また、これらの戦略の具体化に役立つテクノロジ機能の推奨事項も含まれています。 推奨事項は、Application Gateway とその依存関係で使用できるすべての構成の完全な一覧を表すわけではありません。 代わりに、設計パースペクティブにマップされた主要な推奨事項が一覧表示されます。 推奨事項を使用して概念実証を構築するか、既存の環境を最適化します。
主要な推奨事項を示す基本的なアーキテクチャ: ベースラインの高可用性、ゾーン冗長 Web アプリケーション アーキテクチャ。
技術の範囲
このレビューでは、次の Azure リソースに関する相互に関連する決定に焦点を当てます。
- Application Gateway v2
- Application Gateway 上の Web アプリケーション ファイアウォール (WAF)
信頼性
信頼性の柱の目的は、十分な回復性と障害から迅速に回復する機能を構築 、継続的な機能を提供することです。
信頼性設計の原則、個々のコンポーネント、システム フロー、およびシステム全体に適用される高度な設計戦略を提供します。
設計チェックリスト
信頼性 の設計レビュー チェックリストに基づいて、設計戦略を開始します。 Application Gateway の機能とその依存関係を念頭に置いて、ビジネス要件との関連性を判断します。 必要に応じて、より多くのアプローチを含むように戦略を拡張します。
ワークロードに Application Gateway v1 が特に必要な場合を除き、新しいデプロイでは Application Gateway v2 を使用します。
設計の冗長性を構築します。 Application Gateway インスタンスを可用性ゾーンに分散してフォールト トレランスを向上させ、冗長性を構築します。 1 つのゾーンで障害が発生した場合、トラフィックは他のゾーンに送信されます。 詳細については、「可用性ゾーンとリージョンを使用するための推奨事項」を参照してください。
Application Gateway にアクセスしたり、さらに変更を加えたりする前に、ルールの更新やその他の構成変更の追加時間を計画します。 たとえば、サーバーが既存の接続をドレインする必要があるため、バックエンド プールからサーバーを削除するために余分な時間が必要になる場合があります。
ヘルスエンドポイント監視パターンを実装します。 アプリケーションは正常性エンドポイントを公開する必要があります。これは、アプリケーションが要求を処理するために必要な重要なサービスと依存関係の状態を集計します。 Application Gateway 正常性プローブは、エンドポイントを使用して、バックエンド プール内のサーバーの正常性を検出します。 詳細については、「正常性エンドポイント監視パターン」を参照してください。
間隔としきい値の設定がヘルスプローブに及ぼす影響を評価します。 正常性プローブは、設定された間隔で構成されたエンドポイントに要求を送信します。 バックエンドは、異常と見なされる前に、失敗した要求が限度を許容します。 これらの設定は競合する可能性があり、トレードオフが発生します。
間隔が長いほど、サービスの負荷が高くなります。 各 Application Gateway インスタンスは独自の正常性プローブを送信するため、100 インスタンスが存在する場合、30 秒ごとに 100 件の要求が送信されます。
間隔を小さくすると、健康プローブが停止を検出するまでの時間が長くなります。
異常で低いしきい値は、短時間の一時的障害によってバックエンドがシャットダウンする可能性を高めます。
しきい値が高い場合は、バックエンドがローテーションから除外されるまでの時間が長くなります。
正常性エンドポイントを使用してダウンストリームの依存関係を確認します。 エラーを分離するために、各バックエンドに独自の依存関係がある場合があります。 たとえば、Application Gateway の背後でホストするアプリケーションには複数のバックエンドがあり、各バックエンドが異なるデータベースまたはレプリカに接続する場合があります。 このような依存関係が失敗した場合、アプリケーションは動作する可能性がありますが、有効な結果は返されません。 そのため、正常性エンドポイントは、理想的にすべての依存関係を検証する必要があります。
正常性エンドポイントの各呼び出しに直接依存関係の呼び出しがある場合、そのデータベースは 1 つのクエリではなく 30 秒ごとに 100 個のクエリを受け取ります。 過剰なクエリを回避するために、正常性エンドポイントは依存関係の状態を短期間キャッシュする必要があります。
Application Gateway の制限事項と、信頼性に影響する可能性がある既知の問題を考慮してください。 設計上の動作、構築中の修正、プラットフォームの制限事項、考えられる回避策または軽減策に関する重要な情報については、 Application Gateway の FAQ を参照してください。 Application Gateway 専用サブネットでは UDR を使用しないでください。
Application Gateway のバックエンド接続に影響する可能性がある、ソース ネットワーク アドレス変換 (SNAT) ポートの制限事項を設計で検討してください。 一部の要因は、Application Gateway が SNAT ポート制限に達する方法に影響します。 たとえば、バックエンドがパブリック IP アドレスの場合は、独自の SNAT ポートが必要です。 SNAT ポートの制限を回避するには、次のいずれかのオプションを実行します。
各 Application Gateway のインスタンスの数を増やします。
バックエンドをスケールアウトして、IP アドレスを増やします。
バックエンドを同じ仮想ネットワークに移動し、バックエンドにプライベート IP アドレスを使用します。
Application Gateway が SNAT ポートの制限に達すると、1 秒あたりの要求 (RPS) に影響します。 たとえば、Application Gateway はバックエンドへの新しい接続を開けず、要求は失敗します。
推奨事項
| 勧告 | メリット |
|---|---|
|
ゾーン対応の構成で Application Gateway インスタンスをデプロイします。 一部のリージョンでこの機能が提供されているわけではないため、ゾーン冗長のリージョンサポートを確認してください。 |
複数のインスタンスを複数のゾーンに分散すると、ワークロードは 1 つのゾーンでの障害に耐えることができます。 使用できないゾーンがある場合、トラフィックは自動的に他のゾーンの正常なインスタンスに移行され、アプリケーションの信頼性が維持されます。 |
| Application Gateway 正常性プローブを使用して、バックエンドの使用不能を検出します。 | ヘルスプローブにより、トラフィックはトラフィックを処理できるバックエンドにのみルーティングされます。 Application Gateway は、バックエンド プール内のすべてのサーバーの正常性を監視し、異常と見なされるすべてのサーバーへのトラフィックの送信を自動的に停止します。 |
| クライアントがアプリケーションに送信するトラフィックが多くなりすぎないように、Azure WAF の レート制限規則 を構成します。 | 再試行 Storm などの問題を回避するには、レート制限を使用します。 |
|
バックエンドの正常性レポートが適切に機能し、正しいログとメトリックを生成するように、Application Gateway で UDR を使用しないでください。 Application Gateway サブネットで UDR を使用する必要がある場合は、「 サポートされている UDR」を参照してください。 |
Application Gateway サブネット上の UDR は、いくつかの問題を引き起こす可能性があります。 バックエンドの正常性、ログ、メトリックを表示できるように、Application Gateway サブネットで UDR を使用しないでください。 |
| バックエンド アプリケーションのリスナーとトラフィックの特性に合わせて IdleTimeout 設定を構成します。 既定値は 4 分です。 最大 30 分まで構成できます。 詳細については、 ロード バランサーの伝送制御プロトコル (TCP) のリセットとアイドル タイムアウトに関するページを参照してください。 |
バックエンドと一致するように IdleTimeout を設定します。 この設定により、バックエンドが要求に応答するのに 4 分以上かかる場合に、Application Gateway とクライアント間の接続が開いたままになります。 この設定を構成しないと、接続が閉じられ、クライアントにバックエンド応答が表示されません。 |
安全
セキュリティの柱の目的は、ワークロードに対して機密性、整合性、可用性を保証することです。
セキュリティ設計の原則は、Application Gateway の技術的な設計にアプローチを適用することで、これらの目標を達成するための高度な設計戦略を提供します。
設計チェックリスト
セキュリティ の 設計レビュー チェックリストに基づいて設計戦略を開始し、セキュリティ体制を改善するための脆弱性と制御を特定します。 必要に応じて、より多くのアプローチを含むように戦略を拡張します。
エッジで一般的な脅威をブロックします。 WAF は Application Gateway と統合されます。 フロントエンドで WAF ルールを有効にして、攻撃元に近いネットワーク エッジの一般的な悪用や脆弱性からアプリケーションを保護します。 詳細については、「 Application Gateway での WAF」を参照してください。
WAF が Application Gateway の容量変更にどのように影響するかを理解します。 WAF を有効にすると、Application Gateway は次のようになります。
要求が完全に到着するまで、すべての要求をバッファーします。
要求がコア ルール セット内のルール違反と一致するかどうかを確認します。
パケットをバックエンド インスタンスに転送します。
30 MB 以上の大きなファイルアップロードでは、大幅な待機時間が発生する可能性があります。 APPLICATION Gateway の容量要件は WAF を有効にすると変更されるため、最初にこの方法を適切にテストして検証することをお勧めします。
Azure Front Door と Application Gateway を使用して HTTP または HTTPS アプリケーションを保護する場合は、Azure Front Door で WAF ポリシーを使用し、Application Gateway をロックダウンして Azure Front Door からのトラフィックのみを受信します。 特定のシナリオでは、特に Application Gateway にルールを実装することが強制される場合があります。 たとえば、ModSec CRS 2.2.9、CRS 3.0、または CRS 3.1 の規則が必要な場合は、Application Gateway でのみこれらの規則を実装できます。 逆に、Azure Front Door ではレート制限と geo フィルタリングがサポートされており、Application Gateway ではこれらの機能はサポートされていません。
コントロール プレーンへの承認されたアクセスのみを許可します。 Application Gateway のロールベースのアクセス制御 (RBAC) を使用して、アクセスを必要とする ID のみに制限します。
転送中のデータを保護します。 エンド ツー エンドのトランスポート層セキュリティ (TLS)、TLS 終了、およびエンド ツー エンド TLS 暗号化を有効にします。 バックエンド トラフィックを再暗号化するときは、バックエンド サーバー証明書にルート証明機関と中間証明機関 (CA) の両方が含まれていることを確認します。
既知の CA を使用して、バックエンド サーバーの TLS 証明書を発行します。 信頼された CA を使用して証明書を発行しない場合、Application Gateway は信頼された CA 証明書が見つかるまでチェックします。 信頼された CA が見つかるときだけ、セキュリティで保護された接続が確立されます。 それ以外の場合、Application Gateway はバックエンドを異常としてマークします。
アプリケーション シークレットを保護します。 セキュリティを強化し、証明書の更新とローテーションプロセスを容易にするために、Azure Key Vault を使用して TLS 証明書を格納します。
攻撃対象領域を減らし、構成を強化します。 必要のない既定の構成を削除し、Application Gateway の構成を強化してセキュリティ制御を強化します。 Application Gateway のすべてのネットワーク セキュリティ グループ (NSG) の制限に準拠します。
バックエンド プール リソースには、適切なドメイン ネーム システム (DNS) サーバーを使用します。 バックエンド プールに解決可能な完全修飾ドメイン名 (FQDN) が含まれている場合、DNS 解決はプライベート DNS ゾーンまたはカスタム DNS サーバー (仮想ネットワークで構成されている場合) に基づくか、既定の Azure 提供の DNS を使用します。
異常なアクティビティを監視します。 定期的にログを確認して、攻撃と誤検知を確認します。 Application Gateway から組織の一元化されたセキュリティ情報とイベント管理 (SIEM) (Microsoft Sentinel など) に WAF ログを送信して、脅威パターンを検出し、ワークロード設計に予防措置を組み込みます。
推奨事項
| 勧告 | メリット |
|---|---|
| セキュリティを強化するために TLS ポリシー を設定します。 最新の TLS ポリシー バージョンを使用していることを確認します。 | 最新の TLS ポリシーを使用して、TLS 1.2 とより強力な暗号の使用を強制します。 TLS ポリシーには、TLS プロトコル バージョンと暗号スイートの制御と、TLS ハンドシェイクで暗号が使用される順序も含まれます。 |
| TLS 終了には Application Gateway を使用します。 | 異なるバックエンドに送信される要求は、各バックエンドに再認証する必要がないため、パフォーマンスが向上します。 ゲートウェイは要求コンテンツにアクセスし、インテリジェントなルーティング決定を行うことができます。 証明書を Application Gateway にインストールするだけで、証明書の管理が簡素化されます。 |
| Application Gateway を Key Vault と統合して、TLS 証明書を格納します。 | このアプローチにより、セキュリティが強化され、ロールと責任の分離が容易になり、マネージド証明書のサポートが提供され、証明書の更新とローテーションのプロセスが容易になります。 |
| Application Gateway のすべての NSG 制限に準拠します。 | Application Gateway サブネットは NSG をサポートしていますが、いくつかの制限があります。 たとえば、特定のポート範囲との一部の通信は禁止されています。 これらの制限の影響を理解していることを確認してください。 |
コストの最適化
コストの最適化では、支出パターンの検出 、重要な領域への投資の優先順位付け、ビジネス要件を満たしながら組織の予算を満たすために他の での最適化に重点を置いています。
コスト最適化の設計原則は、Application Gateway とその環境に関連する技術的な設計において、これらの目標を達成し、必要に応じてトレードオフを行う高度な設計戦略を提供します。
設計チェックリスト
投資のコスト最適化 の 設計レビュー チェックリストに基づいて、設計戦略を開始します。 ワークロードの設計を、そのワークロードに割り当てられた予算に合わせて微調整します。 設計では、適切な Azure 機能を使用し、投資を監視し、時間の経過と同時に最適化する機会を見つける必要があります。
Application Gateway と WAF の価格について理解を深めてください。 ワークロードの容量の需要を満たし、リソースを無駄にすることなく予想されるパフォーマンスを実現するために、適切なサイズのオプションを選択します。 コストを見積もる場合は、 料金計算ツールを使用します。
未使用の Application Gateway インスタンスを削除し、使用されていないインスタンスを最適化します。 不要なコストを回避するには、バックエンド プールが空の Application Gateway インスタンスを特定して削除します。 Application Gateway インスタンスが使用されていない場合は停止します。
Application Gateway インスタンスのスケーリング コストを最適化します。 スケーリング戦略を最適化し、wokload の需要を減らすには、 スケーリング コストを最適化するための推奨事項を参照してください。
アプリケーション トラフィックの要件に基づいてサービスをスケールインまたはスケールアウトするには、 Application Gateway v2 で自動スケールを使用します。
Application Gateway の使用量メトリックを監視し、そのコストへの影響を理解します。 Azure は、追跡されたメトリックに基づいて Application Gateway のインスタンスを従量制で課金します。 さまざまなメトリックと容量ユニットを評価し、コスト ドライバーを決定します。 詳細については、「 Microsoft Cost Management」を参照してください。
推奨事項
| 勧告 | メリット |
|---|---|
| Application Gateway インスタンスが使用されていない場合は停止します。 詳細については、「 Stop-AzApplicationGateway 」および 「Start-AzApplicationGateway」を参照してください。 | 停止した Application Gateway インスタンスでは、コストは発生しません。 継続的に実行される Application Gateway インスタンスでは、不要なコストが発生する可能性があります。 使用パターンを評価し、不要な場合はインスタンスを停止します。 たとえば、開発/テスト環境では営業時間後の使用率が低いことが予想されます。 |
| 次のような主要なコスト ドライバー Application Gateway メトリックを監視します。 - 推定課金対象容量ユニット。 - 固定請求可能容量ユニット。 - 現在の容量ユニット。 帯域幅のコストを考慮してください。 |
これらのメトリックを使用して、プロビジョニングされたインスタンス数が受信トラフィックの量と一致するかどうかを検証し、割り当てられたリソースを完全に利用していることを確認します。 |
オペレーショナル エクセレンス
オペレーショナル エクセレンスは主に、開発プラクティス、可観測性、リリース管理の手順に重点を置いています。
オペレーショナル エクセレンス設計原則、ワークロードの運用要件に対してこれらの目標を達成するための高度な設計戦略を提供します。
設計チェックリスト
Application Gateway に関連する監視、テスト、デプロイのプロセスを定義するための オペレーショナル エクセレンスの設計レビュー チェックリスト に基づいて、設計戦略を開始します。
Application Gateway と WAF で診断を有効にします。 ログとメトリックを収集して、ワークロードの正常性を監視し、ワークロードのパフォーマンスと信頼性の傾向を特定し、問題のトラブルシューティングを行うことができます。 全体的な監視アプローチを設計するには、 監視システムの設計と作成に関する推奨事項を参照してください。
容量メトリックを使用して、プロビジョニングされた Application Gateway 容量の使用を監視します。 メトリックにアラートを設定して、Application Gateway またはバックエンドで容量の問題やその他の問題を通知します。 診断ログを使用して、Application Gateway インスタンスに関する問題を管理およびトラブルシューティングします。
Azure Monitor Network Insights を使用して、Application Gateway を含むネットワーク リソースの正常性とメトリックの包括的なビューを取得します。 集中型の監視を使用して、問題をすばやく特定して解決し、パフォーマンスを最適化し、アプリケーションの信頼性を確保します。
Azure Advisor で Application Gateway の推奨事項を監視します。 Application Gateway インスタンスの新しい重要な推奨事項がある場合にチームに通知するようにアラートを構成します。 Advisor は、カテゴリ、影響レベル、推奨事項の種類などのプロパティに基づいて推奨事項を生成します。
推奨事項
| 勧告 | メリット |
|---|---|
| CPU 使用率やコンピューティング ユニットの使用量などの容量メトリックが推奨しきい値を超えたときにチームに通知するようにアラートを構成します。 容量メトリックに基づいて包括的な一連のアラートを構成するには、 Application Gateway の高トラフィックのサポートに関する説明を参照してください。 |
メトリックがしきい値を超えたときにアラートを設定して、使用状況がいつ増加するかを把握します。 この方法により、ワークロードに必要な変更を実装するのに十分な時間を確保し、低下や停止を防ぐことができます。 |
| Application Gateway またはバックエンドで問題を示すメトリックについてチームに通知するようにアラートを構成します。 次のアラートを評価することをお勧めします。 - 異常なホスト数 - 4xx エラーや 5xx エラーなどの応答状態 - 4xx エラーや 5xx エラーなどのバックエンド応答の状態 - バックエンドの最後のバイト応答時間 - Application Gateway の合計時間 詳細については、「 Application Gateway のメトリック」を参照してください。 |
アラートを使用すると、チームが問題にタイムリーに対応し、トラブルシューティングを容易にすることができます。 |
| Application Gateway と WAF で 診断ログ を有効にして、ファイアウォール ログ、パフォーマンス ログ、アクセス ログを収集します。 | ログを使用して、Application Gateway インスタンスとワークロードに関する問題の検出、調査、トラブルシューティングを行います。 |
| Advisor を使用して 、Key Vault の構成の問題を監視します。 アラートを設定して、 Application Gateway の Azure Key Vault の問題の解決に関する推奨事項を受け取ったときにチームに通知します。 | Advisor アラートを使用して最新の状態を維持し、問題を直ちに修正します。 コントロール プレーンまたはデータ プレーンに関連する問題を回避します。 Application Gateway は、リンクされた Key Vault インスタンス内の更新された証明書のバージョンを 4 時間ごとに確認します。 Key Vault の構成が正しくないために証明書のバージョンにアクセスできない場合は、そのエラーをログに記録し、対応する Advisor の推奨事項をプッシュします。 |
パフォーマンス効率
パフォーマンス効率とは、容量の管理により、負荷が増加してもユーザー エクスペリエンスを維持することです。 この戦略には、リソースのスケーリング、潜在的なボトルネックの特定と最適化、ピーク パフォーマンスの最適化が含まれます。
パフォーマンス効率設計の原則、予想される使用に対してこれらの容量目標を達成するための高度な設計戦略を提供します。
設計チェックリスト
ワークロード要件をサポートするために、Application Gateway の容量要件を見積もります。 Application Gateway v2 の自動スケール機能を利用します。 インスタンスの最小数と最大数に適切な値を設定します。 Application Gateway に必要な専用サブネットのサイズを適切に設定します。 詳細については、「容量計画の推奨事項」を参照してください。
Application Gateway v2 は、CPU、ネットワーク スループット、現在の接続など、さまざまな側面に基づいてスケールアウトします。 おおよそのインスタンス数を確認するには、次のメトリックを考慮します。
現在のコンピューティング ユニット: このメトリックは、CPU 使用率を示します。 1 つの Application Gateway インスタンスは、約 10 個のコンピューティング ユニットに相当します。
スループット： Application Gateway インスタンスは、約 500 Mbps のスループットを提供できます。 このデータは、ペイロードの種類によって異なります。
インスタンス数を計算するときは、この式を考慮してください。
インスタンス数を見積もった後、その値を最大インスタンス数と比較します。 この比較を使用して、使用可能な最大容量にどの程度近いかを判断します。
自動スケールとパフォーマンスの利点を得るための機能を利用します。 v2 SKU には自動スケールが用意されており、トラフィックの増加に合わせて Application Gateway がスケールアップされます。 v1 SKU と比較して、v2 SKU にはワークロードのパフォーマンスを向上させる機能があります。 たとえば、v2 SKU では、TLS オフロードのパフォーマンスが向上し、デプロイと更新の時間が短縮され、ゾーン冗長がサポートされます。 詳細については、Application Gateway v2 と WAF v2 のスケーリングに関するページを参照してください。
Application Gateway v1 を使用する場合は、Application Gateway v2 への移行を検討してください。 詳細については、「 Application Gateway と WAF を v1 から v2 に移行する」を参照してください。
推奨事項
| 勧告 | メリット |
|---|---|
| 推定インスタンス数、実際の Application Gateway の自動スケーリングの傾向、およびアプリケーション パターンに基づいて、最小インスタンス数を 最適なレベル に設定します。 過去 1 か月間の現在のコンピューティング ユニットを確認します。 このメトリックは、ゲートウェイの CPU 使用率を表します。 最小インスタンス数を定義するには、ピーク使用率を 10 で除算します。 たとえば、過去 1 か月間の現在のコンピューティング ユニットの平均が 50 の場合は、最小インスタンス数を 5 に設定します。 |
Application Gateway v2 の場合、インスタンスの追加セットがトラフィックを処理する準備ができるまで、自動スケールには約 3 分から 5 分かかります。 その間に、Application Gateway のトラフィックのスパイクが短い場合は、一時的な待機時間またはトラフィックの損失が予想されます。 |
|
自動スケールインスタンスの最大数を可能な限り最大 (125 インスタンス) に設定します。 Application Gateway 専用サブネットに、インスタンスの増加セットをサポートするのに十分な使用可能な IP アドレスがあることを確認します。 トラフィック要件に 125 を超えるインスタンスが必要な場合は、Application Gateway の前で Azure Traffic Manager または Azure Front Door を使用できます。 詳細については、「 Private Link を使用して Azure Application Gateway に Azure Front Door Premium を接続する 」および「 Azure Traffic Manager で Azure App Gateway を使用する」を参照してください。 |
Application Gateway は、必要に応じてスケールアウトして、アプリケーションへのトラフィックの増加を処理できます。 この設定では、消費された容量に対してのみ料金が発生するため、コストは増加しません。 |
| Application Gateway 専用サブネットのサイズを適切に設定します。 Application Gateway v2 のデプロイには、/24 サブネットを強くお勧めします。 同じサブネットに他の Application Gateway リソースをデプロイする場合は、インスタンスの最大数に必要な追加の IP アドレスを検討してください。 サブネットのサイズ設定に関する考慮事項の詳細については、 Application Gateway インフラストラクチャの構成に関するページを参照してください。 |
/24 サブネットを使用して、Application Gateway v2 デプロイで必要なすべての IP アドレスをサポートします。 プライベート フロントエンド IP を構成する場合、Application Gateway はインスタンスごとに 1 つのプライベート IP アドレスを使用し、もう 1 つのプライベート IP アドレスを使用します。 Standard_v2またはWAF_v2 SKU では、最大 125 個のインスタンスをサポートできます。 Azure では、内部使用のために各サブネットに 5 つの IP アドレスが予約されます。 |
Azure ポリシー
Azure には、App Service とその依存関係に関連する広範な組み込みポリシー セットが用意されています。 一連の Azure ポリシーは、上記の推奨事項の一部を監査できます。 たとえば、次のことを確認できます。
Application Gateway の WAF を有効にする必要があります。 一般向けの Web アプリケーションの前に WAF をデプロイし、受信トラフィック用に別の検査レイヤーを追加します。 WAF は、Web アプリケーションに対して一元的な保護を提供します。 SQL インジェクション、クロスサイト スクリプティング、ローカルおよびリモートのファイル実行など、一般的な悪用や脆弱性を防ぐのに役立ちます。 また、カスタム ルールを使用して、国または地域、IP アドレス範囲、その他の HTTP または HTTPS パラメーターに基づいて Web アプリケーションへのアクセスを制限することもできます。
WAF では、Application Gateway に対して指定されたモードを使用する必要があります。 Application Gateway のすべての WAF ポリシーで 検出 モードまたは 防止 モードが使用されていることを確認します。
Azure DDoS Protection を有効にする必要があります。 パブリック IP を持つ Application Gateway を含むサブネットを持つすべての仮想ネットワークに対して DDoS Protection を有効にします。
包括的なガバナンスについては、 Azure Policy の組み込み定義 と、ネットワークに影響する可能性があるその他のポリシーを確認します。
Azure Advisor の推奨事項
Azure Advisor は、Azure デプロイを最適化するためのベスト プラクティスに従うのに役立つ、パーソナライズされたクラウド コンサルタントです。 Application Gateway の信頼性、セキュリティ、コスト効率、パフォーマンス、オペレーショナル エクセレンスの向上に役立つ推奨事項をいくつか次に示します。