Amazon OpenSearch Service入門｜Elasticsearchからの移行手順とログ分析・全文検索の実践ガイド

オンプレでELKスタック（Elasticsearch + Logstash + Kibana）を運用していたことがある方なら、「AWSでもElasticsearchが使えるらしいが、いつの間にかOpenSearchに名前が変わっていた」と戸惑った経験があるかもしれません。2021年にAmazonはOpenSearchというオープンソースフォークを立ち上げ、マネージドサービスを「Amazon OpenSearch Service」に刷新しました。

この記事では、Amazon OpenSearch Service について、オンプレElasticsearch経験者にもわかりやすく解説します。ドメイン作成から基本的なインデックス操作、ログ分析のユースケース、料金体系、そして移行時のハマりポイントまでカバーします。

なぜOpenSearch Serviceなのか？（オンプレElasticsearchとの違い・背景）

オンプレのElasticsearchクラスターを運用したことがある方なら、次の作業に心当たりがあるはずです。

・ノードの増設: ディスク容量が逼迫するたびにデータノードを追加し、シャードの再配置（リバランシング）が終わるまで何時間も待つ
・バージョンアップ: Elasticsearchのメジャーバージョンアップは破壊的変更を伴いやすく、プラグインの互換性確認から本番適用まで丸1日以上かかる
・クラスター監視: JVM ヒープ使用率、スレッドプール詰まり、ノード障害時のスプリットブレイン回避など、専門知識が必要な運用が多い

Amazon OpenSearch Serviceはこれらのインフラ運用をAWSが肩代わりしてくれるマネージドサービスです。「クラスター」ではなく「ドメイン」という概念でリソースを管理し、コンソール操作数クリックでクラスターを立ち上げられます。

OpenSearch ServiceとElasticsearchの関係

2021年以前はサービス名が「Amazon Elasticsearch Service」でした。ElasticがElasticsearchのライセンスをAGPL v3からSSPLに変更したことで、AmazonはElasticsearchとKibanaをフォークし、それぞれ「OpenSearch」と「OpenSearch Dashboards」として独立したオープンソースプロジェクトを立ち上げました。

互換性の観点では、OpenSearch 1.x/2.xはElasticsearch 7.10ベースのAPIと高い互換性を持っています。既存のElasticsearchクライアントの多くはそのまま動作しますが、バージョンが上がるにつれてElasticの独自機能との差異が生じているため、移行前の動作確認は必須です。

Amazon OpenSearch Serviceの基本的な使い方

1. ドメインを作成する（コンソール操作）

まずAWSコンソールからOpenSearch Serviceを開き、「ドメインの作成」をクリックします。

主な設定項目を確認していきましょう。

デプロイタイプ
本番環境では「本番ワークロード」を選択します。学習・検証目的なら「開発/テスト」を選ぶとコスト面で有利です。

バージョン
執筆時点（2026年6月）の最新安定版はOpenSearch 2.xです。Elasticsearch 7.x系との互換性を重視するなら、Elasticsearch 7.10互換モードを選択することもできます。ただし新規構築であればOpenSearch 2.xを推奨します。

データノード設定
検証環境なら t3.small.search（1ノード）でも起動できますが、本番環境ではマルチAZ構成が必須です。最低でも3ノード（各アベイラビリティーゾーンに1ノード）を推奨します。データ量に応じて m6g.large.search 以上を選択します。

ストレージ
EBSボリューム（gp3推奨）を各ノードに割り当てます。ログデータは圧縮が効くので、生データ量の30%程度から見積もり始め、ホットデータ（直近30日分）が常時アクセスに収まるよう設計します。

ネットワーク設定
本番環境では必ず「VPC内」を選択してください。パブリックアクセスは評価用途のみに限定するのが鉄則です。VPC内ではセキュリティグループでアクセス元IPを絞り込みます。

# AWS CLIでドメイン作成（基本設定）
aws opensearch create-domain \
  --domain-name my-search-domain \
  --engine-version OpenSearch_2.11 \
  --cluster-config InstanceType=m6g.large.search,InstanceCount=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 ap-northeast-1

ドメインの起動完了まで約15分かかります。コンソールのステータスが「アクティブ」になったらエンドポイントが表示されます。

2. インデックスを作成してデータを投入する

ドメインが立ち上がったら、エンドポイントを確認します。VPC内構成の場合、エンドポイントは vpc-xxx.ap-northeast-1.es.amazonaws.com 形式になります。VPC外からアクセスするには踏み台サーバー経由かSSHトンネルが必要です。

# インデックスの作成（curl例、VPC内踏み台サーバーから実行）
curl -XPUT "https://your-endpoint.ap-northeast-1.es.amazonaws.com/logs-2026-06" \
  -H 'Content-Type: application/json' \
  -d '{
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1
    },
    "mappings": {
      "properties": {
        "@timestamp": { "type": "date" },
        "level":      { "type": "keyword" },
        "message":    { "type": "text" },
        "host":       { "type": "keyword" }
      }
    }
  }'

# ドキュメントの投入
curl -XPOST "https://your-endpoint.ap-northeast-1.es.amazonaws.com/logs-2026-06/_doc" \
  -H 'Content-Type: application/json' \
  -d '{"@timestamp":"2026-06-27T10:00:00Z","level":"ERROR","message":"Connection timeout","host":"web-01"}'

Fluentdからのログ投入
実際のログ収集には fluent-plugin-opensearch（fluent-plugin-elasticsearch の後継）を使います。

# /etc/fluent/fluent.conf（Fluentd設定例）
<match syslog.**>
  @type opensearch
  host your-endpoint.ap-northeast-1.es.amazonaws.com
  port 443
  scheme https
  index_name logs-%Y-%m-%d
  include_tag_key true
  tag_key @log_name
  flush_interval 5s
</match>

AWS環境からのログ収集には、CloudWatch Logs → Lambda → OpenSearch という構成も標準的です。AWSコンソールでCloudWatch Logsのサブスクリプションフィルターを設定するだけで、ログをリアルタイムにOpenSearchへ転送できます。

3. OpenSearch Dashboardsでログを可視化する

OpenSearch Dashboardsは旧KibanaのAWSフォーク版です。URL末尾に /_dashboards/ を付けるとダッシュボード画面が開きます。

初期設定では以下の手順でインデックスパターンを登録します。

・Management → Dashboards Management → Index patterns を開く
・「Create index pattern」をクリック
・インデックス名パターン（例: logs-*）を入力
・タイムスタンプフィールドに @timestamp を指定
・「Discover」タブでログの全文検索が可能になる

ログの文字列検索、フィールドによるフィルタリング、時系列グラフの作成はすべてKibanaと同じ操作感で利用できます。アラートの設定（Alerting）や異常検知（Anomaly Detection）はOpenSearch独自の機能として強化されています。

料金の仕組み（コスト感覚）

Amazon OpenSearch Serviceの料金はインスタンスタイプ × 稼働時間で課金されます（2026年6月時点・東京リージョン（ap-northeast-1）・USD）。

3ノード（マルチAZ）の m6g.large.search + 各100GB（gp3）で構成した場合の月額目安：

・インスタンス費用: $0.128 × 3ノード × 720時間 ≒ $276/月
・EBSストレージ: $0.122/GB × 300GB ≒ $37/月
・合計目安: 約$313/月（東京リージョン、2026年6月時点）

オンプレのElasticsearchクラスターに使っていた物理サーバーのコストと比較すると、中規模構成であればクラウドの方が割高に感じることもあります。ただし、専任の運用担当者が不要になるコスト削減効果を含めて試算すると、多くのケースでトータルコストは逆転します。

コスト削減のポイント
・UltraWarm（ウォームノード）活用: 30日より古いインデックスをUltraWarm（Amazon S3ベースの低コストノード）に移行すると、ストレージコストを最大90%削減できます
・Cold Storage: さらに古いデータはCold Storageに移し、参照頻度が低いデータのコストをほぼS3水準に下げられます
・リザーブドインスタンス: 1年・3年の前払い予約で最大36%割引になります

応用・実務Tips

ISM（Index State Management）でディスク管理を自動化
オンプレElasticsearchではCuratorやILMポリシーを自前で管理することが多かったと思いますが、OpenSearch ServiceのISM（Index State Management）が同等の機能を提供します。

・30日以上経過したインデックスを自動でUltraWarmへ移行
・90日以上経過したインデックスを自動でCold Storageへ移行またはDelete

これを最初から設定しておくだけで、「ディスク枯渇でクラスターが停止」という最悪のシナリオを防げます。

# ISMポリシーの例（30日でUltraWarm移行、90日で削除）
PUT _plugins/_ism/policies/log-lifecycle
{
  "policy": {
    "description": "ログ自動ライフサイクル管理",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "transitions": [{
          "state_name": "warm",
          "conditions": { "min_index_age": "30d" }
        }]
      },
      {
        "name": "warm",
        "actions": [{ "warm_migration": {} }],
        "transitions": [{
          "state_name": "delete",
          "conditions": { "min_index_age": "90d" }
        }]
      },
      {
        "name": "delete",
        "actions": [{ "delete": {} }]
      }
    ]
  }
}

Fine-grained Access Control（FGAC）でテナント分離
オンプレではX-Pack（有償）でしか実現できなかった行・列レベルのアクセス制御が、OpenSearch Serviceでは標準搭載されています。開発チーム別にインデックスへのアクセスを分離したい場合に有効です。インデックスパターン単位でロールを設定し、各チームのIAMユーザーやIAMロールに紐付けられます。

CloudWatch Logs Subscriptionとの連携
VPCフローログ、ALBアクセスログ、Lambda実行ログなどをCloudWatch Logsに集約し、サブスクリプションフィルターでリアルタイムにOpenSearchへ転送するアーキテクチャが現場では定番です。別途Logstashを管理する必要がなくなり、運用が大幅に楽になります。

サーバー側のLinuxシステムログをFluentdで収集する具体的な手順は、姉妹サイトLinuxMaster.JPで詳しく解説しています。

よくあるトラブルと対処法

クラスターが「Yellow」ステータスのまま
シャードのレプリカが配置できていない状態です。1ノード構成で number_of_replicas: 1 を設定するとこの状態になります。検証環境では number_of_replicas: 0 に変更するか、データノードを増やしてください。

# レプリカ数を0に変更（検証環境のみ）
PUT your-index/_settings
{
  "index": {
    "number_of_replicas": 0
  }
}

「Too many shards」エラー
OpenSearch Serviceではクラスターあたりのシャード数上限があります（デフォルト1000）。日次でインデックスを作成し続けると、数か月で上限に達することがあります。ISMポリシーで古いインデックスを定期削除するか、インデックスのシャード数を減らして対応します。

VPC内からダッシュボードにアクセスできない
VPC内ドメインのOpenSearch Dashboardsは、VPC外からは直接アクセスできません。次の方法で対応します。

・SSHポートフォワーディング: 踏み台サーバー経由で自分のPCにポートをフォワード
・AWS Client VPN: VPNで社内ネットワークをVPCに接続
・Application Load Balancer（ALB）プロキシ: Amazon Cognitoと組み合わせてHTTPS公開

# SSHポートフォワーディング（自分のPCから実行）
# opensearch-endpoint をドメインのエンドポイントに置き換える
ssh -L 5601:opensearch-endpoint:443 -N ec2-user@bastion-host-ip
# ブラウザで https://localhost:5601/_dashboards/ を開く

Elasticsearchクライアントからの接続エラー
OpenSearch 2.x以降はElasticsearch 8.x系のクライアントとの互換性が低下しています。opensearch-py（Python）や opensearch-java など、OpenSearch専用クライアントへの移行を推奨します。互換性レイヤーを維持したい場合は、Elasticsearch 7.x系クライアントを使い続ける選択肢もあります。

本記事のまとめ

Amazon OpenSearch Serviceは、オンプレElasticsearchで必要だったインフラ運用の大部分をAWSに委ねられるサービスです。マルチAZ構成・バージョンアップ・スケーリングが管理コンソールから操作できるため、チームの運用負荷を大幅に削減できます。

移行時のポイントは2つです。第一に、OpenSearch 2.xとElasticsearch 7.10以降のAPIには差異があるため、クライアントの互換性を事前に確認すること。第二に、ISMポリシーとUltraWarmを組み合わせたライフサイクル設計を最初から組み込むことで、ディスクコストを大幅に抑えられます。

本記事では基本的な使い方と実務Tipsを紹介しました。ログ分析の規模が大きくなってきたら、Kinesis Data Firehose経由のリアルタイム取り込みや、ALB + Amazon Cognitoを使ったOpenSearch Dashboardsのセキュア公開も検討してみてください。