Amazon OpenSearch Serverlessは名前のとおりサーバーレスに使える検索基盤ですが、これまでは「Serverlessとはいいつつ、コンピューティングは常時課金」という印象が強いサービスでした。
特に個人開発やステージング環境のように、普段はほとんどアクセスがないのに、たまに検索やRAGの検証をしたいだけの用途だと、この常時課金が地味に痛いです。
2026年5月、OpenSearch ServerlessにNextGenアーキテクチャが登場し、ついにscale to zeroが可能になりました。
これはかなり大きいアップデートです。
なぜなら「使っていないときは0課金に近づける」という、ようやく名前どおりのサーバーレスらしい使い方ができるようになったからです。
本記事では、実際にscale to zeroを検証してみて、
を整理します。
AWSの発表では、NextGenアーキテクチャはOpenSearch Serverlessをエージェント時代向けに作り直した新しい基盤とされています。
いくつかの改善点がありますが、今回特に大きいと感じたのは次の2つです。
参考：次世代のAmazon OpenSearch Serverless: エージェント向けにゼロから構築｜Amazon Web Servicesブログ
従来アーキテクチャとNextGenの違いをざっくりまとめると、次のようなイメージです。
加えて、NextGenではOCUのスケーリング速度そのものも改善されています。
AWSの説明では、インデックス作成や検索の負荷に応じてOCUを秒単位で追加でき、以前のアーキテクチャと比べて最大20倍のスケール速度をうたっています。
これは単なるコスト改善だけではなく、
という性能面の改善でもあります。
今回の検証では、AWSコンソールでCollection TypeとしてNextGenを選んでコレクションを作成しました。
また、コンソールからNextGenで作成したコレクションでは、後述する0 OCUとコールドスタートを確認できました。
scale to zeroがうれしいのは、本番の高トラフィック用途というより、次のような「たまにしか使わない」環境です。
こうした用途では、
ということがよくあります。
従来のOpenSearch Serverlessはこのユースケースと相性がよくありませんでした。
一方でNextGenは、まさにこの隙間にハマる機能だと感じました。
さらに、NextGenの価値はそれだけではありません。
秒単位のオートスケーリングが強化されたことで、利用頻度が低い環境だけでなく、アクセスの波が大きいワークロードにも向いています。
たとえば、
のようなケースでは、常時大きめに張っておくよりも、必要なときだけ素早く伸びる基盤の方が相性が良い場面があります。
今回の検証環境は以下です。
ap-northeast-1SEARCHNextGenExpress createというサクッとcollectionを作る機能も一緒に追加されており今回それを利用しました。
まず、コレクションにテスト用のインデックスとドキュメントを投入しました。
その後、検索クエリを実行してwarm状態を作り、一定時間アクセスを止めたあと、再度検索してレイテンシーを計測しています。
検索に使ったPythonはだいたいこんな感じです。
import boto3
from opensearchpy import OpenSearch, RequestsHttpConnection, AWSV4SignerAuth
host = "****.aoss.ap-northeast-1.on.aws"
region = "ap-northeast-1"
auth = AWSV4SignerAuth(boto3.Session().get_credentials(), region, "aoss")
client = OpenSearch(
hosts=[{"host": host, "port": 443}],
http_auth=auth,
use_ssl=True,
verify_certs=True,
connection_class=RequestsHttpConnection,
timeout=120,
)
resp = client.search(
index="console-cold-start-demo",
body={
"query": {
"match": {
"title": "cold start"
}
},
"size": 5
}
)
SigV4署名が必要なので、素直にopensearch-pyを使うのが楽でした。
また、CloudWatchのAWS/AOSSメトリクスも合わせて確認しました。
SearchOCUIndexingOCUこれをcollection group単位で見ることで、実際に0 OCUまで落ちているかを確認できます。
結論から書くと、NextGenのscale to zero自体は確認できました。
ただし、コールドスタートはしっかり発生します。
今回の実測では次のようになりました。
0.136s0.130s11.2s0.169sつまり、
という挙動でした。
さらにCloudWatchメトリクスでは、同じ時間帯に以下のような変化を確認できました。
SearchOCU = 0, IndexingOCU = 0SearchOCU = 2, IndexingOCU = 10この結果から、
というトレードオフがかなり明確に見えました。
なお、コールド状態へ入るまでの無通信時間は、今回の観測では約620秒で再現できました。
公式にもidle timeout windowは10分と記載されています。少なくとも公開APIやCLIを見る限り、この時間自体をユーザーが変更する設定は見当たりませんでした。
正直にいうと、検索が主役の本番Webアプリにはそのままでは使いにくいです。
初回検索に10秒以上かかると、
のような体験ではかなり厳しいです。
もし本番アプリで使うなら、例えば次のような工夫が必要になります。
一方で、次の用途にはかなり相性が良いと感じました。
これまでは「使っていなくてもなんだかんだで常時課金される」せいでOpenSearch Serverlessを置きづらかったケースでも、NextGenならかなり選択肢に入りやすくなります。
OpenSearch ServerlessのNextGenアーキテクチャは、ようやく「真のサーバーレス」に近づいたアップデートだと感じました。
実験してみた結果はシンプルです。
このため、常時低レイテンシーが必要な検索基盤として見ると厳しい一方、低頻度利用の環境ではかなり魅力的です。
個人的には、特にステージング環境や個人開発での価値が大きいと感じました。
「たまにしか使わないのにOpenSearchを置いておきたい」というケースでは、ようやく本命になりそうです。