ログ監視の最適化ポイント

はじめに

こんにちは。hisadonです。
今回はAWSにおけるログ監視の最適化ポイントをご紹介します。

そもそもログ監視とは？

ログを監視する目的は、システムの異常を検知する、もしくは未然に防ぐこと、原因を分析することです。
障害調査を目的としたログ監視の他に監査対応を目的としたログ監視も必要です。

AWSにおけるログの全体像

AWSサービスが出力するログの流れは以下となります。
集約したいログをログ保管(S3推奨)に集約し、目的に合わせて加工や発信、分析をしていく形となります。

ログを1箇所に集約するメリット

業務目的に応じて、必要となるログは1箇所に集めます。
考えられるメリットは以下となります。

• 監査・セキュリティ対応の効率化
  ログを複数アカウントや複数サービスに散在させず、一括して保管することで、監査ログの収集や不正アクセス・障害のトラブルシューティングが迅速に行える。セキュリティインシデントの際、単一の集約先から該当期間・該当リソースのログをすぐに抽出できる。
• 可観測性・分析の向上
  すべてのログが一元管理されていれば、ログ解析ツール（Amazon Athena、Elasticsearch/Splunk など）やダッシュボードで横断的に分析しやすい。複数アカウント・複数リージョンにまたがるシステムであっても、相関分析をシンプルに実施できる。
• 運用コストと管理工数の削減
  クラウドストレージ（S3 など）を活用する場合、ライフサイクルポリシー、データ圧縮・アーカイブを一括で運用可能。各アカウントごとに分散管理する場合と比べ、ポリシー変更やアクセス権限の設定を集約側だけに反映すればよいケースが多い。
• 統一的なログポリシー・ライフサイクル管理
  ログ保存期間、ローテーション、改ざん防止（WORM 領域を利用するなど）のルールを、全アカウント・全サービスにまたがって共通化しやすい。ログの保存期限が来た際の削除・アーカイブ作業を一括で制御できる。
• コンプライアンス準拠が容易
  PCI DSS や ISO 27001 などの基準では、監査ログの安全な保管や改ざん防止の要件がある。ログ集約先として、専用アカウント（セキュリティ部門向け）や独立したセキュリティ管理を適用することで、認証・可用性・監査要件を満たしやすい。
• 権限設計を単純化しやすい
  ログ閲覧や検索を行う担当者に対して、集約先アカウントのバケット（あるいはログ収集基盤）だけにアクセス権を付与すれば済む。各アカウントごとの個別ロール設定よりも、中央管理がしやすい。
• 一貫したメトリクス・アラート運用
  CloudWatch Metrics やアラーム、SIEM などのセキュリティツールを「ログ集約先」で集中的に設定し、全リソースのメトリクス監視を統一できる。新しくアカウントやサービスが増えても、ログ転送設定を行うだけで既存の監視・アラートルールに組み込める。
• 将来的な拡張に備えやすい
  新しいサービスやリソースを追加する際、既存の「ログ集約基盤」へ設定を追加するだけで対応できる。大規模化しても一貫性を保ちやすく、全体を俯瞰しながらログの容量計画・コスト管理が可能。

非機能要件で検討するログのポイント

• ログの取得範囲
• ログの保存期間
• ログの保存先
• ログのフォーマット
• ログのセキュリティ・改ざん防止
• ログの分析方法
• ログの可用性・耐障害性
• 保存先のパフォーマンス要件
• 運用における変更管理プロセス
• コンプライアンス・法規制

ログ監視設計で選定する際の評価軸

• 機能観点
  ログの対象範囲や分析・可視化、アラート設定などがどの程度充実しているか。
• 非機能観点
  高可用性・耐障害性、セキュリティ強度、パフォーマンスなどの品質要件を満たせるか。
• コスト
  ライセンス費やサポート費などの総費用と、運用管理の工数を含めたTCOは適切か。
• 将来性・拡張性
  ロードマップやDR対応、コミュニティサポートなど、長期的な拡大や変化への対応力が十分か。
• セキュリティ
  セキュリティ要件は守るべき項目が非常に多く、AWSでは実現する手段も豊富にあります。

個人的に経験したログ集約による失敗談

• 失敗談1
  必須要件がない中でログ集約を設計に組み込んだ結果、思ったよりも料金高騰に繋がってしまった。
• 失敗談2
  目的を持たせたものではあったものの、どのログをどの程度集約させるのか都度判断になり苦労してしまった。
• 失敗談3
  マルチアカウント先で復旧アクションとしてEC2の再起動を組み込もうとした際、マルチアカウントでは機能を提供していない事が判明し手戻りが発生した。
  ログ集約先のマルチアカウント先でアラート発報、アクションを実施していくことになるので仕様を事前に確認する必要がありました。
• 失敗談4
  マルチアカウントになるとアクセス設計が複雑すぎて、構築に時間を要してしまう。
  勉強不足な部分はチーム内で課題提起して解決してく必要がありました。

まとめ

本記事では、ログ監視の最適化ポイントを一部解説しました。まだまだ奥が深く、料金高騰にも繋がりやすい領域なので難しいポイントが多いです。
本記事がログ監視に悩んでいる方の助けになりましたら幸いです。

hisadon