S3アクセスログを同じバケットに保存する際の落とし穴
AWS の公式ドキュメントなどを読んで、それを実践している方はS3バケットを作成する際に「用途別にS3バケットを用意する」という考え方はベスト・プラクティスとは言わないまでも「当たり前の作法」のようになってて、あまり意識せずとも実践されていると思います。
しかし、その一方で「S3バケットが増えるとその管理コストが増えるので、できるだけ管理対象を減らしたい」というインフラの管理者としての要求もあると思います。そうしたとき、「S3のアクセスログはそれと同じバケットに保存してしまえば管理対象が減らせて良いのでは？」 という発想に行き着くことがあります。
この記事では、そのような設定がもたらす運用面での問題を具体的に例示し、なぜそれがいけないのかをAWS初級者向けに説明した記事です。
前提
- バケットは、ACLが有効となっている。
- バケットには、画像やCSSなどのアセットが格納されており、Webアプリケーションから直接参照されている。
- バケットに格納されるアクセスログは、ACLによってアクセス可能なAWSアカウントが制限されている。
※要するにACLで公開・非公開の制御は行っているため、セキュリティ的な懸念については取り上げないということです。[1]
問題点1.バケットへのログの格納自身がログとして記録されてしまう
外部公開しているS3バケットに、アクセスログの出力を設定する主な目的は、そのバケットが外部からどのようにアクセスされているかを分析する、という事があると思います。
しかし、バケット自身へのログの保存という行為そのものがログを発生させ、それが連鎖的にログを発生させ、無駄にログの行数が増えてしまい分析の妨げとなります。また、それを保存するコストも多少とはいえ無駄になります。
問題点2.不要なログの削除などバケットに対する破壊的変更が難しくなる
分析が終わった後に不要なログを削除する場合、それが大量になるとスクリプトなどを使って一括削除を行うことになると思います。
しかし、該当バケットに不要なファイルと重要なファイルが混在していると、絶対に消してはいけないファイルと消したいファイルが混在することになり、必要以上に作業の難易度が上がります。
DALL·E が生成したジェンガする人の図
ログの格納専用バケットを用意しておけば、そこに格納されているものが最悪消えたとしてもユーザーに提供しているサービスに影響することは無い、ということが確実になります。そうすることで作業の難易度が下がります。
問題点3.バージョニング設定の導入が難しくなる
バージョニング設定は、ファイルの変更や削除によるバケット内のファイルの変更履歴を管理して、いざと言うときに元に戻したりするような目的で導入します。
しかし、通常ログファイルについては出力されたあとその内容を変更することはありませんし、保持期間が過ぎて削除したあとにやっぱり戻したい、というような運用もほぼ想定されません。バージョニング設定とログの運用は相容れないケースが大半だと思われます。
ログファイルと通常のアセットについて、その利用目的が異なり運用方法も全く異なるものです。そうした場合、バケットを分けて管理するほうが運用がシンプルになるはずです。
まとめ
S3のアクセスログをログの発生元のバケットそのものに格納してしまう設定による問題点を３つ上げました。
AWSのドキュメントを読むとベストプラクティスや原理・原則といわれるものが記載されています。また、それも時間の経過とともに新機能の追加や機能の廃止などで日々変化していきます。
ベストプラクティスや原理・原則にはその時それなりの背景があります。場合によってはあえてそれを無視するというケースはあるとは思いますが、今の設定についてこれで良いのか？ほかに良い方法は無いか？について改めて見直すタイミングは必要かもしれないですね。
-
ACLの設定によって問題が出ていないからといって、外部公開用のバケットに非公開のファイルを格納することはお勧めしません。設定を一つ間違えると非公開であるべきファイルが簡単に公開できてしまうリスクと常に隣り合わせの状態だからです。 ↩︎
Discussion