この記事はVinoth kumar AshokによるTransit Gateway use-cases in DB@AWSを日本語に翻訳したものです。

2026年05月11日

はじめに

現在、多くのAWSネットワーク・アーキテクチャは、AWS Transit Gateway（TGW）を中心に構築されています。TGWは、複数のVPC、ハイブリッド環境、共有サービスを接続するためのスケーラブルなハブ・アンド・スポーク・モデルを提供します。複雑で拡張性に欠けるポイント・ツー・ポイントのVPCピアリング接続を不要にし、各VPCまたはネットワークを単一のTGWにアタッチできるようにすることで、ネットワーク・トポロジを簡素化し、ルーティングを一元的に制御できます。

TGWはAWSネットワーキングの観点だけで説明されることが多いですが、これらのアーキテクチャをOracle Database@AWS（DB@AWS）の視点から捉え直し、それが実際のエンタープライズ設計にどのように統合されるかを理解することが重要です。

このブログでは、DB@AWSが一般的なAWS TGWベースのシナリオにどのように自然に適合するかを、アーキテクチャの観点から説明します。これにより、お客様はOracle Databaseサービスを引き続き活用しながら、アプリケーション・アーキテクチャをモダナイズできます。

DB@AWSが議論の前提をどう変えるか

従来のAWSネットワーキングに関する議論では、アプリケーション層と汎用的なデータベースの接続に焦点が当てられてきました。DB@AWSでは、データベース層がAWS内で稼働するOracle管理のファーストクラス・サービスとなり、次のような要素をもたらします。

  • Oracle Databaseのネイティブ機能（Exadataベースのパフォーマンス、Data Guard、RMAN）
  • AWSネットワーク構成要素（VPC、TGW、Direct Connect）との緊密な統合
  • 複雑なクロスクラウド・アーキテクチャの必要性の低減

その結果、TGWはもはや単なる接続ハブではありません。TGWは、多様なアプリケーション環境からDB@AWSへ安全かつスケーラブルにアクセスするための中心的なファブリックになります。

1. アプリケーションVPC向けの一元的な接続

AWSのパターン

AWS TGWは、複数のアプリケーションVPC（開発、テスト、本番、異なるチームやアカウントなど）をハブ・アンド・スポーク・モデルで接続するためによく使用されます。

DB@AWSの視点

このモデルでは、DB@AWSは複数のアプリケーションVPCからアクセスされる共有データベース・プラットフォームとして機能します。

  • 各アプリケーションVPCをTGWにアタッチする
  • DB@AWSを専用のVPCアタッチメント経由で公開する
  • TGWルート・テーブルを使用してルーティングを一元的に制御する

主な価値

  • 複数のアプリケーション領域にまたがるOracle Databaseへのアクセスを簡素化する
  • VPCごとにデータベースを重複してデプロイする必要をなくす
  • データベース・アクセスに対して一貫したセキュリティ・ポリシーを適用できる

実践的なポイント

DB@AWSは、各アプリケーションVPC内にデータベースを組み込むのではなく、共有サービス層として扱います。TGWは、次のような制御ポイントになります。

  • ネットワーク分離（開発環境と本番環境など）
  • 制御された東西トラフィック
  • 必要に応じた一元的な検査

2. 一元的なセキュリティ検査（Firewall VPC）

AWSのパターン

スポークVPCからのトラフィックは、TGWを使用して一元的なファイアウォールまたは検査用VPCにルーティングされます。

TGWは、すべてのアプリケーションVPCを専用の検査用VPCまたはファイアウォールVPCに接続するハブとして機能し、一元的な接続を実現します。これにより、VPC間トラフィックおよびアウトバウンド・トラフィックをすべて中央のセキュリティ層にルーティングできます。直接的なVPC間通信を許可する代わりに、トラフィックを統制された経路に集約します。

DB@AWSの視点

DB@AWSを導入すると、このパターンは次の目的において重要になります。

  • データベース・アクセス制御
  • 規制要件への対応
  • 機密データ・フローに対する脅威検査

アーキテクチャの整合性

  • アプリケーションVPC → TGW → Firewall VPC → TGW → Transit VPC → DB@AWS
  • すべてのデータベース・トラフィックは、DB@AWSに到達する前に検査される

主な価値

  • すべてのデータベース・アクセスに対して一貫したセキュリティ・ポリシーを適用する
  • SQLおよびアプリケーション・トラフィック・パターンの可視性を提供する
  • 金融や医療など、コンプライアンス要件の厳しい業界を支援する

実践的なポイント

規制対象の環境では、VPCからDB@AWSへの直接アクセスを避けます。代わりに、次のように設計します。

  • TGWルート・テーブルを使用して、トラフィックを検査層経由に強制する
  • すべての東西トラフィック（アプリケーション ↔ データベース）が専用のファイアウォール／検査VPCを経由するようにTGWルート・テーブルを構成し、直接的なスポーク間経路を排除する
  • ファイアウォールVPCのTGWアタッチメントでアプライアンス・モードを有効にし、対称ルーティングを確保する。これは、ステートフル検査と一貫したポリシー適用に不可欠です
  • TGWで明示的なルート伝播とブラックホール・ルートを実装し、ファイアウォール経路のバイパスを防ぎ、最小権限のネットワーク・アクセスを強制する

これにより、ネットワーク層とデータベース層にまたがる多層防御モデルを構築できます。

3. ハイブリッド・ハブ・アンド・スポーク（オンプレミス ↔ AWS ↔ DB@AWS）

AWSのパターン

TGWは、VPNまたはDirect Connectを使用して、オンプレミス・ネットワークと複数のAWS VPCを接続します。

AWS Transit Gatewayは、複数のVPC（スポーク）とオンプレミス・ネットワークをVPNまたはDirect Connectで接続する中央のネットワーク・ハブとして機能します。これにより、複雑なメッシュ型アーキテクチャを、よりシンプルでスケーラブルなハブ・アンド・スポーク・モデルに置き換えることができます。

DB@AWSの視点

ハイブリッド環境において、DB@AWSはデータベース・モダナイゼーションの戦略的な移行先になります。

一般的なフロー

  • オンプレミス・アプリケーション → DB@AWS
  • AWSアプリケーション → DB@AWS
  • 中央のOracle Databaseにアクセスする混在ワークロード

主な価値

  • オンプレミスのOracle DatabaseからDB@AWSへの円滑な移行
  • ワークロードをAWS内に維持することで、クロスクラウド（OCI ↔ AWS）レイテンシを回避
  • 単一のTGWハブによるハイブリッド接続の簡素化

実践的なポイント

規制対象のハイブリッド環境では、オンプレミスからDB@AWSへの直接接続を避けます。代わりに、次のように設計します。

  • AWS Transit Gatewayを中央ハブとして使用し、オンプレミス・トラフィックが単一の制御されたルーティング・ポイントからAWSに入るようにする
  • TGWルート・テーブルを使用して、オンプレミス → TGW → ファイアウォール／検査VPC → DB@AWS の経路を強制し、データベース・アクセスが直接行われないようにする
  • Oracle DB VPCをスポーク・モデルに配置し、オンプレミスへ直接戻る経路を持たせないことで、一貫したポリシー適用を確保する
  • 個別のVPCに別々のVPNやDirect Connectを接続するのではなく、TGWを通じてオンプレミス接続を一元化する。これにより、複雑性とバイパス・リスクを低減できる

これにより、TGWが経路を制御し、ファイアウォールが検査を実施し、Oracleの制御機能がデータベース自体を保護する、安全なハイブリッド・ハブ・アンド・スポーク・モデルを構築できます。

4. マルチアカウント／マルチOUガバナンス

AWSのパターン

組織では、開発、テスト、本番などの分離を目的として複数のAWSアカウントを使用し、それらをTGWで接続し、AWS Resource Access Manager（AWS RAM）を使用して共有します。

マルチアカウントまたはクロスアカウントのAWS環境では、AWS Transit Gateway（TGW）が一元的なネットワーク・ハブとして使用されます。通常は専用のネットワーク・アカウントまたは共有サービス・アカウントにデプロイされ、複数アカウントのVPCを接続します。

DB@AWSの視点

DB@AWSは、複数のアカウントにまたがる一元的なデータベース・プラットフォームとして機能します。

アーキテクチャ

  • TGWを共有ネットワーク・アカウントにデプロイする
  • 複数のアプリケーション・アカウントからDB@AWSにアクセスできるようにする
  • ExadataインフラストラクチャとODBネットワークは購入者アカウントに存在し、信頼されたアカウントに共有される必要がある

主な価値

  • アプリケーション所有権を分散しながら、データベース管理を一元化できる
  • 環境間の強力な分離を実現できる
  • ガバナンスと監査を簡素化できる

実践的なポイント

完全な接続性ではなく、制御された共有を前提に設計します。

  • 開発／テスト環境からは非本番のDB@AWSインスタンスのみにアクセスを許可する
  • TGWを使用して、複数のアプリケーション・アカウントから一元的なデータベース・アクセスを可能にし、すべてのアプリケーションからデータベースへの通信が制御されたルーティング・パスを通るようにする
  • TGWを通じてアカウント間の共有サービス統合を有効にしつつ、データベースを広範に公開しない
  • 新しいアプリケーション・アカウントのオンボーディングをスケーラブルにする。新しい利用者は、既存のDBネットワーク・アーキテクチャを変更することなく、TGWにアタッチすることで安全にDB@AWSへアクセスできる

5. TGWを使用したOracle Disaster Recovery（DR）

AWSのパターン

AWS上のディザスタ・リカバリ（DR）アーキテクチャでは、Transit Gateway（TGW）が、プライマリ・データベース環境とスタンバイ・データベース環境の間に、一元化された信頼性の高いスケーラブルなネットワーク接続を提供するために使用されます。これらの環境は、異なるVPC、アカウント、場合によってはリージョンにまたがってデプロイされることがあります。TGWは、アプリケーション層、データベース層、ハイブリッドなオンプレミス・システムを制御された方法で接続するハブとして機能します。

DB@AWSの視点

DB@AWSは、Data Guardなどの技術を使用するOracle DRに自然に統合されます。この場合、TGWはプライマリとセカンダリの間の接続を可能にします。

代表的なアーキテクチャ

  • 一方のVPCまたはリージョンにあるプライマリDB@AWS
  • 別のVPCまたはリージョンにあるスタンバイDB@AWS
  • TGWによるレプリケーション・トラフィックの制御された接続

主な価値

  • 高スループットかつ低レイテンシのレプリケーション
  • 一元的なルーティングによるDRトポロジの簡素化
  • 制御されたフェイルオーバー・パスによるDR環境の分離

実践的なポイント

Oracle DR構成では、場当たり的な接続や、プライマリからスタンバイへの直接接続を避けます。代わりに、次のように設計します。

  • VPC、アカウント、リージョンをまたぐプライマリ環境とDR環境の間で、Transit Gatewayを中央のルーティング層として使用し、接続を簡素化・標準化する
  • すべてのData Guardレプリケーション・トラフィック（REDO転送）をTGW経由でルーティングし、一貫性があり、制御可能で、観測可能なネットワーク・パスを確保する
  • フェイルオーバー・シナリオに備えてTGWルート・テーブルを事前構成し、アプリケーション・トラフィックを大きなネットワーク変更なしにスタンバイDBへ迅速にリダイレクトできるようにする
  • クロスリージョンDRでは、リージョン間TGWピアリングを使用し、複数のポイント・ツー・ポイント接続を管理する代わりに、クリーンでスケーラブルなアーキテクチャを維持する

主なポイント

ネットワーク・アーキテクチャの観点では、DB@AWSの導入により、TGWは汎用的なネットワーク構成要素から、AWS上のOracle Databaseアーキテクチャを実現するための戦略的な基盤へと位置づけが変わります。

すべてのシナリオに共通して、TGWは接続ファブリックを提供し、DB@AWSはエンタープライズ・グレードのデータベース・プラットフォームを提供します。この2つを組み合わせることで、スケーラブルで、安全で、ガバナンスの効いたアーキテクチャを実現できます。

設計原則

  • DB@AWSを共有サービスとして扱う
  • セグメンテーションと制御にTGWを使用する
  • 必要に応じて、一元的な検査によりセキュリティを強制する
  • ネットワーク設計をデータベース・アーキテクチャ（DR、ハイブリッド、ガバナンス）と整合させる

最後に

DB@AWSを採用する際には、TGWを単なるAWSネットワーク・ツールとして捉えるのではなく、データベース・ファーストの考え方で設計する必要があります。TGWとDB@AWSを組み合わせることで、組織はOracle環境に期待されるパフォーマンス、回復性、ガバナンスを維持しながら、AWS内でOracleワークロードをモダナイズできます。

重要なのは、AWSネイティブのネットワーク・パターンとOracle Databaseのベスト・プラクティスの間にあるギャップを埋めることです。