OpenSearchを別アカウントへ移行する方法｜手動スナップショットとリモート再インデックスの選び方

2026年10月13日

AWSアカウントを分けるとき、Amazon OpenSearch Serviceは「今のドメインの所有者だけを変更する」という移行はできません。移行先アカウントに新しいドメインを作り、検索データを移してからアプリケーションの接続先を切り替えます。この記事はドメイン型のOpenSearch Serviceを対象とします。

まず決めたいのは、既存インデックスをまとめて復元したいのか、必要なデータを選んで入れ直したいのかです。この違いから、手動スナップショットとリモート再インデックスを選びます。

どちらを選ぶ？データの移し方を比較

比較点	手動スナップショット	リモート再インデックス
仕組み	S3に保存したバックアップを移行先で復元	移行先が移行元を読み、ドキュメントを登録し直す
検討しやすい用途	既存インデックスをまとめて移す	特定インデックスや条件に合うデータを移す
準備の中心	S3リポジトリとアクセス権限	移行元への通信と移行先インデックスの設計
注意点	復元できるバージョンの組み合わせを確認	マッピングや設定は自動コピーされない

スナップショットでも復元対象のインデックスは選べます。「一部なら必ず再インデックス」と決まるわけではありません。現在の構造を復元したいか、データを読み直して移行先を作りたいかで判断すると整理しやすくなります。

手動スナップショット：S3を経由して復元する

自動スナップショットは元のドメインの復旧用です。別ドメインへデータを移す場合は、利用者が管理するS3バケットへ取得する手動スナップショットを使います。基本の流れは次のとおりです。

移行先ドメインを作成し、バージョンと容量を確認する。
スナップショット用S3バケットとIAMロールを用意し、移行元にリポジトリを登録する。
移行元で対象インデックスのスナップショットを取得する。
移行先にも同じリポジトリを登録し、対象インデックスを復元する。

別アカウントでは、S3バケット側のポリシーとアクセスするIAMロールの権限を合わせて確認します。リポジトリ登録を実行する主体には、スナップショット用ロールを渡す権限なども必要です。細粒度アクセス制御を使用している場合は、OpenSearch側のロールマッピングも確認します。

移行先のリポジトリは readonly: true で登録し、複数ドメインから同じリポジトリへ書き込まないようにします。また、業務データの復元と、セキュリティ設定・Dashboardsなどの管理用データの扱いは分けて計画します。すべてのシステムインデックスをそのまま上書きする前提にはしません。

詳しい権限要件はスナップショットの前提条件、登録方法は手動スナップショットリポジトリの登録で確認できます。

リモート再インデックス：移行先が移行元から読み込む

リモート再インデックスは、移行元のドキュメントを読み出し、移行先に登録し直す方法です。処理を実行するのは移行先（local）で、読み取り先が移行元（remote）です。この向きを押さえると、ネットワークの確認箇所が明確になります。

移行先から移行元へ到達できる通信経路と認証を用意する。
移行先にインデックスを作成し、マッピングやシャード数などを設定する。
移行先へ再インデックス要求を送り、移行元と対象データを指定する。
完了状況とエラーを確認し、検索結果を検証する。

VPC内のドメインでも利用方法はありますが、インターネット経由の例をそのまま適用できるとは限りません。利用する接続方式に応じて、移行先から移行元への到達性を確認してください。対応バージョンにも条件があり、T2・T3インスタンスではリモート再インデックスを利用できません。詳細はAWSのリモート再インデックス手順を参照してください。

この方式はインデックス定義を丸ごと複製する操作ではありません。設定・マッピング・シャード構成は自動コピーされず、移行元の _source が有効である必要があります。検索時の挙動を維持したい場合は、アナライザーを含む定義を先に比較します。仕様はReindex Documents APIで確認できます。