**の新しいコンソールエクスペリエンスの紹介 AWS WAF**

更新されたエクスペリエンスを使用して、コンソールの任意の場所で AWS WAF 機能にアクセスできるようになりました。詳細については、[「コンソールの使用](https://docs.aws.amazon.com/waf/latest/developerguide/working-with-console.html)」を参照してください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Shield Advanced と Route 53 を使用したヘルスチェックを使用したヘルスベースの検出
<a name="ddos-advanced-health-checks"></a>

ヘルスベースの検出を使用するように Shield Advanced を設定することで、攻撃の検出と緩和策の応答性と精度を改善できます。このオプションは、Route 53 ホストゾーンを除くすべてのリソースタイプで使用できます。

ヘルスベースの検出を設定するには、Route 53 でリソースのヘルスチェックを定義し、正常であると報告されていることを検証してから、Shield Advanced 保護と関連付けます。Route 53 ヘルスチェックの詳細については、「Amazon Route 53 デベロッパーガイド」の「[Amazon Route 53 がリソースのヘルスをチェックする方法](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/welcome-health-checks.html)」および「[ヘルスチェックの作成、更新、削除](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html)」を参照してください。

**注記**  
Shield Response Team (SRT) のプロアクティブなエンゲージメントサポートには、ヘルスチェックが必要です。プロアクティブなエンゲージメントの詳細については、「[SRT が直接連絡するためのプロアクティブエンゲージメントの設定](ddos-srt-proactive-engagement.md)」を参照してください。

ヘルスチェックでは、定義した要件に基づいて、リソースのヘルスを測定します。ヘルスチェックのステータスは、Shield Advanced 検出メカニズムに重要な入力を提供します。これにより、特定のアプリケーションの現在の状態に対する感度が向上します。

Route 53 ホストゾーンを除くリソースタイプのために、ヘルスベースの検出を有効にできます。
+ **ネットワークおよびトランスポートレイヤー (レイヤー 3 /レイヤー 4) のリソース** – ヘルスベースの検出により、ネットワークレイヤーおよびトランスポートレイヤーのイベント検出の精度と、Network Load Balancer、Elastic IP アドレス、および Global Accelerator 標準アクセラレーターのための緩和が改善されます。Shield Advanced を使用してこれらのリソースタイプを保護する場合、Shield Advanced は、トラフィックがアプリケーションの容量内である場合でも、小規模な攻撃の緩和と、攻撃のより迅速な緩和を行うことができます。

  ヘルスベースの検出を追加する場合、関連付けられたヘルスチェックが異常な期間中に、Shield Advanced を使用してより迅速に、低いしきい値で緩和策を行えます。
+ **アプリケーションレイヤー (レイヤー 7) リソース** - ヘルスベースの検出により、CloudFront ディストリビューションおよび Application Load Balancer のウェブリクエストのフラッド検出の精度が向上します。Shield Advanced を使用してこれらのリソースタイプを保護する場合、リクエストの特性に基づいて、トラフィックパターンの大幅な変化を伴うトラフィック量の統計的に有意な偏差がある場合に、ウェブリクエストのフラッド検出アラートが送信されます。

  ヘルスベースの検出では、関連付けられた Route 53 ヘルスチェックが異常な期間中に、Shield Advanced は、アラートするためにより小さな偏差を必要とし、より迅速にイベントを報告します。逆に、関連付けられた Route 53 ヘルスチェックが正常である場合、Shield Advanced では、アラートするためにより大きな偏差が必要です。

アプリケーションが許容可能なパラメータ内で実行されている場合にのみヘルスチェックが正常であることを報告し、そうでないときにのみ異常であることを報告する場合に、Shield Advanced におけるヘルスチェックの使用から最も大きな恩恵を受けることができます。このセクションのガイダンスを使用して、Shield Advanced でヘルスチェックの関連付けを管理します。

**注記**  
Shield Advanced は、ヘルスチェックを自動的に管理しません。

Shield Advanced でヘルスチェックを使用するには、次が必要です。
+ ヘルスチェックは、Shield Advanced 保護に関連付けるときに、正常であると報告するものである必要があります。
+ ヘルスチェックは、保護されたリソースのヘルスに関連している必要があります。お客様は、アプリケーションの特定の要件に基づいて、アプリケーションのヘルスを正確に報告するヘルスチェックを定義し、維持する責任があります。
+ ヘルスチェックは、Shield Advanced 保護で使用できるようにしておく必要があります。Shield Advanced 保護に使用している Route 53 のヘルスチェックを削除しないでください。

**Contents**
+ [Shield Advanced でヘルスチェックを使用するためのベストプラクティス](health-checks-best-practices.md)
+ [Shield Advanced によるヘルスチェックに一般的に使用される CloudWatch メトリクス](health-checks-metrics.md)
  + [アプリケーションのヘルスをモニタリングするために使用されるメトリクス](health-checks-metrics.md#health-checks-metrics-common)
  + [各リソースタイプの Amazon CloudWatch メトリクス](health-checks-metrics.md#health-checks-protected-resource-metrics)
+ [Shield Advanced で保護されたリソースにヘルスチェックを関連付ける](associate-health-check.md)
+ [Shield Advanced で保護されたリソースとヘルスチェックの関連解除する](disassociate-health-check.md)
+ [Shield Advanced でのヘルスチェックの関連ステータスの表示](health-check-association-status.md)
+ [Shield Advanced のヘルスチェックの例](health-checks-examples.md)
  + [Amazon CloudFront ディストリビューション](health-checks-examples.md#health-checks-example-cloudfront)
  + [ロードバランサー](health-checks-examples.md#health-checks-example-load-balancer)
  + [Amazon EC2 Elastic IP アドレス (EIP)](health-checks-examples.md#health-checks-example-elastic-ip)

# Shield Advanced でヘルスチェックを使用するためのベストプラクティス
<a name="health-checks-best-practices"></a>

Shield Advanced でヘルスチェックを作成して使用する場合は、このセクションのベストプラクティスに従います。
+ モニタリングするインフラストラクチャのコンポーネントを特定して、ヘルスチェックを計画します。ヘルスチェックでは、次のリソースタイプを検討してください。
  + 重要なリソース。
  + Shield Advanced の検出と緩和で高感度が必要なリソース。
  + Shield Advanced からプロアクティブに通知を受けたいリソース。プロアクティブなエンゲージメントは、ヘルスチェックのステータスによって通知されます。

  モニタリングする可能性のあるリソースの例には、Amazon CloudFront ディストリビューション、インターネット向けロードバランサー、Amazon EC2 インスタンスが含まれます。
+ 可能な限り少ない通知で、アプリケーションオリジンのヘルスを正確に反映するヘルスチェックを定義します。
  + アプリケーションが利用できない場合や許容可能なパラメータ内で動作しない場合のみ異常になるようにヘルスチェックを記述します。お客様は、アプリケーションの特定の要件に基づいてヘルスチェックを定義し、維持する責任があります。
  + アプリケーションのヘルスを引き続き正確に報告しながら、できる限り少ないヘルスチェックを使用します。例えば、すべてが同じ問題を報告するアプリケーションの複数の領域からの複数のアラームは、情報価値をもたらすことなく、レスポンスアクティビティにオーバーヘッドを追加する可能性があります。
  + 計算されたヘルスチェックを使用して、Amazon CloudWatch メトリクスの組み合わせを用いてアプリケーションのヘルスをモニタリングします。例えば、アプリケーションサーバーのレイテンシーと 5xx エラー率に基づいて、複合ヘルスを計算できます。これは、オリジンサーバーがリクエストを満たしていないことを示唆します。
  + 必要に応じて、独自のアプリケーションヘルスインジケーターを作成し、CloudWatch カスタムメトリクスに発行して、計算されたヘルスチェックで使用します。
+ ヘルスチェックを実装および管理して、検出を改善し、不要なメンテナンス作業を減らします。
  + ヘルスチェックを Shield Advanced 保護に関連付ける前に、ヘルスチェックが正常な状態であることを確認してください。異常を報告しているヘルスチェックを関連付けると、保護されたリソースに関する Shield Advanced 検出メカニズムが歪む可能性があります。
  + ヘルスチェックは Shield Advanced で使用できるようにしておきます。Shield Advanced 保護に使用している Route 53 のヘルスチェックを削除しないでください。
  + ステージング環境とテスト環境は、ヘルスチェックのテストにのみ使用します。本番稼働レベルのパフォーマンスと可用性を必要とする環境のヘルスチェックの関連付けのみを維持します。ステージングおよびテスト環境のために、Shield Advanced でヘルスチェックの関連付けを維持しないでください。

# Shield Advanced によるヘルスチェックに一般的に使用される CloudWatch メトリクス
<a name="health-checks-metrics"></a>

このセクションには、Distributed Denial of Service (DDoS) イベント中のアプリケーションのヘルスを測定するためのヘルスチェックで一般的に使用される Amazon CloudWatch メトリクスが記載されています。各リソースタイプの CloudWatch メトリクスに関する詳細については、表の後のリストを参照してください。

**Topics**
+ [アプリケーションのヘルスをモニタリングするために使用されるメトリクス](#health-checks-metrics-common)
+ [各リソースタイプの Amazon CloudWatch メトリクス](#health-checks-protected-resource-metrics)

## アプリケーションのヘルスをモニタリングするために使用されるメトリクス
<a name="health-checks-metrics-common"></a>


| リソース | メトリクス | 説明 | 
| --- | --- | --- | 
| Route 53 | `HealthCheckStatus` | ヘルスチェックエンドポイントのステータス。 | 
| CloudFront | `5xxErrorRate` | HTTP ステータスコードが 5xx であるすべてのリクエストの割合。これは、アプリケーションに影響を与えている攻撃を示しています。 | 
| Application Load Balancer | `HTTPCode_ELB_5XX_Count` | ロードバランサーによって生成された HTTP 5xx クライアントエラーコードの数。 | 
| Application Load Balancer | `RejectedConnectionCount` | ロードバランサーが接続の最大数に達したため、拒否された接続の数。 | 
| Application Load Balancer | `TargetConnectionErrorCount` | ロードバランサーとターゲット間で正常に確立されなかった接続数。 | 
| Application Load Balancer | `TargetResponseTime` |  リクエストがロードバランサーを離れてから、ターゲットからの応答を受信するまでの経過時間 (秒)。  | 
| Application Load Balancer | `UnHealthyHostCount` | 異常とみなされるターゲットの数。 | 
| Amazon EC2 | `CPUUtilization` | 割り当てられた EC2 コンピューティングユニットのうち、現在使用されているものの割合。 | 

## 各リソースタイプの Amazon CloudWatch メトリクス
<a name="health-checks-protected-resource-metrics"></a>

保護されたリソースのために使用できるメトリクスの詳細については、リソースガイドの次のセクションを参照してください。
+ Amazon Route 53 – 「Amazon Route 53 デベロッパーガイド」の「[Amazon Route 53 のヘルスチェックと Amazon CloudWatch を使用したリソースのモニタリング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html)」。
+ Amazon CloudFront – 「Amazon CloudFront デベロッパーガイド」の「[Amazon CloudWatch による CloudFront のモニタリング](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/monitoring-using-cloudwatch.html)」。
+ Application Load Balancer – 「Application Load Balancer のユーザーガイド」の「[Application Load Balancer の CloudWatch メトリクス](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)」。
+ Network Load Balancer – 「Network Load Balancer のユーザーガイド」の「[Network Load Balancer の CloudWatch メトリクス](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html)」。
+ AWS Global Accelerator – [デベロッパーガイドの「 での Amazon CloudWatch AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/cloudwatch-monitoring.html) の使用」。 AWS Global Accelerator 
+ Amazon Elastic Compute Cloud – https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ の「[インスタンスの利用可能な CloudWatch メトリクスのリスト表示](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html)」。
+ Amazon EC2 Auto Scaling – 「Amazon EC2 Auto Scaling ユーザーガイド」の「[Monitoring CloudWatch metrics for your Auto Scaling groups and instances](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)」(オートスケーリンググループおよびインスタンス用の CloudWatch メトリクスのモニタリング)。

# Shield Advanced で保護されたリソースにヘルスチェックを関連付ける
<a name="associate-health-check"></a>

次の手順は、Amazon Route 53 ヘルスチェックを保護されたリソースに関連付ける方法を示しています。

**注記**  
ヘルスチェックを Shield Advanced 保護に関連付ける前に、ヘルスチェックが正常な状態であることを確認してください。詳細については、「Amazon Route 53 デベロッパーガイド」の「[ヘルスチェックのステータスモニタリングと通知の受信](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-monitor-view-status.html)」を参照してください。

**ヘルスチェックを関連付けるには**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/) で AWS WAF & Shield コンソールを開きます。

1.  AWS Shield ナビゲーションペインで、**保護されたリソース**を選択します。

1. **[Protections]** (保護) タブで、ヘルスチェックに関連付けるリソースを選択します。

1. **[Configure protections]** (保護を設定) を選択します。

1. **[Configure health check based DDoS detection - *optional]*** (ヘルスチェックベースの DDoS 検出を設定 - オプション) ページが表示されるまで **[Next]** (次へ) を選択します。

1. **[Associated Health Check]** (ヘルスチェックを関連付ける) で、保護に関連付けるヘルスチェックの ID を選択します。
**注記**  
必要なヘルスチェックが表示されない場合は、Route 53 コンソールに移動して、ヘルスチェックとその ID を検証します。詳細については、「[ヘルスチェックの作成と更新](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html)」を参照してください。

1. 設定を完了するまで残りのページを順を追って確認します。**[Protections]** (保護) ページに、リソースについて、更新されたヘルスチェックの関連付けが一覧表示されます。

1. **[Protections]** (保護) ページで、新しく関連付けられたヘルスチェックが正常であるとレポートされていることを確認します。

   ヘルスチェックが異常を報告している間は、Shield Advanced でヘルスチェックの使用を正常に開始することはできません。そうすることで、Shield Advanced は非常に低いしきい値で誤検出を検出し、Shield Response Team (SRT) がリソースにプロアクティブなエンゲージメントを提供する能力にも悪影響を及ぼす可能性があります。

   新しく関連付けられたヘルスチェックで異常が報告されている場合は、次の手順を実行します。

   1. Shield Advanced で、ヘルスチェックと保護機能の関連付けを解除します。

   1. Amazon Route 53 のヘルスチェックの仕様を再確認し、アプリケーション全体のパフォーマンスと可用性を検証します。

   1. アプリケーションが良好なヘルスのためのパラメータ内で実行され、ヘルスチェックが正常であると報告している場合は、Shield Advanced でのヘルスチェックの関連付けをもう一度お試しください。

ヘルスチェックの関連付け手順は、新しいヘルスチェックの関連付けを確立し、Shield Advanced で正常であると報告されると完了します。

# Shield Advanced で保護されたリソースとヘルスチェックの関連解除する
<a name="disassociate-health-check"></a>

次の手順は、保護されたリソースから Amazon Route 53 ヘルスチェックの関連付けを解除する方法を示しています。

**ヘルスチェックの関連付けを解除するには**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/) で AWS WAF & Shield コンソールを開きます。

1.  AWS Shield ナビゲーションペインで、**保護されたリソース**を選択します。

1. **[Protections]** (保護) タブで、ヘルスチェックから関連付けを解除するリソースを選択します。

1. **[Configure protections]** (保護を設定) を選択します。

1. **[Configure health check based DDoS detection - *optional]*** (ヘルスチェックベースの DDoS 検出を設定 - オプション) ページが表示されるまで **[Next]** (次へ) を選択します。

1. **[Associated Health Check]** (関連付けられたヘルスチェック) で、**-** としてリストされている空のオプションを選択します。

1. 設定を完了するまで残りのページを順を追って確認します。

**[Protections]** (保護) ページでは、リソースのヘルスチェックフィールドが **-** に設定されます。これは、ヘルスチェックの関連付けがないことを示しています。

# Shield Advanced でのヘルスチェックの関連ステータスの表示
<a name="health-check-association-status"></a>

保護に関連付けられているヘルスチェックのステータスは、 AWS WAF & Shield コンソールの **[Protected resources]** (保護されたリソース) ページと各リソースの詳細ページで確認できます。
+ **[Healthy]** (正常) - ヘルスチェックが使用可能で、正常であると報告されています。
+ **[Unhealthy]** (異常) - ヘルスチェックが使用可能で、異常があると報告されています。
+ **[Unavailable]** (使用不可) - Shield Advanced によるヘルスチェックは使用できません。

****[Unavailable]** (使用不可) のヘルスチェックを解決するには**

新しいヘルスチェックを作成して使用します。Shield Advanced でステータスが使用不可になった後、ヘルスチェックを再度関連付けないでください。

これらのステップの実行に関する詳細なガイダンスについては、前のトピックを参照してください。

1. Shield Advanced で、リソースからヘルスチェックの関連付けを解除します。

1. Route 53 で、リソースの新しいヘルスチェックを作成し、その ID を記録します。詳細については、「Amazon Route 53 デベロッパーガイド」の「[ヘルスチェックの作成と更新](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html)」を参照してください。

1. Shield Advanced で、新しいヘルスチェックをリソースに関連付けます。

# Shield Advanced のヘルスチェックの例
<a name="health-checks-examples"></a>

このセクションは、計算されたヘルスチェックで使用できるヘルスチェックの例を示します。計算されたヘルスチェックでは、多数の個別のヘルスチェックを使用して、組み合わせたステータスを決定します。個々のヘルスチェックのステータスは、エンドポイントのヘルスまたは Amazon CloudWatch メトリクスの状態に基づきます。ヘルスチェックを計算されたヘルスチェックに組み込んでから、個々のヘルスチェックの組み合わせられたヘルスステータスに基づいてヘルスをレポートするように、計算されたヘルスチェックを設定します。アプリケーションのパフォーマンスと可用性の要件に応じて、計算されたヘルスチェックの感度をチューニングします。

計算されたヘルスチェックの詳細については、「Amazon Route 53 デベロッパーガイド」の「[他のヘルスチェック (算出したヘルスチェック) のモニタリング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-values.html#health-checks-creating-values-calculated)」を参照してください。詳細については、「[Route 53 Improvements – Calculated Health Checks and Latency Checks](https://aws.amazon.com/blogs/aws/route-53-improvements-calculated-health-checks-and-latency-checks/)」(Route 53 の改善 – 計算されたヘルスチェックとレイテンシーチェック) のブログ記事を参照してください。

**Topics**
+ [Amazon CloudFront ディストリビューション](#health-checks-example-cloudfront)
+ [ロードバランサー](#health-checks-example-load-balancer)
+ [Amazon EC2 Elastic IP アドレス (EIP)](#health-checks-example-elastic-ip)

## Amazon CloudFront ディストリビューション
<a name="health-checks-example-cloudfront"></a>

次の例では、CloudFront ディストリビューションの計算されたヘルスチェックと組み合わせることができるヘルスチェックについて説明します。
+ 動的コンテンツを提供するディストリビューション上のパスへのドメイン名を指定して、エンドポイントをモニタリングします。正常な応答には、HTTP レスポンスコード 2xx と 3xx が含まれます。
+ CloudFront オリジンのヘルスを測定する CloudWatch アラームの状態をモニタリングします。例えば、Application Load Balancer メトリクス `TargetResponseTime` で CloudWatch アラームを維持し、アラームのステータスを反映するヘルスチェックを作成できます。ヘルスチェックは、応答時間 (リクエストがロードバランサーから発信されてから、ロードバランサーがターゲットから応答を受け取るまでの時間) がアラームで設定されたしきい値を超えると、異常になることがあります。
+ レスポンスの HTTP ステータスコードが 5xx であるリクエストの割合を測定する CloudWatch アラームの状態をモニタリングします。CloudFront ディストリビューションの 5xx エラーレートが CloudWatch アラームで定義されたしきい値よりも高い場合、このヘルスチェックのステータスは異常に切り替わります。

## ロードバランサー
<a name="health-checks-example-load-balancer"></a>

次の例では、Application Load Balancer、Network Load Balancer、または Global Accelerator 標準アクセラレーターの計算されたヘルスチェックで使用できるヘルスチェックについて説明します。
+ クライアントがロードバランサーに対して確立した新しい接続の数を測定する CloudWatch アラームの状態をモニタリングします。新しい接続の平均数に関するアラームのしきい値は、毎日の平均よりある程度高い値に設定できます。各リソースタイプのメトリクスは次のとおりです。
  + Application Load Balancer: `NewConnectionCount`
  + Network Load Balancer: `ActiveFlowCount`
  + Global Accelerator: `NewFlowCount`
+ Application Load Balancer および Network Load Balancer では、正常とみなされるロードバランサーの数を測定する CloudWatch アラームの状態をモニタリングします。アラームのしきい値は、アベイラビリティーゾーン、またはロードバランサーが必要とする最小数の正常なホストで設定できます。ロードバランサーのリソースで使用可能なメトリクスは次のとおりです。
  + Application Load Balancer: `HealthyHostCount`
  + Network Load Balancer: `HealthyHostCount`
+ Application Load Balancer では、ロードバランサーのターゲットによって生成された HTTP 5xx レスポンスコードの数を測定する CloudWatch アラームの状態をモニタリングします。Application Load Balancer の場合、メトリクス `HTTPCode_Target_5XX_Count` を使用して、ロードバランサーのすべての 5xx エラーの合計に基づいてアラームしきい値を設定できます。

## Amazon EC2 Elastic IP アドレス (EIP)
<a name="health-checks-example-elastic-ip"></a>

次のヘルスチェックの例を、Amazon EC2 Elastic IP アドレスの計算されたヘルスチェックに組み合わせることができます。
+ Elastic IP アドレスへの IP アドレスを指定して、エンドポイントをモニタリングします。IP アドレスの背後にあるリソースと TCP 接続を確立できる限り、ヘルスチェックは正常なままです。
+ 割り当てられた Amazon EC2 コンピューティングユニットのうち、現在インスタンス上で使用されているものが占める割合を測定する CloudWatch アラームの状態をモニタリングします。Amazon EC2 メトリクス `CPUUtilization` を使用して、高いと考えるアプリケーションの CPU 使用率 (90% など) に基づいてアラームしきい値を設定できます。