翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon OpenSearch Service のコスト最適化手法
以下は、Amazon OpenSearch Service の使用中にコストを最適化するために最もよく使用される手法の一部です。マネージドクラスターとサーバーレスの両方です。すべてのワークロードは一意であるため、これらの戦略を特定の使用パターンに照らして評価し、本番環境に適用する前にテスト環境で検証します。
**Topics**
+ [1-Yearまたは複数年のコミットメントで大きな節約](#cost-opt-savings-commitments)
+ [Amazon OpenSearch Service マネージドクラスターのコスト最適化](#cost-optimization-managed)
+ [Amazon OpenSearch Service Serverless のコスト最適化](#cost-optimization-serverless)
## 1-Yearまたは複数年のコミットメントで大きな節約
Amazon OpenSearch Service では、最低料金や使用要件なしで使用した分のみお支払いいただきます。Amazon OpenSearch Service には 2 つのデプロイモデルがあります。
+ マネージドクラスターの場合、インスタンス時間、ストレージ、データ転送に対して課金されます。料金は、選択したインスタンスタイプとストレージ階層によって異なります。インスタンスの場合は、リザーブドインスタンスの料金を使用するか、オンデマンド料金よりも Database Savings Plans で保存できます。
+ Serverless の場合、コンピューティングとストレージに対して個別に課金されます。コンピューティング容量は OpenSearch Compute Units (OCUs は、データのインデックス作成やクエリの実行に必要な CPU、メモリ、I/O リソースに対応します。Serverless は Database Savings Plans でもカバーされています。
Database Savings Plans は、1 年間の一貫した使用量にコミット ($/時間で測定) するときに Amazon OpenSearch Service のコストを削減する柔軟な料金モデルです。この節約プランは、エンジンバージョン、インスタンスファミリー、サイズ、デプロイオプションに関係なく、または前払い AWS リージョン なしで、対象となるサーバーレスおよびプロビジョニングされたインスタンスの使用に自動的に適用されます。詳細については、[「 Database Savings Plans の料金」ページ](https://aws.amazon.com/savingsplans/database-pricing/)を参照してください。
リザーブドインスタンスは、1 年間または 3 年間の特定のインスタンス設定にコミットするときに Amazon OpenSearch Service のコストを削減する料金モデルを提供します。リザーブドインスタンスは、特定のインスタンスタイプ、サイズ、および の容量を予約する場合、オンデマンド料金と比較して大幅な割引を提供します AWS リージョン。支払いオプションには、全額前払い、一部前払い、前払いなしなどがあります。前払いの支払いには割引が適用されます。詳細については、[Amazon OpenSearch Service リザーブドインスタンスの料金ページ](https://aws.amazon.com/opensearch-service/pricing/)を参照してください。
## Amazon OpenSearch Service マネージドクラスターのコスト最適化
### 派生ソース — \_source フィールドの保存をスキップします
派生ソースは、 `_source`フィールドを保存するオーバーヘッドを排除するストレージ最適化機能です。
+ OpenSearch は、取り込まれたすべてのドキュメントを 2 回保存します。1 回は `_source`フィールド (raw ドキュメント) に、もう 1 回は検索用のインデックス付きフィールドとして保存します。
+ `_source` フィールド単独では、大量のストレージ領域を消費する可能性があります。多くの場合、インデックスストレージ全体の 30～50% です。
+ 派生ソースでは、保存をスキップ`_source`し、必要に応じてインデックス付きフィールドから動的に再構築します (検索、取得、mget、再インデックス、または更新オペレーション中）。
+ これはオプトインであり、複合インデックス設定を使用してインデックスの作成時に有効になります。
+ OpenSearch 3.1 以降がサポートされているすべてのリージョンで使用できます。
最適: 元の raw ドキュメントを頻繁に取得する必要はなく、フィールド上で検索して集計する必要がある分析ワークロードとログワークロード。
詳細については、[オープンソースのドキュメント](https://docs.opensearch.org/latest/mappings/metadata-fields/source/)と[最新情報のお知らせ](https://aws.amazon.com/about-aws/whats-new/2025/09/amazon-opensearch-derived-source/)を参照してください。
### OR1 / OR2 / OM2 インスタンス — OpenSearch 最適化インスタンスファミリー
OR1 以降の OR2 および OM2 インスタンスは、セグメントレプリケーションを介したレプリカストレージに Amazon S3 を使用します。
+ OR2: OR1 よりもインデックス作成スループットが最大 26% 高く、R7g インスタンスよりも 70% 高くなります。
+ OM2: OR1 よりもインデックス作成スループットが最大 15% 高く、M7g インスタンスよりも 66% 高くなります。
+ どちらも同じアーキテクチャを使用しています。プライマリストレージにはローカル EBS、耐久性には S3 です。
+ レプリカストレージコストを排除 - 高価な EBS ボリュームの代わりに S3 に保存されるレプリカ (耐久性 9 分の 11)。
+ 前世代のインスタンスと比較して、最大 30% の価格パフォーマンスの向上。
+ 浅いスナップショット v2 をサポート — I/O オーバーヘッドのないほぼ即時のスナップショット。
最適: 大量の運用分析とログ分析ワークロードのインデックス作成。
詳細については、[OR2 と OM2 の最新情報](https://aws.amazon.com/about-aws/whats-new/2025/03/aws-or2-om2-instances-opensearch-service/)」および「 デ[Amazon OpenSearch Service ドメインの OpenSearch 最適化インスタンス](or1.md)ベロッパーガイド」トピックを参照してください。
### インデックスロールアップ — 履歴時系列データを集計する
インデックスロールアップは、古い時系列データを要約してより粗い時間間隔に圧縮し、ストレージボリュームを大幅に削減します。
+ IoT/センサーデータ: 最近の期間、1 秒あたりのデータをホットストレージに保持します。古いデータについては、時間単位または日単位の概要にロールアップします。
+ システムメトリクス: 過去 30 日間の詳細なメトリクスを保持し、古いデータを時間単位または日単位の概要に集約します。
+ ログデータ: アクティブなトラブルシューティングウィンドウ (1 週間など) の完全な詳細を保持し、古い期間に要約されたエラーパターンを維持します。
+ ISM ポリシーと組み合わせて、単一のライフサイクルポリシーでロールアップと階層の移行を自動化します。
+ 数秒から数時間への集計では、数秒から数分への集計よりも大幅な削減が可能です。
詳細については、[Index Rollups ブログ記事](https://aws.amazon.com/blogs/big-data/decrease-your-storage-costs-with-amazon-opensearch-service-index-rollups/)を参照してください。
### インデックス状態管理 — フルデータライフサイクルを自動化する
ISM ポリシーは、ストレージ階層とライフサイクルアクションを介したインデックスの移動を自動化します。
+ インデックスを自動的に移行する: 年齢、サイズ、ドキュメント数に基づいて、ホットから UltraWarm へ、コールドから削除へ。
+ 階層が移行する前にロールアップをトリガーして、データ量を減らします。
+ ロールオーバーポリシー (インデックスが 50 GB に達した場合や 30 日が経過した場合など) を設定して、インデックスの増加を制御します。
+ 読み取り専用インデックスの強制マージを自動化して、削除されたドキュメントからストレージを再利用します。
+ ロールアップと組み合わせることで、大規模な時系列データセットの節約を最大化できます。
### 適切なサイズのインスタンスタイプと数
Well-Architected OpenSearch レンズの主なガイダンスと適切なサイジングのベストプラクティス:
+ 常に最新世代のインスタンスを使用してください (例えば、Graviton3 インスタンスは Graviton2-basedインスタンスよりもパフォーマンスが最大 25% 向上します）。
+ gp2 の代わりに gp3 EBS ボリュームを使用する — 追加料金なしで低コストでパフォーマンスが向上します。
+ インスタンスタイプをワークロードに一致: 検索量が多い場合はメモリ最適化、インデックス作成量が多い場合はコンピューティング最適化。
+ 専用クラスターマネージャーノードを評価する: 3 つ以上のデータノードにのみ必要です。マスターノードサイズの過剰プロビジョニングは避けてください。
+ CloudWatch メトリクスをモニタリングしてオーバープロビジョニングを検出します。持続的な CPU が 40% 未満、JVM が 50% 未満、ストレージが 50% 未満の場合は、無駄の兆候です。
+ 最適な範囲: CPU 60～80%、JVM 65～85%、持続的なワークロードのストレージ 70～85%。
詳細については、[「Right-Sizing Best Practices」ブログ記事](https://aws.amazon.com/blogs/big-data/best-practices-for-right-sizing-amazon-opensearch-service-domains/)を参照してください。
### シャードの最適化 — オーバーシャーディングを回避する
オーバーシャーディングは隠れたコスト要因です。小さなシャードが多すぎると CPU、メモリ、JVM ヒープが浪費されます。
+ 推奨されるシャードサイズ: ワークロードに応じて、シャードあたり 10～50 GiB。
+ Java ヒープの GiB あたり 25 個以下のシャード、データノードあたり 1,000 個以下のシャード。
+ ISM ロールオーバーポリシーを使用してインデックスの増加を制御し、無制限のシャードの拡散を回避します。
+ 耐久性が許容されるレプリカ数を減らします (OR1/OR2 インスタンスはレプリカを完全に不要にします）。
+ 読み取り専用インデックスで強制マージを使用して、セグメント数を減らし、ストレージを再利用します。
詳細については、[「必要なシャードの数」を参照してください。](https://aws.amazon.com/blogs/big-data/amazon-opensearch-service-101-how-many-shards-do-i-need/)
### Amazon S3 でのゼロ ETL / 直接クエリ
クエリはほとんど行われないがアクセス可能なデータの場合、Direct Query (S3 ではゼロ ETL) では、S3 データを OpenSearch から直接クエリでき、取り込む必要はありません。
+ 取り込みコストなし — データは S3 に残ります。
+ アーカイブデータのホット階層ストレージコストはかかりません。
+ Pay-per-queryコンピューティングモデル。
+ 視覚化のために OpenSearch Dashboards をサポートします。
+ 秒または分のレイテンシーは許容されます。リアルタイムのユースケースでは許容されません。
### 取り込み時のサンプリングと圧縮
データが OpenSearch に到達する前にコストを削減します。
+ サンプリング: 大量のログストリームの代表的なサブセットのみを取り込みます (デバッグログの 10% など）。
+ インデックス圧縮: 最適な圧縮コーデックを有効にして、ストレージフットプリントを削減します。
+ フィールドフィルタリング: インデックス作成の前に高カーディナリティ、低値フィールドを削除します (古いログの raw スタックトレースなど）。
+ 保持ポリシー: コンプライアンス要件に合わせて最大保持期間を定義します。データを無期限に保存しないでください。
### 延長サポートコストの回避 — エンジンバージョンを最新の状態に保つ
Amazon OpenSearch Service は、延長サポートのエンジンバージョンに対して、正規化されたインスタンス時間あたりの定額料金を請求します。
+ サポートされていない古いバージョンにとどまると、インスタンスコストに加えて追加料金が発生します。
+ 延長サポート料金が発生しないように、現在サポートされているバージョンにアップグレードします。
### コスト配分タグと CloudWatch モニタリング
プロアクティブコストガバナンスは無駄を防ぎます。
+ OpenSearch ドメインにコスト配分タグを適用して、チームまたはワークロードごとの詳細なコスト追跡を行います。
+ ストレージ使用率、JVM プレッシャー、CPU の CloudWatch アラームを設定して、オーバープロビジョニングを早期に検出します。
+ 一貫して使用率が低いドメインを識別するには、 AWS Cost Explorer を使用します。
+ 自動調整の評価 — JVM ヒープサイズやその他の設定を自動的に調整して、パフォーマンスを向上させ、リソースの無駄を削減します。
## Amazon OpenSearch Service Serverless のコスト最適化
### ディスク最適化ベクトル検索 (ベクトルコレクション)
ディスク最適化ベクトル検索は、ベクトルワークロードの最も強力なコスト削減手法の 1 つです。圧縮されたベクトルのみを RAM に保持し、完全精度ベクトルをディスクに保存することで、インメモリモードのコストのごく一部でベクトル検索を実行します。
仕組み:
+ 標準 (`in_memory`) モードでは、完全な HNSW グラフが RAM にロードされます。RAM は大規模に非常に高価になります。
+ `on_disk` モードでは、圧縮 (量子化) ベクトルのみが候補生成のためにメモリに保持されます。完全精度ベクトルは、最終的な再スコアリングフェーズ (2 フェーズ検索) でのみディスクから取得されます。
+ これにより、高い検索品質を維持しながら RAM 要件が大幅に削減されます。
+ デフォルト`on_disk`モードでは 32 倍のバイナリ量子化が使用されるため、メモリ内モードと比較してメモリ要件が 97% 削減されます。
+ 圧縮レベルをサポート: 2x (FP16)、4x (バイト）、8x、16x、32x (バイナリ）。
+ 100～200 ミリ秒の範囲の P90 レイテンシー — 1 桁ミリ秒の応答時間を必要としないワークロードに適しています。
コスト削減ベンチマーク:
| データセット | リコール@100 | P90 レイテンシー | コスト削減 |
| --- | --- | --- | --- |
| Cohere TREC-RAG | 0.94 | 104 ミリ秒 | 83% |
| Tasb-1M | 0.96 | 7 ミリ秒 | 67% |
| Marco-1M | 0.99 | 7 ミリ秒 | 67% |
最適: RAG パイプライン、セマンティック検索、ドキュメント取得、および P90 レイテンシーが 100～200 ミリ秒でコスト削減が優先されるベクトルワークロード。
**注記**
この変更を既存のインデックス付きデータに適用するには、インデックスを再作成する必要があります。などの外部パイプラインツールを使用して、データを新しいインデックスに再インデックスできます。
詳細については、[Disk-Optimized Vector Search ブログ記事](https://aws.amazon.com/blogs/big-data/opensearch-vector-engine-is-now-disk-optimized-for-low-cost-accurate-vector-search/)、[Quantization Techniques ブログ記事](https://aws.amazon.com/blogs/big-data/cost-optimized-vector-database-introduction-to-amazon-opensearch-service-quantization-techniques/)、および を参照してください[ベクトル検索コレクションの使用](serverless-vector-search.md)。
### Vector Auto-Optimize (ベクトルコレクション)
自動最適化は、ベクトルインデックス設定を自動的に評価し、ベクトルの専門知識を必要とせずに、検索品質、レイテンシー、メモリコストの最適なトレードオフを推奨します。
+ 最適化に関する推奨事項を 1 時間未満で提供します。
+ ベクトル取り込みパイプラインと統合されています。
+ 数十億規模のベクトルデータベースの GPU アクセラレーションインデックス作成と組み合わせることができます。
詳細については、[「Auto-Optimize」ブログ記事](https://aws.amazon.com/blogs/big-data/auto-optimize-your-amazon-opensearch-service-vector-database/)を参照してください。
### GPU アクセラレーションベクトルインデックス作成 (ベクトルコレクション)
GPU アクセラレーションは、HNSW ベクトルインデックス作成をサーバーレス GPUs、大きなベクトルインデックスを構築する時間と OCU コストを大幅に削減します。
+ CPU のみのインデックス作成と比較して、インデックスの構築時間が 6.4 倍から 13.8 倍短縮されました。
+ 書き込みが多いベクトルワークロードのインデックス作成 OCU コストを最大 75% 削減します。
+ GPUsは動的にアタッチされます。GPU アクセラレーションがアクティブな場合にのみ OCUs に対して料金が発生します。
+ 1 時間以内に 10 億規模のベクトルデータベースを構築できます。
+ Vector Acceleration OCUs。
最適: 大規模な初期ベクトル取り込み、またはインデックスの再構築にコストがかかる頻繁なモデル再トレーニングシナリオ。
詳細については、[GPU アクセラレーションのブログ記事](https://aws.amazon.com/blogs/big-data/build-billion-scale-vector-databases-in-under-an-hour-with-gpu-acceleration-on-amazon-opensearch-service/)を参照してください。
### 最大 OCU 制限を設定する (すべてのコレクションタイプ)
Amazon OpenSearch Service Serverless は、需要に基づいて OCUs を自動スケーリングします。上限がないと、コストが予期せず急増する可能性があります。ランナウェイスケーリングを防ぐために、アカウントレベルまたはコレクショングループごとに最大 OCU 制限を設定します。システムはピーク負荷時にこの制限までスケールアップしますが、それを超えることはありません。
許可される値:
+ アカウントレベル – 最大 1,700 OCUs の値 (16 の倍数に制限されません）。
+ コレクショングループ (NextGen) – 0、2、4、8、16、および 16～1,696 OCUs。
+ コレクショングループ (Classic) – 1、2、4、8、16、および 16～1,696 OCUs。
CloudWatch メトリクス (`OCUUtilization`) をモニタリングして、時間の経過とともに最大 OCU 設定のサイズを適正化します。
**注記**
使用率が最大 OCU 上限に達すると、コストが含まれていてもパフォーマンスが大幅に低下する可能性があります。上限に達しても、OCU スパイクの根本的な原因は解決されません。ベクトルコレクションの場合、根本原因は通常インメモリベクトルです。これは、ベクトルインデックス作成の最適化、インデックスサイズの縮小、リコールと精度のトレードオフの調整によって直接対処する必要があります。
**ヒント**
保守的な最大 OCU から開始し、CloudWatch が上限付近で持続的な使用率を示している場合にのみ増加します。常に上限に達した場合は、単に制限を引き上げるのではなく、根本原因、特にベクトルコレクションのインメモリベクトルの使用を調査します。
詳細については、「[Amazon OpenSearch Serverless でのキャパシティ制限の管理](serverless-scaling.md)」を参照してください。
### 保持期間の最適化 (時系列コレクション)
データライフサイクルポリシーは、指定された保持期間後に時系列コレクションからデータを自動的に削除し、無制限のストレージの増加を防ぎます。時系列コレクションのみがデータライフサイクルポリシーをサポートしており、検索コレクションとベクトルコレクションはサポートしていません。
時系列コレクションの OCU 数は、ローカルストレージに保存する必要がある最新のデータの量によって直接決まります。時系列コレクションは、ローカル OCU ストレージ内のデータの最新の部分のみを保持します。古いデータは S3 にオフロードされ、OCUs の数はそれに応じてスケーリングされます。
必要な OCUs = max (最小 OCUs、保持期間内にデータを保持するために必要な OCUs)
データライフサイクルポリシーの設定:
+ インデックスまたはインデックスパターンごとに保持期間を 24 時間から 3,650 日に設定します。
+ Amazon OpenSearch Service Serverless は、ベストエフォートベース (通常は 48 時間以内、または保持期間の 10% 以内) でデータを自動的に削除します。
+ ルールは、コレクションレベル、インデックスパターンレベル、または個々のインデックスレベルで適用できます。より具体的なルールが優先されます。
サイジングの例:
+ 1 TiB/日取り込み、保持期間が 30 日 = 約 1 TiB のホットデータ = インデックス作成の場合は 20 OCUs、検索の場合は 20 OCUs。
+ 7 日間の保持期間に短縮 = 約 233 GiB のホットデータ = インデックス作成の場合は約 4 OCUs、検索の場合は 4 OCUs。
保持期間が短いほど、ローカルストレージのホットデータが少なくなり、必要な OCUsが少なくなり、コンピューティング料金が低くなります。保持期間を実際のビジネス要件とコンプライアンス要件に合わせる — デフォルトでは、データを無期限に保持しないでください。
詳細については、「[Amazon OpenSearch Serverless でデータライフサイクルポリシーを使用する](serverless-lifecycle.md)」を参照してください。
### 不要なデータ (すべてのコレクションタイプ) を保存しない
直接取り込まれるデータの量を減らすと、コンピューティング (OCUs) とストレージの両方のコストが削減されます。
+ 取り込み時にフィールドをフィルタリングする: パイプラインを使用して、コレクションに到達する前に低値のフィールドを削除します。
+ 重複データや冗長データを取り込まないでください: パイプラインレベルで重複排除します。
+ 適切なインデックスマッピングを使用する: 保存されているが検索されていないフィールドでインデックス作成を無効にします (`"index": false`)。
+ 検索コレクションの場合: 検索値なしでストレージを膨張させる大きなバイナリ BLOB や raw テキストを保存しないでください。
### マルチテナントワークロードのコレクショングループ (すべてのコレクションタイプ)
コレクショングループを使用すると、異なる KMS キーを持つ複数のコレクションが同じセキュリティ境界内で OCU リソースを共有できるため、マルチテナントアーキテクチャのコストを大幅に削減できます。テナントごとまたはコレクションごとに複数の KMS キーを使用するお客様に適用されます。
+ 以前は、各一意の KMS キーに専用 OCUs。これにより、テナントあたりの分離コストが大幅に高くなります。
+ コレクショングループを使用すると、個別の暗号化キーを持つテナントは OCU 容量を共有できます。
+ 多数の小規模なテナントワークロードで最大 90% のコスト削減。
+ 最小 OCUs (保証されたベースライン、コールドスタートなし) と最大 OCUs (コスト上限) の両方をサポートします。
+ 異なるネットワークアクセスタイプ (パブリックと VPC) のコレクションは、同じグループに共存できます。
+ CloudWatch メトリクスは、リソースの消費量とレイテンシーをグループごとに可視化します。
最適: SaaS プロバイダー、マルチテナントプラットフォーム、または多数の小さなコレクションを持つワークロードで、それぞれに独自の KMS キーが必要です。
詳細については、[コレクショングループのブログ記事](https://aws.amazon.com/blogs/big-data/amazon-opensearch-serverless-introduces-collection-groups-to-optimize-cost-for-multi-tenant-workloads/)、[最新情報のお知らせ](https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-opensearch-serverless-supports-collection-groups/)、および を参照してください[Amazon OpenSearch Serverless コレクショングループ](serverless-collection-groups.md)。