初めて情報発信をするので、拙い箇所が多々あるかと思いますがご容赦ください。
AWS環境下でのログ基盤について考える機会があったので、備忘も兼ねて記事にします。
前提
- AWS環境
- ECS使用
- アプリケーションログの収集（アクセスログ、監査ログまでは取らない）
簡単な構成図（基本的なもの）
詳細
さっと作った構成図になりますが、一番手っ取り早くコストも抑えることができる選択肢の一つと考えています。
サイドカーコンテナとしてfluent bitを用いた構成であり、
ECSのタスク定義からログの出力先をfluent bitに指定し、fluent bitからS3へログ出力
その後S3のデータを元にGlueデータカタログを作成しAthenaから参照できるようになる
Firelensの設定値については割愛します。（そんな難しいものでもないので安心してください）
S3にはパーティション射影を用います。
これはAthenaの検索結果の高速化、ならびにコストを抑えるために用います。
※パーティション射影はS3のディレクトリを自動的にパーティション分けしてくれる便利な機能と思ってください
例）year=2024/month=10/day=23/hour=00 みたいなHive形式でS3出力するときに勝手にパーティション分けしてくれる
これでログの内容をAthenaから参照することはできる、はず
とは言ってもdev/staging/prodでAWSアカウントを分けていることが多いと思われますので、そういった場合に1つの案として下記提示しておきます。
※検証等していない頭の中で考えたものなので、うまく行かなかった場合の責任は取れません。
構成図（クロスアカウントでのログ基盤想定）
記載していませんが、Staging/prod共にECSからS3へのログ出力があると思ってください。
詳細
これはGlueデータカタログの共有を用いた方法を使って、DevアカウントからStag/Prodアカウントのログを見られる構成になります。
多分、S3のクロスアカウントを用いることでDevアカウントがstaging/prodのS3を元にしてデータカタログを作ることも可能だと思います。
個人的に環境による差異をできるだけ生み出したくないので、深掘りはしません…
（今回でいうとデータカタログがDevにだけあるけど、他には無いという状態）
メリット
- 逐一アカウントを切り替える必要がない
- Staging/prodアカウントにアクセスする権限は渡したくないけど、ログは見られるようにしたい場合
デメリット
- ログに見てほしくない内容が出力されている場合は運用を更に考える必要がある
（そんな内容ログに出すなとは思いますが）
以上、簡単なログ基盤を作ることがあったので気分転換として記載させていただきました。
ざっくりとしか書いてないので、ツッコミどころはあると思いますがあくまでこんなもんもあるんだなと思ってもらえると助かります。
余談ではありますが、CloudWatchLogsに一度吐き出してからDataFirehoseを用いてS3に転送する方法はコストがバカ高くなるのでオススメしません。