次世代 Amazon OpenSearch Serverless の登場
2026年5月、AWS は Amazon OpenSearch Serverless の次世代アーキテクチャを発表しました。生成 AI エージェントやベクトル検索といった新しいワークロードを支えるために、サービスの内部構造を抜本的に作り直したアップデートです。技術解説メディア The New Stack は、新アーキテクチャの約97%が AWS のエンジニアによってゼロから再設計されたと報じています。
今回の刷新で最も大きな変更点は、コンピュートとストレージの完全分離です。従来は計算リソースとデータが密に結びついていましたが、新世代では OpenSearch が独自のストレージ層の上で動作し、計算リソースだけを必要なときに必要なだけ増減できるようになりました。この分離があったからこそ、本記事の主役である「Scale to Zero（ゼロまでのスケールダウン）」が実現しています。
従来の Amazon OpenSearch Serverless では、検索や取り込みのリクエストがまったくない時間帯でも最低限の OpenSearch Compute Unit（OCU）が常時稼働し、その分の料金が発生していました。次世代アーキテクチャは、この「アイドル時にも払い続ける」という前提そのものを取り払う設計になっています。
この刷新の背景には、生成 AI エージェントの普及があります。エージェントが知識を参照する RAG やベクトル検索の需要は急増する一方で、その利用は会話のたびに発生する断続的なものになりがちです。常時フル稼働を前提とした料金体系では、こうした「使うときは集中し、使わないときは長く空く」ワークロードと相性が良くありませんでした。次世代アーキテクチャは、まさにこの課題に正面から応える形で設計されています。
Scale to Zero の仕組み
Scale to Zero とは、アプリケーションがアイドル状態になったときにコンピュート容量を OCU 0 まで縮小し、コンピュートの課金を停止する仕組みです。具体的には、10分間リクエストが届かないとサービスが計算リソースを解放し、OCU の使用量が 0 になります。
気になるのは、止まった状態からの復帰速度でしょう。トラフィックが再開すると、約10秒でキャパシティが戻ります。この立ち上がりの間、サービスは届いたリクエストをキューに保持し、容量が用意できた時点で順番に処理するため、リクエストがそのまま失われることはありません。新世代はリソースを数秒で作成し、従来世代と比べて最大20倍速くキャパシティをスケールさせます。
さらに重要なのが、取り込み用と検索用の OCU が独立してスケールする点です。たとえば取り込みは続いているが検索リクエストがまったく来ない場合、取り込み用 OCU を維持したまま検索用 OCU だけを 0 にできます。逆もまた同様で、ワークロードの実態に合わせて二つの軸を別々に最適化できます。
観点 | 従来世代 | 次世代アーキテクチャ |
|---|---|---|
アイドル時の OCU | 最低限の OCU が常時稼働 | 0 までスケールダウン |
アイドル時のコンピュート課金 | 発生する | 発生しない |
スケール速度 | 分単位 | 秒単位（最大20倍高速） |
取り込みと検索のスケール | まとめて確保 | 独立してスケール |
コスト削減効果
AWS によると、アイドル時間が長いワークロードでは、ピーク容量に合わせてプロビジョニングした OpenSearch Service クラスターと比較して、インフラコストを最大60%削減できるとされています。使っていない時間に料金を払わずに済むことが、この削減幅を生み出す主な要因です。
あわせて、起動時のコストも下がりました。次世代では取り込みと検索のそれぞれで 0.5 OCU（ハーフ OCU）に対応します。ハーフ OCU は 0.5 vCPU、3 GB のメモリ、60 GB のストレージに相当し、小規模なベクトルワークロードの起動コストは実質半分になりました。
最低料金の目安は構成によって変わります。スタンバイを持つ冗長構成の本番向けでは、ハーフ OCU 4 個でおよそ月額350ドルです。冗長性を無効にした開発・検証向けでは、ハーフ OCU 2 個でおよそ月額174ドルまで下げられます。そのうえでアイドル時にはコンピュートが 0 になるため、断続的に使うシステムほど効果が大きくなります。
構成 | 最低キャパシティ | 月額の目安 |
|---|---|---|
本番（冗長あり） | ハーフ OCU 4 個 | 約350ドル |
開発・検証（冗長なし） | ハーフ OCU 2 個 | 約174ドル |
アイドル時 | 0 OCU | コンピュート課金なし |
実装方法とコレクショングループ
Scale to Zero は、コレクショングループの容量設定で有効化します。コレクショングループは複数のコレクションが世代設定や OCU を共有する単位で、1 つのグループには検索・時系列・ベクトル検索のうち同じ種類のコレクションだけをまとめられます。取り込みと検索の最小キャパシティを 0 に設定することで、アイドル時にゼロまで縮小する挙動になります。
AWS CLI では、容量の上限と下限を次のように指定します。最小を 0、最大を必要なピークに合わせて設定するのが基本的な考え方です。
{
"minIndexingCapacityInOCU": 0,
"minSearchCapacityInOCU": 0,
"maxIndexingCapacityInOCU": 10,
"maxSearchCapacityInOCU": 10
}最大キャパシティは、想定されるスパイクを吸収できる十分な値にしておくことが推奨されます。OpenSearch Serverless はこの範囲の中で OCU を自動的に増減させるため、運用担当者がキャパシティを手で調整する必要はありません。実際の使用量は CloudWatch の SearchOCU と IndexingOCU メトリクスで把握できます。
導入時に押さえておきたい考慮事項
便利な仕組みですが、いくつか押さえておきたい点があります。まず、アイドルから復帰する最初のリクエストには約10秒のコールドスタートが発生します。多くのバッチ処理や社内検索では問題になりにくい一方、常に低レイテンシが求められる対人向けの検索では、この待ち時間が体感に影響する可能性があります。リクエストはキューされてドロップしないとはいえ、レイテンシ要件は事前に確認しておくと安心です。
次に、コンピュートとストレージは別々に課金されます。OCU が 0 になってもデータ自体は保持され、ストレージ料金は GB 単位で発生し続けます。したがって Scale to Zero が効くのは、あくまでアイドル時のコンピュート費用である点を理解しておく必要があります。
冗長性の設定もコストと可用性のトレードオフになります。スタンバイを別のアベイラビリティーゾーンに持つ冗長構成は高可用性を確保できますが、その分だけ最低キャパシティが増えます。本番では冗長構成、開発や検証では冗長性を無効にするなど、用途に応じて使い分けるとコストを抑えやすくなります。
向き不向きもあります。利用が時間帯や曜日で偏るシステム、開発・検証環境、立ち上げ直後でトラフィックが読めない AI エージェント基盤などは恩恵が大きい一方、24時間ほぼ一定の高トラフィックが続くワークロードでは、OCU が 0 に落ちる機会が少なく削減効果は限定的になります。自社の利用パターンとレイテンシ要件を踏まえて判断することが大切です。
まとめ
次世代 Amazon OpenSearch Serverless の Scale to Zero は、コンピュートとストレージの分離を土台に、アイドル時のコンピュート課金をゼロにできる仕組みです。最大60%のコスト削減、約10秒での復帰、取り込みと検索の独立スケール、ハーフ OCU による起動コスト半減といった改善が組み合わさり、断続的なワークロードやベクトル検索基盤のコスト効率を大きく高めます。
Ragate は AWS パートナーとして、サーバーレスを軸にしたクラウド活用とコスト最適化の支援を行っています。OpenSearch Serverless の容量設計やコレクショングループの構成、自社ワークロードに Scale to Zero が適するかどうかの見極めなど、検討段階からお気軽にご相談ください。
