二つのAWSアカウント、一つのオンプレミス網：どの経路を選ぶか

明白な枠組みはピアリング対VPNですが、それは誤った枠組みです。ピアリングされたVPCは、エッジ間ルーティングのために隣のVPCのVPN接続を借りることはできないため、その選択肢はルートテーブルがどう示唆しようと最初から存在しませんでした。実際に選ぶのは、共有ネットワークハブ、二つの独立したVPN経路、狭いアプリケーション入口のいずれかです。それぞれが、ルーティングの所有者は誰かという別の問いに答えます。

三つの選択肢と、選択肢でないもの

まずピアリングという発想を消し、残ったものを図の単純さではなく所有権で比較してください。下の表は決定を凝縮したものです。

アカウントAがオンプレミス網全体への到達性を必要とするなら、プロキシの行は形が違います。アカウントAが一つのAPIを必要とするなら、最初の二行は要件が求めた以上のネットワークです。

共有 Transit Gateway が勝つとき

Transit Gateway は各VPCとVPNを別々のネットワークとして接続します。アカウント間の共有によりVPCの所有者はアカウントを統合せずにハブを利用でき、オンプレミスのプレフィックスがAWSのネットワークと出会う場所が一か所になり、どのアタッチメントがどのルートを学習するかを考える場所も一つになります。

すべてを接続することは、すべてを許可することではありません。関連付けと伝播がどのアタッチメントがどのルートテーブルを使うかを決めるため、二つのVPCプレフィックスがそれぞれオンプレミスのサービスに到達しつつ、相互アクセスはハブの設計によって除外されたままにできます。オンプレミス側にはAWSプレフィックスへの戻りルートが依然として必要で、それは別チームの変更チケットです。

コストは財務面だけでなく組織面でもあります。ハブの所有者は他チームが依存するルーティング関係を握るため、一つのアタッチメントの変更が、ハブの所有者が聞いたこともないサービスのトラフィックを動かすことがあります。アタッチメント時間とデータ処理は接続するネットワークごとに積み上がるため、ハブはそれを運用するチームより速く成長しがちです。

独立したVPNや狭いプロキシが勝つとき

独立した二つのVPNは、実際の運用境界がある小規模な展開に向いています。各アカウントが自分のトンネルを変更し、どちらもルートテーブルの編集で相手を壊せません。制約はオンプレミス側にあります。ピアゲートウェイには追加トンネル分の容量が必要で、アドレス計画は重複してはならず、同じプレフィックスを広告する二つの構成には期待ではなく意図的な優先順位が必要です。

プロキシは最も狭いインターフェースです。アカウントAがアカウントBのデータベースやAPIを一つ必要とするなら、範囲を限定した仲介役が、独自の認証・ログ・可用性の物語を持つ定義済みの入口を与えます。同時に最も悪用されやすい選択肢でもあります。あらゆるプライベート宛先に転送する仲介役は、手順を増やした無制限の中継になっており、それ以外のことではVPCからオンプレミス網への透過的な通過として振る舞いません。

その前にVPCピアリングの制約を読む価値があります。四つ目の発想がなぜ繰り返し戻ってくるのか、なぜ機能しないのかを説明しているからです。

要件を満たす最も狭いインターフェースを選ぶ

問いを並べます。Aが必要とするのはネットワークか、ネットワークの集合か、一つのサービスか。オンプレミスのチームは一本の経路を望むのか、複数を望むのか。他のチームのトラフィックのルーティングを変えてよいのは誰か。最も狭いインターフェースを生む最初の答えがアーキテクチャであり、その後のすべては実装です。

プレフィックス計画、ルートの所有権、トンネルまたはアタッチメントの一覧、双方が想定する障害モードとともに答えを記録してください。後で誰かが、なぜアカウントAは単にアカウントBのVPNを使えないのかと尋ねたとき、その記録が答えになり、次のプロジェクトで同じ三つの選択肢を蒸し返す手間を省きます。