re:Invent 2024: AWS WAFでのコスト最適化 - Bot Control活用法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - How to optimize costs with AWS WAF (CDN201)
この動画では、AWS WAFを使用してWebアプリケーションを保護する際のコスト最適化について解説しています。AWS WAFの基本的な仕組みや料金体系を説明した上で、無料のAWS Managed Rulesの活用方法や、Intelligence Threat Mitigationなどの高度な保護機能の費用対効果の高い導入方法を紹介しています。特に、パブリックアプリケーションへのトラフィックの約47%がBotからのものであることを指摘し、Bot Controlを適切に実装することで大幅なインフラコスト削減が可能であることを具体的な数値とともに説明しています。また、ルールの優先順位設定やScope-down statementの活用など、実践的なコスト最適化のテクニックをデモを交えて詳しく解説しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS WAFの概要とセッションの導入
チェック、チェック、チェック。おはようございます、皆様。本セッションにご参加いただき、ありがとうございます。皆様、いかがお過ごしでしょうか？ このように多くのIT専門家の方々が一堂に会して協力し合う様子を見るのは、いつも素晴らしいことですね。私にとって間違いなく年間で最も好きな時期とイベントです。皆様にとってもそうであることを願っています。そして、私たちはちょうどその真っ只中にいます。
始める前に、皆様に簡単な質問をさせていただきたいと思います。挙手でお答えください。組織内でパブリックアプリケーションやAPIの保護を担当されている方は何人いらっしゃいますか？素晴らしいですね。では、何らかのWeb Application Firewallをご利用されたことがある方は？素晴らしい、たくさんの手が挙がりましたね。最後の質問です。AWS WAFを使ってコストを削減したいと思われる方は何人いらっしゃいますか？朗報です。皆様は正しいセッションに来られました。
私はIgor Kushnirovと申します。AWSのSenior Solutions Architectとして、主にお客様のAmazon CloudFrontというコンテンツデリバリーネットワークサービスの導入支援、そして本日のトピックであるAWS WAFや、マネージド保護サービスであるAWS Shieldといったペリメーター保護サービスの導入支援を担当しています。本日は、Devansh Agrawalと共同発表させていただきます。一言ご挨拶をお願いできますか？皆様、こんにちは。ありがとうございます。
通常の業務では、インターネットからの脅威に対してアプリケーションやAPIを保護し、セキュリティ態勢を改善するためのベストプラクティスについて、お客様とお話しさせていただいています。本日は少し方向性を変えて、AWS WAFを費用対効果の高い方法で運用するためのベストプラクティスについてお話しさせていただきたいと思います。
本日は盛りだくさんの内容をご用意しています。プレゼンテーション中に質問の時間が取れない場合は、このTheater領域に残っておりますので、ご質問がございましたらお気軽にお声がけください。また、ネットワークとコンテンツデリバリーのキオスクがすぐそちらにありますので、そちらでもお話しできます。これはレベル200のセッションですので、まずAWS WAFの概要と主要なワークフローについて簡単に説明させていただきます。その後、楽しい部分に入っていきますが、これを2つのパートに分けています。まず、一般的な脅威に対する保護の構築方法についてお話しし、次に高度な保護について、すべてコスト効率を念頭に置いてお話しします。その後、簡単なデモをご覧いただき、最後に追加の考慮事項と、このセッションを終えた後に覚えておいていただきたい主なポイントについてお話しします。
AWS WAFの基本構成と一般的な脅威への対策
通常、お客様が日常的に直面している脅威は、大きく3つのカテゴリーに分類されます。1つ目は、Volumetric Attack（容量型攻撃）で、DDoS（分散型サービス妨害）攻撃としても知られています。2つ目はアプリケーションレベルの脅威です。OWASP Top 10リスト（Open Web Application Security Projectが発表する脆弱性リスト）についてご存知の方もいらっしゃるかもしれません。そして3つ目がBotです。このトレンドは拡大傾向にあり、Botからのトラフィック量は増加しています。後ほど詳しくご説明させていただきます。興味深い統計をご紹介しますと、AWSは毎日1000件以上のDDoS攻撃を緩和しており、そのうち約48%がアプリケーション層で発生しています。
このような状況から、AWS WAFは上記3つの脅威カテゴリーすべてからアプリケーションを保護するのに最適なポジションにあると考えています。AWS WAFはクラウドネイティブなファイアウォールです。カスタムルールやレートベースのルールを設定できる柔軟なルールエンジンを提供しています。また、AWSやマーケットプレイスパートナーが管理する様々なマネージドルールからお選びいただくこともできます。さらに、より高度な脅威への対応が必要な場合は、Intelligence Threat Mitigationと呼ばれる高度な保護機能も提供しています。可観測性の面では、様々なルールメトリクスや、異なる視点から確認できる各種ビルトインダッシュボードを提供しています。そして、トランザクションレベルでより詳しく調査したい場合は、様々な保存先を選択してアクセスログを有効にすることができます。
それでは、主要な構成要素についてお話ししましょう。1つ目はWeb ACL（Web Access Control List）です。これはAWS WAFのリソースで、保護したいリソースに作成して関連付ける、ルールやルールグループのコンテナのようなものだとお考えください。 次にRule Groupですが、これも別のAWSリソースです。カスタムルールやマネージドルールなど、再利用可能なルールのセットを含んでおり、これもWeb ACLに関連付けます。そして最後がRule（ルール）自体です。これは基本的な要素で、AWSリソースではなく、Rule GroupまたはWeb ACL内に完全に含まれるものです。
ルールには検査基準とアクションが含まれています。これらの検査基準が受信リクエストにマッチした場合、アクションが実行されます。アクションについてお話ししましょう。Terminatingと Non-terminatingの2つのカテゴリーがあります。BlockやAllowなどのTerminatingアクションの場合、検査基準が受信リクエストにマッチすると、アクションが実行され、処理が停止します。Blockアクションの場合、設定に応じて403レスポンスまたはカスタムレスポンスがユーザーに返されます。Non-terminatingアクションの場合、検査基準が受信リクエストにマッチすると、ルールメトリクスは増加しますが、トラフィックには影響を与えません。
これは、トラフィックに影響を与えることなく、脅威やトラフィックの状況を理解するための優れた方法です。本番環境でAWS WAFを導入する際は、まずCountアクションから始めることを常にお勧めしています。
CAPTCHAとChallengeアクションは、2つのカテゴリーのいずれかに分類されます。インターネットを閲覧中にCAPTCHAを目にしたことがあるかもしれません。これは、解く必要のある小さなパズルです。その主な目的は、リクエストが正当なユーザーまたは人間からのものであり、ボットではないことを確認することです。Challengeの方は、クライアントやブラウザがJavaScriptを実行できることを確認するためのテストです。これらの2つが正常に実行されると、ChallengeやCAPTCHAの状態を含む固有のトークンが生成され、すべてのリクエストと共に送信されます。このトークンが有効で期限切れでない場合、非終了アクションとなり、後続のルールで処理が継続されます。トークンが無効な場合や、CAPTCHAまたはChallengeが失敗した場合は、終了アクションとなり、ChallengeレスポンスまたはCAPTCHAがユーザーに返されます。
では、AWS WAFの使用を始めるにはどうすればよいでしょうか？最初のステップは、Web ACLを作成することです。また、複数のリソースに関連付けることができる既存のWeb ACLを再利用することもできます。 Web ACLを作成すると、最初は空の状態で、ルールは含まれていません。ブロックまたは許可のいずれかに設定できるデフォルトアクションのみが含まれています。次に、保護したいリソースにWeb ACLを関連付けます。6つのリージョナルリソースと、グローバルリソースであるAmazon CloudFront（常に推奨）から選択できます。これは非常に重要なポイントですが、セキュリティ、コスト、パフォーマンスの観点から、リージョナルエンドポイントの前にAmazon CloudFrontを使用することを常に推奨しています。
その後、ルールとルールグループの追加を開始できます。 ルールは、定義した優先順位に従って処理されます。 設定が完了すると、一部のリクエストは許可され、 一部のリクエストはブロックされます。これで基本的な側面をカバーしたので、コスト効率を念頭に置きながら、一般的な脅威に対する保護の構築方法について説明していきましょう。
AWS WAFのコスト効率と高度な保護機能
コストに関して、AWS WAFの課金の仕組みについて疑問に思われるかもしれません。他のAWSサービスと同様に、契約は不要で、使用した分だけお支払いいただきます。料金カテゴリーは2つだけです。1つ目は月額料金です：Web ACLを作成するたびに5ドル、ルールまたはルールグループを追加するたびに月額1ドルがかかります。Managed Rule Groupsを追加する場合、そのグループに対して1ドルを支払うだけで、内部のルールに対する追加料金は発生しません。これは、Managed Rulesを使用することで月額料金を最適化する優れた方法です。2つ目はリクエストごとの料金です：Web ACLで処理されるリクエストごとに課金され、1個、25個、10個のルールが含まれているかに関わらず、100万リクエストあたり60セントです。
まずは無料のAWS Managed Rulesから始めることをお勧めします。無料とは、先ほど説明した基本料金を除いて、これらのルールを追加することによる追加コストがかからないという意味です。ルールの順序に関しては、最初に高信頼性のルールから始めることをお勧めします。すでに独自の脅威インテリジェンスを持っていてブロックリストがある場合、Amazon IP Reputation ListとAnonymous IP Listを追加することで、内部の脅威インテリジェンスを補完する優れた方法となります。 その後、さまざまな一般的な脅威カテゴリーから保護するルールを選択できます。これをBaselineルールグループと呼んでいます。さらに、ユースケース固有のルールグループを追加できます。例えば、Linuxバックエンドを使用している場合、Linux Managed Rule Groupを追加して、Linuxオペレーティングシステムに関連するローカルファイルインクルージョンから保護することができます。
私たちは、常に少なくとも1つのRate-basedルールを追加することをお勧めしています。これは、大量攻撃に対する第一の防御ラインであり、Blanket Rate-basedルールと呼んでいます。また、より機密性の高いページを保護するために、さらに詳細なルールを追加することもお勧めしています。 この時点で、いくつのルールを追加できるのか気になっているかもしれません。答えは、好きなだけです - ルールの数は制限していません。私たちが計測しているのは、それらのルールが使用する計算能力で、WAF Capacity Units（WCU）と呼んでいます。1,500 WCUの範囲内であれば、追加料金は発生しません。
5,000まで設定可能です - 私の経験では5,000を使用しているお客様を見たことはありませんが、それだけの余裕があるということです。
さて、最初のステップを終えましたが、これらの種類の保護は、さまざまなアプリケーションやユースケースにとって十分かもしれません。しかし、しつこいBotがまだ諦めずに攻撃を続けている場合はどうでしょうか？ 驚かれるかもしれませんが、パブリックアプリケーションに到達するトラフィックの約50%（正確には47%）は、人間ではなくBotからのものです。問題なのは、Botからのトラフィックを処理するためのインフラコストが、人間からのトラフィックを処理するコストと同じだということです。
パブリックの生成AIアプリケーションを使用している場合を想定してみましょう。Amazon Bedrockで大規模言語モデルを使用し、平均入力プロンプトが1,400トークン、出力プロンプトが150トークンで、AWSが提供するBot Control機能を使用してBotトラフィックの大部分（47%ではなく43%とします）をブロックできた場合、1ドルの投資に対して277ドルのリターンが得られます。これはかなり驚くべき数字です。ただし、一点お断りしておきますが、インフラコストの削減を実現するために生成AIを使用する必要はありません - AWS WAFを使用すれば、どのようなパブリック向けWebアプリケーションでもインフラコストの削減効果を得ることができます。これは、アプリケーションに不要なトラフィックのインフラコストを削減できるという、AWS WAFを使用することの別の側面を示しています。
では、より高度な脅威にまだ悩まされているかどうかをどのように知ることができるでしょうか？最適な方法は、私たちの組み込みダッシュボードを使用することです。例えば、これらのインテリジェンス脅威対策を追加する前でも、サンプルトラフィックに基づいて、Botのタイプ、カテゴリー、発信元などを確認することができます。私たちはこれらの可視性をすべて提供しています。 アプリケーションにまだ対処が必要なトラフィックが到達していることが確認された場合は、高度な保護を検討する時期です。
それでは、コストについてお話ししましょう。ベースラインコストと同様に、Intelligence Threat Mitigation Setからルールグループを追加する場合、月額料金とリクエストごとの料金の2種類があります。前払いの約束はなく、使用した分だけお支払いいただきます。Intelligence Threat Mitigation Setのルールグループに対して月額10ドルの月額料金を支払い、そのルールグループで処理されたリクエストに対してのみリクエストごとの料金を支払います。そのルールグループで処理されないリクエストについては料金は発生せず、その理由はすぐにご説明します。
前払いの約束がないのに月額料金があるのは、と思われるかもしれません - それは鋭い指摘ですね。明日ルールを削除したりWeb ACLを削除したりすることにした場合、時間単位のレートに基づいて按分計算された料金のみを請求します。そのため、依然として約束事はありません。 ChallengeアクションやCAPTCHAアクションを使用する場合、返されたChallengeレスポンスの数に対して料金を支払い、CAPTCHAを解こうとした試行回数に対してのみ料金を支払います。例えば、あるBotがCAPTCHAで保護されたエンドポイントに大量のリクエストを送信しようとしても、CAPTCHAを解こうとしない場合、この場合のCAPTCHA料金は発生しません。
では、Intelligence Threat Mitigationをどのように追加すればよいのでしょうか？それは直面している課題の種類によって異なります。Botトラフィックに関する課題がある場合は、直感的な名前のBot Control Rule Groupを追加できます。CommonとTargetedの2つのティアがあります。Commonティアは一般的なBotの多くをブロックするのに役立ち、より高度なBot対策が必要な場合は、Targetedティアを有効にすることをお勧めします。また、アカウントの乗っ取りやブルートフォース攻撃、クレデンシャルスタッフィングなどのアカウント不正の課題がある場合は、Account Takeover PreventionやAccount Creation Fraud PreventionなどのAccount Fraud Managerグループの追加を検討できます。
この設定で気づいたことがあります。私が今行ったのは、実はそれらのプレミアムルールをすべて設定の一番上に追加してしまったことです。以前お話ししたように、ルールは優先順位順に処理されます。これは、すべてのリクエストが少なくともBot Controlルールによって処理されることを意味し、それは望ましくありません。望ましいのは、まず無料のルールを活用することです - より高い優先順位に配置し、それらを十分に活用して、プレミアムルールに到達する前に、一般的な脅威や Rate-based ruleによる大量のトラフィックをできるだけブロックすることです。それが正しいやり方です。また、Scope-down statementを使用することもでき、これによってプレミアムルールで処理したいリクエストの種類をさらに制限することができます。例えば、画像やCSSファイルをBot Controlで処理したくない場合は、そのためのScope-down statementを設定できます。
CAPTCHAとChallengeに関しては、Application Integration SDKを使用してウェブページ上でトークン生成を事前に統合することで、コストを最適化することをベストプラクティスとして常に推奨しています。また、トークンのImmunity time（免疫時間）を設定することも忘れないでください。これによってトークンの有効期間が決まり、ユーザーがCAPTCHAを頻繁に解く必要がなくなることでユーザーエクスペリエンスが向上します。より機密性の高いページに対してのみCAPTCHAを設定するようにしてください。
AWS WAFの実装デモとコスト最適化のベストプラクティス
ここまで理論的な話をしてきましたが、ここからは、コスト最適化について話してきたことを実際にどのように実装できるかをデモンストレーションしていきます。パブリックに公開されているアプリケーションを保護したいとします。そのために、reinvent24というWeb ACLを設定しました。 そこに、いくつかのルールを追加しています - AWS Managed Rules Common Rule SetとAmazon IP Reputation Listです。 Common Rule Setは一般的な攻撃から保護し、Amazon IP Reputation Rulesはインターネット上で悪評のあるIPからの保護を支援します。
ここで、いくつかのIPアドレスをブロックリストに追加したいという要件が出てきたとします。簡単にルールを追加して、blocklistという名前を付けることができます。 IPリストを追加し、アクションとしてBlockを選択します。ルールの優先順位を設定することは、 コスト削減の観点から非常に重要です。今回は、優先順位を一番上に設定します。次に、 特定の国からのトラフィックのみを許可したいという要件があるとします。というのも、ビジネスがそれ以外の地域にないからです。 Geo Blockを実装して、トラフィックを許可したい国を選択できます。 この例では、オーストラリアとニュージーランドを選択しています。つまり、オーストラリアまたはニュージーランドから発信されていないトラフィックはブロックしたいということです。優先順位は Blocklistの直下に設定します。
特定のIPアドレスが一定数以上のリクエストを行った場合にスロットリングするというビジネス要件があるシナリオを考えてみましょう。 これはRate-based Ruleを使って実装できます。制限を 300に設定します。 つまり、任意のIPがその時間枠内で300以上のリクエストを行うと、それらのリクエストのスロットリングが開始されます。優先順位はGeo Blockの直下に設定します。 これらの優先順位を調整する理由を理解することは非常に重要です。
次に、マーケティングウェブサイトがBot攻撃を受けていて、それから保護したいというシナリオを考えてみましょう。AWS Managed Rule Groupsの一部であるBot Control Ruleを実装できます。追加は非常に簡単で、AWS Managed Rulesに移動して クリックするだけです。これは有料のRule Groupの一部なので、追加の料金が発生することに注意してください。 ここが重要なポイントです - 有料のRule Groupを追加する際は、必ずスコープを絞り込むようにしてください。マーケティングページを保護するという要件があるため、 Bot Controlをすべてのリクエストに適用する必要はありません。保護が必要な場所を具体的に指定する必要があります。 正しいパスを 指定していることを確認します。 Bot Controlを一番下に配置する必要があります。画面で確認できるように、すべてのルールが設定されました。
すべてのルールには0から4までの優先順位が割り当てられています。基本的に、アプリケーションに来るすべてのリクエストは、この優先順位に従って処理されます。何百ものリクエストが来ていると想像してください - そのうちのいくつかがブロックされたIPに属している場合、それらのリクエストは最初のルールでブロックされ、それ以上の処理は行われません。また、Geo Blockルールで定義した国からのリクエストが20%あるとすると、それらはその段階でブロックされます。そして、特定のIPから多数のリクエストがある場合、それらはRate-based Ruleによってスロットリングされます。
つまり、より確実なルールを最初に配置して優先順位を適切に設定していれば、その後のリクエストのみがBot Controlに移行することになります。また、スコープダウンステートメントを使用することで、100件のリクエストのうち、Bot Controlが処理するのは20〜30%程度に抑えることができます。これにより、大幅なコスト削減が可能になります。Bot Controlを最上位に配置するのではなく、常に確実なルールを最初に配置し、保護したいパスに適切にスコープダウンすることが重要です。このデモからの重要なポイントは、適切なルールの優先順位の配置とPaid Rule Groupsのスコープダウン、この2点です。
では、他にコストを最適化する方法はあるでしょうか？見ていきましょう。AWS WAFを使用すると、分析に不要かもしれない多くの情報が得られます。ログフィルターオプションとフィールドリダクションオプションを使用することで、ログの全体量を削減できます。さらに、マルチアカウント設定や複数のWeb ACLを持つ大規模な展開がある場合は、AWS Firewall Manager (FMS)の使用を検討できます。これにより、コスト面でのメリットと全体的なコスト保護が得られます。また、Amazon Security Savings Bundleの利用も検討できます。これにより、CloudFrontのコストを最大30%、WAFの課金を10%削減できます。
セッションの終わりに近づいてきました。これまで議論した重要なポイントを振り返ってみましょう。ルールの優先順位は重要で、適切なフロー制御を確立する必要があります。過剰な支払いを避けるため、Paid Rule Groupsに対して具体的にスコープダウンする必要があります。ログフィルターとフィールドリダクションを使用して、リクエストのログ量を削減することを検討してください。また、トークンリクエストを最適化するために、AWS WAF SDKsを実装してインテリジェントな脅威検出を行うこともできます。WAFの価格設定やWebアプリケーションを費用対効果の高い方法で保護する方法についてさらに詳しく知りたい場合は、こちらの参考資料をご覧ください。ご参加いただき、ありがとうございました。私たちはブースにいますので、AWS WAFについて質問がある方や、さらに詳しく知りたい方は、お気軽にお声がけください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion