DDoS 攻撃の最中に「いま実際にどんなトラフィックが押し寄せているのか」を把握できれば、インシデント対応の判断は大きく変わります。AWS Shield Advanced に追加された攻撃フローログは、攻撃中のトラフィックメタデータを 5 分間隔でキャプチャし、送信元の特定や緩和策の検証、既存の分析パイプラインへの投入を可能にする機能です。本記事では従来課題との違い、取得できるフィールド、AWS CLI による有効化手順、配信先の使い分け、攻撃中の活用シナリオを解説します。
攻撃フローログとは何か従来の可視化課題からの進化
AWS Shield Advanced は、DDoS（分散型サービス妨害）攻撃からアプリケーションを保護するマネージドサービスです。今回追加された攻撃フローログは、保護対象に向けられた攻撃トラフィックのメタデータ（送信元や宛先のアドレスとポート、パケット数やバイト数、緩和アクションなど）を記録し、攻撃の様子をリアルタイムに可視化します。
これまで DDoS 攻撃のトラフィックを再構成するには、攻撃が収束した後に複数のデータソースを突き合わせる必要があり、全体像が見えるのは事後でした。攻撃フローログはこれを変え、進行中からメタデータを取得できるようにします。送信元の特定、緩和策の検証、取得データの既存分析基盤への投入を、攻撃のさなかに進められます。
この機能は一般提供（GA）です。What's New での発表は 2026 年 5 月 29 日、解説ブログの公開は 2026 年 6 月 4 日です。注意したいのが提供範囲で、提供開始時点では Elastic IP（EIP）保護に対するインフラストラクチャレイヤー（L3/L4）の攻撃フローログが対象です。その他のリソースタイプへの対応は順次拡大予定とされており、現時点ですべてのリソースに対応しているわけではありません。
基本仕様として、ログは 5 分間隔で書き込まれ、攻撃の進行中および終了後に利用できます。1 ファイルの最大サイズは 75 MB で、ウィンドウ内に上限へ達するとファイルがクローズ・配信され、新しいファイルが開始されます。
攻撃フローログで取得できるメタデータフィールド
攻撃フローログでは、1 レコードあたり 17 個のメタデータフィールドを取得できます。送信元と宛先、トラフィック量、緩和アクション、地理情報といった観点で整理すると理解しやすくなります。
フィールド名 | 説明 |
|---|---|
protection_arn | Shield 保護の Amazon Resource Name（ARN） |
event_timestamp | ログ生成のタイムスタンプ |
version | フローログのバージョン番号 |
srcaddr | 送信元 IP アドレス |
dstaddr | 宛先 IP アドレス |
srcport | 送信元ポート |
dstport | 宛先ポート |
protocol | IP プロトコル番号 |
packets | ウィンドウ内のパケット数 |
bytes | ウィンドウ内のバイト数 |
starttime | 集計ウィンドウの開始時刻 |
endtime | 集計ウィンドウの終了時刻 |
action | Shield が取った緩和アクション |
location | AWS のイングレスロケーション |
sampling_rate | 処理時のサンプリングレート |
tcp_flags | パケットの TCP フラグ |
srccountry | 送信元の 2 文字の国コード |
action は Shield が取った緩和アクションを表し、緩和が機能しているかの手がかりになります。location と srccountry（送信元の 2 文字の国コード）を合わせると、攻撃がどの地域から来ているかを把握できます。出力フォーマットは JSON、plain text、W3C、Parquet の 4 種類をサポートし、長期保管してクエリする用途では列指向の Parquet を選べます。
なお、ここで取得できるフィールドは AWS WAF の web ACL トラフィックログのフィールド（clientIp や country など）とは別物です。名前が似ていても内容や粒度が異なるため、取り違えに注意してください。
CLIでフローログを有効化し配信先を設定する
攻撃フローログの配信には、CloudWatch Logs の vended logs（ベンドログ）配信基盤を利用します。これは各種サービスがログを S3 や CloudWatch Logs、Data Firehose へ配信する共通の仕組みで、配信ソース、配信先、その両者を結ぶ配信（delivery）の 3 要素を登録して使います。AWS 公式の解説は AWS CLI による手順を中心に示しているため、本記事でも AWS CLI による手順を中心に解説します。マネジメントコンソールの具体的な画面遷移は公式情報で未確認のため触れません。
配信先リソースとポリシーを用意する
まずログの配信先となるリソースを用意します。長期保管や Athena でのクエリには Amazon S3 バケット、リアルタイム監視には CloudWatch Logs ロググループ、外部 SIEM へのストリーミングには Amazon Data Firehose ストリームを選びます。次に配信サービスが書き込めるようリソースポリシーを設定します。S3 は s3:GetBucketPolicy と s3:PutBucketPolicy の権限があればポリシーを自動作成できます。
保護ARNを取得して配信を登録する
重要なのは、配信ソースに指定するのが保護対象リソースそのものの ARN ではなく、Shield Advanced の保護（protection）ARN である点です。Shield Advanced はリソースをラップする保護オブジェクトを作成し、フローログはその保護レイヤーから生成されるためです。保護 ARN は次のコマンドで取得します。Shield Advanced はグローバルサービスのため、管理操作は us-east-1 を使用します。
aws shield list-protections --region us-east-1取得した保護 ARN を配信ソースとして登録します。log-type には FLOW_LOGS を指定します。
aws logs put-delivery-source \
--name my-shield-delivery-source \
--resource-arn <protection-arn> \
--log-type FLOW_LOGS \
--region us-east-1続いて配信先を作成します。output-format に出力フォーマット、destinationResourceArn に配信先リソースの ARN を指定します。
aws logs put-delivery-destination \
--name my-shield-delivery-destination \
--output-format plain \
--delivery-destination-configuration '{"destinationResourceArn":"<resource-arn>"}' \
--region us-east-1最後に、配信ソースと配信先を接続する配信（delivery）を作成します。
aws logs create-delivery \
--delivery-source-name my-shield-delivery-source \
--delivery-destination-arn <delivery-destination-arn> \
--region us-east-1設定が完了したら、配信の状態を確認しておきましょう。提供範囲は Shield Advanced が利用可能なすべてのリージョンですが、管理操作は us-east-1 を使う点に留意します。
aws logs describe-deliveries --region us-east-1
S3 CloudWatch Logs Data Firehoseの配信先を使い分ける
配信先は Amazon S3、Amazon CloudWatch Logs、Amazon Data Firehose の 3 つから選べます。それぞれ得意な用途が異なるため、目的に合わせて選ぶか併用します。
配信先 | 適した用途 |
|---|---|
Amazon S3 | 長期保管、コンプライアンス対応、Athena でのバッチ分析 |
Amazon CloudWatch Logs | リアルタイム監視、Logs Insights での対話的分析、アラーム連携 |
Amazon Data Firehose | 外部 SIEM やサードパーティ分析基盤へのストリーミング配信 |
S3 は大量のログを安価に蓄積でき、Athena の SQL 分析と組み合わせやすいため、監査証跡の保管に向きます。CloudWatch Logs はログをそのまま監視・検索でき、アラーム連携による即時の気づきが強みです。Data Firehose はデータを継続的に外部へ流し込めるため、既存の SIEM や分析基盤への取り込みに適します。
料金は、フローログに標準の CloudWatch Logs vended log 料金が発生し、加えて配信先リソースの料金（S3 やロググループのストレージ、Data Firehose のデータ処理）がかかります。具体的な金額や単価は変動しうるため本記事では断定しません。実際の見積もりは AWS の公式料金ページで確認してください。
Athena CloudWatch Logs Insights SIEMへ統合する
攻撃フローログは標準的な配信基盤を通じて出力されるため、既存の監視・分析ツールへ素直に統合できます。
- Amazon Athena — S3 上のフローログに対しサーバーレスで SQL クエリを実行でき、フォレンジック分析を必要なときだけ行えます。
- CloudWatch Logs Insights — ログを追加インフラなしで対話的に分析でき、攻撃中に絞り込みクエリを試しながら状況を把握できます。
- CloudWatch アラーム — 攻撃パターンやしきい値を監視し、条件超過時にアラートを発報します。
- サードパーティ SIEM — Data Firehose 経由でストリーミング配信し、既存の SIEM 製品へログを取り込めます。
- クロスアカウント／クロスリージョン集約 — 標準の配信基盤を通じて複数アカウントやリージョンのログ集約にも対応します。
組織の既存フローへ組み込むことで、平時の監視から有事のフォレンジックまで一貫した運用が実現します。リアルタイム性、長期分析や監査、既存ツールとの親和性のいずれを重視するかで選ぶとよいでしょう。
DDoS攻撃中のリアルタイム活用シナリオ
最後に、攻撃が進行している最中に攻撃フローログをどう生かせるかを 3 つのシナリオで見ていきます。ログは 5 分間隔で攻撃中も利用できるため、これらの分析を攻撃のさなかに繰り返し行えます。
トラフィックパターンを再構成する
packets や bytes、protocol を集計すると、トラフィック量、送信元の分布、プロトコルの構成比が見えてきます。UDP が大半なのか、TCP のどのポートに集中しているのかが分かれば、攻撃の種類を推定し対応の優先順位を決められます。攻撃の形の時間変化も、5 分ごとの更新で追跡できます。
攻撃の送信元を特定する
srccountry（送信元の国コード）と location（AWS のイングレスロケーション）を組み合わせると、攻撃がどの地域から、どの経路で入ってきているかを把握でき、影響範囲の見極めがしやすくなります。
緩和動作を検証する
action フィールドを見れば、Shield が実際にどの緩和アクションを取ったかを確認できます。緩和が想定どおり適用されているかをログ上で裏付けられるため、対応の妥当性をその場で評価し、必要なら追加対策へ移れます。
このように AWS Shield Advanced の攻撃フローログは、事後分析に頼っていた DDoS 攻撃の可視化を、攻撃中のリアルタイムなメタデータ取得へと進化させます。提供開始時点では EIP 保護のインフラストラクチャレイヤー（L3/L4）攻撃が対象で、その他のリソースは順次拡大予定という段階です。まずは保護対象を確認し、自組織に合った配信先で有効化してみてください。攻撃中に「いま何が起きているか」を見える化できることが、確かなインシデント対応への第一歩になります。
