[レポート] AWS WAF管理者の一日を追体験できるセッションに参加しました #AWSreInvent #NET317

はじめに

皆様こんにちは、あかいけです。

AWS re:Invent 2025に参加しており、
「A day in the life of an AWS WAF administrator」というセッションを聞いてきました。

AWS WAFを運用されている方であれば、朝のアラート対応から夕方のコストレポートまで、日々様々な課題に直面されているのではないでしょうか。
このセッションでは、架空の(しかし非常にリアルな)WAF管理者の一日を追いながら、実践的なTipsと運用のベストプラクティスを学ぶことができたので、その内容をまとめてみました。

セッション概要

タイトル:
A day in the life of an AWS WAF administrator [SIMULCAST] (NET317-SC2)

概要:

From sunrise alerts to sunset cost reports, the AWS WAF administrator's day is never dull. Join us as we follow a fictional (but all-too-relatable) admin navigating setup, fine-tuning rules, building dashboards, and taming budgets - while outsmarting emerging threats before they bite. You'll see how to adapt quickly to shifting traffic, uncover hidden risks, and make data-driven decisions without breaking the bank - or the application. Packed with tips, real-world examples, and a dash of bot traffic, this session turns the daily grind of web application protection into a well-architected adventure.

日の出アラートから日没コストレポートまで、AWS WAF管理者の1日は決して退屈することはありません。架空の（しかし、共感できる）管理者が、設定、ルールの微調整、ダッシュボードの構築、予算管理を行いながら、新たな脅威に先手を打つ様子を追っていきます。変化するトラフィックに迅速に対応し、隠れたリスクを発見し、コストやアプリケーションに負担をかけずにデータに基づいた意思決定を行う方法を学びます。ヒント、実例、そしてボットトラフィックを交えたこのセッションは、日々のWebアプリケーション保護の煩雑さを、洗練された冒険へと変貌させます。

スピーカー:

• Tzoori Tamam氏 (Principal Solutions Architect Specialist, AWS)
• Dan Avidan氏 (Platform Team Lead, HSBC)

セッション情報:

• レベル: 300 - Advanced
• セッションタイプ: Breakout Session
• トピック: Networking & Content Delivery

セッションの内容

このセッションは大きく2部構成でした。
前半はAWSのTzoori Tamam氏によるAWS WAF運用のベストプラクティス、後半はHSBCのDan Avidan氏による実際の大規模運用事例の紹介でした。

架空のシナリオ: ロボット売買アプリの立ち上げ

セッションでは、ロボットを売買するWebサイトとモバイルアプリを新規ローンチするという架空のシナリオが設定されました。
ちなみにAIの専門知識は不要とのことです(笑)。

フロントエンドアーキテクチャ

典型的なフロントエンドアーキテクチャが例として紹介されました。

• クライアント(Web/モバイルユーザーおよび自動化クライアント)からのトラフィック
• Amazon CloudFrontを経由
• ALB経由でEC2インスタンス(Auto Scaling Group)へ
• API Gateway経由でLambdaへ
• S3での静的アセット配信

AWS WAFデプロイの検討事項

AWS WAFをデプロイする際に考慮すべき4つの観点が示されました。

CloudFrontへのAWS WAF配置

AWS WAFはCloudFrontに紐付けて配置するのが推奨されています。
CloudWatch MetricsとLogsでモニタリングを行います。

Origin Cloaking(オリジンの隠蔽)

AWS WAFをバイパスされないようにするための重要な設定が紹介されました。
CloudFrontのみがアプリケーションリソースにアクセスできるようにします。

VPC Origins

• CloudFrontから内部ロードバランサーへ直接トラフィックを送信
• VPC Originsが使えない場合は、マネージドCloudFrontプレフィックスリストを使用

S3バケット(Lambda, MediaStore, MediaPackage含む)

• Origin Access Control(OAC)を使用してバケットをロックダウン
• IAM認証のみを許可

その他のオリジン

• マネージドプレフィックスリストとエッジで挿入されるシークレットヘッダーを使用
• 非AWSオリジンの場合は、パブリックプレフィックスリストJSONファイルとシークレットヘッダーを使用

CloudFrontの定額料金プラン

CloudFrontには複数の定額料金プランがあり、WAFの保護機能も含まれています。

これは2025/11/18でローンチされた比較的最近の機能ですね。

https://aws.amazon.com/jp/about-aws/whats-new/2025/11/aws-flat-rate-pricing-plans/

AWS WAFの保護パック作成

AWS WAFでは、アプリのカテゴリとフォーカス(API/Web/両方)を選択することで、最適な保護パックを作成できます。

初期保護の選択

3つの保護オプションが提供されています。

1. Recommended rules for you - 推奨ルール(月額$57-$58/1000万リクエスト)
2. Essential rules - 必須ルール(月額$42-$43/1000万リクエスト)
3. You build it - カスタム構築(月額$11/1000万リクエスト)

The Essentials(必須設定)

最初に設定すべき必須項目が紹介されました。

• Rate-limitsルールの適切な基準値を設定
• コアセキュリティ機能の有効化
  • SQL Injection、Cross Site Scripting
  • HTTPコンプライアンス
  • 既知の脆弱性(Log4Shellなど)
• Geo/IPベースのリストを設定
• L7 DDoS保護を有効化(Countモードで)

Essential rulesには以下が含まれます。

• Layer 7 anti-DDoS (Count)
• IP allowlist (Allow)
• IP blocklist (Block)
• Geographic restriction (Block)
• Global rate limit (Count)
• Body size restriction rule (Count)
• AWS core rule set (Default)
• SQL injection protection (Default)
• Admin protection rule (Default)

ダッシュボードの活用

トラフィックが流れ始めたら、AWS WAFの組み込みダッシュボードでモニタリングを開始します。
トラフィック特性、リクエスト元の地域、ルール特性、Bot情報などを確認できます。

Log Explorer

Log Explorerでは、ブロックされたリクエストの詳細を確認できます。
タイムスタンプ、アクション、ホスト、パス、メソッド、IPアドレス、国、Bot、User-Agent、Rate limitedなどの情報が表示されます。

誤検知(False Positive)のチューニング

実運用では、マーケティングチームから「顧客から403エラーの苦情が来ている」と報告を受けることがあります。

状況

• ダッシュボードでCrossSiteScripting違反が多数表示
• 複数の異なるIPがこのルールでフラグされている
• ログを見ると、これらのIPは他に問題のある動作をしていない
• セキュリティポリシーを破らずに修正が必要

対処法

1. ログでパターンを見つける - 特定のURI、メソッド、User-Agent、クエリパラメータなどを確認
2. マッチしたルールをオフにする - 特定のサブルールをCountモードに変更し、ログで確認したラベルをメモ
3. マッチしたパターンを除外するブロッキングルールを作成

IF
  has a label "awswaf:managed:aws:core-rule-set:CrossSiteScripting_Body"
  AND NOT
  URI equals "/missing_robots_form"
BLOCK

カオスを避ける

早めにチューニング、頻繁にチューニング

• 新しいルールのヒットを追跡
• どのルールにもマッチしなかったリクエストを追跡
• ヒットのないルールを追跡

ルールを段階的に追加

• 管理できるとわかっているルールを早めに追加(高価値、低運用負荷)
• ルールを追加し続け、セキュリティポスチャを進化させる

ラベルでトラフィックを管理

• ラベルでトラフィックをマークし、特定のルールでチェックまたはバイパス
• ダッシュボードとログでラベルを追跡

ラベルについて

ラベルは非常に強力な機能です。

• カスタムルールのアクションとして追加可能 - マネージドルールはデフォルトで追加
• マッチ条件とスコープダウンステートメントとして使用可能 - ダッシュボードとレポートの構築、ログノイズ(とコスト)削減のためのラベルベースログフィルタリング
• CloudWatch Logsとメトリクスで確認可能
• ログからノイズの多いトラフィックをフィルタリング - 内部トラフィック、信頼できるモニタリングツール、信頼できるソース、ゼロリスクリソース

2PM Coffee - コスト最適化

午後2時はコスト最適化の時間？らしいです。

有料マネージドルールの順序とスコープを見直す

• L7 DDoSマネージドルールを保護パックの上部に配置(DDoSリクエストは課金されない)
• Bot検査を行いたくないトラフィックタイプ(ラベル)をスコープダウン

ログの最適化

• ビジネス要件に応じて保持期間を設定
• ログをより安価なストレージ階層に移動
• ノイズの多いログをフィルタリング

定額プランへの切り替え

• アカウントあたり最大100プランまで
• ロギング、DNS、S3ストレージなどが含まれる

AWS WAFのロギングオプション

3つのロギングオプションが紹介されました。

料金プランの追跡

CloudFrontの料金プランでは、使用量の追跡が重要です。
リクエスト数やデータ転送量が許容量を超えていないか確認し、必要に応じてプラン変更を検討します。

HSBCの事例: エンタープライズでのAWS WAF活用

後半は、HSBCのDan Avidan氏による実際の大規模運用事例が紹介されました。

HSBCについて

• 創業: 1865年
• 資産: $3兆以上
• 顧客数: 4100万以上
• 市場: 58カ国
• グローバルソリューションをリージョナルにデプロイ(Build once, scale fast)

HSBC Edge Platform(EP)のスケール

HSBCのEdge Platformは非常に大規模です。

• 35マーケット x 7環境 x 約10バリューストリーム x 約10アプリケーション = 巨大な攻撃対象領域
• 月間数百TBのトラフィック
• 月間数十億のリクエスト
• 数百のCloudFrontディストリビューション/ドメイン
• 数十のWebACL
• 複数のCSP(クラウドサービスプロバイダー)
• 毎日の攻撃!

銀行業界の4つの大きな課題

1. 変化する顧客の期待
2. 競争/フィンテック/デジタルファースト
3. 複雑性/レガシーシステム
4. 効率性/コンプライアンス

HSBCのジャーニー

• re:Invent 2018からスタート
• 100%サーバーレスプラットフォームを目指す
• 主な目標:
  • オンプレミスからクラウドへの移行(結果的にハイブリッドクラウドに)
  • セキュリティの左シフト - サードパーティサービスプロバイダー/オリジンを認証・認可から抽象化
  • エッジでのコンピューティング

HSBCのソリューション

100%サーバーレスのエッジ保護およびルーティングプラットフォームを構築しました。

• AWS Shield
• Amazon Route 53
• Amazon CloudFront(複数ディストリビューション)
• AWS WAF(Firewall Manager、マネージドルール、カスタムルール)
• AWS Lambda(認証・認可、コールギャップ&スロットリング、リダイレクト、ヘッダー&クライアントIP処理)
• オンプレミスおよびサードパーティへの接続

組織とアプリケーションの課題

組織的な課題

• 常に進化する脅威の状況
• 経営層がWAFを本当に理解していない
• すべてのアプリケーションエンジニアがWAFを理解しているわけではない

アプリケーションの課題

• アプリチーム固有のルールをAWS Firewall Manager経由で組織全体のWAFポリシーに統合するのは難しい
• デプロイステージがない(API Gatewayのような)- Blue/Green WebACL
• 実際の攻撃の検出
• Amazon Managed Rules(AMR)が必要な柔軟性を提供しているか?
• チューニングには時間がかかる

チューニングの課題(HSBCの事例)

人間とボットの区別、最初の2市場での長いチューニング期間がありました。

初期の誤検知率が高かった

• ~30% アプリケーション変更
• ~10% トークン取得ロジックの変更
• ~10% 古いトークンの削除
• ~5% アグリゲーターの許可
• ~5% モニタリングエージェントの許可
• ~5% AWSの機能改善
• ~2% ジャーニーの早い段階でトークン取得
• ~2% 不要なリダイレクトの削除
• ~2% 不要なAPIコールの削除

→ ビジネスが許容できる誤検知率レベルに到達

良いニュース: 初期チューニング期間後、他の市場には「クッキーカッター」アプローチが適用可能

Firewall Manager/WAFの課題

• オンプレミスオリジンの保護
  • オリジンのマスカレードが課題
  • CloudFrontプライベートVPCオリジンは同じAWSアカウントにある必要があったが、最近発表された機能でその制約がなくなった
• 新しいCloudFrontディストリビューションはAWS Shield Advanced L7自動軽減に自動登録されない
• CloudFront Functions/Lambda@EdgeはAWS WAFが追加したカスタムヘッダーを読める - まだ使用していない

オブザーバビリティの課題

• 大量のロギングと分析は課題
• DDoS攻撃中のロギング要件は持続不可能だった
• CloudWatch Logs Insights
  • 30分かかる長時間実行クエリ
  • 比較的高価
• AWS OpenSearchへの移行を検討中

アーキテクチャ: Amazon CloudWatch → AWS Lambda(Unzip & decode) → Amazon Kinesis → Splunk

学んだ教訓と推奨事項

HSBCからの推奨事項

• 明日の攻撃から守る(昨日の攻撃ではなく)
• TAMやソリューションアーキテクトと関係を築く
• AWSのプライベートベータ/プレビューに参加する
• SOCへの投資を続ける
• AWS SRTチームのようなルール追加方法を学ぶ
• Infrastructure as Code(IaC)は味方
• サイト訪問者のユニークさを過小評価しない

今後の展望

• エッジベースのレイヤー7ルーティングをメガスケールで
• TLD配下の数万の外部向けドメイン/サブドメイン/マイクロサイトを統合
• WAF実装を組織の残りの部分にロールアウト

L7 DDoS保護の有効化

L7 DDoS保護を有効化する際は、DDoS組み込みダッシュボードでイベントを確認します。
ルールグループのオーバーライドで、各ルールアクション(Challenge、Block)を設定できます。

ステージング環境の維持

• 新しいルールバージョンを追跡し、変更に敏感な環境ではテスト
• 変更された保護パックに対してテストトラフィックを実行
• 非本番環境でラベルロジックを構築
• 場合によっては、同じマネージドルールの異なるバージョンを本番構成に追加可能

参考資料

セッションでは、以下の追加リソースが紹介されました。

• Flat-rate pricing plans(ブログ)
• AWS WAF L7 DDoS(ブログ)
• Configuring AWS WAF L7 DDoS rule

さいごに

以上、「A day in the life of an AWS WAF administrator」セッションのレポートでした。

このセッションは、AWS WAF運用の実践的なTipsが満載で非常に参考になりました。
個人的には特に以下の点が印象的でした。

• Origin Cloaking(オリジンの隠蔽)の重要性 - WAFをバイパスされないための設計は必須
• 段階的なルール適用とチューニング - 最初からすべてをBlockにせず、Countモードで様子を見ながらチューニング
• ラベルの活用 - トラフィック管理、ログフィルタリング、コスト最適化に有効
• HSBCの実例 - 大規模エンタープライズでの運用課題と解決策は非常に実践的

また、HSBCの事例では、初期の誤検知率が高かったものの、様々な改善を重ねてビジネスが許容できるレベルに到達し、他の市場に展開できたという話は、大規模組織でのWAF導入を検討されている方には励みになるのではないでしょうか。

AWS WAFを運用されている方、これから導入を検討されている方にとって、このセッションで紹介されたベストプラクティスが参考になれば幸いです。