2026 亚马逊 OpenSearch Service 深度实战：托管域 / Serverless / S3 Vectors 三形态怎么选，真实价格、成本测算与避坑

Meta Description: 亚马逊 OpenSearch Service（AWS 国际版）2026 全解：托管域、Serverless、S3 Vectors 三种形态对比，us-east-1 真实单价、OCU 计费模型、36 个可用区域、配额硬限制、CLI 从 0 建域与向量搜索实战，附三场景月账单测算与七个坑。

30 秒结论：Amazon OpenSearch Service 是 AWS 的托管搜索引擎（OpenSearch / Elasticsearch 内核 + Dashboards + 向量检索 + 日志分析）。2026 年它有三条部署路径：托管域（Provisioned）按「实例小时 + 存储」计费，适合稳定负载；Serverless 按 OCU（本站采集的 us-east-1 口径 $0.24 / OCU·小时）计费，适合波峰波谷明显的日志与搜索；S3 Vectors 是新增的超低成本向量存储（官方称存储、写入与查询成本最高可降约 90%），专供 RAG。最关键的一条：OpenSearch 的官方定价页当前没有 with AWS Free Tier 每月免费额度列，也就是它不像 EC2 / Lambda 那样有「每月前 N 小时免费」的长期档，新账号能白嫖的只有免费计划的 $200 赠金（12 个月内用完）。所以「先建一个大域试试」在这项服务上会真金白银地花钱，务必先读本文第三节的起步姿势。

决策口诀：日志与搜索稳态用托管域、流量飘忽用 Serverless、只做向量检索用 S3 Vectors。动手前先想清楚「我的负载是平稳的还是有尖峰的」，这一句话就决定了账单量级。

关键词：Amazon OpenSearch Service、AWS OpenSearch 价格、OpenSearch Serverless、OCU 计费、OpenSearch 向量搜索、AWS 免费套餐、OpenSearch 区域与配额、AWS 日志分析、Elasticsearch 托管

一、先划边界：这篇讲什么，和你可能看过的相邻文章怎么分工

AWS 的数据栈里「能搜索、能存日志、能做分析」的服务有一大把，非常容易串台。先用一张表把边界钉死：

一句话边界：本文只讲 OpenSearch Service 本身——它是「开箱即用的托管搜索引擎」，你负责导入数据、建索引、查结果，AWS 负责集群运维、快照、升级与安全。上游的 ETL、流式接入、下下游的 BI 都不在这条线上，这也是本文与站内其他几篇的明确分工。

二、一张表看懂：三种部署形态的能力与计费差异

OpenSearch 最常见的困惑是「我到底该用托管域还是 Serverless」。二者不是新旧关系，而是两种负载形态的取舍：

读表结论：先判断负载形状——平稳就托管域（可控、可预留、能上冷层），尖峰就 Serverless（不为你闲置的算力付钱），只要向量就 S3 Vectors。三者还能混用：托管域承载主搜索，S3 Vectors 独立扛 RAG 的向量存储，是很常见的组合。

三、托管域：节点家族与存储层级，别一上来就选贵机型

托管域的成本 = 实例小时 加 存储。理解这两块就理解了七成账单。

节点分三类：数据节点（真正存数据、扛查询）、专用主节点（可选，负责集群元数据与选主）、以及数据节点的「温 / 冷」层级。生产环境官方推荐的做法是：数据节点跨 3 个可用区（3-AZ） 部署、数量取 3 的倍数、并配置 3 个专用主节点——多 AZ 能显著提升可用性，代价是要接受约 3 份数据的存储开销。

存储分四档（单价见下一节）：通用 SSD（gp2 / gp3）、Provisioned IOPS（对 IO 敏感的场景），以及两个「托管存储」——UltraWarm（把不常查的日志放到更低成本的存储，查询仍走同一入口）与 OR1 / 远程存储（数据同步写入 S3，本地只留缓存，云原生弹性更强）。冷热分层的意义：热层用 r6g / or1 扛查询，温层放历史日志，单 GB 存储单价能从 $0.122 级别降到 $0.024 级别。

起步姿势（重要）：不要用生产机型做第一次实验。t3.small.search 在 us-east-1 是 $0.036 / 小时，一个月满跑约 $26——这是全家族最便宜的入口，用来跑通索引、Mapping、Dashboards 再升级到生产机型，能省下大量「试错费」。t3 系列还有个硬限制：单个域最多 10 台 T2/T3 实例，所以它只适合起步，不适合生产规模。

四、真实单价表（US East 弗吉尼亚北部口径，2026-10 采集）

以下数字来自 AWS 官方 Price List API 的 AmazonES 报价（pricing.us-east-1.amazonaws.com），按小时与按 GB 逐一核对，不是「参考区间」：

常用数据节点（$ / 实例小时）

存储与 IOPS（$ / GB·月 或 IOPS·月）

Serverless / Ingestion / Direct Query 的 OCU：$0.24 / OCU·小时（us-east-1 口径，OCU = OpenSearch Compute Unit，一个 OCU 约等于一份 vCPU + 内存 + 相应加速资源）。Serverless 的托管存储同为 $0.024 / GB·月。

⚠️ 表中价格为 2026 年参考价，实际费用随区域和官方调价变动，请以 AWS 官网为准。同机型在不同区域单价不同，下表未列区域一律为 us-east-1。

五、Serverless：OCU 计费模型，什么时候它比托管域便宜

Serverless 把「选机型、定节点数」这件事整个抽走，只留下一个计费单位——OCU。真正决定贵不贵的是：你的负载在时间上有多「不平均」。

官方文档给过一个可直接对照的算例：从一个已经建好的域出发，用 Direct Query 把 CloudWatch Logs 的 VPC Flow Log 日志接入并做仪表盘，每月摄取 1440 GB，账单构成为——Direct Query 的 OCU 约 $3、Serverless 索引 OCU 约 $176、托管存储 约 $29、Search and Query OCU 约 $176，合计约 $384 / 月。这个算例的价值在于它把「钱花在哪」摊开了：索引与查询各占约 176 美元，存储只有 29 美元——和 CloudWatch Logs 的结论一样，摄取与检索才是账单主角，存储从来不是。

什么时候 Serverless 更划算：负载有明确峰谷（白天查询多、夜里几乎为零），或流量无法预测。什么时候托管域更划算：负载长期平稳、且你能做预留（Reserved Instance）压价——闲置的 OCU 在 Serverless 里同样按秒计费，而托管域稳态下的实例单价更容易用预留优化。

一个必须记住的细节：OCU 按小时计费、分到分钟粒度，但空闲时不消耗 OCU——这是 Serverless 相对按实例满跑的托管域最大的省法。相反，如果你的查询几乎 24 小时不停，Serverless 的 OCU 会一直挂着，直接和托管域的实例小时正面对打，这时要拿计算器比一比。

六、免费套餐真相：OpenSearch 没有「每月免费额度」，怎么省才是真的

这是最容易被旧教程误导的一点。OpenSearch Service 的官方定价页当前没有 with AWS Free Tier 列——也就是说它没有「每月前 750 小时免费」这类长期按服务免费档（对照：EBS、Amplify 等定价页是带这一列的）。能依赖的免费资源只有两处：

1. 账号级免费计划：新账号注册可获最高 $200 赠金，其中注册即得 $100、完成入门操作最多再得 $100，需在 12 个月内用完；免费计划本身最长 6 个月。这是新域「零成本跑通」的唯一正路。
2. 自动化小时快照免费：官方明确「自动快照不额外收费，快照免费存放在 OpenSearch 的 S3 桶中」——即快照不是另一个付费项，别被吓到。

省钱三招（按 ROI 排序）：第一，起步用 t3.small.search 加 gp3，把架构跑通再升级；第二，上冷热分层，历史日志进 UltraWarm / OR1（$0.024 / GB·月 量级），热层只留最近数据；第三，稳态负载买预留实例（Reserved Instance，1 年 / 3 年承诺）——OpenSearch 支持 RI，折扣按机型与区域在控制台查看，长期跑的生产域用 RI 通常是最直接的一刀。

还有一条隐性成本要提防：版本扩展支持（Extended Support）附加费。官方说明，2026-11-07 起，对仍运行已到 EOL 版本的域，扩展支持附加费「等于你的实例成本（在实例成本之上叠加）」，存储费不受影响。也就是说，一个长期不升级的域，实例费可能直接翻倍。把「定期升级版本」当成一项成本控制，而不是可选项（详见第十二节）。

七、数据怎么进来：OpenSearch Ingestion / 零 ETL / Logstash 三条路

理解了「存哪」，还要回答「数据怎么进去」。这一层独立计费，很多人第一次看账单会懵。

路线 A，OpenSearch Ingestion（托管管道）：AWS 提供一个托管的管道服务，你写一段 pipeline 配置（源 → 处理器 → Sink），它替你持续把数据从 S3、DynamoDB、CloudWatch Logs、Kinesis、MSK 等源灌进托管域或 Serverless 集合。计费按 OCU·小时，和 Serverless 是同一个单位（us-east-1 口径 $0.24 / OCU·小时），你不再需要自己运维一套 Logstash 集群。

路线 B，零 ETL（DynamoDB → OpenSearch）：这是省心度最高的一条。官方在账号内自动建一条 OpenSearch Ingestion 管道，把 DynamoDB 表的数据在写入后数秒内同步到托管域或 Serverless 集合，还会理解表结构并引导式地用现有数据初始化索引，之后表的更新继续自动同步、无需人工干预。它解决的是「运营库与搜索库双写不一致」这个经典痛点。

路线 C，传统方式：Logstash、Kinesis Firehose、或直接调 _bulk API。适合已经有一支 ELK 团队、想复用既有脚本的场景。

一条纪律：接入层的 OCU 与存储层的实例小时 / OCU 是两笔独立的钱。做成本测算时别只算域，忘了管道。

八、安全与网络：VPC 端点、三重加密与细粒度权限

日志与检索里往往有敏感数据，安全配置不是可选项。

网络形态二选一：公网端点上手简单，但必须叠加访问策略与 IP 限制；VPC 端点让流量完全不出 VPC，生产域强烈建议。相关 CLI 命令：create-vpc-endpoint、describe-vpc-endpoints、list-vpc-endpoints-for-domain、authorize-vpc-endpoint-access、revoke-vpc-endpoint-access。

三重加密：① 传输中——开启 --node-to-node-encryption-options Enabled=true，节点间流量加密；② 静态——--encryption-at-rest-options Enabled=true，数据通过 KMS 密钥加密落盘；③ 端点走 HTTPS。

权限两层：IAM 策略负责「域级」访问（谁能调 API、谁能读域）；细粒度访问控制（FGAC）负责「数据级」访问（文档级、字段级、索引级），并支持用 SAML / AD / Cognito 登录 OpenSearch Dashboards。建域时用 --advanced-security-options 一并开启 FGAC 与加密。

一条纪律：内网生产域务必凑齐「节点间加密 + 静态加密 + FGAC」三件套；公网域额外加 IP 白名单与最小权限访问策略。

九、实战一：用 CLI 从 0 建一个生产域

下面是从零到「能查」的最小路径。命令用 AWS CLI 的 opensearch 命名空间，步骤说明放在代码块外，避免把注释写进命令行。

第 1 步，确认可用机型与配额：先看你要的机型在当前区域是否可用、是否触到账号配额。常用命令是 describe-instance-type-limits（查机型上限）与 list-domain-names（列出已有域）。

aws opensearch describe-instance-type-limits --engine-version OpenSearch_2.11
aws opensearch list-domain-names --region us-east-1

第 2 步，创建域：关键参数是数据节点数、机型、存储、专用主节点数与部署 AZ 数。下面的例子建一个 3 数据节点、3 主节点、多 AZ 的生产域，存储用 gp3。

aws opensearch create-domain \
  --domain-name my-logs-domain \
  --engine-version OpenSearch_2.11 \
  --cluster-config InstanceType=r6g.large.search,InstanceCount=3,DedicatedMasterEnabled=true,DedicatedMasterType=c6g.large.search,DedicatedMasterCount=3,ZoneAwarenessEnabled=true,ZoneAwarenessConfig={AvailabilityZoneCount=3} \
  --ebs-options EBSEnabled=true,VolumeType=gp3,VolumeSize=100 \
  --node-to-node-encryption-options Enabled=true \
  --encryption-at-rest-options Enabled=true \
  --region us-east-1

第 3 步，查创建进度与健康：describe-domain-change-progress 看创建进度，describe-domain-health 看健康状态，describe-domain 看最终配置与端点。

aws opensearch describe-domain-change-progress --domain-name my-logs-domain
aws opensearch describe-domain-health --domain-name my-logs-domain

第 4 步，加访问策略与细粒度权限：生产域一定要开节点间加密与静态加密（上面的参数已开），再用 update-domain-config 调整访问策略；用户级权限走 FGAC（见第八节）。

第 5 步，灌数据、建索引：数据可以通过 OpenSearch Ingestion、Logstash、或直接走 _bulk API；索引与文档级操作用 create-index / get-index 管理。到这一步，你的域就能在 OpenSearch Dashboards 里查询了。

日常运维常用命令：describe-domain-auto-tunes（看自动调优）、list-domain-maintenances 与 start-domain-maintenance（看 / 启动维护窗口）、start-service-software-update（打补丁）、upgrade-domain（版本升级）、describe-reserved-instance-offerings 与 purchase-reserved-instance-offering（预留实例，见第六节）。

十、实战二：向量搜索（k-NN）与 RAG 接入

2026 年 OpenSearch 最热的用法是向量检索——把文本 / 图片转成向量存进去，按「语义相近」而非「关键词命中」来搜，这正是 RAG（检索增强生成）的检索层。三条实现路线：

路线 A，托管域做 k-NN：在建索引时把向量字段声明为 knn_vector，写入时把 embedding 一并存进文档，搜索时用 k-NN 查询。适合「已经在用 OpenSearch 做日志 / 搜索，顺便加一层语义检索」的场景，一个集群两用。

路线 B，Serverless 的向量集合：Serverless 原生支持向量搜索集合，不用管节点与分片，按 OCU 计费。适合向量检索流量波动大的团队。

路线 C，S3 Vectors：把向量的「存储」与「查询」从集群里拆出来，官方定位是「以最高约低 90% 的成本提供弹性、持久的向量存储」，计费按写入 GB + 存储 + 查询三块走。适合「只要向量底座、不想为集群付费」的纯 RAG 场景。若你已经在用 Bedrock 做生成侧，S3 Vectors 常是最省钱的检索底座。

配 RAG 时的两个连接点：一是语义增强——OpenSearch 提供 Automatic Semantic Enrichment（自动语义富化），按 OCU 计费，官方口径是一个 OCU 约处理 45 MB（约 1,110 万 input token）英文内容或 30 MB（约 730 万 token）多语内容，空闲不计费；二是零 ETL 同步——DynamoDB 与 OpenSearch 之间的 zero-ETL 集成（见第七节），运营库写入后数秒内即可搜到。

一句提醒：向量检索的成本模型和关键词检索完全不同——向量索引的存储与查询按「平均向量大小 × 向量数」计价，维度越高、数据越多，查询的数据处理费越高（超过一定规模后进入更低单价档）。设计 embedding 维度时要同时算「效果」和「账单」，别默认用最高维。

十一、区域、端点与配额：动手前必须知道的硬限制

区域：OpenSearch Service 官方端点页列出 36 个区域，含 ap-east-1（中国香港）、ap-east-2（中国台北）、ap-southeast-7（泰国）、mx-central-1（墨西哥）、ca-west-1 等较新的站点，以及 2 个 GovCloud 区域；us-west-1（北加州）是唯一只支持 2 个 AZ 的区域，做 3-AZ 或多 AZ 待命部署时要避开它。华人用户想就近低延迟，香港 ap-east-1 是可用的最近选择。

配额（每账号每区域，多数可提额）

三个容易忽略的硬限制：① 单域总存储上限 3 PiB，且是数据节点与温节点的合计——超大规模日志栈要提前规划分域；② T2 系列单域最多 10 台，所以 t3 只做起步；③ 专用主节点上限 5 台，3 台是生产惯例，不必纠结更多。

十二、版本与升级：别让 EOL 附加费把账单翻倍

OpenSearch 的版本治理直接影响成本，这一节值得单独记。

当前主流引擎是 OpenSearch 2.x / 3.x；Elasticsearch 兼容模式停在 7.x 世代。官方对老版本提供了一段「扩展支持」缓冲：Elasticsearch 1.5、2.3、5.1–5.6、6.0–6.7、7.1–7.8，以及 OpenSearch 1.0–1.2、2.3–2.9 的安全与补丁覆盖延续至 2027-11-07。

费用变化是本节的要害：从 2026-11-07 起，对上述版本，扩展支持附加费等于你的实例成本（在实例成本之上叠加），存储费不受影响——即一个长期停在 EOL 版本的域，实例费直接翻倍。而扩展支持一旦彻底结束，域会被隔离、数据只保留至少 30 天，此后只能把数据恢复到受支持的新版本域里。

升级规则三条：① in-place 版本升级一旦触发，在完成或失败前不能再修改域配置；② 升级期间仍可读写数据，不是停机；③ 也可以删除域来终止升级，但域也一并没了。升级前先用 get-compatible-versions（看兼容版本）、get-upgrade-status 与 get-upgrade-history 摸清路径。

一条纪律：把「版本体检」排进季度计划，别等到附加费生效才发现账单翻倍。

十三、三个真实场景的月账单测算

下面用第四节采集到的 us-east-1 单价做三个典型测算，帮你建立量级直觉（均按 730 小时/月）。

场景 A：个人测试域——单 AZ 1 台 t3.small.search，20 GB gp3 存储。

结论：测试一个月不到一杯咖啡 × 8，但别忘了它 24 小时都在计费——测完记得 delete-domain。

场景 B：小团队生产（3-AZ）——3 台 r6g.large.search 数据节点、3 台 c6g.large.search 专用主节点、每节点 100 GB gp3。

结论：生产域里专用主节点往往被忽略，但在这套配置里占了近四成——如果集群规模不大，可以先评估是否真的需要独立主节点。

场景 C：日志冷热分层——3 台 r6g.xlarge.search 热节点（各 100 GB gp3）加 2 台 ultrawarm1.medium.search 温节点（各 1.5 TB 托管存储）。

结论：分层后，3 TB 冷数据只花约 $74，若全放热层按 gp3 要 $375——冷热分层的降本幅度就在这个 5 倍差价里，这是 OpenSearch 日志栈最值得做的一件事。

十四、七个最容易踩的坑

坑 1，把它当成「免费服务」。OpenSearch 定价页没有每月免费额度列，一个跑着的域 24 小时都在计费。纪律：实验域用完立刻删。

坑 2，用 t3 硬扛生产。T2/T3 有单域 10 台上限，且共享型 CPU 在突发查询下会被限流。纪律：t3 只做起步与压测。

坑 3，忽略专用主节点成本。3 台主节点在场景 B 里占了近四成账单。纪律：小集群先评估是否真的需要独立主节点。

坑 4，数据不分层一直堆热层。热层 gp3 与温层托管存储差约 5 倍。纪律：历史日志下沉 UltraWarm / OR1。

坑 5，版本不升级吃扩展支持附加费。2026-11-07 起 EOL 版本的附加费等于实例成本，账单可能翻倍；扩展支持结束后域会被隔离、数据只保留 30 天。纪律：版本升级排进季度计划。

坑 6，部署到只有 2 个 AZ 的区域还想要 3-AZ。us-west-1 只支持 2 AZ。纪律：要 3-AZ 就别选北加州。

坑 7，向量维度拍脑袋定太高。向量检索按平均向量大小 × 向量数计价，维度越高查询费越高。纪律：在效果与成本之间做一次实测再定维度。