Oracle Database@AWS の Exadata Dedicated Infrastructure への接続方式を整理してみる。

Last updated at 2026-10-26Posted at 2026-10-25

Oracle Database@AWS の Exadata Database Service on Dedicated Infrastructure(以下、ExaDB-D@AWS)への接続方法について、ODB Peering や Transit Gateway、VPC Lattice など選択肢が色々あるので整理してみますやで。
彡(ﾟ)(ﾟ)

なお本記事は、2026年10月25日時点で参照した公式ドキュメントを基にした構成の整理です。各方式の設定手順や実機での検証結果については取り扱いません。

1. Exadata Infrastructure, VM Cluster, ODB Network の関係性

最初に、この3つのリソースの関係を整理しておきます。

リソース	役割
Exadata Infrastructure	DB Server や Storage Server から構成される、専有の Exadata基盤
VM Cluster	Exadata Infrastructure上で稼働する、Oracle Grid Infrastructure / Oracle Database を備えたVM群
ODB Network	VM Cluster の接続先となる、AWS の特定AZに配置されるプライベート・ネットワーク

VM Cluster を作成する時に、稼働先となる Exadata Infrastructure と、接続先となる ODB Network を指定します。

参考：Oracle Database@AWS の仕組み

図にすると以下の関係です。

※構成図はクリックすると拡大できます。

図1は、1つの Exadata Infrastructure のリソースを、複数の VM Cluster に分割して割り当てる構成例です。2つの VM Cluster に、それぞれ別の ODB Network を割り当てて Client Subnet と Backup Subnet を表現しています。

Exadata Infrastructure は物理的な稼働基盤で、アプリケーションからのDB接続では ODB Network を経由して VM Cluster上のリスナーに接続する、という関係です。

また ODB Network は、通常の Amazon VPC とは別のネットワークです。ODB Network を作成すると、対応する OCI VCN がリンク済みの OCIテナントに作成され、両者は1対1で対応します。

参考：Oracle Database@AWS で Amazon VPC への ODB ピアリングを設定する（「Oracle Database@AWS での DNS の仕組み」節）

アプリケーションの EC2インスタンスなどは自分たちの VPC に配置して、この ODB Network への接続経路を用意します。以下、その方式を順番に整理します。

2. ODB Peering による ODB Network への接続

最初は同一AWSアカウント内での ODB Peering です。

Application VPC と ODB Network の間に、ODB Peeringによる直接接続でプライベートな通信経路を作成します。今回紹介する接続方式のうち、基本となる構成です。

名前は似ていますが、ODB Peering と VPC Peering は別の機能です。ODB Peering の詳細は下記を参照してください。

参考：Oracle Database@AWS の仕組み（「ODB ピアリング」節）

2-1. 接続に必要な設定

大きくは以下の設定を確認します。

VPC と ODB Network の CIDR が重複しないようにする。
ODB Peering を作成する。
Application VPC側のルートテーブルに、ODB Network宛ての経路を設定する。
DB接続先の名前解決を設定する。
接続に必要なポートやセキュリティルールを確認する。

VPC側のルートは、例えば以下のイメージです。

宛先	ターゲット
ODB Network の Client CIDR	ODB Network

ODB Peering作成時に VPC側のルートテーブルを指定してルーティングを追加できます。手動設定する場合を含め、実際にアプリケーションが使うサブネットのルートテーブルに経路が入っているかを確認します。

接続元CIDRが Peered CIDRs に含まれている必要があります。 Peering作成時の Peer network CIDRs 欄は Optional（任意）ですが、自動登録される範囲を確認し、不足する接続元CIDRは追加してください。

参考：Oracle Database@AWS で Amazon VPC への ODB ピアリングを設定する（作成手順の「ピアネットワーク CIDR」（オプション））
参考：CreateOdbPeeringConnection（peerNetworkCidrsToBeAdded は Required: No）
参考：Oracle Database@AWS ネットワーク接続パターンの実装（「考慮事項」節の Peered CIDRs の説明）

2-2. DNSによる名前解決

IPアドレスへの経路ができても、SCAN名などを名前解決できなければ接続できません。

一般的には Route 53 Resolver の Outbound Endpoint と転送ルールを用意し、ODB Network の対象ドメインへの問い合わせを、OCI Private DNS Resolver Listening Endpoint に転送します。

Application
  → Route 53 Resolver
  → Outbound Endpoint
  → OCI Private DNS Resolver Listening Endpoint

DB接続の通信経路と DNS問い合わせの通信経路、それぞれを確認します。

参考：Oracle Database@AWS ネットワーク接続パターンの実装（「DNSの構成」節）

2-3. 複数VPCからのODB Peeringによる直接接続

ODB Peering は、1つの ODB Network に複数作成できます。現時点では 1つの ODB Network あたり最大125接続と記載されています。

参考：Configuring ODB peering to an Amazon VPC in Oracle Database@AWS（英語版「Peering connection limits」節）

なお、古い資料には45接続などの記載が残っています。また既存の ODB Network では作成時期などによる追加条件もあるため、導入先の条件は現行ドキュメントで確認してください。

3. クロスアカウントの ODB Peering による ODB Network への接続

DB基盤用とアプリケーション用で AWSアカウントを分けている場合は、クロスアカウントの ODB Peering が利用できます。

ODB Network所有側から AWS RAM(Resource Access Manager)で ODB Network を共有し、共有先のアカウントで、自分の VPC との ODB Peering を作成します。

参考：AWS RAM でのリソース共有の作成

Peering を作成したアカウントが、その接続を所有・管理します。

参考：Oracle Database@AWS の仕組み（「ODB ピアリング」節）

3-1. 前提条件と役割分担

ODB Network のリソース共有は、同一 AWS Organizations組織内のアカウント間で行います。共有先では Oracle Database@AWS のサービス初期化も必要です。

クロスアカウントでも、接続元CIDRが Peered CIDRs に含まれている必要があります。 Peering作成時の Peer network CIDRs 欄は Optional（任意）ですが、自動登録される範囲を確認し、不足する接続元CIDRを追加してください。

参考：Oracle Database@AWS で Amazon VPC への ODB ピアリングを設定する（クロスアカウント ODB ピアリング、および作成手順の「ピアネットワーク CIDR」（オプション））
参考：CreateOdbPeeringConnection（peerNetworkCidrsToBeAdded は Required: No）
参考：Oracle Database@AWS ネットワーク接続パターンの実装（「考慮事項」節の Peered CIDRs の説明）

設定の役割分担は、おおよそ以下の通りです。

担当	主な設定
ODB Network所有側	AWS RAMによる共有、ODB Networkの管理
Application VPC所有側	ODB Peeringの作成・管理、VPC側の経路、接続元の設定
DNS管理担当	転送ルールやOutbound Endpointの整備、必要に応じた共有

参考：Oracle Database@AWS でのリソース共有

下記のAWS公式ブログも参考にしてください。

参考：Oracle Database@AWS のクロスアカウント共有のベストプラクティスとアーキテクチャパターン

4. TGW + VPCトランジットによる ODB Network への接続

オンプレミスから ExaDB-D@AWS に接続する場合や、ODB Peeringによる直接接続を行うVPC数が上限を超える見込みの場合は、AWS Transit Gateway（以下、TGW）＋ Transit VPC を利用する構成が候補になります。

この構成では、中継役となる Transit VPC を ODB Network に Peering して、その Transit VPC を TGW に接続します。

通信経路は以下の通りです。

Application VPC
  → TGW
  → Transit VPC
  → ODB Peering
  → ODB Network
  → Database

ODB Network を TGW に直接アタッチする構成ではありません。 現行ドキュメントでは、ODB Network を直接の Attachment とするネイティブ統合は提供されていないため、Transit VPC を経由する必要があります。

参考：Oracle Database@AWS で Amazon VPC への ODB ピアリングを設定する（「Oracle Database@AWS の Amazon VPC Transit Gateway の設定」節）

4-1. 経路設定のポイント

主な設定箇所は以下の通りです。

設定箇所	設定の考え方
Application VPC のルートテーブル	ODB Network宛てを TGW に向ける
TGW のルートテーブル	ODB Network宛てを Transit VPC の Attachment に向ける
Transit VPC のルートテーブル	ODB Network宛てを ODB Network に向け、接続元への戻り経路を TGW に向ける
ODB Peering の Peered CIDRs	接続元となる Application VPC やオンプレミスのCIDRを登録する

TGW経由の別VPC・オンプレミスから接続する場合は、それらの接続元CIDRの追加が必須です。 Peering作成時の Peer network CIDRs 欄自体は Optional ですが、接続に使う Application VPC やオンプレミスのCIDRを Peered CIDRs に登録する必要があります。

参考：Oracle Database@AWS で Amazon VPC への ODB ピアリングを設定する（「ODB ピアリング接続の更新」節）

4-2. Transit VPC側の Attachment の AZ に注意

Transit VPC の TGW Attachment には、ODB Network と同じAZのサブネットを指定します。

Transit VPC 自体には、複数AZにサブネットを配置できます。ここで確認するのは、TGW Attachment に指定するサブネットのAZです。

またクロスアカウントでは、AZ名の文字列だけでなく AZ ID で同じ物理AZかを確認します。

参考：Oracle Database@AWS で Amazon VPC への ODB ピアリングを設定する（「Oracle Database@AWS の Amazon VPC Transit Gateway の設定」節）

オンプレミスからの ODB Network接続要件がある場合や、ODB Peeringによる直接接続を行うVPC数が上限を超える見込みの場合に、本方式が選択肢になります。デメリット/考慮事項として経路やDNSの設定箇所が増えます。また TGW の接続時間・データ処理に関する料金も見込む必要があります。

参考：AWS Transit Gateway の料金

4-3. ODB Peeringによる直接接続との併用も可能

TGW経由の接続と、Application VPC からのODB Peeringによる直接接続は併用できます。 同じ ODB Network に対して、ある VPC はODB Peeringによる直接接続を利用し、別の VPC やオンプレミスは TGW ＋ Transit VPC 経由で接続する、といった構成も可能です。

AWSマニュアルでも、複数の Application VPC と ODB Network をODB Peeringによる直接接続で結ぶ構成に加えて、TGW / Cloud WAN を組み合わせる接続パターンが挙げられています。接続元ごとに経路を選び、必要なルート・DNS・Peered CIDRsを設定します。

参考：Configuring ODB peering to an Amazon VPC in Oracle Database@AWS（英語版「Configuring Multiple Application VPCs for Oracle Database@AWS」節の「Multiple VPCs to multiple ODB networks via TGW」）

なお、TGW の代わりに AWS Cloud WAN を利用し、Transit VPC ＋ ODB Peering 経由で接続する構成もあります。

参考：Oracle Database@AWS で Amazon VPC への ODB ピアリングを設定する（「Oracle Database@AWS の AWS Cloud WAN の設定」節）

5. VPC Lattice を使用した ODB Network への接続

最後は Amazon VPC Lattice を利用する方式です。

VPC Lattice では、ODB Network内の接続対象をリソースとして公開して、そのリソースに接続します。

ネットワーク全体へのIP到達性を用意する方式とは異なり、ネットワーク間で CIDR が重複している環境でも利用できるのが特徴です。

参考：Amazon VPC Latticeを使った Oracle Database@AWS ネットワーク接続

5-1. 構成イメージ

以下は、クロスアカウントで Service Network Endpoint または VPC Association を利用する場合の構成図です。

ODB Network の作成時には、Service Network（図5の①） / Resource Gateway（②） / Service Network Endpoint がデフォルトで用意されます。

図5では、DB側アカウントAの Service Network（①）を AWS RAM でアプリ側アカウントBに共有し、Resource Gateway（②）を経由して接続します。アプリ側では、Service Network Endpoint または VPC Association のいずれかを設定します。

VPC内のクライアントからの接続はどちらも利用可能ですが、オンプレミスや別VPCなど、VPC外のクライアントからそのVPCを経由して接続する場合は Service Network Endpoint を使用します。

参考：VPC Lattice サービスネットワークの関連付けを管理する（「サービスネットワーク VPC の関連付けを管理する」「サービスネットワーク VPC エンドポイントの関連付けを管理する」節）

5-2. 設定の流れ

大まかな流れは以下の通りです。

接続対象となるVMの IPアドレスを確認する。
ODB Network のデフォルト Resource Gateway を使い、Resource Configuration を作成する。
Resource Configuration を Service Network に関連付ける。
別アカウントから利用する場合は Service Network を共有する。
クライアント側で Service Network Endpoint または VPC Association を設定する。
公開されたリソースの接続先名などを確認し、接続する。

Resource Configuration では、公開するTCPポートの範囲なども考慮します。ODB Network全体を開放するのではなく、接続対象を絞って公開する構成です。

この VPC Lattice 経由の接続では、Peer network CIDRs の指定は対象外（不要）です。 ODB Peering を経由せず、Resource Gateway と Resource Configuration などを使うためです。代わりに、リソースの公開・関連付けと必要なセキュリティ設定を行います。

参考：VPC Lattice エンティティにアクセスして共有する（「VPC Lattice 経由で ODB ネットワークを共有する」節）

5-3. SCAN接続はサポートされない

公式ドキュメントには、VPC Lattice は OCI の SCAN Listener をサポートしないと記載されています。AWS公式ブログでも、SCAN接続ではなく個々のVMへのアクセスとして説明されています。

SCAN接続が利用できないため、VMごとの公開先を接続先として設定し、障害時の再接続動作も考慮する必要があります。

参考：VPC Lattice エンティティにアクセスして共有する（「VPC Lattice 経由で ODB ネットワークを共有する」の「考慮事項」節）

5-4. 接続元IPの見え方も異なる

VPC Lattice経由の通信では、Resource Gateway で送信元NATが行われます。ODB側で見える送信元は、アプリケーションの元のIPアドレスとは異なります。

ODB側の NSG などを設定する際は、Resource Gateway側のIP範囲からの通信を考慮します。

この接続方式では ICMP（ping）は利用できません。 疎通確認は、公開したTCPポートへの接続や、実際のDB接続で行います。

参考：VPC リソースのリソース設定（「プロトコル」節）

参考：Amazon VPC Latticeを使った Oracle Database@AWS ネットワーク接続（「Oracle VMへの顧客ネットワークアクセス」節）

6. 各接続方式のメリット/デメリット/ユースケース一覧表

ここまでの内容を一覧にしてみます。

メリット/デメリットやユースケースは、上記仕様を基にしたワイ個人の整理です。
彡(ﾟ)(ﾟ)

接続方式	メリット	デメリット・注意点	主なユースケース
同一アカウントの ODB Peering	ODB Peeringによる直接接続でシンプルな構成通常のDB接続方式を使いやすい	CIDR重複を避ける必要がある経路・DNS設定が必要 VPCごとに接続を管理するため、接続数が多くなると管理が煩雑	同一アカウント内のアプリケーションからDBへ接続通信経路をシンプルにしたい場合
クロスアカウントの ODB Peering	アカウントを分離したままODB Peeringによる直接接続が可能	ODB Network のAWS RAM共有が必要同一組織などの前提条件があるアカウント間の運用調整が必要その他は同一アカウントのODB Peeringによる直接接続と同様	DB基盤用アカウントとアプリケーション用アカウントを分離している場合
TGW ＋ Transit VPC ＋ ODB Peering	オンプレミスからの接続要件がある場合の選択肢 ODB Peeringによる直接接続を行うVPC数が上限を超える見込みの場合の選択肢 ODB Peeringによる直接接続と併用可能	Transit VPCが必要経路・DNS・Peered CIDRsの管理が増える AttachmentのAZ条件に注意 TGW料金を考慮する必要がある	オンプレミスを含むハイブリッド構成多数の接続元がある構成ネットワークの集中管理
VPC Lattice	リソース単位で公開できる CIDR重複のあるネットワーク間でも接続可能	SCAN接続非対応 ICMP（ping）非対応 OCI NSGでResource Gatewayによる送信元IP変換(SNAT)を考慮する必要がある Lattice関連料金を考慮する必要がある	CIDR重複があり直接ルーティングが難しい場合 Service Network Endpointを使って、オンプレミスや別VPCからDBへ接続する場合

料金については、Peering接続だけでなく、DNS用Endpoint、AZをまたぐ通信、TGW、VPC Lattice / Endpoint など、構成全体で比較します。

参考：Amazon VPC Lattice の料金
参考：Oracle Database@AWS 向けの VPC Lattice（「考慮事項」節）

7. まとめ

Oracle Database@AWS の ExaDB-D@AWS への接続方式を整理しました。要件に応じて、おおよそ以下のように検討する感じでしょうか。

ODB Peeringによる直接接続で要件を満たせるなら、その構成を選択
DB基盤とアプリケーションのアカウントが分かれている場合はクロスアカウント ODB Peeringによる直接接続
オンプレミスからの接続要件がある場合または ODB Peering数が上限を超える見込みの場合は TGW ＋ Transit VPC
CIDR重複への対応やリソース単位の公開が必要なら、SCAN非対応を踏まえて VPC Lattice
各接続方式は、各接続方式の前提条件/制限にしたがって併用できます。

接続VPC数、アカウント分離、既存のネットワーク構成、CIDR、DB接続文字列、障害時の動作、コストまで含めて選ぶのが良さそうですやね。

それぞれの方式を上手く活用してくださいね。
彡(^)(^)

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up