はじめに
お疲れ様です。技術本部リードセキュリティエンジニアの田口です。
ここ数年でAWSのセキュリティ関連の機能が増えてきており、良い時代になったと感じます。しかしセキュリティと利便性・コストの兼ね合いで頭を悩ませることが多くなったセキュリティ担当者さんも多いでしょう。
今回は、セキュリティのコストに頭を抱える皆様に向け、大規模にEC2オートスケーリングを利用しているAWSアカウントにおいて、
AWS Configのコストを抑えつつセキュリティチェックを実施した取り組みについて紹介します。
「セキュリティチェックをしたいが、AWS Configのコストがネックで有効化に踏み切れない」という方の参考になれば幸いです。
背景:セキュリティチェック実施のモチベーション
当社では、大規模なオートスケーリングを行うAWSアカウントを運用しています。このアカウントでも定期的なセキュリティチェックの仕組みを整備したいというモチベーションから、検討を始めました。
セキュリティ対策を継続的にアップデートしていきたいと考え取り組みました。また、セキュリティの話題を通じて定期的にコミュニケーションを取り、関係値を構築していきたいという狙いもありました。
課題:AWS Configのコストが壁になった
AWSでセキュリティチェックを行う標準的なアプローチとして、Security HubとAWS Configの組み合わせがあります。Security Hubがセキュリティ基準に基づいたチェックを実行し、AWS Configがリソースの構成情報を記録・評価する構成です。
しかし、このアカウントでは大きな壁がありました。AWS Configのコストです。
EC2のオートスケーリングでは、インスタンスの起動と終了が頻繁に発生します。AWS Configはリソースの変更を検知するたびに記録するため、インスタンスの起動→終了で1つの設定変更イベントとして記録されます。大規模なオートスケーリング環境では、まさに「塵も積もれば山となる」でコストが暴騰してしまいます。
試算では、AWS ConfigとSecurity Hubを常時有効化した場合、月額約1〜3万ドルものコストが発生する見込みでした。これではとても有効化に踏み切れません。
解決策:コストを抑える3つの工夫
コストの問題をクリアするために、3つの工夫を組み合わせました。
1. チェック方式の使い分け（逐次チェック vs 日次チェック）
AWS Configのルール評価には、リソース変更時に即座に評価する「逐次チェック」と、1日1回まとめて評価する「日次チェック」の2つの方式があります。
もともとは全てのルールを逐次チェックで設定していましたが、以下のように使い分けることにしました。
| チェック方式 | 対象 | 理由 |
|---|---|---|
| 逐次チェック | EC2関連のルール | インスタンスの変更を即座に検知する必要がある |
| 日次チェック | EC2以外のルール | 変更頻度が低く、日次で十分 |
EC2以外のリソース（S3、IAM、RDS、VPC、Security Groupなど）は基本的に静的で、設定変更は人手による意図的な操作がほとんどです。
また、今回のセキュリティチェックの目的はある時点でのセキュリティ状態のスナップショットを取ることであり、リアルタイムの継続的監視ではありません。
24時間の限定ウィンドウ内でこれらのリソース設定が変わる可能性は極めて低く、逐次チェックにしても日次チェックにしても結果はほぼ同じになります。
そのため、EC2以外は日次チェックで十分と判断しました。これにより、不要な評価回数を削減できました。
2. Config / Security Hubのスポット有効化
常時有効化するのではなく、事前に日時を決めて24時間だけ有効化する方式を採用しました。
通常時はAWS ConfigとSecurity Hubが無効の状態で運用し、セキュリティチェックを実施するタイミングでのみ有効化します。いわば「スポットチェック」のような運用です。
このアプローチにはメリットとデメリットがあります。
メリットとしては、常時有効化で月1〜3万ドルかかるコストを劇的に抑えられる点です。そもそもコスト面で有効化できなかった環境にセキュリティチェックを導入できるようになりました。また、実施タイミングと期間が決まっているため、1回あたりのコストが見積もりやすいという利点もあります。
一方で、デメリットも存在します。
- チェック実施日以外はセキュリティ上の問題を検知できない。チェックとチェックの間に発生した設定変更や脆弱性を見逃すリスクがある。
- Configが無効な期間のリソース変更は記録されないため、「いつ・何が変わったか」の追跡ができない。
- 有効化・無効化を手動で行うため、タイミングのミスや作業忘れが起こりうる。
- 常時有効でないと、Config Rules + SSM Automationなどによる自動修復の仕組みが使えない。
これらのデメリットに対しては、以下のように対応しています。
2については、チェックの際にAWS CLIからAPI経由で検出結果を取得し、BigQueryに蓄積しています。そのデータを元にダッシュボードを作成し、チェックごとの脆弱性の増減を把握できるようにしています。Configの記録自体は残らなくても、セキュリティ状態の変化を追跡する手段は確保しています。
3については、今後有効化・無効化の自動化を行い、ミスや作業漏れを減らすことを検討しています。
4については、自動修復の仕組みは現時点では導入していませんが、報告会を通じて開発側に検出結果を共有し、対応してもらう運用で補っています。
これらのトレードオフを理解した上で、コスト制約が大きい環境ではスポット有効化が現実的な選択肢になると考えています。
3. EC2関連チェックの時間制限
当初は24時間の有効化でチェックを行っていましたが、それでもEC2のオートスケーリングによるコストが無視できませんでした。
そこで、EC2関連の調査は2時間に絞ることにしました。EC2以外のリソースは24時間の間にチェックし、EC2関連は2時間の短い時間枠で集中的にチェックを行います。
EC2 等特定のリソースを AWS Config のチェックから除外する方法については以下の記事に記載されています。
AWS Config のコスト最適化に関する推奨事項 | AWS クラウドオペレーションブログ
コスト効果
3つの工夫を組み合わせた結果、コストを大幅に削減できました。
| 方式 | 月額コスト |
|---|---|
| 常時有効化（試算） | 約1〜3万ドル |
| 工夫前（24時間有効化） | 約500ドル |
| 工夫後（日次チェック + スポット有効化 + EC2は2時間） | 約100ドル台 |
常時有効化と比較すると99%以上の削減、工夫前と比較しても約80%の削減を実現しています。
運用の実際
現在の運用フローは以下の通りです。
- 事前に実施日を先方に連絡する
- 実施日にAWS ConfigとSecurity Hubを手動で有効化する
- EC2関連のチェックを2時間実施する
- EC2以外のチェックを24時間実施する
- チェック結果を確認し、先方にフィードバックする
有効化作業は現時点では手動で実施しています。コストが掛かる作業のため、慎重に進める必要があるからです。
先方もセキュリティチェックにはポジティブに捉えてくれており、発見された脆弱性への対応にも積極的に取り組んでいただいています。当初の狙いでもあった「定期的にセキュリティの話ができる関係」が構築できたことは、技術面以上に大きな成果だと感じています。
失敗と学び
もちろん、すべてが順調に進んだわけではありません。
チェック方式や有効化タイミングのミス
チェック方式の設定や有効化のタイミングを誤り、ほしい情報が取得できなかったことがありました。また、想定以上にコストが発生してしまったケースもあります。
コストが掛かる作業だけに、やり直しのコストも大きく、慎重な運用が求められます。
今後の改善
現在は手動で行っている有効化作業を自動化し、取りこぼしやヒューマンエラーをなくしていきたいと考えています。
応用可能性
今回のアプローチは、AWS Configの記録が大量に発生するケースであれば応用が可能です。
EC2のオートスケーリングに限らず、リソースの変更が頻繁に発生する環境であれば、同様に「スポット有効化」や「チェック方式の使い分け」が有効な選択肢になるでしょう。
大規模なAWSアカウントを運用している他社がどのように対応しているか、調査してみるといくつかの事例が出てきますので、組み合わせて最適解を探ってみてください。
おわりに
「AWS Configのコストが高いからセキュリティチェックができない」という課題に対して、
チェック方式の使い分け・スポット有効化・時間制限の3つの工夫を組み合わせることで、コストを大幅に抑えつつセキュリティチェックを実現しました。
コスト制約があるからといってセキュリティを諦める必要はありません。工夫次第で、限られた予算の中でもセキュリティレベルを向上させることは可能です。
今後は有効化作業の自動化に取り組み、より安定的かつ効率的な運用を目指していきます。
最後までお読みいただき、ありがとうございました。
