この記事はAndrei StoianによるNetworking architecture for ODB@AWS deploymentを日本語に翻訳したものです。
2026年5月21日
ODB@AWS製品、とくにすべてのODB@デプロイメント全般に関しては、多くの統合オプションがあります。このトピックにおける統合とは、既存の顧客AWSネットワーキング・アーキテクチャに対して、構成やアーキテクチャの変更を最小限に抑えながらODB@AWS製品を組み込む方法を意味します。
この記事では、分離された複数の環境で複数のODB Networkを使用する際に、構成作業を最小化するODB@AWSネットワーク設計を紹介します。
以下のネットワーク・トポロジは、最も重要な要素を含めた簡略化された形でデプロイされたアーキテクチャを示しています。
このトポロジについて少し説明し、ODB@AWS製品統合において、構成変更とメンテナンス負荷を最小限に抑えるうえで、なぜこの設計が最適化されているのかを見ていきます。
ここでは、Production、Production DR、NonProduction、NonProduction DRという各環境ごとに1つずつODB Networkがあります。図からわかるように、個別のAZを使用しています。AZ 1はアクティブなProductionおよびNonProduction用に構成され、AZ 2には同じAWSリージョン内でDRを構成します。
Active Data Guardは、LPGを使用してOCIインフラストラクチャ経由でルーティングされます。
AZ 1内のすべてのODB Networkは、Transit VPCにピアリングされています。このTransit VPCは、特定のAWS cWANセグメントにアタッチされています。
AZ 2内のすべてのODB Networkは、別のDR Transit VPCにピアリングされています。
この構成について、1つの疑問が出るかもしれません。なぜ、以下の図のように、すべてのODB Networkを1つのTransit VPCだけにピアリングできないのでしょうか。
この疑問に答えるには、ODB Networkは通常のVPCとは異なるという点を思い出す必要があります。Transit VPCには2つのサブネットにcWANアタッチメントがあります。1つのサブネットはAZ1に、もう1つはAZ2に構成されます。これにより、Transit VPC内の異なるAZに構成された両方のサブネットへの接続が提供されます。しかし、ODB Networkに関して、Transit VPC経由で異なるAZ間のトラフィックをルーティングする場合、cWANおよびTGWにはいくつかの制限があります。
Transit VPCの主な機能は、Spoke VPCからODB Networkへのルーティング・パス、およびODB NetworkからSpoke VPCへのルーティング・パスを作成することです。このデプロイメントでは、このVPCには副次的な役割もあります。
- 各ODB NetworkへのIP接続をテストするためのテスト用EC2インスタンスを含みます。これにより、すべてが正しくデプロイされていることを確認できます。
- Spoke VPCからODB NetworkへのDNS解決、およびODB NetworkからSpoke VPCまたはオンプレミス環境へのDNS解決におけるDNSアグリゲータとして機能します。
顧客はExadataクラスタにカスタム・ドメイン名を使用しており、ODBのデプロイメントが準備完了になると、各ODB Networkにはクライアント・サブネット内に作成されたDNSリスナーIPアドレスが割り当てられます。
このネットワーキング設計には、Transit VPC内に2つのカスタムDNSサーバーが含まれます。1つはAZ 1、もう1つはAZ2のDR DNSサーバーです。これらのDNSサーバーは、中央DNS Hubとして機能します。
Spoke VPCからODB NetworkへのDNS解決では、各ODBカスタム・ドメインに対してRoute 53のDNS条件付き転送ルールを設定し、そのターゲットとしてTransit VPC内のDNSサーバーを使用します。DNSサーバーには、各ODB Networkカスタム・ドメインに対応する条件付き転送ルールが構成されており、それぞれのDNSリスナーをターゲットにしています。
以下は、Spoke VPCからODB NetworkへのDNS解決ホップを示しています。
注: DNSサーバーをバイパスし、Spoke VPCから各ODB Network内のDNSリスナー・エンドポイントへDNS問合せを直接送信することもできます。このシナリオでは、セキュリティ要件により、DNSトラフィックと構成に対する高い可視性を維持するため、中央DNSサーバー管理を採用しています。
各ODB Networkから他のSpoke VPCまたはオンプレミスへのDNS解決には、DNSフォワーディング・エンドポイントが必要です。DNSフォワーディング・エンドポイントは自動的に作成されます。解決が必要な特定のAWSドメインに対して、各ODB Networkに対応するOCI Child Site内にDNS条件付き転送ルールを作成し、そのターゲットとしてTransit VPC内のDNSサーバーを指定します。Transit VPCのDNSサーバーには、AWS Spoke VPC向けのDNS条件付き転送ルールが構成されており、それらはさらに顧客AWSインフラストラクチャ内の別のRoute 53リスナー・エンドポイントまたは他のDNSサーバーをターゲットにします。
ODB NetworkからSpoke VPCへのDNS解決を、簡略化した図で示します。
以上が、使用する各AZにTransit VPCを配置し、すべてのODB Networkに対してDNSアグリゲータ機能を実装することで実現できる、ODB@AWSの設計統合です。