Amazon OpenSearch Serverless の集中型・分散型ネットワーク接続パターンの設計 – パート 1

本記事は 2026 年 3 月 24 日 に公開された「Designing centralized and distributed network connectivity patterns for Amazon OpenSearch Serverless – Part 1」を翻訳したものです。

Amazon OpenSearch Serverless は、Amazon OpenSearch Service のフルマネージドなサーバーレスオプションです。OpenSearch クラスターのプロビジョニング、設定、チューニングといった運用を省力化します。OpenSearch Serverless コレクションを中央アカウントで運用し、オンプレミス環境や複数の AWS アカウントからセキュアなプライベートアクセスが必要な場合、ネットワークアーキテクチャが重要になります。本記事では、セキュアな接続を実現する 2 つのパターンを紹介します。

ソリューション概要

OpenSearch Serverless を導入するお客様と協力する中で、要件の変化に対応するさまざまなネットワーク接続パターンについてブログ記事を公開してきました。

• 「Amazon OpenSearch Serverless のネットワーク接続パターン」では、インターネットゲートウェイ経由のパブリックアクセス、インターフェイス VPC エンドポイント経由のプライベートアクセス、マルチ VPC 接続、Route 53 VPC Resolver インバウンドエンドポイントによるオンプレミスアクセスなどの基本パターンを取り上げました。
• 「Amazon OpenSearch Serverless の集中型・分散型ネットワーク接続パターンの設計」では、Amazon Route 53 Profiles を使用した集中型インターフェイス VPC エンドポイントモデルと、セルフマネージドのプライベートホストゾーン (PHZ) による集中 DNS 管理を備えた分散型エンドポイントモデルという 2 つの高度なマルチアカウントパターンを紹介しました。

本記事では、上記のパターンをさらに発展させ、エンタープライズの追加要件に対応します。多数の OpenSearch Serverless コレクションを集中管理しつつ、複数のアカウントやオンプレミスからアクセスする必要がある場合、次のような課題があります。

• アカウント間の VPC エンドポイント調整: 多数のコンシューマーアカウントにまたがるエンドポイントのプロビジョニングとライフサイクル管理は運用負荷を増大させます
• コンシューマーごとの DNS 設定管理: 新しいアカウントやオンプレミス環境ごとに独自の DNS 設定が必要となり、複雑さが増します
• ネットワーク責務とアプリケーション所有権の分離: 明確な境界がないと、ネットワークチームとアプリケーションチームが密結合になり、双方の作業が遅くなります

このアーキテクチャは、責務を明確に分離して課題に対処します。中央ネットワーキングアカウントが Route 53 Profiles を共有し、スポークアカウント全体の DNS 伝播を管理します。OpenSearch Serverless アカウントのオーナーは、VPC エンドポイントと関連する PHZ を完全に制御できます。アプリケーションオーナーは、DNS 設定とコレクション管理を自律的に行えます。

1 つの VPC エンドポイントで AWS リージョン内の複数の OpenSearch Serverless コレクションに対応でき、複雑さとコストを削減できます。ネットワークチームが接続インフラストラクチャを管理し、アプリケーションチームは OpenSearch Serverless コレクション、データアクセスポリシー、コレクション固有の DNS 設定を独立して管理します。AWS Direct Connect や AWS Site-to-Site VPN 経由のオンプレミスネットワークと、複数の AWS アカウントのコンピューティングリソースから、統一されたネットワークパスで接続できます。

ネットワーク管理者とアプリケーションチームが独立して作業できるため、組織の拡大に合わせてスケールするガバナンスモデルを実現できます。本記事では、ハイブリッドアクセスを網羅する 2 つの補完的なパターンを取り上げます。パターン 1 はオンプレミスアクセス、パターン 2 はマルチアカウントアクセスで、いずれも集中型インターフェイス VPC エンドポイントと Route 53 Profiles を使用します。

先に進む前に、OpenSearch Serverless インターフェイス VPC エンドポイントの DNS 解決を理解しておく必要があります。OpenSearch Serverless インターフェイス VPC エンドポイントを作成すると、AWS は自動的に 4 つのプライベートホストゾーンをプロビジョニングします。コレクション、ダッシュボード、FIPS エンドポイント用の 3 つの可視プライベートホストゾーンと、1 つの非表示の内部プライベートホストゾーンが連携して、コレクションエンドポイントをプライベート IP アドレスに解決します。DNS 解決メカニズムの詳細は、以前のブログ記事を参照してください。

パターン 1: 集中型 VPC エンドポイントと Route 53 Profiles を使用したマルチアカウントアーキテクチャでのオンプレミスから複数の OpenSearch Serverless コレクションへのアクセス

このアーキテクチャは 3 つのコンポーネントで構成されます。

• コレクションとインターフェイス VPC エンドポイントをホストする中央 OpenSearch Serverless アカウント
• Route 53 Profiles とインバウンドリゾルバーを所有する中央ネットワーキングアカウント
• AWS Direct Connect または AWS Site-to-Site VPN で接続されたオンプレミス環境

次の図は、3 つのコンポーネントにまたがるアーキテクチャを示しています。オンプレミスクライアントからの DNS クエリが Route 53 Profile とインバウンドリゾルバーを通じてどのように解決され、データトラフィックが AWS PrivateLink で OpenSearch Serverless コレクションに到達するかを示しています。

(A) Route 53 Profiles は中央ネットワーキングアカウントで作成され、AWS Resource Access Manager (AWS RAM) を通じて中央 OpenSearch Serverless アカウントと共有されます。中央 OpenSearch Serverless アカウントは、エンドツーエンドのプライベート DNS 解決に必要な PHZ とインターフェイス VPC エンドポイントを、共有された Route 53 Profiles に関連付けます。

(B) 中央 AOSS VPC には、プライベート DNS が有効な OpenSearch Serverless 用インターフェイス VPC エンドポイントがあります。4 つのプライベートホストゾーン (PHZ) があります。

• us-east-1.aoss.amazonaws.com
• us-east-1.opensearch.amazonaws.com
• us-east-1.aoss-fips.amazonaws.com
• privatelink.c0X.sgw.iad.prod.aoss.searchservices.aws.dev

(C) 最初の 3 つの PHZ は、Route 53 Profile に手動で関連付ける必要があります。

(D) 4 つ目は、VPC エンドポイントを Profile に関連付けると自動的に関連付けられます。

(E) オンプレミス側では、DNS リゾルバーに us-east-1.aoss.amazonaws.com の条件付き転送を設定し、クエリを中央ネットワーキングアカウントの Route 53 Resolver インバウンドエンドポイントに転送します。

DNS 解決フロー

1. オンプレミスクライアントが collection-id-1.us-east-1.aoss.amazonaws.com へのリクエストを開始します。
2. オンプレミス DNS リゾルバーは us-east-1.aoss.amazonaws.com の条件付きフォワーダーを持ち、AWS Direct Connect または AWS Site-to-Site VPN 経由で中央ネットワーキング VPC の Route 53 Resolver インバウンドエンドポイント IP にクエリを転送します。
3. インバウンドリゾルバーがクエリを受信し、Route 53 VPC Resolver に渡します。
4. VPC Resolver は、中央ネットワーキング VPC に関連付けられた Route 53 Profiles を確認します。Profiles により、中央 OpenSearch Serverless VPC の可視および非表示の PHZ にアクセスできます。
5. VPC Resolver は可視 PHZ でワイルドカード CNAME *.us-east-1.aoss.amazonaws.com をインターフェイス VPC エンドポイント (VPCE) DNS 名に一致させます。次に、非表示の PHZ で VPCE DNS 名を中央 OpenSearch Serverless VPC のインターフェイス VPC エンドポイントのプライベート Elastic Network Interface (ENI) IP アドレスに解決します。
6. プライベート ENI IP アドレスは、インバウンドリゾルバーエンドポイントを通じてオンプレミス DNS リゾルバーに返され、オンプレミスクライアントに到達します。

データフロー

1. オンプレミスクライアントは、解決されたプライベート ENI IP アドレスに対して、TLS Server Name Indication (SNI) ヘッダーを collection-id-1.us-east-1.aoss.amazonaws.com に設定した HTTPS リクエストを送信します。リクエストは、AWS Direct Connect または AWS Site-to-Site VPN 経由で AWS Transit Gateway または AWS Cloud WAN を通じてルーティングされます。
2. トラフィックは中央 OpenSearch Serverless VPC のインターフェイス VPC エンドポイント ENI に到達します。
3. インターフェイス VPC エンドポイントがリクエストを OpenSearch Serverless サービスに転送し、Collection 1 にルーティングされます。

Collection 2 にアクセスするには、collection-id-2.us-east-1.aoss.amazonaws.com を使用して同じフローに従います。ワイルドカード DNS は同じインターフェイス VPC エンドポイントに解決され、OpenSearch Serverless サービスがホスト名に基づいて適切なコレクションにルーティングします。

パターン 2: 集中型 VPC エンドポイントと Route 53 Profiles を使用したスポークアカウントから複数の OpenSearch Serverless コレクションへのアクセス

パターン 1 はオンプレミスアクセスに対応しますが、複数の AWS アカウントにまたがるコンピューティングリソースや分散アプリケーションからのアクセスも必要になる場合があります。このパターンでは、スポークアカウント VPC 内のコンピューティングリソースが、単一の共有インターフェイス VPC エンドポイントを通じて、中央 OpenSearch Serverless VPC にホストされた複数の OpenSearch Serverless コレクションにプライベートにアクセスできます。

次の例では、コンピューティングリソースとして Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使用してパターンを説明します。ただし、スポーク VPC 内のどのコンピューティングリソースにも同じアプローチを適用できます。

次の図は、このマルチアカウントアーキテクチャを示しています。スポークアカウント VPC が、共有された Route 53 Profile と AWS PrivateLink を通じて、中央 OpenSearch Serverless コレクションへの DNS 解決とデータトラフィックのルーティングをどのように行うかを、パターン 1 のオンプレミスアクセスパスとともに示しています。

(A) 中央ネットワーキングアカウントで作成された Route 53 Profiles は、AWS RAM を通じて OpenSearch Serverless アカウントとスポークアカウントの両方に共有されます。OpenSearch Serverless アカウントはインターフェイス VPC エンドポイントとプライベートホストゾーン (PHZ) を Profiles に関連付け、各スポークアカウントは Profiles を自身の VPC に関連付けます。スポーク VPC は、独自のインターフェイス VPC エンドポイント、PHZ、手動 DNS 設定なしで、OpenSearch Serverless コレクションエンドポイントの DNS 解決が可能になります。

(B) 中央 AOSS VPC には、プライベート DNS が有効な OpenSearch Serverless 用インターフェイス VPC エンドポイントがあります。4 つのプライベートホストゾーン (PHZ) があります。

• us-east-1.aoss.amazonaws.com
• us-east-1.opensearch.amazonaws.com
• us-east-1.aoss-fips.amazonaws.com
• privatelink.c0X.sgw.iad.prod.aoss.searchservices.aws.dev

(C) 最初の 3 つの PHZ は、Route 53 Profile に手動で関連付ける必要があります。

(D) 4 つ目は、VPC エンドポイントを Profile に関連付けると自動的に関連付けられます。

DNS 解決フロー

1. Spoke VPC 1 の Amazon EC2 インスタンスが collection-id-1.us-east-1.aoss.amazonaws.com へのリクエストを開始し、Route 53 VPC Resolver に DNS クエリを送信します。
2. VPC Resolver は、スポーク VPC に関連付けられた Route 53 Profiles を検索します。Profiles には、中央 OpenSearch Serverless アカウントの PHZ が含まれています。
3. 可視 PHZ がワイルドカード CNAME *.us-east-1.aoss.amazonaws.com を VPCE DNS 名に一致させます。非表示の PHZ が VPCE DNS 名を中央 OpenSearch Serverless VPC のインターフェイス VPC エンドポイントのプライベート ENI IP アドレスに解決します。
4. Route 53 がプライベート ENI IP アドレスを Amazon EC2 インスタンスに返します。

データフロー

1. Amazon EC2 インスタンスは、解決されたプライベート ENI IP アドレスに対して、TLS SNI ヘッダーを collection-id-1.us-east-1.aoss.amazonaws.com に設定した HTTPS リクエストを送信します。リクエストは、AWS Transit Gateway または AWS Cloud WAN を通じて中央 OpenSearch Serverless VPC にルーティングされます。
2. リクエストは中央 OpenSearch Serverless VPC のインターフェイス VPC エンドポイント ENI に到達します。
3. インターフェイス VPC エンドポイントがリクエストを OpenSearch Serverless サービスに転送し、Collection 1 にルーティングされます。

Collection 2 にアクセスするには、collection-id-2.us-east-1.aoss.amazonaws.com を使用して同じフローに従います。Spoke Account 2 やその他の Route 53 Profiles が関連付けられたスポークアカウントのリソースにも同様に適用されます。

AWS RAM のリソース関連付け用権限設定

中央ネットワーキングアカウントが AWS RAM を通じて Route 53 Profiles を共有する場合、デフォルトの AWS マネージド権限ポリシー (AWSRAMPermissionRoute53ProfileAllowAssociationActions) は、Profile と VPC の関連付けと関連付け解除、Profiles の詳細表示、関連付けの一覧表示のみを許可します。OpenSearch Serverless アカウントがインターフェイス VPC エンドポイントと PHZ を共有された Profiles に関連付けるために必要な route53profiles:AssociateResourceToProfile や route53profiles:DisassociateResourceFromProfile アクションは含まれていません。

リソース関連付けを有効にするには、中央ネットワーキングアカウントが AWS RAM で以下のアクションを含むカスタムマネージド権限を作成する必要があります。

• route53profiles:AssociateProfile
• route53profiles:AssociateResourceToProfile
• route53profiles:DisassociateProfile
• route53profiles:DisassociateResourceFromProfile
• route53profiles:GetProfile
• route53profiles:GetProfileResourceAssociation
• route53profiles:ListProfileAssociations
• route53profiles:ListProfileResourceAssociations
• route53profiles:ListProfiles

カスタム権限は、中央 OpenSearch Serverless アカウントが PHZ とインターフェイス VPC エンドポイントを Profiles に関連付ける前に、RAM リソース共有にアタッチする必要があります。

コストに関する考慮事項

本記事で説明したアーキテクチャパターンでは、Amazon Route 53 (ホストゾーン、DNS クエリ、Resolver エンドポイント) や Route 53 Profiles など、全体のコストに影響する複数の AWS サービスを使用します。最新の料金については、公式の AWS 料金ページを確認してください。

• Amazon Route 53 の料金
• AWS PrivateLink の料金

ワークロードに合わせた詳細なコスト見積もりには、AWS Pricing Calculator をご利用ください。

まとめ

本記事では、単一の集中型インターフェイス VPC エンドポイントと Route 53 Profiles を使用して、オンプレミス環境と分散 AWS アカウントの両方から複数の OpenSearch Serverless コレクションにセキュアなプライベートアクセスを提供する方法を紹介しました。このアーキテクチャは、OpenSearch Serverless コレクションとネットワークインフラストラクチャを専用アカウントに集約し、Route 53 Profiles でアカウント間の DNS を伝播します。アカウントごとの VPC エンドポイント、手動の PHZ 関連付け、スポークアカウントでのカスタム DNS 設定が不要になります。

このパターンは、単一のチームやビジネスユニットが OpenSearch Serverless コレクションを集中管理する場合に適しています。しかし、多くのエンタープライズでは、ビジネスユニットが独自の AWS アカウントで OpenSearch Serverless コレクションを独立して管理し、それぞれのインターフェイス VPC エンドポイント、セキュリティポリシー、コレクションライフサイクルを持つ必要があります。パート 2 では、各ビジネスユニットが自身のアカウントで OpenSearch Serverless を運用しつつ、Route 53 Profiles による集中型ネットワーク接続と DNS 管理を活用する分散所有モデルについて説明します。インターフェイス VPC エンドポイントとコレクションが複数のアカウントに分散している場合の DNS 解決と Route 53 Profiles の設定の変更点を取り上げます。

詳細については、OpenSearch Serverless VPC エンドポイントのドキュメントと Route 53 Profiles のドキュメントを参照してください。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。