この記事はCatalin AndreiによるHow to Migrate from a TGW-Centric Oracle Database at AWS Design to Multi-VPC ODB Peeringを日本語に翻訳したものです。
2026年03月30日
Oracle Database at AWSのネットワーキング更新後に出てくる、より興味深いフォローアップの質問の1つは、直接のマルチVPC ODBピアリングがサポートされているかどうかではありません。すでに以前の、より制約の多いモデルを前提に構築している場合にどうするか、という点です。
非常によくある出発点は次のような構成です。1つのODBネットワークが1つのTransit VPCとピアリングされ、そのVPCがAWS Transit Gatewayにアタッチされています。その後、Transit Gatewayが他のVPCへの接続性を拡張します。このパターンは現在も有効であり、AWSドキュメントでも引き続きサポートされています。しかし、Oracle Database at AWSで1つのODBネットワークを複数のVPCと直接ピアリングできるようになったため、一部のお客様はすべてを作り直すことなく、その設計の一部を簡素化したいと考えるでしょう。
ODBネットワークのワークロードがTransit VPC経由でTGWへ出ていくためには、現在、TGWがODBネットワークと同じAZ内のサブネットに1つだけアタッチメントを持つ必要があるという制約があります。お客様の一般的なランディング・ゾーンでは、アプリケーションの冗長性を確保し、複数のAZに分散させます。同じ考え方がTGWアタッチメントにも適用されます。
ワークロードが複数のAZに分散され、TGW接続を持つ既存のアプリケーションVPCは、ODBのトランジットとして使用できないため、参照アーキテクチャにはTGWアタッチメントを1つだけ持つTransit VPCが含まれます。実務的には、移行先は明確です。Transit VPCがまだ有用な役割を果たしている場合はTransit Gatewayへのアタッチを維持しつつ、選択したアプリケーションVPCについては、TGW経由の間接的なデータベース・アクセスから、それぞれの直接ODBピアリング接続へ移行します。
開始時のアーキテクチャ
開始時のアーキテクチャには、通常3つの特徴があります。
- 1つのODBネットワークが、1つのVPCと直接ピアリングされています。
- その最初のVPCは一般的にTransit VPCと呼ばれ、Transit Gatewayアタッチメントを持っています。
- 他のアプリケーションVPCは、Transit GatewayとTransit VPCを通じてODBネットワークへ間接的に到達します。
このアーキテクチャは、直接ピアリングの選択肢がより限定的だった時期には理にかなっていました。また、集中ルーティングを意図的に選択している場合には、現在でも理にかなっています。しかし、目的が単に複数のアプリケーションVPCから同じODBネットワークへ到達できるようにすることであれば、新しい直接ピアリング・モデルにより、ルーティングの迂回と運用上の複雑さを軽減できます。
ターゲット・アーキテクチャ
ターゲット・アーキテクチャは、必ずしもTGWを完全に置き換える必要はありません。これは重要なポイントです。
元のVPCをTransit Gatewayに接続したまま、同じODBネットワークから追加のVPCへ直接ODBピアリング接続を作成することができます。つまり、この移行は必ずしも「TGWを廃止して直接ピアリングへ置き換える」というものではありません。「直接ピアリングが役立つところでは直接ピアリングを使い、TGWがまだ意味を持つところではTGWを使い続ける」という形にできます。
開始前に確認すべきこと
何かを変更する前に、基本的な制約を確認してください。
- ODBネットワークが追加のピアリング接続をサポートできることを確認します。
- ODBネットワークと、ピアリング予定のすべてのVPCとの間でCIDR範囲が重複していないことを確認します。
- ODBネットワークがUS East（N. Virginia）またはUS West（Oregon）で2026年2月7日より前に作成されたものかどうかを確認します。これらのリージョンの古いネットワークでは、複数のODBピアリング接続を追加する前に再作成が必要です。
- 元のTGW接続VPCが、他のネットワークやオンプレミス・パスのトランジット・ハブとして引き続き必要かどうかを確認します。
- 変更を加える前に、現在のルート表とDNS設定を文書化します。
どのVPCをTGWの背後に残し、どのVPCを直接ODBピアリングへ移行するかを、事前に決めておくことも重要です。すべてのスポークVPCを一度に移行する必要はありません。
段階的な移行手順
ステップ1: 現在のトラフィック・パスを棚卸しする
まず、現在どのアプリケーションVPCがTGW経由でODBネットワークへ到達しているかを特定します。各VPCについて、関係するサブネット、使用されているルート表、アプリケーションの送信元CIDR、DNSの動作、ODBネットワーク内の宛先データベースまたはサービスを記録します。
これにより、明確なベースラインが得られ、データベース接続以外の理由でTGWに依存しているVPCを誤って移行することを避けられます。
ステップ2: 最初に移行するVPCを決める
強い理由がない限り、最も重要なVPCから始めないでください。ルーティングが明確で、接続要件が十分に理解されている低リスクのアプリケーションVPCを選びます。
最初の移行の目的は、勇気を示すことではなく、パターンを検証することです。
ステップ3: 対象VPC向けに直接ODBピアリング接続を作成する
既存のODBネットワークと、移行したいアプリケーションVPCとの間に、新しいODBピアリング接続を作成します。必要に応じて、ピア・ネットワークCIDRを指定し、ODBネットワークと通信すべき正確なサブネットにアクセスを限定します。
これが中心となる変更です。ピアリングが作成されると、対象VPCはデータベースへ到達するためだけにトランジット・パスへ依存する必要がなくなります。
ステップ4: 新しくピアリングされたVPCのルート表を更新する
ピアリング接続を作成したら、そのVPC内のルート表を更新し、ODBネットワーク宛てのトラフィックがTGWではなく直接ODBピアリング接続へ向かうようにします。
このステップで移行が実質的に有効になります。ルート表を変更するまでは、新しいピアリングは可能性にすぎません。
ステップ5: DNSと接続性を検証する
移行したVPCからターゲットのOracleデータベースへのアプリケーション接続をテストします。名前解決、接続文字列、レイテンシ、セキュリティ制御、以前のトランジット・パスを前提に構築されていた可能性のあるデータベース・クライアントの前提条件を検証します。
多くの環境では、ルーティング変更は単純でも、DNS検証の段階で運用上の予期しない問題が現れます。
ステップ6: そのVPCのTGW経由の古いODBルートを削除する
直接パスが検証できたら、このVPCのODB宛てトラフィックをTGW経由で送っていた古いルート・エントリを削除または廃止します。これにより、曖昧なルーティングを避け、最終的なアーキテクチャを理解しやすくできます。
そのVPCが他のトラフィック・パターンでまだTGWを必要としている場合は、TGWアタッチメント自体は維持します。目的はTGWを盲目的に削除することではありません。目的は、Oracle Database at AWSアクセスにおけるTGWへの不要な依存を取り除くことです。
ステップ7: VPC単位で繰り返す
間接的なTGWベースのアクセスから直接ODBピアリングへ移行すべき追加のアプリケーションVPCごとに、同じプロセスを繰り返します。各ピアリング接続は独立したリソースであるため、移行は段階的に実施できます。
これは新しいモデルの非常に良い点の1つです。大規模な一括ネットワーク切り替えは不要です。
ステップ8: 元のTGWアタッチVPCの役割を再評価する
いくつかのVPCを直接ピアリングへ移行した後、TGWにアタッチされたままの元のVPCの役割を再確認します。それは、オンプレミス・アクセス、共有サービス、または直接ピアリングに適さないVPCのための中央トランジット・ポイントとして、引き続き価値があるかもしれません。
あるいは、そのトランジットの役割を時間とともに縮小できることが分かるかもしれません。
運用面で何が変わるか?
最も目に見える変化は、ルーティングがより明示的になることです。直接ピアリングされたVPC内のアプリケーションは、それぞれ専用のODBピアリング接続を通じてODBネットワークへ到達します。これにより、TGW接続VPCへの「隠れた」ネットワーク依存が減ります。
2つ目の変化は、ピアリングのライフサイクル管理がより細分化されることです。各アプリケーションVPCは、単一のトランジット・ベースのデータベース・アクセス・パスの背後にあるスポークとしてではなく、独立したピアリング関係として追加、更新、削除できるようになります。
移行しない方がよい場合
すべての環境で、あらゆる場所を急いで直接ピアリングへ移行すべきではありません。
- 集中ルーティングとインスペクションが必須要件である場合、TGWがよりクリーンな制御点であり続ける可能性があります。
- アプリケーションがOracleデータベース・アクセスを超えた広範な共有接続にすでに依存している場合、トランジット・パターンが引き続き適切なアンカーである可能性があります。
実践的な最後のアドバイス
私がこの移行を計画するなら、これをネットワーク再設計プロジェクトとして位置付けることはしません。依存関係を減らす取り組みとして位置付けます。
VPCを1つずつ移行します。ルーティングとDNSを慎重に検証します。TGWがまだ価値を提供する場所ではTGWを維持します。追加の迂回に見合う価値がなくなった場所でのみ削除します。
これこそが、新しいOracle Database at AWSネットワーキング・モデルの本当の価値です。すべてを一度に再設計するのではなく、選択的に簡素化できるのです。