当CloudWatch日志成本成为负担时，自行部署OpenSearch是正确的选择吗？

6 月 20, 2026

—

cslab

in IT Security

在AWS环境中收集日志时，大多数人最初都会使用CloudWatch Logs。

这是因为它设置简单，与AWS服务无缝集成，并且可以立即使用警报和Logs Insights等功能。

然而，当日志量开始增加时，情况就不同了。

特别是，如果将所有大量日志，如应用程序日志、容器日志、Web服务器访问日志、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本质上是一个持续运行的集群结构。

考虑到数据节点、主节点、存储、快照和多可用区配置，固定成本相当可观。

如果日志量不大，运营托管式OpenSearch Service可能会比CloudWatch感觉更昂贵。

因此，一些组织选择在EC2上直接安装和运行OpenSearch，而不是使用Amazon OpenSearch Service。

在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按目的分离的策略。