Amazon Web Services ブログ
Amazon OpenSearch Serverless の集中型・分散型ネットワーク接続パターンの設計 – パート 2
本記事は 2026 年 3 月 24 日 に公開された「Designing centralized and distributed network connectivity patterns for Amazon OpenSearch Serverless – Part 2」を翻訳したものです。
本記事は、Amazon OpenSearch Serverless のハイブリッドマルチアカウントアクセスパターンに関する 2 部構成シリーズのパート 2 です。パート 1 では、単一のアカウントで複数の OpenSearch Serverless コレクションと共有 VPC エンドポイントをホストする集中型アーキテクチャを紹介しました。単一の事業部門やチームが組織を代表してコレクションを管理する場合に適したアプローチです。
しかし、多くの企業では複数の事業部門が OpenSearch Serverless インフラストラクチャを独立して所有する必要があります。各事業部門が自身の AWS アカウント内でコレクション、セキュリティポリシー、VPC エンドポイントを管理したい場合、パート 1 の集中型モデルでは対応できません。
本記事では、マルチ事業部門シナリオに対応するパターンを紹介します。中央のネットワーキングアカウントがカスタムプライベートホストゾーン (PHZ) を管理し、各事業部門の VPC エンドポイントを指す CNAME レコードを保持します。DNS 管理と接続性を集中化しつつ、各事業部門にコレクションとインフラストラクチャの自律性を確保するアプローチです。
複数の事業部門がある場合の課題
複数の事業部門がそれぞれの AWS アカウントで OpenSearch Serverless コレクションを独立して管理する場合、各アカウントには独自の VPC エンドポイントとプライベートホストゾーンがあります。各アカウントのプライベートホストゾーンは対応する VPC 内でのみ機能するため、組織全体で DNS が分断されます。スポークアカウントやオンプレミス環境の利用者は、追加の DNS 設定なしに他のアカウントのコレクションエンドポイントを名前解決できません。
利用側の VPC ごとに個別の PHZ アソシエーションを管理するのはスケールせず、各事業部門にすべての利用側との DNS 調整を求めると運用負荷が増大します。各チームに自律性を与えつつ、DNS 管理と接続性を集中化するネットワークアーキテクチャが必要です。
ソリューションの概要
本アーキテクチャは、コレクションと VPC エンドポイントの所有権を各事業部門に残しつつ、DNS 管理をネットワーキングアカウントに集中化することで課題を解決します。ネットワーキングアカウントは、各コレクションエンドポイントを対応する VPC エンドポイントのリージョナル DNS 名にマッピングする CNAME レコードを含むカスタム PHZ を管理します。カスタム PHZ は Route 53 Profile に関連付けられ、AWS Resource Access Manager (AWS RAM) を通じてスポークアカウントに共有されます。オンプレミスの DNS 解決は、中央ネットワーキング VPC 内の Route 53 Resolver インバウンドエンドポイントを経由し、同じカスタム PHZ を使用します。
本記事では 2 つの補完的なパターンを紹介します。パターン 1 はオンプレミスから複数の事業部門アカウントのコレクションへのアクセス、パターン 2 はスポークアカウントから同じコレクションへのアクセスです。どちらもネットワーキングチームが管理する集中型カスタム PHZ に依存します。
パターン 1: オンプレミスから複数の事業部門アカウントの OpenSearch Serverless コレクションへのアクセス
パターン 1 では、オンプレミスのクライアントが複数の事業部門アカウントにホストされた OpenSearch Serverless コレクションにプライベートにアクセスできます。各事業部門は独自の VPC エンドポイントを持ちます。次の図は、マルチ事業部門アーキテクチャを示しています。オンプレミスの DNS クエリが中央ネットワーキングアカウントのカスタム PHZ を通じて解決され、AWS PrivateLink を経由して適切な事業部門の VPC エンドポイントにルーティングされる仕組みです。
(A) Route 53 Profile は中央ネットワーキングアカウントで作成され、AWS Resource Access Manager (AWS RAM) を通じて中央の OpenSearch Serverless アカウントに共有されます。
(B) 中央ネットワーキングアカウントには、ドメイン us-east-1.aoss.amazonaws.com のカスタム PHZ があり、中央ネットワーキングアカウントの VPC と Route 53 Profile に関連付けられています。
(C) PHZ には、各事業部門の VPC エンドポイントを指す CNAME レコードが含まれています。
(D) 各事業部門アカウントでは、VPC エンドポイントのプライベート DNS が有効になっています。
(E) VPC エンドポイント作成時に以下の PHZ が自動的に作成され、事業部門の VPC に関連付けられます。Route 53 Profile に依存せず VPC 内でローカルに DNS 解決が機能します。
us-east-1.aoss.amazonaws.comus-east-1.opensearch.amazonaws.comus-east-1.aoss-fips.amazonaws.comprivatelink.c0X.sgw.iad.prod.aoss.searchservices.aws.dev
DNS 解決フロー
- オンプレミスのクライアントが
bu-1-collection-id-1.us-east-1.aoss.amazonaws.comへのリクエストを開始します。 - オンプレミスの DNS リゾルバーは
us-east-1.aoss.amazonaws.comの条件付きフォワーダーを持ち、AWS Direct Connect または AWS Site-to-Site VPN 経由で中央ネットワーキング VPC 内の Route 53 Resolver インバウンドエンドポイント IP にクエリを転送します。 - インバウンド Resolver エンドポイントが、中央ネットワーキング VPC の Route 53 VPC Resolver にクエリを渡します。
- VPC Resolver が、中央ネットワーキング VPC に関連付けられたカスタム PHZ を検出します。
bu-1-collection-id-1.us-east-1.aoss.amazonaws.comの CNAME レコードは、BU1 の VPC エンドポイントのリージョナル DNS 名 (例:vpce-1234567890abcdefghi.a2oselk.vpce-svc-0c3ebf9a1a3ad247b.us-east-1.vpce.amazonaws.com) に解決されます。 - VPC Resolver が VPC エンドポイントのリージョナル DNS 名を Elastic Network Interface (ENI) のプライベート IP アドレスに解決します。
- オンプレミスのクライアントは AWS Direct Connect または AWS Site-to-Site VPN 経由で AWS Transit Gateway または AWS Cloud WAN を通じて接続しているため、トラフィックはプライベートネットワーク接続を通じて BU1 の VPC エンドポイント ENI に到達します。
データフロー
- オンプレミスのクライアントが、解決された IP アドレスに対して TLS Server Name Indication (SNI) ヘッダーを
bu-1-collection-id-1.us-east-1.aoss.amazonaws.comに設定した HTTPS リクエストを、AWS Direct Connect または AWS Site-to-Site VPN 経由で AWS Transit Gateway または AWS Cloud WAN を通じて送信します。 - トラフィックが BU1 の OpenSearch Serverless VPC 内の VPC エンドポイント ENI に到達します。
- VPC エンドポイントがリクエストを OpenSearch Serverless サービスに転送し、サービスがホスト名を検査して BU1 Collection 1 にルーティングします。
BU2 のコレクションにアクセスする場合、クライアントは bu-2-collection-id-1.us-east-1.aoss.amazonaws.com を使用して同じフローに従います。カスタム PHZ には BU2 の VPC エンドポイントを指す別の CNAME レコードがあり、OpenSearch Serverless サービスがホスト名に基づいて適切なコレクションにルーティングします。
パターン 2: スポークアカウントから複数の事業部門アカウントの OpenSearch Serverless コレクションへのアクセス
パターン 1 はオンプレミスアクセスに対応しますが、スポークアカウントのコンピューティングリソースや分散アプリケーションから複数の事業部門アカウントの OpenSearch Serverless コレクションへのアクセスが必要な場合もあります。パターン 2 では、スポークアカウント VPC 内のコンピューティングリソースが、中央ネットワーキングアカウントの集中型プライベートホストゾーン (PHZ) を通じて、複数の事業部門アカウントの OpenSearch Serverless コレクションにプライベートにアクセスできます。
以下の例では、パターンを説明するためにコンピューティングリソースとして Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使用します。ただし、スポーク VPC 内のあらゆるコンピューティングリソースに同じアプローチが適用できます。次の図は、マルチ事業部門・マルチスポークアーキテクチャを示しています。スポーク VPC が共有 Route 53 Profile とカスタム PHZ を通じて DNS を解決し、AWS PrivateLink 経由で適切な事業部門の OpenSearch Serverless コレクションにトラフィックをルーティングする仕組みです。
(A) 中央ネットワーキングアカウントで作成された Route 53 Profile は、AWS RAM を通じてすべてのスポークアカウントと中央の OpenSearch Serverless アカウントに共有されます。
(B) 中央ネットワーキングアカウントには、ドメイン us-east-1.aoss.amazonaws.com のカスタム PHZ があり、中央ネットワーキングアカウントの VPC と Route 53 Profile に関連付けられています。
(C) PHZ には、各事業部門の VPC エンドポイントを指す CNAME レコードが含まれています。
(D) 各事業部門アカウントでは、VPC エンドポイントのプライベート DNS が有効になっています。
(E) VPC エンドポイント作成時に以下の PHZ が自動的に作成され、事業部門の VPC に関連付けられます。Route 53 Profile に依存せず VPC 内でローカルに DNS 解決が機能します。
us-east-1.aoss.amazonaws.comus-east-1.opensearch.amazonaws.comus-east-1.aoss-fips.amazonaws.comprivatelink.c0X.sgw.iad.prod.aoss.searchservices.aws.dev
DNS 解決フロー
- BU1 スポーク VPC 1 内の Amazon EC2 インスタンスが
bu-1-collection-id-1.us-east-1.aoss.amazonaws.comへのリクエストを開始し、Route 53 VPC Resolver に DNS クエリを送信します。 - VPC Resolver がスポーク VPC に関連付けられた Route 53 Profile を検出します。
- Profile は中央ネットワーキングアカウントで管理されるカスタム PHZ (
us-east-1.aoss.amazonaws.com) を参照します。bu-1-collection-id-1.us-east-1.aoss.amazonaws.comの CNAME レコードは、BU1 の VPC エンドポイントのリージョナル DNS 名に解決されます。 - VPC Resolver が VPC エンドポイントのリージョナル DNS 名を ENI のプライベート IP アドレスに解決します。
- スポーク VPC は AWS Transit Gateway または AWS Cloud WAN を通じて BU1 の VPC に接続しているため、トラフィックはプライベートネットワーク接続を通じて VPC エンドポイント ENI に到達します。
データフロー
- Amazon EC2 インスタンスが、解決された IP アドレスに対して TLS SNI ヘッダーを
bu-1-collection-id-1.us-east-1.aoss.amazonaws.comに設定した HTTPS リクエストを、AWS Transit Gateway または AWS Cloud WAN 経由で BU1 の OpenSearch Serverless VPC にルーティングして送信します。 - リクエストが BU1 の OpenSearch Serverless VPC 内の VPC エンドポイント ENI に到達します。
- VPC エンドポイントがリクエストを OpenSearch Serverless サービスに転送し、サービスがホスト名を検査して BU1 Collection 1 にルーティングします。
BU2 のコレクションにアクセスする場合、bu-2-collection-id-1.us-east-1.aoss.amazonaws.com を使用して同じフローが適用されます。カスタム PHZ が BU2 の VPC エンドポイントに解決し、Transit Gateway を通じて BU2 の VPC にトラフィックをルーティングします。Route 53 Profile が関連付けられたスポークアカウントのリソースにも同様に適用されます。
カスタム PHZ のレコード構造
中央ネットワーキングアカウントのカスタム PHZ はドメイン us-east-1.aoss.amazonaws.com を使用し、各コレクションエンドポイントを対応する VPC エンドポイントのリージョナル DNS 名にマッピングする CNAME レコードを含みます。同じ事業部門アカウント内のコレクションは同じ VPC エンドポイントを共有するため、CNAME レコードは同じリージョナル DNS 名を指します。異なる事業部門アカウントのコレクションは異なる VPC エンドポイントを指します。
カスタム PHZ の管理
パート 1 では VPC エンドポイントから自動作成される PHZ が DNS 解決を処理しましたが、パターン 2 ではネットワーキングチームがカスタム PHZ を手動で管理する必要があります。事業部門が新しいコレクションを追加した場合、ネットワーキングチームがカスタム PHZ に対応する CNAME レコードを追加する必要があります。
コストに関する考慮事項
本記事で紹介したアーキテクチャパターンでは、Amazon Route 53 (ホストゾーン、DNS クエリ、Resolver エンドポイント) や Route 53 Profile など、複数の AWS サービスを使用します。最新の料金については、公式の AWS 料金ページを確認してください。
ワークロードに合わせたコスト見積もりには、AWS Pricing Calculator をご利用ください。
まとめ
本記事では、オンプレミスのクライアントとスポークアカウントのリソースから、複数の事業部門アカウントに分散した OpenSearch Serverless コレクションにプライベートにアクセスする方法を紹介しました。ネットワーキングアカウントのカスタム PHZ で DNS 管理を集中化し、Route 53 Profile で共有することで、アカウント間の PHZ アソシエーション調整を不要にしつつ、各事業部門にコレクションと VPC エンドポイントの所有権を維持できます。
パート 1 と合わせて、OpenSearch Serverless へのハイブリッドマルチアカウントアクセスに対する 2 つのアーキテクチャアプローチが揃いました。集中型モデルは単一のアカウントがすべてのコレクションと共有 VPC エンドポイントを所有し、分散型モデルは複数の事業部門がそれぞれのコレクションと VPC エンドポイントを管理します。単一のチームが組織を代表してコレクションを管理する場合は集中型モデルを、事業部門が OpenSearch Serverless インフラストラクチャの独立した所有権を必要とする場合は分散型モデルを選択してください。
詳細については、Amazon OpenSearch Serverless VPC エンドポイントのドキュメントと Route 53 Profile のドキュメントを参照してください。
著者について
この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。