AWS WAFのログ出力先をS3バケットにした場合、リージョン集約が可能です
はじめに
AWS WAFのログ出力先として、以下の3つの選択肢があります。それぞれのメリット、デメリット、およびユースケースは以下の通りです。
- Amazon CloudWatch Logs
- 主なユースケース
- リアルタイムでのログ監視やアラート設定が必要な場合
- 短期間のログデータの保存と分析が主な目的の場合
- ログの中身を迅速に確認したい場合
- 考慮点
- コスト: 大量のログデータを長期間保存すると、S3バケットに比べてコストがかさみます。
- 主なユースケース
- Amazon S3
- 主なユースケース
- データアーカイブ用など、長期間のログデータ保存が必要な場合
- コストを抑えたい場合
- データレイクとして利用したい場合
- 考慮点
- 分析の手間: ログデータを分析するためには、Amazon Athenaなどの別サービスが必要です。
- リアルタイム性の欠如: リアルタイムでのログ監視やアラート設定には向いていません。
- WAFのログは、5分間隔でS3バケットに保存されます。
- 主なユースケース
- Amazon Data Firehose
- 主なユースケース
- リアルタイムでのデータ変換が必要な場合
- 複数の出力先にデータを送信したい場合
- CloudWatch LogsやS3バケットではなく、Amazon RedshiftやAmazon OpenSearch Serviceなど別サービスにログを保存したい場合
- 考慮点
- 保存先の指定: Data Firehoseはストレージサービスではないため、保存先を指定する必要があります。
- コスト: データストリーミングのコストがかかります。
- 主なユースケース
ログ出力先を選択する際には、構築するアプリケーションの特性、コスト、分析性、リアルタイム性などを考慮する必要があります。
本記事では、「リージョン集約が可能で最小限のリソースで済む」という観点から、S3バケットを選択するメリットについて紹介します。
CloudWatch LogsとData Firehoseの場合、作成したWAFと同じリージョンを指定する必要があります。
一方、S3バケットの場合、作成したWAFとは異なるリージョンを指定できます。
そのため、S3バケットのみが複数のリージョンに作成されたWAFのログを集約することが可能です。
具体的な構成例を示して解説します。
構成例
以下の構成では、CloudFrontとALBにそれぞれWAFを適用しています。ALBに適用するWAFは、ALBと同じリージョンである東京リージョンに作成し、CloudFrontに適用するWAFは、グローバルとして作成します。
CloudFrontに適用するWAFのログ出力先は、CloudWatch LogsもしくはData Firehoseの場合、バージニアリージョンを指定する必要があります。
ログ出力先がCloudWatch Logs or Data Firehose
ログ出力先がCloudWatch LogsもしくはData Firehoseの場合、今回の構成ではバージニアリージョンと東京リージョンにそれぞれリソースを作成する必要があります。
ちなみに、CloudFormationでCloudFrontに適用するWAFを作成する際には、バージニアリージョンでスタックを作成する必要があります。
For CLOUDFRONT, you must create your WAFv2 resources in the US East (N. Virginia) Region, us-east-1.
ログ出力先がS3
ログ出力先がS3バケットの場合、バージニアリージョンと東京リージョンのWAFはどちらも東京リージョンのS3バケットにログを出力できます。
ログ出力先が東京リージョンのS3バケット1つでよく、他の選択肢に比べ最小限の工数で構築できます。また、ログを1つのバケットで一元管理することで、管理の煩雑さを軽減できます。
ログ出力先がData Firehose
ログを出力先をData Firehoseに指定し、Data Firehoseの送信先を東京リージョンのS3バケットにして集約することは可能です。このケースは、Data Firehoseでデータ処理し、S3バケットに集約したい場合が考えられます。
最後に
AWS WAFのログ出力先には3つの候補がありますが、どれを選ぶか迷われている場合、S3バケットを選択することでリージョン集約が可能であるという点も参考にしていただければと思います。
これにより、複数リージョンにまたがるログ管理が容易になります。