Amazon S3 Tablesでつくるアプリケーションログ分析基盤 - CloudWatch Logsからの移行によるコスト最適化 - - カミナシ エンジニアブログ

はじめに カミナシの共通ID管理基盤を開発しているmanaty（@manaty226）です。カミナシ ID管理基盤ではログストレージにCloudWatch Logsを使っていましたが、サービスの成長に伴いコストに悩んでいました。この記事では、私たちが実践したAmazon S3 Tables（以下、S3 Tables）を使ったログストレージの構築と移行、そのコスト最適化効果について書きます。 サービス成長に伴うCloudWatch Logsのコスト増大 Amazon CloudWatch Logs（以下、CloudWatch Logs）はAWSが提供するログの保管や分析のためのサービスです。多くの一般的な構成ではアプリケーションが出力するログをそのままCloudWatch Logsに保管し、何かあればCloudWatch Logs Insightsを利用してログをクエリしたり、特定のエラーロ

[itib]

CloudWatch Logs高いって思ったことある全人類に読んでほしい

[sora_h]

CloudWatch Logs 使い辛くてただ高いだけのサービスのまま10年やってて本当に凄いんだよな。前職でも捨てて何年もたつ……

[toricls]

CloudWatch Logs の Ingestion 料金に危うく殺されかけたところで手を打てた話です (合掌)

[kiririmode]

CloudWatch Logs は初期の正解だが成長後の全量ログ分析基盤としてはコスト構造が合わなくなる。S3 Tables はその逃げ道になるが、採用は“安いS3に置くこと”ではなく、ログをIcebergテーブルとして設計・運用する覚悟を持つこ

[mkusaka]

CloudWatch LogsからS3 Tables(Apache Iceberg)へ移行し、投入コスト8割以上削減とAthena化を実現した事例。

[everybodyelse]

他のログサービスと比較しても安いんかな。とりあえずログ検索できればいいならS3でもいいのか。

[Eiichiro]

Icebergほど分散する必要もないので、似たようなことを、duckDBベースでできないかなぁと検討中。ログ保存にお金かけたくないよぉ。

[kanikanidokokani]

ログは高くなる（だからバカみたいにログを吐かせるな）のはクラウド使う全人類の共通認識であるべき