Amazon Web Services ブログ
Amazon OpenSearch Serverless の集中型・分散型ネットワーク接続パターンの設計
本記事は 2025 年 6 月 10 日 に公開された「Designing centralized and distributed network connectivity patterns for Amazon OpenSearch Serverless」を翻訳したものです。
Amazon OpenSearch Serverless は、フルマネージドの検索・分析サービスで、インフラストラクチャの自動プロビジョニングとスケーリングにより、クラスター管理なしで検索や分析のワークロードを実行できます。アプリケーションに検索・分析機能をすばやく組み込めます。
OpenSearch Serverless の利用が拡大するにつれ、ネットワークアーキテクチャと DNS 管理への理解が欠かせなくなっています。以前の記事「Network connectivity patterns for Amazon OpenSearch Serverless」で紹介した接続パターンを踏まえ、本記事では集中型・分散型のアクセスパターンに焦点を当てた高度なデプロイシナリオを取り上げます。具体的には、複数の AWS アカウントにまたがるネットワーク接続の簡素化と、オンプレミス環境から OpenSearch Serverless へのアクセス拡張について説明します。
本記事では、2 つの主要なデプロイパターンを紹介します。
- パターン 1 – 集中型エンドポイントモデル。共有サービス VPC に OpenSearch Serverless のインターフェイス仮想プライベートクラウド (VPC) エンドポイントをデプロイし、他の AWS アカウントのスポーク VPC やオンプレミスから、集約されたエンドポイント経由で OpenSearch Serverless コレクションにアクセスできるようにします。
- パターン 2 – 分散型エンドポイントモデル。個々のスポーク VPC にインターフェイス VPC エンドポイントを作成し、中央アカウント、オンプレミスネットワーク、他のスポークアカウントなど複数のコンシューマーが、集中管理された DNS を通じてアクセスします。各スポーク VPC 内での直接接続を維持しつつ、組織全体で DNS の一元管理を実現します。
高度なデプロイパターンに入る前に、インターフェイス VPC エンドポイント (AWS PrivateLink) 経由でアクセスする場合の OpenSearch Serverless の DNS 動作を確認しましょう。この基本的な仕組みを押さえておくと、以降の接続パターンを理解しやすくなります。
OpenSearch Serverless インターフェイス VPC エンドポイントの DNS 解決
OpenSearch Serverless のインターフェイス VPC エンドポイントを作成すると、3 つのプライベートホストゾーンが自動作成されます。1 つ目は、OpenSearch Serverless コレクションとダッシュボードのドメイン解決を処理する可視プライベートホストゾーン us-east-1.aoss.amazonaws.com です。2 つ目は、OpenSearch UI (OpenSearch Dashboards) の解決を管理する可視プライベートホストゾーン us-east-1.opensearch.amazonaws.com です。3 つ目は、プライベート IP アドレスへの最終的な DNS 解決を管理する非表示の内部プライベートホストゾーンです。
本記事では、OpenSearch Serverless の 2 つのプライベートホストゾーンがどのように連携するかを探ります。コレクションとダッシュボード用の可視プライベートホストゾーン us-east-1.aoss.amazonaws.com と、プライベート IP アドレスへの最終的な DNS 解決を行う非表示プライベートホストゾーンです。集中型・分散型の両アーキテクチャで、これらのプライベートホストゾーンがスケーラブルな DNS 解決をどう実現するかを検証します。次のワークフロー図は、us-east-1 リージョンの DNS 解決フローを示しています。同じパターンが他のリージョンにも適用され、DNS レコード内のリージョン識別子が変わるだけです。
ワークフローのステップは次のとおりです。
- ユーザーがコレクション URL (例:
abc.us-east-1.aoss.amazonaws.com) へのアクセスをリクエストします。 - DNS リクエストが Amazon Route 53 Resolver に送信されます。Resolver は可視プライベートホストゾーン
us-east-1.aoss.amazonaws.comを確認し、エンドポイント固有のドメインを指す CNAME レコードを見つけます。 - Route 53 Resolver は非表示の内部プライベートホストゾーンを使用して、エンドポイント固有のドメインを VPC エンドポイントのプライベート IP アドレスに解決します。
- トラフィックは、OpenSearch Serverless ネットワークポリシーで承認されたインターフェイス VPC エンドポイントから発信された場合にのみ許可されます。
この DNS 解決プロセスにより柔軟でセキュアなプライベートアクセスが可能ですが、複数の VPC、異なる AWS アカウント、オンプレミスネットワークからの接続が必要な場合は構成が複雑になります。以降のパターンでは、こうした課題に対処し、OpenSearch Serverless のネットワークアクセスと DNS 管理を簡素化する戦略を紹介します。
パターン 1: OpenSearch Serverless の集中型インターフェイス VPC エンドポイント
このパターンでは、共有サービス AWS アカウントの共有サービス VPC に OpenSearch Serverless のインターフェイス VPC エンドポイントと OpenSearch Serverless コレクションをホストする集中型アプローチを採用します。他の AWS アカウントの Amazon VPC (スポーク VPC) から、この中央エンドポイントを通じて OpenSearch Serverless コレクションにアクセスする必要があります。AWS Transit Gateway や AWS Cloud WAN で VPC を接続するハブアンドスポーク型のネットワーク設計でよく採用されます。次の図はこのアーキテクチャを示しています。
課題
オンプレミスネットワークからアクセスする場合、OpenSearch Serverless インターフェイス VPC エンドポイントへのネットワークアクセスと DNS 解決はどちらも正常に機能します。しかし、スポーク VPC からは Transit Gateway や AWS Cloud WAN 経由でエンドポイントに到達できるにもかかわらず、DNS 解決が失敗します。
OpenSearch Serverless はプライベートホストゾーン us-east-1.aoss.amazonaws.com を作成し、エンドポイントを含む VPC (この場合は共有サービス VPC) にのみ関連付けるためです。このプライベートホストゾーンをスポーク VPC と共有するだけでは問題は解決しません。ワイルドカード CNAME レコードが参照する DNS 名 privatelink.c0X.sgw.iad.prod.aoss.searchservices.aws.dev は、共有サービス VPC にのみ関連付けられたプライベートホストゾーン privatelink.c0X.sgw.iad.prod.aoss.searchservices.aws.dev に属しているためです。このプライベートホストゾーンはアカウント上では表示されず、AWS が管理しています。
解決策: Amazon Route 53 Profiles によるクロス VPC DNS 解決
集中型の DNS 解決を実現するには、Amazon Route 53 Profiles を使用します。Route 53 Profiles を使えば、DNS 関連の Amazon Route 53 設定を複数の VPC や AWS アカウントにまたがって管理・適用できます。次の図はソリューションアーキテクチャを示しています。
手順は次のとおりです。
- 共有サービス VPC に OpenSearch Serverless インターフェイス VPC エンドポイントを作成します。次のリソースが自動的に作成・関連付けられます。
-
- 2 つのデフォルトプライベートホストゾーン
- 1 つの非表示プライベートホストゾーン (この VPC に関連付け)
-
- 共有サービスアカウントで Route 53 Profile を作成します。
- OpenSearch Serverless のインターフェイス VPC エンドポイントを Route 53 Profile に関連付けます。
- Route 53 Profile が非表示プライベートホストゾーンを自動的にプロファイルに関連付けます。
- OpenSearch Serverless が自動作成したプライベートホストゾーン
us-east-1.aoss.amazonaws.comを Route 53 Profile に関連付けます。 - AWS Resource Access Manager (AWS RAM) で Route 53 Profile を組織内の他の AWS アカウントと共有します。
- スポーク VPC (異なるアカウントに配置) を Route 53 Profile に関連付けます。
共有サービスアカウントに既存の Route 53 Profile があり、すでにスポーク VPC に関連付けられている場合は、OpenSearch Serverless インターフェイス VPC エンドポイントとプライベートホストゾーン us-east-1.aoss.amazonaws.com をそのプロファイルに関連付けるだけで済みます。
これらのステップを完了すると、Route 53 Profile に関連付けられたスポーク VPC から、OpenSearch Serverless コレクションとダッシュボードエンドポイントの DNS 解決がシームレスに機能します。スポーク VPC のクライアントは、集中型 VPC エンドポイントを通じて OpenSearch Serverless コレクションとダッシュボードを解決・アクセスできます。
パターン 2: OpenSearch Serverless の分散型インターフェイス VPC エンドポイント
各スポーク VPC がそれぞれの AWS アカウントに配置され、独自の OpenSearch Serverless コレクションとインターフェイス VPC エンドポイントをホストします。ここでは次の目標を達成します。
- 共有サービス VPC で DNS 管理を一元化し、複数のスポークアカウントにデプロイされた OpenSearch Serverless コレクションに対して一貫した名前解決を提供する
- 共有サービス VPC の Route 53 Resolver インバウンドエンドポイントを通じて、オンプレミスリソースが組織全体の OpenSearch Serverless コレクションの DNS 解決を行えるようにする
次の図はこのアーキテクチャを示しています。
課題
分散型モデルでは、OpenSearch Serverless コレクションとダッシュボードの DNS 解決管理が複雑になります。各インターフェイス VPC エンドポイントが独自のプライベートホストゾーンセットを作成し、それぞれの VPC にのみ関連付けられるためです。共有サービス VPC とオンプレミスネットワークが、複数のスポークアカウントにまたがる OpenSearch Serverless コレクションとダッシュボードのドメインを統合的に解決する方法が必要になります。
解決策: 共有サービス VPC のセルフマネージドプライベートホストゾーンによるオンプレミス DNS 解決
分散型エンドポイントの集中 DNS 解決を実現するには、共有サービスアカウントにセルフマネージドプライベートホストゾーンを作成し、共有サービス VPC に関連付けます。このプライベートホストゾーン内に、各 OpenSearch Serverless コレクションエンドポイントをスポークアカウントの対応するインターフェイス VPC エンドポイント DNS 名にマッピングする CNAME レコードを作成します。次の図はこのアーキテクチャを示しています。
手順は次のとおりです。
- 共有サービスアカウントにドメイン名
us-east-1.aoss.amazonaws.comのセルフマネージドプライベートホストゾーンを作成し、共有サービス VPC に関連付けます。各 OpenSearch Serverless コレクションについて、対応するインターフェイス VPC エンドポイントのリージョナル DNS 名を指す CNAME レコードを作成します。
この設定により、オンプレミスリソースと共有サービス VPC のリソースの両方が、スポークアカウントにある OpenSearch Serverless エンドポイントを解決できるようになります。
これらのステップを完了すると、各 OpenSearch Serverless インターフェイス VPC エンドポイントは元の AWS アカウント内に留まり、セキュリティ境界とアカウントレベルの自律性が維持されます。オンプレミスシステムは、共有サービス VPC のプライベートホストゾーンによる DNS 解決を通じて、元のコレクション DNS 名 (例: {collection-name}.us-east-1.aoss.amazonaws.com) で OpenSearch Serverless コレクションとダッシュボードにアクセスできます。
まとめ
OpenSearch Serverless の導入が拡大する中、セキュアで集中管理されたネットワークアクセスの設計が重要な課題です。本記事では、DNS 管理に焦点を当てた 2 つのアーキテクチャパターンを紹介しました。
- 集中型エンドポイントモデル – 共有サービスアカウントが OpenSearch Serverless インターフェイス VPC エンドポイントを管理し、複数のスポークアカウントが集中管理されたネットワークリソースを通じて OpenSearch Serverless コレクションとダッシュボードにアクセスするパターンです。
- 集中 DNS による分散型エンドポイントモデル – 各 AWS アカウントが独自の OpenSearch Serverless インターフェイス VPC エンドポイントを管理しつつ、共有サービスアカウントのセルフマネージドプライベートホストゾーンで DNS 解決を一元化するパターンです。アカウントレベルの自律性が求められる組織に適しています。
OpenSearch Serverless の DNS アーキテクチャを理解し、Route 53 Profiles や AWS RAM などのサービスを活用することで、組織の構造やニーズに合ったセキュアなアクセスパターンを構築できます。
著者について
この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。