こんにちは、大林です。JAWS-UG朝会 #63 で、「ガードレールの有用性とリスク対策」というタイトルで登壇してきました。ガードレールはアカウントを安全に運用する上で実装しておきたい仕組みですが、必ず理解しておくべきリスクもあります。本ブログでは、JAWS-UG朝会 #63で発表した内容を説明していきます。
- 発表資料
- アカウント運用のあるべき姿
- アカウント運用におけるコスト増加
- アカウント運用の自動化によって発生するリスク
- 小さく自動化を進める
- ガードレールの大量課金リスク
- ガードレールの大量課金リスク対策
- 大量課金リスクへの予防策
- まとめ
発表資料
アカウント運用のあるべき姿
上の図は、AWSアカウントを安全かつ効率的に運用するための4つのプロセス、「検知・通知」「調査・修正」「分析」「改善」を示しています。これらのプロセスを循環的に行うことで、継続的なセキュリティ強化と運用の効率化を実現します。
まず、「検知・通知」では、AWSガードレールを利用してポリシーからの逸脱やセキュリティリスクを検出し、即座に通知を行います。次に、「調査・修正」では、通知された内容を確認し、問題の原因を特定してリソースや設定の修正を行います。
その後、「分析」のフェーズで、検知された問題の傾向や頻度を分析し、繰り返し発生している根本的な原因を把握します。
そして最後に、「改善」では、分析結果を踏まえて具体的な対策を実施し、同じ問題が再発しないよう運用ルールやシステム設定を見直します。
このように、単発的な修正ではなく、改善サイクルを回し続けることで、セキュリティリスクを削減し、安定したAWSアカウント運用が実現されます。
アカウント運用におけるコスト増加
理想的な運用を目指してAWSアカウントの管理や改善を進める際に、意図せず運用負荷が増加してしまう場合があります。「理想」では効率的でコスト削減につながる運用を描いていますが、「現実」では運用が複雑化し、必要な人材やコストの増加に直面することが多いというギャップが存在します。この課題を克服するための一つのアプローチとして、自動化の仕組みを導入することが考えられます。
アカウント運用の自動化によって発生するリスク
自動化の一例として、AWS WAF（以下 WAF）の自動化に伴うリスクについて説明します。この仕組みは、WAFのログを分析し、例えば異常なリクエスト頻度のIPアドレスを自動的にIPセットに登録するものです。
この仕組みのプロセスは、Amazon EventBridge（以下 EventBridge）でAWS Step Functions（以下 StepFunctions）を起動させ、Step Functions内のLambda関数でAmazon AthenaのAPIを実行してAmazon Simple Storage Service（以下 S3）に保存されたログをクエリで分析し、IPセットを更新する流れを示しています。この自動化により、これまで手作業で行われていたIPリストの更新を効率化し、人材が他の重要なタスクに時間を割けるようになります。
しかし、自動化された処理が意図しないIPアドレスを誤ってブロックしてしまうインシデントが発生する可能性があります。その結果、インシデント対応に追われて、人手不足になったり、お客様からの信用を失うことになります。そのため、自動化は小さく始めていく必要があります。
小さく自動化を進める
WAFのIPセットを更新するプロセスにおいて、「小さく自動化を進める」アプローチを説明します。具体的には、遮断対象のIPアドレスを運用担当者が判断した上で、手動でそのIPリストをS3にアップロードするところまでを人間が行い、それ以降の更新作業は自動化する仕組みを構築する方法です。このプロセスでは、EventBridgeがS3へのアップロードイベントを検知し、Step Functionsをトリガーします。Step Functions内ではLambda関数を活用して、アップロードされたリストを元にWAFのIPセットを更新します。さらに、更新作業の結果はAmazon SNSを通じて運用担当者に通知される仕組みになっています。
この方法により、人間が関与するのは判断と初期入力の部分に限定されるため、効率化が図れるうえに、誤ったIPアドレスを登録するリスクを最小限に抑えることができます。また、完全自動化ではなく運用担当者の判断を残すことで、信頼性と柔軟性を確保することができます。
ガードレールの大量課金リスク
AWS Config（以下 Config）は便利ですが、「大量課金リスク」が潜んでいます。Configは環境で繰り返されるリソースの作成や削除を逐一検知し、課金が発生する仕組みです。
特に、IaCを利用している環境では、コードの変更やデプロイのたびにリソースが再生成されるケースが多く、Configがそのすべてのイベントを監視するためにコストが増加しやすい状況が生まれます。この問題により、Configの利用が予想以上に高額な課金を引き起こす可能性があります。例えば、ECSクラスター内で頻繁にコンテナを作成・削除する場合、それに関連するVPCやサブネット、セキュリティグループなども含めてConfigの監視対象となるため、コストが急増します。
ガードレールの大量課金リスク対策
Configの記録頻度に関するコストとセキュリティのバランスをどう取るべきかについて説明します。Configの記録頻度を「継続的な記録」に設定すると、詳細なリソース変更をリアルタイムに監視できるため、セキュリティ水準を高めることができます。しかし、その分コストが大幅に増加する可能性があり、特に開発環境など頻繁にリソースが作成・削除される環境では注意が必要です。
この問題を解決するためには、Configの記録頻度を「日次記録」や特定のリソースタイプに限定してオーバーライドする方法が最適です。マルチアカウント構成においては、組織全体では「継続的な記録」を維持しつつ、コストが高くなる特定のアカウントに対してのみ設定を変更すると、セキュリティを高い水準に保ちつつ、ある程度の柔軟性を確保することができます。一方で、記録頻度を「日次記録」にや特定のリソースタイプに限定してオーバーライドすると、Configの検知が遅れるリスクが発生するため、そのリスクを受容する必要があります。
大量課金リスクへの予防策
Configなどのガードレール導入時における大量課金リスクに対する継続的な対応策を3つ挙げて説明していきます。
まず1つ目は、AWS Budgetsを利用して予算を設定することです。アカウント全体や特定のサービスごとに予算を設定し、コストが予算を超過しそうな場合には通知を受け取ることで、早期に対応が可能になります。これにより、想定外のコスト増加を未然に防ぎます。
2つ目は、AWS Cost Explorerを使用してコストの推移を定期的に分析することです。月次や日次のコストデータを視覚化することで、どのサービスが主なコストの要因になっているのかを特定できます。特にConfigの利用に関連するコストが急増していないかを確認することで、効率的なリソース管理が可能となります。
最後に、Amazon CloudWatchを活用して、具体的なメトリクスを監視することが推奨されています。例えば、Configがどのリソースタイプを頻繁に記録しているかを分析することで、記録頻度の調整や不要なリソースの監視対象からの除外といった改善アクションにつなげることができます。
まとめ
AWSをより多くの人に安全に利用してもらうため、このブログ記事を執筆しました。
AWSは多彩なサービスを提供し、継続的なアップデートで進化を続ける非常に有用なクラウドプラットフォームです。しかし、安全に利用するためには「ガードレール」の実装が欠かせません。
一方で、ガードレールの導入にはコスト増加のリスクが伴う場合があります。ただし、コストの増加は必ずしも悪いことではありません。重要なのは、統制と柔軟性を両立させながら、ケースに応じたセキュリティとコストの最適なバランスを追求することです。このブログで紹介した内容が、皆様のAWS運用の一助となれば幸いです。
