AWS WAF統合でコスト削減 マネージドルール料金を最適化した方法

株式会社リゾーム 業務ソリューション事業グループのあめぎです。

定期的にAWS費用の内訳と睨めっこして、「どこか削減できるんじゃないか?」と考えてしまうところがあるのですが、今回はそれが実を結んだ。というお話です。 結果として、毎年パソコンが何台も買える経費削減につながりました。

もしALBとWAFをお客様ごとに用意して、マネージドルールを使用しているなら、同様の経費削減ができるかもしれません。

WAFのマネージドルールに着目した経緯

利用しているマネージドルールの料金体系をよく見ると、月額サブスクリプションが環境ごとにかかる事に着目しました。そこで「できるならWAFをまとめてしまおう」という発想に至りました。

きっかけは、WAFのバージョンアップについて調べていたときに、ふと目にした「AWSのWAFは複数のリソースを割り当て可能」という情報です。そこから「これは使えるかも?」と思い、詳しく調べてみました。

参考:Web ACL を AWS リソースに関連付ける - AWS WAF

WAFとは?

WAF(Web Application Firewall)は、ウェブアプリケーションを悪意ある攻撃から保護する機能です。AWSはこれをサービスとして提供しており、クラウド環境で簡単に導入できます。 リゾームでも一部の製品でこのWAFを利用しています。

主な特徴は以下の通りです。

Webアプリは常に攻撃のリスクにさらされています。そこでWAFが攻撃を防ぐ門番として活躍します。

WAFにおけるマネージドルールとは?

マネージドルールとは、AWSやセキュリティベンダーが事前に作成したセキュリティルールセットで、AWS WAFに簡単に適用できます。これを使えば、専門知識がなくても高度なセキュリティを導入できます。

特徴

  • 専門知識不要で導入可能
  • 最新の脅威に対応(ベンダーが随時更新)
  • 数クリックで設定完了

料金体系は、月額サブスクリプション+リクエスト単位の従量課金が一般的です。サードパーティ製のルールはAWS Marketplaceで提供され、目的に応じて選べます。

WAFをまとめたらコスト削減できる?発想のきっかけ

この発想に至った理由は、採用していたマネージドルールの料金体系と、自社製品のAWS環境構成にありました。 ある製品では、ALB(このリソースにWAFを割り当てます)を「お客様ごと」に構築していました。

そして、利用していたWAFのマネージドルールの料金体系は

という仕組みでした。この「月額サブスクリプション料金」が環境数ごとにかかってしまう。 つまり、環境が増えるほどコストが膨らむ構造だったのです。

まとめても大丈夫と判断した理由は3つ

ではどうやって「まとめてもよい」と判断したのか?詳しく説明します。 まとめるということは、ポリシーやログなど、WAFに関するあらゆる要素が1つに統合されるということです。今回は次の3つが理由となりました。

1. お客様ごとにWAFのカスタム設定をしていなかった

調査した結果、細かいカスタマイズはなく、全て同一の設定でした。対象の製品は「環境が異なっても共通の品質を維持する」という運用ポリシーがあり、今回のWAF統合を後押しするものとなりました。

2. ログからお客様ごとの環境が識別できた

WAFのログについて改めて調べたところ、通信ごとに関連するALBがログに記載される事がわかりました。WAF統合後はこのALBの情報を頼りにお客様を識別すればよいとわかりました。

参考:保護パック (ウェブ ACL) トラフィックのログフィールド
※ httpSourceIdが該当します

3. WAFリクエスト数の上限を超えなければ良い

WAFにはリクエスト数の上限が設けられています。引き上げリクエストにより拡張が可能で、最大は1秒当たり100,000です。この数値を下回る範囲で統合作業を行えば、利用するお客様に影響はないとわかりました。

参考:AWS WAF クォータ

WAFリクエスト数の計測方法

検討した方法は2つです。

1. Athenaを使う方法

WAFのログをS3に保存しているので、Athenaを使って分析する。 Web ACLsの件数がリクエスト数に相当するので、1秒単位のログ件数を算出する。

2. CloudWatchの活用

リクエストに相当する以下のメトリクスの合計を利用する。

  • AllowedRequests
  • BlockedRequests
  • CaptchaRequests
  • ChallengeRequests

メトリクスの集計期間を工夫し、およそのリクエスト数を把握する。

検討した結果

Athenaを使う方法がより正確な数値を出せそうでしたので、今回はそちらを採用しました。 計測をした結果を元に、お客様をいくつかのグループに分け、リクエスト数が確実に上限を下回るよう統合を進める事になりました。

徐々に統合を進めていく

最初はかなり慎重に動きました。統合先となるWAFを新規作成して、まずは2社をWAFに統合し、1週間ほど経過観察を行いました。 Athenaを使った計測結果を元に、リクエスト数がおよそ2社の合計に収まっている事や、お客様の環境に変化がない事を確認しました。

ここまで確認が出来たら、あとはミスなく進めるだけでした。利用するお客様に合わせ、製品利用に影響のないスケジュールを立て徐々に移行していきました。 結果として、「お客様に提供する環境の品質を維持したまま」、「コスト削減のみ実現」できました。

まとめ

ひょんな閃きからWAFの統合について調査を始めましたが、運よく条件が重なり統合を行う事ができました。同じような課題をお持ちの方にとって、お役に立つ情報になりましたら幸いです。