CloudWatchログのコストが負担になるとき、OpenSearchを直接構築する選択は正しいのか？

6月 20, 2026

—

cslab

in IT Security

AWS環境でログを収集する場合、最初はほとんどの人がCloudWatch Logsを使用します。

設定が簡単で、AWSサービスと自然に連携し、アラームやLogs Insightsのような機能もすぐに利用できるためです。

しかし、ログ量が増え始めると話は変わってきます。

特に、アプリケーションログ、コンテナログ、ウェブサーバーのアクセスログ、VPC Flow Log、WAFログのように大量に蓄積されるログをすべてCloudWatch Logsに入れると、コスト負担が急速に増大する可能性があります。

現場で「CloudWatchのログコストが高いからOpenSearchを別途使っている」という話が出るのも、まさにこの点です。

CloudWatchで高く感じる部分

多くの人がCloudWatchのコストを「保管費用」とだけ考えています。

しかし、実際に負担が大きくなるのは、通常、ログを初めてCloudWatch Logsに入れる際の取り込み費用です。

つまり、ログがCloudWatch Logsに入った瞬間にGB単位の課金が発生します。

その後、そのログをLambda、Firehose、OpenSearch、S3などに転送すると、ダウンストリームの費用も追加される可能性があります。

構造を見ると次のようになります。

애플리케이션 로그
  → CloudWatch Logs
  → Subscription Filter / Lambda / Firehose
  → OpenSearch 또는 S3

この構造では、CloudWatch Logsの取り込み費用を一度支払った後、再度他のサービスの費用を負担することになります。

そのため、コスト最適化の観点からは、CloudWatchを必ず経由する方式が常に良い選択とは限りません。

そこでOpenSearchに直接送る構造が登場する

大量ログ環境では、次のような構造がよく検討されます。

EC2 / ECS / EKS / 온프레미스
  → Fluent Bit / Vector / Logstash
  → OpenSearch

または、長期保管まで考慮すると、次のように分けることができます。

최근 검색용 로그
  → OpenSearch

장기 보관용 로그
  → S3

こうすることで、すべてのログをCloudWatch Logsに入れる必要がなくなります。

CloudWatchは、必要な運用指標、アラーム、一部のコアログを中心に利用し、大量検索用のログはOpenSearchやS3を中心に分離する方式です。

しかし、Amazon OpenSearch Serviceも高価である

問題は、Amazon OpenSearch Serviceも安価なサービスではないという点です。

OpenSearchは基本的に常時稼働するクラスター構造です。

データノード、マスターノード、ストレージ、スナップショット、マルチAZ構成を考慮すると、固定費用はかなり大きくなります。

ログ量がそれほど多くないのにマネージドOpenSearch Serviceを運用すると、CloudWatchよりもかえって高く感じられることがあります。

そのため、一部の組織ではAmazon OpenSearch Serviceの代わりにEC2に直接OpenSearchをインストールして運用することもあります。

EC2に直接OpenSearchを構築すると本当に安価なのか？

単純なインフラ費用だけを見ると、EC2での自己構築方式の方が安価に見えるかもしれません。

例えば、マネージドサービスの費用ではなく、EC2インスタンスとEBSの費用だけを負担すれば済むからです。

しかし、ここには隠れたコストがあります。

自己構築方式では、以下を直接管理する必要があります。

- OpenSearch 버전 관리
- 보안 패치
- JVM 튜닝
- 샤드 설계
- 인덱스 rollover
- 디스크 워터마크 관리
- 장애 복구
- 스냅샷 백업
- TLS / 인증 / 권한 설정
- 노드 증설 및 축소
- 멀티 AZ 구성

運用人員が十分で、ログプラットフォームの運用経験がある場合、EC2での自己構築はコスト削減効果があるかもしれません。

しかし、運用負担まで考慮すると、単に「EC2が安い」と結論付けるのは難しいです。

現実的なログアーキテクチャ

実務では、通常、一つのサービスですべてのログを処理するのではなく、目的に応じて分けます。

CloudWatch
  → 알람, 주요 운영 로그, AWS 네이티브 모니터링

OpenSearch
  → 최근 로그 검색, 장애 분석, 대시보드

S3
  → 장기 보관, 감사 대응, 저비용 아카이빙

この構造は、コストと運用利便性のバランスを取るのに適しています。例えば、直近30日または90日のログはOpenSearchに保存して高速に検索し、それ以降のログはS3に移行して長期保管する方式です。

CloudWatchにはすべてのログを入れるのではなく、アラームと運用に必要なコアログのみを残すように最適化できます。

どの選択が正しいのか？

ログ量が少なく、AWSネイティブな運用利便性が重要であれば、CloudWatch Logsが最もシンプルです。

運用負担も少なく、アラームやダッシュボードとの連携も容易です。

しかし、ログ量がTB単位に増大すると、CloudWatch Logsにすべてのログを入れる構造はコスト負担が大きくなる可能性があります。

この場合は、OpenSearchやS3を併用する構造を検討するのが良いでしょう。

ただし、OpenSearchも無料ではありません。

マネージドOpenSearch Serviceは運用利便性が高い代わりにコストが高く、EC2での自己構築はインフラ費用は抑えられますが、運用責任が大きくなります。

結論

「CloudWatchが高いからOpenSearchを使う」という言葉はある程度事実です。

ただし、正確には「大量のログをすべてCloudWatch Logsに入れる構造が高価になる可能性があるため、検索用ログと長期保管ログを分離する」という表現がより適切です。

また、「OpenSearch Serviceが高いからEC2に直接OpenSearchを構築する」という話も現実には出てくる可能性があります。

しかし、この選択は運用人員と障害対応能力がある場合にのみ可能な方式です。

最も現実的な結論は次のとおりです。

CloudWatch는 운영 알람과 핵심 로그 중심으로 사용하고,
OpenSearch는 최근 로그 검색과 분석용으로 사용하며,
S3는 장기 보관과 감사 대응용으로 분리하는 것이 좋다.

ログプラットフォームは、単に収集がうまくいけば良いという領域ではありません。

コスト、検索性能、保管期間、障害対応、セキュリティ、運用人員までを総合的に考慮する必要があります。

したがって、最初はCloudWatchを中心にシンプルに開始し、ログ量が増大する時点からはCloudWatch、OpenSearch、S3を目的別に分離する戦略が必要です。