Amazon Web Services ブログ

Oracle Database@AWS ネットワーク接続パターンの実装

本投稿は、 Sameer Malik 、Anvesh Koganti、Shubham Singhによる記事「Implement network connectivity patterns for Oracle Database@AWS」を翻訳したものです。

Oracle Database@AWS（ODB@AWS）は、Amazon Web Services（AWS）データセンター内に配置されたOracle Cloud Infrastructure（OCI）が管理するOracle Exadataインフラストラクチャへのアクセスに使用できるサービスです。ODB @AWS を使用すると、オンプレミスのOracle Exadataデプロイメントと同じパフォーマンスと機能を維持しながら、Oracle ExadataワークロードをAWSに移行できます。Oracle ExadataとAWS上で稼働しているアプリケーションとの間に低レイテンシーの接続を確立することで、アプリケーションのレイテンシーが短縮されるというメリットがあります。さらに、Oracle Database @AWS を他の AWS サービスと統合して、Oracle Databaseアプリケーションの可用性とスケーラビリティを向上させることができます。

この投稿では、ODBネットワークとAWSにデプロイされている他のリソースとオンプレミスネットワークとの接続に、さまざまなIPルーティングベースのネットワーク接続パターンを実装する方法を示します。このパターンは、IPアドレス空間が重複しておらず、従来のレイヤー3接続が必要な場合に適しています。

この記事で取り上げる接続パターンは次のとおりです。

  • アプリケーション用の仮想プライベートクラウド（VPC）とODBネットワーク間の1対1の接続
  • AWS Transit Gatewayを使用した、マルチVPCまたはオンプレミスのインフラストラクチャとODBネットワーク間のスケーラブルな単一リージョン接続
  • AWS Cloud WANを使用して、マルチVPCまたはオンプレミスのインフラストラクチャとODBネットワーク間のスケーラブルなグローバル接続

本投稿の理解を深めるために、Amazon Virtual Private Cloud（Amazon VPC）、AWS Direct Connect、Amazon Route 53 Resolver endpoints、Transit Gateway、AWS Cloud WANなどのAWSサービスを理解しておくことをお勧めします。

基本の理解

以下は、ネットワーク接続に不可欠な ODB @AWS のコアコンポーネントの概要です。詳細については、Oracle Database @AWS ユーザーガイドを参照してください。

  • ODBネットワーク — ODBネットワークは、AWSアベイラビリティーゾーン内のOracleインフラストラクチャをホストするプライベートで独立したネットワークです。標準のVPCとは異なり、ODBネットワークはインターネット接続がなく、ODB @AWS リソースのみをサポートします。
  • ODBピアリング — ODBピアリングは、ODBネットワークとAmazon VPC間のプライベートネットワーク接続を確立し、アプリケーションが同じネットワーク上にあるかのようにOracle Databaseと通信できるようにします。ODBピアリングはAWS環境とOracle環境をつなぎ、ピアリングされたVPCに接続された特定のAWSネットワークサービスを使用してトラフィックがODBネットワークに到達できるようにするルーティング機能をサポートします。次の図は、ピアリングされたVPCとODBネットワークのピアリング関係を示しています。

  • ピアリングCIDRによるアクセス制御 — ピアリングCIDRは、ネットワークレベルのアクセス制御リスト（ACL）として機能する設定です。ODBネットワーク内のOracle Databaseリソースに到達できるIP CIDR範囲を指定して管理できます。ピアリングされたCIDRを設定すると、Oracle OCI側で自動化が開始され、特定のプロトコルとポート上の特定のCIDRとの間のトラフィックを許可するリソースが存在するOracle Virtual Cloud Network（Amazon VPCと同等のもの）にリンクされたルートルールとセキュリティルールが設定されます。VPC範囲全体ではなく、特定のサブネットCIDRを含めることで、きめ細かなセキュリティ管理が可能になります。ピアリングCIDRとOCI自動化の詳細については、この記事の後半にある考慮事項のセクションを参照してください。
  • ピアリングされたVPCの使用パターン — ピアリングされたVPCは複数の目的を果たすことができます。ダイレクトアプリケーションVPCとして機能し、専用のOracleワークロードに最もシンプルなネットワークパスを提供します。あるいは、トランジティブルーティングを使用するトランジットVPCとして機能して、Transit GatewayまたはAWS Cloud WANベースのハブアンドスポークアーキテクチャを介して複数のVPCやオンプレミスネットワークからODBネットワークにアクセスできるようにすることもできます。ピアリングされたVPCは、ワークロードをホストするアプリケーションVPCとしても、他のネットワークをODBネットワークに接続するTransit VPCとしても、両方の役割を同時に果たすことができます。

DNSの構成

ODB@AWS は ODB ネットワーク内で DNS を管理し、仮想マシン (VM) クラスターの完全修飾ドメイン名 (FQDN) を作成します。デフォルトでは、これらは*.oraclevcn.comのドメインパターンを使用します（myhost.oraclevcn.comなど、oraclevcn.comに追加されるプレフィックスをここで指定できます）。別の方法として、独自の完全なドメイン（myhost.myodb.comなど）を使用してカスタムドメイン名を設定することもできます。どちらのドメイン構成を選択したとしても、これらのドメイン名を解決するには、VPCからのDNSクエリをODBネットワークのDNSインフラストラクチャに転送する必要があります。

DNSアーキテクチャは次のコンポーネントで構成されています。

  • Route 53リゾルバーのアウトバウンドエンドポイント — DNSクエリをVPCからODBネットワークのDNSインフラストラクチャに転送します。ODBネットワークが作成されると、アウトバウンドエンドポイントがネットワークに接続する必要のあるDNSリスナーIPアドレスが提供されます。
  • 転送ルール — アウトバウンドエンドポイントを使用して、Oracleドメイン（client.xxxxx.oraclevcn.comなど）のクエリをODBネットワークのDNSリスナーIPに直接送信します。ルールは正確なドメインとそのサブドメインの両方に一致します（たとえば、ルールがexample.comの場合、example.comとsub.example.comの両方に一致します）。これらのルールは、 AWS Resource Access Manager （AWS RAM）を使用してAWSアカウント間で共有し、Oracleドメイン名を解決する必要のあるVPCに関連付けることができます。ドメインマッチングの詳細については、「Resolver がクエリ内のドメイン名とルールの一致を判断する際の動作」を参照してください。

次の図では、設定を簡素化し、ピアリングされたODBネットワークに直接接続するために、アウトバウンドエンドポイントがアプリケーションVPC内にデプロイされています。代替の導入オプションと一元化されたDNS管理設計については、この記事の後半で説明します。DNS 設定の詳細な手順については、「Configuring DNS for Oracle Database@AWS」を参照してください。

ネットワーク接続パターン

このセクションでは、単純な直接接続からスケーラブルなマルチリージョンアーキテクチャまで、ODB @AWS の3つの一般的なネットワーク接続パターンについて説明します。それぞれのパターンは、さまざまなビジネスニーズとスケーリング要件に対応しています。分かりやすくするために、この図にはアカウントレベルのリソース配置は示されていません。各パターンのアカウント配置に関する考慮事項については、次のセクションで詳しく説明します。

接続パターン1：アプリケーションVPCとODBネットワーク間の直接ピアリング

このパターンでは、ピアリングされたVPCをアプリケーションVPCとして使用し、ODBネットワークにピアリングされたVPC内でデータベースアプリケーションを直接ホストします。このアプローチは、アプリケーションとデータベース間の最もシンプルなネットワークパスを提供します。

このパターンは、Oracle Databaseが主に単一のVPC内のアプリケーションにサービスを提供する場合に適しています。次の図に示すように、ODBネットワークは単一のアベイラビリティーゾーン（ODBネットワークの作成時に定義される）にバインドされますが、アプリケーションVPCとそのリソースは複数のアベイラビリティーゾーンにまたがることができます。マルチVPCまたはハイブリッドアーキテクチャの場合は、以降のセクションでODBトランジットVPCパターンを検討してください。

ワークフローは次のコンポーネントで構成されています。

  1. アプリケーションVPCのAmazon Elastic Compute Cloud（Amazon EC2）インスタンスは、データベースのホスト名を解決してIPアドレスを取得し、このIPを使用してデータベース接続を開始します。
  2. VPCルートテーブルは、ODBピアリング接続を介してトラフィックをODBネットワークに転送します。
  3. VPC CIDRはピアリングCIDRリストに含まれているので、Oracle OCI側にはこのトラフィックを許可するための設定がされています。応答トラフィックは、元のEC2インスタンスに戻る逆の経路をたどります。

接続パターン2：Transit Gatewayを使用した単一地域のスケーラブル接続

このパターンでは、単一AWSリージョンの大規模なODBネットワークへのネットワーク接続を検討します。2025年9月時点で、ODBネットワークは1つのVPCとのダイレクトピアリングのみをサポートしています。ODBネットワークと複数のVPC間の1対多のピアリング接続はサポートされていません。Transit Gatewayは、複数のVPCとオンプレミスネットワークの相互接続ポイントとして機能する集中型のネットワークコンポーネントです。2025年9月時点では、ODBネットワーク用の組み込みTransit Gatewayアタッチメントはサポートされていません。ただし、次の図に示すように、ODBネットワークを単一のトランジットVPCにピアリングし、そのトランジットVPCをTransit Gatewayに接続することはできます。

このパターンでは、ピアリングされたVPCは（この記事の前半で説明したように）ODBトランジットVPCとしてのみ機能します。ただし、ピアリングされたVPCの使用パターンで強調されているように、ピアリングされたVPCは必要に応じてワークロードを同時にホストできます。

トランジット VPC へのTransit Gatewayアタッチメントは、単一のアベイラビリティーゾーンのみ、具体的には ODB ネットワークが作成されるのと同じアベイラビリティーゾーンで作成する必要があります。これを強調するために、前の図では、アプリケーションVPCの複数のアベイラビリティーゾーンにまたがるワークロードを示しましたが、トランジットVPCのアベイラビリティーゾーン1にはTransit Gatewayしかアタッチされていません。詳細な設定手順については、「Configuring Amazon VPC Transit Gateways for Oracle Database@AWS」を参照してください。

ワークフローは次のコンポーネントで構成されています。

  1. アプリケーションVPCのEC2インスタンスは、データベースのホスト名を解決してIPアドレスを取得し、このIPを使用してデータベース接続を開始します。VPCサブネットのルートテーブルが検索され、パケットはTransit Gatewayアタッチメントを使用してTransit Gatewayに転送されます。
  2. 関連するTransit Gatewayのルートテーブルには、宛先をトランジットVPCアタッチメントとするODBネットワークCIDRの静的ルートがあります。
  3. トランジットVPCからのトラフィックは、VPCサブネットルートテーブルのODBピアリングルートを使用し、ODBネットワークに転送されます。
  4. VPC CIDRはピアリングCIDRリストに含まれているので、Oracle OCI側にはこのトラフィックを許可するための設定があります。応答トラフィックは、元のEC2インスタンスに戻る逆の経路をたどります。

接続パターン 3: AWS Cloud WANを使用したマルチリージョンのスケーラブルな接続

このパターンでは、複数の地域やオンプレミスネットワークからODBへのネットワーク接続を検討します。AWS Cloud WANは、動的なルート伝播によりマルチリージョン接続を簡素化します。これを使用して、複数の地域のデータセンター・支社・VPCを1つの統合ネットワークに接続することにより、単一のグローバルネットワークポリシーで制御できます。AWS Cloud WANは組み込みのセグメンテーションをサポートしています。つまり、リージョンやオンプレミスの場所全体でネットワークの分離を簡単に管理できます。ネットワークセグメントを使用すると、グローバルネットワークを別々のネットワークに分割できます。詳細については、AWS Cloud WANユーザーガイドを参照してください。

2025年9月時点では、ODBネットワーク用の組み込みアタッチメントはAWS Cloud WANではサポートされていません。ODBネットワークをトランジットVPCにピアリングし、そのトランジットVPCをAWS Cloud WANコアネットワークに接続することで、AWS Cloud WANを使用して、ODBネットワークと他の複数のVPC間のネットワークトラフィックをリージョンやオンプレミスの場所にルーティングできます。このパターンでは、ピアリングされたVPCは、ピアリングされたVPCの使用パターンに基づいてトランジットVPCとして機能します。AWS Cloud WANコアネットワークへのトランジットVPCアタッチメントが、ODBネットワークと同じ1つのアベイラビリティーゾーンのみで作成されていることを確認する必要があります。

わかりやすくするために、次の図に示すように、ODBネットワークにアクセスする必要があるすべてのアプリケーションVPCをODBアプリケーションVPCセグメントに関連付け、Direct Connectゲートウェイをハイブリッドセグメントに関連付け、両方のセグメント間でセグメント共有を有効にすることを示しました。詳細な設定手順については、「Configuring AWS Cloud WAN for Oracle Database@AWS」を参照してください。

ワークフローは次のコンポーネントで構成されています。

  1. アプリケーションVPCのEC2インスタンスは、データベースのホスト名を解決してIPアドレスを取得し、このIPを使用してデータベース接続を開始します。VPCサブネットのルートテーブル検索が行われ、パケットはAWS Cloud WAN VPCアタッチメントを使用してAWS Cloud WANコアネットワークに転送されます。
  2. アプリケーションVPC 1は、関連するアタッチメントCIDRが動的に伝達されるODBアプリケーションVPCセグメントに関連付けられています。ODBネットワークへの組み込み接続は現在、AWS Cloud WANではサポートされていないため、トランジットVPC接続を指す静的ルートを作成します。
  3. トランジットVPCからのトラフィックは、サブネットルートテーブルのODBピアリングルートを使用し、ODBネットワークに転送されます。
  4. 前のセクションで強調したように、アプリケーションVPCとオンプレミスネットワークに必要なCIDRは、ODBネットワークのピアリングCIDRリストに追加されます。レスポンストラフィックは、元のEC2インスタンスに戻る逆の経路をたどります。

考慮事項

ODB @AWS ネットワーク接続を実装するときは、アーキテクチャの計画と導入を成功させるために役立つ、技術的および設計上の重要な考慮事項に留意が必要です。

  • ODBネットワークを構築するときは、接続されたネットワークと重複しないCIDRや、使用できない予約済みのIP範囲など、IPアドレス空間の要件を考慮してください。これらのCIDR範囲は、ODBネットワークの作成後は変更できません。
  • ODBピアリングを設定しても、ODBネットワークCIDR（クライアントCIDRまたはバックアップCIDR）のルートは、ピアリングされたVPCルートテーブルに自動的に追加されません。これらのルートをVPCルートテーブルに追加するには、必要に応じてaws ec2 create-routeコマンドを手動で実行する必要があります。具体的なAWSコマンドラインインターフェイス（AWS CLI）コマンドについては、「Configuring VPC route tables for ODB peering」を参照してください。
  • VPCとのODBピアリングを設定すると、プライマリVPC CIDRがピアリングされたCIDRリストに自動的に追加されます。ピアリングされたVPCのセカンダリCIDRは手動で追加する必要があります。2025年9月時点では、自動的に追加されたプライマリCIDRを編集して、このVPCの特定のサブネットCIDRに制限することはできません。ACLとして機能するピアリングされたCIDRリストに、データベースとの通信に必要なすべてのソースCIDR範囲を含めてください。
  • ピアリングされたCIDRリストにエントリが追加されると、接続を容易にするためにOCI側の自動化が行われます。エントリとして追加されたCIDR範囲へのトラフィックを容易にするために、Virtual Cloud Network（Amazon VPCと同等のもの）に関連するルートルール（同等のVPCルートテーブル）に新しい静的ルートが追加されます。さらに、ICMPトラフィック（MTUパス検出とping用）、ポート22のTCPトラフィック（SSH用）、およびデータベーストラフィックに必要なその他のTCPポートを許可するために、Virtual Cloud Networkに関連するセキュリティルール（AWSセキュリティグループおよび同等のネットワークACL）にエントリが追加されます。
  • Route 53 Resolverのアウトバウンドエンドポイントは、ピアリングされたVPCにデプロイすることも、ネットワーキングチームが管理する別のVPCにデプロイすることもできます。ハイブリッドDNS解決を容易にするためにアウトバウンドエンドポイントがすでに設定されている場合は、それらも使用できます。いずれの場合も、エンドポイントを含むVPC CIDRがODBのピアリングCIDRリストに追加され、エンドポイントVPCとピアリングされたVPCの間に（Transit GatewayまたはAWS Cloud WANを介して）ネットワーク接続が存在することを確認してください。
  • Route 53プロファイルを使用すると、AWS RAMを使用して個々のルールを直接共有する代わりに、AWSアカウント間でリゾルバールを共有できます。
  • 2025年9月時点で、Transit GatewayアタッチメントとTransit VPC用のAWS Cloud WANアタッチメントは、1つのアベイラビリティーゾーン、つまり接続用のODBネットワークと同じアベイラビリティーゾーンでのみ作成する必要があります。
  • マルチリージョン接続は、クラウドWANの代わりにTransit Gatewayのリージョン間ピアリングを使用して実現することもできます。このアプローチでは、ピアリングされたTransit Gateway間の静的ルーティング設定が必要です。
  • トランジットVPCは、Transit GatewayとAWS Cloud WANの両方、あるいは複数のTransit GatewayやクラウドWANコアネットワークに同時に接続することはできません。接続するには、1つのトランジットサービスを選択する必要があります。
  • パターン1のアカウント配置では、ODBネットワークは購入者のアカウントにプロビジョニングされ、AWS RAMを使用して複数のアカウントで共有できます。ただし、2025年9月時点では、ODBネットワークに確立できるピアリング接続は1つだけです。つまり、AWS RAMを使用してODBネットワークを別のアカウントと共有し、その共有アカウントのアプリケーションVPCとのODBピアリング接続を作成できるため、アカウント間のアプリケーションを柔軟にデプロイできます。詳細については、「Resource sharing in Oracle Database@AWS」を参照してください。
  • パターン2と3のアカウント配置では、Transit GatewayとAWS Cloud WAN接続を実装する場合、トランジットVPCとODBネットワークの両方が同じAWSアカウント、特にODBネットワークがプロビジョニングされている購入者アカウントに存在する必要があります。ただし、Transit GatewayとAWS Cloud WANは別のアカウント（中央ネットワークアカウントなど）にあり、必要な接続を確立するためにAWS RAMを使用して購入者のアカウントと共有することができます。

こちらの考慮事項で記載している制限は、2025年9月時点のもので、将来変更される可能性があります。

結論

この記事では、Oracle Database@AWS のネットワーク統合機能について説明しました。これは、企業が AWS クラウドで Oracle Exadata データベースの機能をシームレスに拡張するための、堅牢で用途の広いソリューションを提供します。

Oracle Database @AWS は、組織に Oracle Databaseのデプロイメントをより広範な AWS インフラストラクチャやハイブリッド環境に統合するための柔軟なオプションを提供します。ODBネットワークを単一のVPCと直接ピアリングするか、Transit Gatewayを使用して複数のVPCを接続するか、AWS Cloud WANの一元接続を使用するかを選択することで、特定の要件に最適なネットワーク構成を選択できます。

IP に依存しない接続、重複する IP アドレス空間のサポート、または Zero-ETL や Amazon Simple Storage Service（Amazon S3）アクセスなどの特殊な統合を必要とする場合は、「Amazon VPC Latticeを使った Oracle Database@AWS ネットワーク接続」を参照してください。

本投稿へのご意見はコメント欄にお願いします。

翻訳はソリューションアーキテクトの 矢木 覚 が担当しました。原文はこちらです。