AWS Transit Gateway で複数の VPC に共通のサイト間 VPN

VPN を一度だけ接続し、各 VPC を同一のトランジットゲートウェイに接続したうえで、関連付けと伝播を分ければ、スポークはオフィスに届いても互いには届きません。

今期は二つの VPC がオフィスネットワークを必要としており、見積もりが崩れるのはまさに二本目のトンネルです。AWS Transit Gateway は、VPN が一度だけ接続され各 VPC が同じハブに接続される共有のルーティングハブとして機能できます。そのうえでオンプレミスネットワークは一本の接続で接続済みのすべての VPC に届きます。これはルーティングの決定権が誰にあるかを変えるもので、多くの設計が間違えるのはまさにこの部分です。

VPN のアタッチメントと VPC のアタッチメントは同じゲートウェイ上の別個のオブジェクトであり、だからこそルーティングの関係は後から構築する必要があります。

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

ピアリングが期待される近道にならない理由

魅力的な代替案は、VPN を VPC A で終端し、VPC B をそこにピアリングすることです。通常の VPC ピアリングは、A の VPN 接続を介したエッジ間のトランジットを提供しません。ピアはピアリング自体が提供するアドレスにしか到達できず、VPN のエッジはその一つではありません。トランジットはハブが与えるものであり、ピアリングが与えるのは一対だけです。

その制限はピアリングの性質であり、引き上げられるクォータではありません。

関連付けと伝播は別の仕事をする

トランジットゲートウェイの内部では、関連付けがアタッチメントから到着するトラフィックの参照に使うルートテーブルを選びます。伝播は、あるアタッチメントの学習済みまたは接続済みのプレフィックスをどのテーブルが受け取るかを決めます。ひとつのアタッチメントをひとつのテーブルに関連付けながら、複数のテーブルへ伝播させることもできます。この二つを混同することが、誰も計画していない到達性に設計が至る理由です。

完全に接続された小さなハブは簡単なケースです。

すべてのアタッチメントをひとつのテーブルに入れれば、VPN と両方の VPC プレフィックスはきれいに解決します。同時に、共有テーブルにはスポークという概念がないため、組織が意図していなかった VPC 間の到達性も許してしまいます。

ワークロードのルートは別の場所にある

各ワークロードサブネットには、想定されたオンプレミスのプレフィックスへ向かうトランジットゲートウェイ経由のルートが依然として必要です。それらの VPC ルートテーブルは、トランジットゲートウェイ自身のテーブルとは別個のオブジェクトです。必要なプレフィックスを追加し、すべての宛先を新しいデフォルトで置き換えるのではなく既存のルートを保ってください。サブネットのルートは顧客側デバイスに何も広告しません。

ピアリングはどちらも与えないため、動的ルーティングか静的ルーティングかを意識して選んでください。

オンプレミスアクセスを失わずにスポークを分離する

A と B のどちらもオフィスには届いてよいが互いにルーティングしてはならない場合、テーブルを分割します。VPN アタッチメントの関連付け先テーブルが VPC プレフィックスを持ちます。VPC アタッチメントの関連付け先テーブルはオンプレミスのプレフィックスを持ち、A と B を結ぶルートはありません。この関係を作るのは伝播なので、すべてのデフォルト関連付けを受け入れる必要はありません。

これはルーティングの分離であり、アプリケーションの認可ではありません。

セキュリティグループ、ネットワーク ACL、ホストのファイアウォール、各サービス自身の権限が、どのトラフィックを受け入れるかを依然として決めます。検査が必要なら、ハブがやってくれると仮定せず、対応する経路を明示的に設計してください。

ハブが直さないもの

ハブがひとつのプレフィックスに二つのワークロードを識別させることを許さないため、アドレス計画は依然として重複してはなりません。各 VPC アタッチメントは、そのワークロードが期待する Availability Zone のカバレッジを必要とします。BGP を使う場合、顧客側デバイスの各必要プレフィックスへの戻りルートは、設計とそのインポートポリシーに一致していなければなりません。欠けた広告は壊れたトンネルとまったく同じに見えます。

VPN 接続とトランジットゲートウェイは今や共有インフラストラクチャです。

トンネルの冗長性、デバイスの容量、監視、保守は、各 VPC を独立に接続されたものとして扱うのではなく、依存するすべての VPC を中心に計画してください。

既存の virtual private gateway 構成からの移行にも、同じ明示的な計画が必要です。アタッチメントとポリシーを構築し、管理されたワークロード経路をひとつ移し、古い経路を廃止する前に許可される関係と拒否される関係を確認してください。中央集約は、ネットワークチームに共有接続を管理する一箇所を与えるときには助けになり、ひとつの大きなテーブルの背後で誰が誰に届くかを隠すときには害になります。

関連記事