SaaS トラフィックを適切な顧客 VPN にルーティングする方法

ある SaaS プラットフォームは十数の顧客ネットワークに接続しており、そのうち二社の顧客がどちらもプライマリデータベースに 10.20.0.10 を使っています。ジョブでそのアドレスを受け取ったワーカーには、そのジョブがどのデータベースを指すのかを知る方法がなく、共有ルーティングテーブルはプレフィックスが指すトンネルへ喜んで送り出します。解決策はトンネルを増やすことではなく、テナント ID が経路のどこで入るのか、アドレス計画がどの分離モデルを必要とするのかを決めることです。三つの条件が選択を決めます：顧客プレフィックスが重複するか、誤りがどこまで広がり得るか、誰がコネクタを運用するかです。

二つの顧客データベース、一つの宛先アドレス

IP アドレスは位置であり、ID ではありません。リクエストはサーバーが検証したテナントを運び、そのテナントが宛先を解決する前にネットワークコンテキストを選ぶ必要があります。

そうならない場合、障害は静かに起きます。接続は成功し、クエリは実行され、ルーティングテーブルに 10.20.0.10 のエントリが一つしかなかったため、回答は誤った顧客のデータベースから返ります。DNS はさらに悪化させます：テナント A のコンテキストで解決されたキャッシュ済みの名前が、テナント B のために実行されているジョブで再利用される可能性があります。パケット内の何も両者を区別しないため、どれだけリトライロジックを積んでも修復できません。

まず分離モデルを決める

製品を比較する前に三つの条件を書き出してください。重複は一つのアドレス空間を共有できるかどうかを決め、影響範囲はルーティングの誤りがサポートチケットで済むか侵害になるかを決め、運用上の所有権はテナントごとにコネクタ群を運用できるかを決めます。

プレフィックスが異なり、ポリシーが管理されたハブを許すなら、テナントごとのルーティングテーブルを持つ一つの Transit Gateway は実現可能です。アタッチメントの関連付けはそのアタッチメントから入るトラフィックに使うルーティングテーブルを選び、伝播はどのルートがテーブルに現れるかを選びます。自分のテーブルだけに関連付けられ、自分のプレフィックスだけを伝播するテナントアタッチメントは、ハブに到達し、それ以外には到達しません。これはルーティングの決定であり、誰も共有テーブルにデフォルトルートを追加しない限り正しいままです。

プレフィックスが重複する場合、ルーティングだけでは分離できません。テナントごとに別のネットワークコンテキストを持つか、各顧客の空間に明確な意味を与える変換計画が必要です。

Transit Gateway の分離とは実際に何を意味するか

重要なのは関連付けと伝播の二つの設定で、混同しやすいものです。関連付けはこのアタッチメントからのパケットをどのテーブルで検索するかを答え、伝播はどのテーブルがこのアタッチメントのルートを学習するかを答えます。分離は両方をテナント固有にすることで生まれ、アタッチメントを増やすことでは生まれません。

デフォルトの全対全構成は便利ですが分離ではありません。別々のルーティングテーブルは接続性を制限しますが、同じルーティングコンテキスト内で一つの不変の宛先アドレスに二つの意味を与えることはできません。アプリケーションがテナントを知る前に 10.20.0.10 を解決するなら、ルーティング層は必要な情報をすでに失っています。

AWS は 2026 年十月 23 日に Transit Gateway と Cloud WAN 向けのアタッチメントレベルの 1:1 NAT を追加し、サポート対象のアタッチメントにおける重複への答えが変わりました。Transit Gateway NAT のドキュメントには、ホストビットを保持した静的でステートレスな同一プレフィックスの IPv4 マッピングが説明されています。これを前提に設計する前に、サポートされるアタッチメントの種類とリージョン制約を確認してください。

ジョブを検証済みテナントに結び付ける

すべてのジョブはサーバーが検証したテナント ID を運び、その ID が管理者所有の接続レコードを選ぶべきです。レコードは承認済みのネットワークコンテキスト、サービスアドレス、資格情報の参照、そこで許可される操作を指定します。信頼できないリクエストが独自の VPN 識別子、ゲートウェイ、プライベートターゲットを提供してはなりません、有効なログインは、接続されたすべての顧客のアドレス空間を調べる許可ではないからです。

分離コネクタの設計では、テナント A の作業は A 固有のコネクタに送られ、そのコネクタは A の VPC で動作し、A の承認済みリソースにのみ到達できます。一台のホスト上の別々のコンテナでは、その分離は自然には生まれません：ネットワーク名前空間、ルート、外向きポリシーが実装する必要があります。コネクタにはテナント単位の資格情報とキューも必要です、プライベートルートは共有シークレットや共有作業項目の範囲を制限しないからです。アプリケーションワーカーをプールしても、ネットワークコンテキストと資格情報をホスト単位ではなくテナント単位で選ぶ限り問題ありません。

ヘルスチェックはテナントと段階を明示すべきです：トンネル確立、ルートの存在、実際のサービスリクエストの成功は三つの異なるシグナルです。稼働中のトンネルの集計数は、コネクタが壊れている一社の顧客を隠してしまいます。

失敗すべき経路をテストする

起動前に三つのテストを実行します。許可された A の操作は成功し、許可された B の操作は成功し、意図的に B のコネクタまたは変換されたエイリアスに向けた A のジョブはクローズドに失敗しなければなりません。次に一つのトンネルを切断し、そのジョブがそのテナントだけ失敗し、別の顧客の同じ番号のサブネットにフォールバックしないことを確認します。復旧もテストすべきです、古いルートやキャッシュされた資格情報は障害より長く残ることがあるからです。

アーキテクチャは、分離コネクタを持つプールされたワーカーでも、完全に分離されたテナントリソースでもかまいません。不変条件は同じです：検証済みのテナントコンテキストがルートと資格情報を選び、ルートの変更がテナント間のアプリケーション許可を与えることは決してありません。