Oracle Database@AWS でトラフィック検査が論点になる理由

Oracle Database@AWS は、AWS のデータセンター内に設置された専用の Oracle Exadata インフラストラクチャ上で、Oracle Cloud Infrastructure（OCI）が管理する Oracle Exadata Database Service や Oracle Autonomous Database を利用できるサービスです。2025 年 7 月に一般提供が始まり、あわせて AWS Transit Gateway や AWS Cloud WAN、Amazon VPC Lattice との接続がサポートされ、ハイブリッド環境への組み込みがしやすくなりました。慣れ親しんだ AWS のネットワークサービスと同じ感覚で、Oracle の高性能データベースをそのまま業務システムに取り込めるようになったわけです。

ところが、いざ本番の設計に入ると必ずと言ってよいほど持ち上がるのがトラフィック検査の扱いです。金融や医療、公共といった規制の厳しい業界では、データベースに出入りする通信を素通しにするわけにはいきません。侵入検知・防止（IDS/IPS）、データ損失防止（DLP）、ドメインフィルタリングといった検査を、アプリケーションとデータベースの間や、データベースとインターネットの間に差し込む必要があります。しかも監査に耐えられるように、検査点は分散させず一箇所に集約したいという要望が強いのです。

本記事では、Oracle Database@AWS の通信を集中検査するための代表的な 2 つの構成、すなわち AWS Transit Gateway を使うパターンと AWS Cloud WAN のサービス挿入を使うパターンを、東西トラフィックと南北トラフィックの流れに沿って整理します。どちらを選ぶかの判断材料になれば幸いです。

ODB ネットワークの制約と検査 VPC の必要性

設計を始める前に、Oracle Database@AWS 特有のネットワーク構造を押さえておく必要があります。データベースが動くのは ODB ネットワークと呼ばれる隔離された領域で、これは指定した 1 つのアベイラビリティゾーン内に Exadata VM クラスターや Autonomous VM クラスターを収容します。ODB ネットワークは既定では完全にプライベートで、AWS の VPC ともオンプレミスともインターネットとも通信できません。

この ODB ネットワークと AWS 側をつなぐ仕組みが ODB ピアリングです。ユーザーが作成する接続で、Amazon VPC と ODB ネットワークの間を private に結び、VPC 内の EC2 インスタンスがあたかも同じネットワークにいるかのように Exadata へアクセスできるようになります。1 つの ODB ネットワークは最大 45 個の ODB ピアリング接続を持てます。ODB ネットワークとピアリングした VPC を、ここでは ODB トランジット VPC と呼びます。

厄介なのは、この ODB トランジット VPC にファイアウォールのエンドポイントを直接置けないという制約です。そのため検査機能は ODB トランジット VPC の中に閉じ込められず、別に用意した検査 VPC を経由させる形をとります。検査 VPC にはファイアウォールエンドポイントに加えて、インターネット送信を扱うための NAT ゲートウェイやインターネットゲートウェイを配置します。以降で紹介する 2 パターンは、いずれもこの検査 VPC へトラフィックをどう迂回させるかという工夫だと捉えると理解しやすくなります。

パターン1 AWS Transit Gateway による集中検査

1 つ目は、Transit Gateway をハブに据える古典的かつ堅実な構成です。Transit Gateway に、アプリケーション VPC、ODB トランジット VPC、検査 VPC、そして AWS Direct Connect または AWS Site-to-Site VPN 経由のオンプレミスネットワークをアタッチします。制御の要になるのが 2 つのルートテーブルの使い分けです。

アプリケーションからデータベースへ向かう東西トラフィックの流れを追うと、まずアプリケーション VPC の EC2 が接続を開始し、パケットがアプリケーション VPC のアタッチメント経由で Transit Gateway に届きます。検査前ルートテーブルでは 0.0.0.0/0 が検査 VPC を指しているため、パケットはいったん検査 VPC のファイアウォールエンドポイントへ送られます。検査を通過したパケットは検査後ルートテーブルに従い、ODB トランジット VPC のアタッチメントへ、そして ODB ピアリング接続を経て ODB ネットワークへ到達します。

インターネットへ抜ける南北トラフィックも考え方は同じです。ODB ネットワークから出た通信は ODB ピアリング接続を通って ODB トランジット VPC に入り、Transit Gateway の検査前ルートテーブルで検査 VPC へ誘導されます。ファイアウォールで検査したあと NAT ゲートウェイで送信元アドレスを変換し、インターネットゲートウェイからインターネットへ出ていきます。戻りの通信は逆の経路をたどります。分岐点をルートテーブルで明示的に管理できるため、挙動を追いやすいのがこの方式の長所です。

パターン2 AWS Cloud WAN のサービス挿入による検査

2 つ目は、AWS Cloud WAN のサービス挿入機能を使う構成です。複数リージョンにまたがるグローバルなネットワークをポリシーで一元管理したい場合に向いています。Cloud WAN のコアネットワーク上に、アプリケーション VPC 用のセグメント、オンプレミス用のハイブリッドセグメント、ODB Network セグメントを定義し、検査 VPC はネットワーク機能グループ（NFG）としてマッピングします。ODB トランジット VPC は Transit Gateway ルートテーブルアタッチメントを介して Cloud WAN につなぎます。

ここで効いてくるのがルートの動的伝播です。ODB ネットワークの CIDR に対する静的ルートを Transit Gateway 上の ODB トランジット VPC アタッチメントへ向け、その TGW ルートテーブルを Cloud WAN のアタッチメントに関連付けると、ODB の CIDR が BGP を通じて Cloud WAN のセグメントや NFG のルートテーブルへ自動的に伝わります。手作業でルートを撒く手間が減り、構成変更にも追従しやすくなります。

検査への迂回は 2 種類のアクションで表現します。東西トラフィックには send-via アクションを使います。アプリケーション VPC の EC2 が接続を開始すると、Cloud WAN のルーティングによってパケットが NFG のアタッチメント経由で検査 VPC へ送られ、ファイアウォールを通過したあと Cloud WAN に戻り、Transit Gateway 経由で ODB トランジット VPC、そして ODB ネットワークへ届きます。send-via は双方向に働くため、ODB ネットワーク側から来る通信もアプリケーション VPC に着く前に検査 VPC を通過します。一方、インターネットへ出す南北トラフィックには send-to アクションを使い、検査 VPC で検査したのち NAT ゲートウェイとインターネットゲートウェイを経て外部へ送出します。ルーティングの意図をポリシーとして宣言的に書ける点が、Transit Gateway 単体構成との大きな違いです。

実装で押さえておきたい勘所

どちらのパターンを選ぶにしても、実装で足をすくわれやすいポイントがいくつかあります。最初に確認したいのがアプライアンスモードです。検査 VPC のアタッチメント（パターン1 では Transit Gateway アタッチメント、パターン2 では AWS Cloud WAN アタッチメント）でこれを有効にしておかないと、往路と復路が別々のアベイラビリティゾーンを通ってしまい、ステートフルな検査が成立しなくなる恐れがあります。ここは最優先で設定しておきたい項目です。

もう一つ知っておくと選択肢が広がるのが、AWS Network Firewall のネイティブ Transit Gateway アタッチメントです。これを使うと専用の検査 VPC を用意しなくても東西トラフィックの検査を実現できます。ただしインターネットへの南北送信については、NAT ゲートウェイを備えた VPC を別途用意する必要がある点は変わりません。ピアリングされた CIDR の設計も忘れがちな要素です。東西通信ではアプリケーション VPC やオンプレミスの CIDR をピアリング対象に含める必要があり、南北通信では宛先 CIDR を個別に設定します。現時点では 0.0.0.0/0 をそのまま指定する運用には対応していないため、必要な宛先を明示していく形になります。

まとめ

Oracle Database@AWS の集中検査は、ODB トランジット VPC にファイアウォールを直接置けないという制約を出発点に、検査 VPC へどう迂回させるかを設計する作業だと言えます。AWS Transit Gateway のパターンは、検査前と検査後のルートテーブルで経路を明示的に管理でき、単一リージョンで完結する構成や既存の Transit Gateway 資産を活かしたい場面に向いています。AWS Cloud WAN のパターンは、send-via と send-to をポリシーとして宣言し、BGP による動的伝播と組み合わせることで、複数リージョンにわたる大規模なネットワークを一元管理しやすくします。どちらの場合も、アプライアンスモードの有効化と DNS 経路の見極め、ピアリング CIDR の設計を押さえておけば、規制要件を満たしつつ Oracle の高性能データベースを安全に業務へ組み込めるはずです。自社のリージョン構成と運用体制に照らして、無理のない方を選んでいただければと思います。