トップ > AWS re:Inforce 2025 > 【AWS re:Inforce 2025】WAF と CloudFront セキュリティ設定 の簡素化とその効果 (NIS203-NEW)

【AWS re:Inforce 2025】WAF と CloudFront セキュリティ設定 の簡素化とその効果 (NIS203-NEW)

AWS re:Inforce 2025 セキュリティ Amazon CloudFront AWS WAF
記事タイトルとURLをコピーする

マネージドサービス部 佐竹です。
AWS re:Inforce 2025 に現地参加してきましたので、そのログを順番に記述しています。

はじめに

reinforce.awsevents.com

2025年6月16日から18日にかけて、ペンシルベニア州フィラデルフィアで AWS のセキュリティに特化したカンファレンス「AWS re:Inforce 2025」が開催されました。

参加したセッションのレポートを「1日のまとめ」に書いていこうとしたらあまりにも文章量が増えすぎてしまったので小分けにしています*1。

本ブログは「【AWS re:Inforce 2025】現地参加レポート 3日目 6月18日(火) 佐竹版」より NIS203-NEW Simplify AWS WAF and Amazon CloudFront Security for Faster Deployment のセッションレポート（解説）です。

私の感想やコメントは解説の邪魔になると感じたので「脚注」として記載しています。

NIS203-NEW Simplify AWS WAF and Amazon CloudFront Security for Faster Deployment 解説

翻訳すると「AWS WAF と Amazon CloudFront のセキュリティを簡素化し、より迅速な導入を実現」となります。

概要

本セッションは、Amazon CloudFront と AWS WAF という、Web アプリケーションのパフォーマンスとセキュリティを支えている 2つのサービスに焦点を当てたものです。

セッションで共通の課題として挙げられたのは、「CloudFront や WAF の価値は理解しているが、設定が複雑で専門知識が必要なため、導入のハードルが高い」という利用者の声です。特にセキュリティや CDN の専門家ではない開発者にとって、その設定は大きな負担となります。

この課題を解決するため、設定プロセスを根本から見直した新しいユーザーエクスペリエンス（UX）となった AWS マネジメントコンソールが公開されました。

背景：なぜ、CloudFront と WAF の設定は複雑だったのか

セッションでは、この課題を具体的に理解するため、「Example Corp」という急成長中の Eコマース企業と、そのリード開発者である「Alex」というペルソナが紹介されました*2。

Example Corp はハイエンドファッションを専門とする Eコマース企業で、45,000 人以上のアクティブカスタマーを抱え、年 35% の成長を遂げています。

VC*3 からの資金調達にも成功し、事業が急拡大する中で、Next.js で構築されたアプリケーションのパフォーマンスとセキュリティを維持することが急務となっていました。

このミッションを担うのが、リード開発者の Alex です。彼女は Next.js やモダンな Web 技術に精通した優秀なフルスタック開発者ですが、インフラや CDN、セキュリティは専門外。

彼女のような開発者が、コードではなく設定に時間を費やさざるを得ない状況が課題となっていました。

これまでの UI では、もし彼女が CloudFront と AWS WAF を使用し、アプリケーションを保護しようとした場合には、以下のような「複雑な旅」が待ち受けていました*4。

このスライドは、従来の設定作業の複雑さを示しています。どれだけ手間がかかるのか、見てみましょう。

  1. まず Amazon CloudFront の設定を開始しますが、すぐにドキュメント (AWS Developer Guide) を参照する必要に迫られます
  2. 次に AWS WAF を有効にするため、CloudFront コンソールを離れて WAF コンソールへ移動します
  3. WAF の設定方法が分からず、ここでもまたドキュメントを参照することになります
  4. WAF の設定後、CloudFront に戻って設定を続けると、今度はカスタムドメイン用の TLS 証明書を取得するため、AWS Certificate Manager (ACM) へ移動するよう促されます
  5. AWS Certificate Manager (ACM) では、証明書を発行する前提として、まずドメインの所有権を証明するよう要求されます
  6. そのため、Amazon Route 53 へ移動し、ACMから指示されたDNSレコード（CNAMEレコードなど）を追加または更新する操作が必要になります
  7. すべてのプロビジョニングが完了し、ディストリビューションが作成された後も、最終的にトラフィックを CloudFront に向けるため、再度 Amazon Route 53 へ移動して、アプリケーションの DNS レコードを更新する必要があります

この一連のプロセスは、複数のサービスコンソールを行き来し、多くの専門知識を要求される「苦行」となってしまっていました。

この複雑さが、開発者が迅速にセキュアなアプリケーションをデプロイすることを阻む障壁そのものなのです。

①：CloudFront エクスペリエンスの刷新

この複雑な問題を解決するため、AWS は CloudFront のコンソールエクスペリエンスを再設計しました。

新しい CloudFront の UX の目的は、以下の3点に集約されます。

  • セキュアなデプロイの加速: ベストプラクティスを数クリックで導入
  • 複雑さの軽減: 専門知識なしで最適な設定を実現
  • 管理の一元化: サービス間を移動する必要性をなくす

単一のワークフローで完結する CDN デプロイ

新しいコンソールは、従来のフォームを廃止し、ユーザーをガイドするステップバイステップのウィザード形式を採用しています。

最大のポイントは、CloudFront の設定に必要な関連サービスの操作を、すべて CloudFront の UI 内で完結できるようになったことです。

  • 統合されたセットアップ: Route 53 でドメインを管理している場合、TLS 証明書のプロビジョニング（ACM との連携）や DNS レコードの管理（Route 53 との連携）が、CloudFront のコンソールを離れることなく自動的に処理されます。
  • デフォルトでのセキュリティ保護: 新しいワークフローでは、AWS が推奨するセキュリティ保護（WAF ルール）がデフォルトで有効になります。これにより、ユーザーは WAF の設定について深く悩むことなく、最初からベストプラクティスに基づいた保護を受けられます。
  • 最適なキャッシュ設定: オリジンの種類（S3, ALB など）に応じて、最適な CDN キャッシュルールが自動で推奨・設定されます。Alex のような CDN の専門家でない開発者でも、パフォーマンスを最大化する設定を簡単に行えるようになりました。

この統合されたエクスペリエンスにより、ユーザーは複数のサービスの詳細な知識がなくても、迅速かつ安全にアプリケーションをデプロイできるようになります。

デモ

デモでは、ほんの数ステップで CloudFront ディストリビューションが作成できるようになったと説明されました。

  1. ディストリビューション名とドメイン名を入力。
  2. S3 オリジンを選択。ここで「Grant CloudFront access to origin」を有効にすると、S3 バケットをプライベートに保ちながら CloudFront からのアクセスのみを許可するオリジンアクセスコントロール（OAC）とバケットポリシーが自動で設定されます。
  3. 「Enable security protections」のチェックボックスをオンに。これだけで、オリジンタイプに応じた推奨 WAF ルールが自動で適用されます。
  4. TLS 証明書がない場合、「Create certificate」ボタンをクリックするだけで、バックグラウンドで ACM と Route 53 が連携し、証明書が発行・設定されます。

また、作成後のルール管理も簡素化され、CloudFront のコンソールから直接カスタム WAF ルールを追加できる点も合わせて紹介されました。

②：AWS WAF エクスペリエンスの刷新

セッションの後半は、AWS WAF エクスペリエンスの刷新についてです。

Example Corp がスタートアップから 5,000 万人の顧客を持つ大企業へと成長したというシナリオのもと、より高度化・多様化するセキュリティ要件にどう応えるかがテーマとされました。

企業が成長するにつれ、セキュリティの課題も変化します。

月間アクティブユーザーは 5,000 万人に増え、アプリケーションは Next.js だけでなく、API、LAMP、WordPress など多様化。年間 5億ドル のデジタル収益がリスクに晒され、ゼロデイ攻撃を含む日々の攻撃も増加しつつあります。

これを 5人のチームで守っているのが実情という、企業が規模の拡大と共に直面する「現実味を帯びた課題」が提示されました。

従来の WAF には、スライドに示された以下のような課題（Pain Points）がありました。

  • 時間のかかる設定（Time-Consuming Configuration）: 複雑なインターフェースが迅速な実装を妨げていました
  • セキュリティギャップ（Security Gaps）: どのルールを適用すべきか分からず、アプリケーションが脅威に晒される可能性がありました
  • ダッシュボードの過負荷（Dashboard Overload）: 複数のコンソールにまたがる断片的な情報では、全体像の把握が困難でした
  • 専門知識の不足（Expertise Shortage）: 効果的な運用には、高度な専門知識が必要でした

これらの課題を解決するのが、新しくなった AWS WAF コンソールです。

保護パック (Protection Packs)

新しい AWS WAF のフローでは、まず最初に「アプリケーションのカテゴリ（Eコマース、API、WordPress など）」や「トラフィックの主な送信元」といった簡単な質問に答えます。

すると、その回答に基づき、AWS が推奨するルールの組み合わせである「保護パック（Protection Packs）」が提示されます。これには、AWS Managed Rules のコアセットや IP レピュテーションリストだけでなく、Amazon Bot Control のような高度なルールも含まれています*5。

実際の新しいマネジメントコンソールの画面キャプチャ

ユーザーは「Recommended（推奨）」または「Essential（基本）」のパックを選択するだけで、WAF のルールセットをワンクリックで展開できます。最下部に「Estimated cost $62-$63」のように、想定される月額コストも合わせて表示される親切設計です。

トラフィックが語る、次の一手

新しいダッシュボードの最も強力な機能の一つが、トラフィックベースの推奨機能です。

これは、実際に Web ACL を通過しているトラフィックを WAF が分析し、「現在許可されているトラフィックの中に、このルールを有効にすればブロックできる悪意のあるリクエストがこれだけあります」といった具体的な改善案を提示してくれる機能です。

「このルールを有効にすれば、悪意のあるボットトラフィックを 75% 以上ブロックできます」のように、効果が数値で示されるため、セキュリティ担当者はそれを根拠としてルールを有効化できます。

直感的な可視化と迅速な分析

ダッシュボードの可視性だけでなく、ルール管理の UI も直感的になりました。

  • インタラクティブな Sankey ダイアグラム: 全てのトラフィックが、設定されたルールの順序に従って、どのように処理されていくかを視覚的に追跡できます。
  • アウトカム駆動のダッシュボード: 「DDoS」「Bot Management」といった目的別にメトリクスが整理されており、見たい情報に素早くアクセスできます。
  • ダッシュボードからのログクエリ: ダッシュボード上のグラフで気になる部分をクリックすると、その場で CloudWatch Logs に保存された生ログをフィルタリングして表示できます。コンソールを離れることなく、ドリルダウン分析が可能となり、インシデント調査の時間が大幅に短縮されます。

この刷新がもたらした結果です。

  • 追加コスト=ゼロ
  • 設定にかかる時間を 80% 削減
  • これまでの複数のダッシュボードは、単一のオブザーバビリティダッシュボードに統合

これらの新機能はすべて、既存の Web ACL とも後方互換性があり、ユーザーはいつでも新旧のコンソールを切り替えることが可能です。

セッションの最後には、本日紹介された機能がすでに利用可能であることが伝えられました。新旧コンソールの柔軟な切り替えも可能で、すべての AWS リージョン（GovCloud や中国リージョン含む）でグローバルに利用できます。

関連記事等

セッションの動画

この概要を読んで興味が出た方は YouTube に既に動画がアップロードされているので是非ご覧ください。

Amazon CloudFront が新しいユーザーフレンドリーなインターフェースでウェブアプリケーションの配信とセキュリティを簡素化

aws.amazon.com

まとめ

本セッションは、キーノート(基調講演)でも語られた「簡素化によるイノベーションの加速」というビジョンが、いかに具体的なプロダクトとして形になっているかを示す内容でした。

  • CloudFront の刷新は、CDN、WAF、ACM、Route 53 という複数のサービスにまたがる複雑な設定を、単一の直感的なワークフローに統合しました。
  • AWS WAF の刷新は、「保護パック」や「トラフィックベースの推奨」といった機能により、セキュリティの専門知識がない開発者でも、専門家レベルの保護を容易に適用できるようになりました。

これらのアップデートが意味するのは、単なる利便性の向上ではなく、セキュリティにおける「差別化につながらない重労働（undifferentiated heavy lifting）」を AWS が肩代わりすることで「開発者は本来の価値創造に、より集中できるようになる」ということを示しています。

ただ注意すべき点もあります。特に、AWS WAF の Recommended 設定に含まれる有料オプションがそれです。自社のトラフィックや予算への影響を鑑み、導入にあたっては十分な検証が必要となります。

「推奨を鵜呑み」とせず、実環境での動作確認も正確に行ってください。

とはいえ、セキュリティが「専門家の仕事」から「開発の標準プロセス」へとスライドした価値のあるアップデートと考えられる点は特筆すべき事象です。

では、またお会いしましょう。

*1:あとこれは単に謝罪ですが、メイン業務の都合3日目のブログ投稿が随分遅れており申し訳ないです。

*2:UI/UX におけるペルソナとは、デザインのターゲットとなる架空の人物像のこと。ペルソナを設定することで、デザイナーはユーザーのニーズや行動をより深く理解し、使いやすいインターフェースを設計することができます。私は新卒採用の時、Web UI に非常に興味があり、UI/UX のペルソナ設計には少しだけ思い入れがあります

*3:ベンチャーキャピタル/Venture Capital

*4:AWS の発表を見て良く思うのですが、Journey (旅) という言葉を好んで使う傾向にあると感じます

*5:別途、追加の利用料が発生するオプションが設定される点に注意してください

佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ

セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。