『AWS Direct Connect の仮想インタフェースの種類は3つに分けられる、private、public、transit。AWS Transit Gateway につなぎたい時は transit だ。』
どーも、トンネルとか隙間をみるとくぐれるかを考えてしまうくらいには Ace Combat が好きな 
id:nabeop です。前回の続編として AWS Transit Gateway に AWS Direct Connect を接続したので、検証などでわかった設計時の知見などを書いてみます。
ネットワーク外観と作業前後の変化
「オンプレ ネットワーク A」と「AWS VPC B」を接続している AWS TGW が前回の作業で導入した Transit Gateway です。
今回はオンプレ ネットワーク B から Transit Gateway に接続している VPC に直接通信したいという要件が出てきたので、上記のようにオンプレ ネットワーク B から Direct Connect を新規構築して Transit Gateway に収容しました。
検証作業などで得られた知見や設計時に注意すること
このような構成を作成するにあたり検証などを通じて以下のような知見が得られました。
TGW のルートテーブル内での経路選択の優先順位
オンプレネットワーク内は OSPF で経路制御しており、Transit Gateway のルートテーブルにはオンプレネットワークの経路を BGP で再広報した内容が入っています。Transit Gateway のルートテーブルにはオンプレ ネットワークへの経路も含まれています。
今回の作業が完了した場合、AWS Trasnit Gateway のルートテーブルにはオンプレ ネットワーク B への経路が以下の2種類が流れ込んでくることが想定していました。
- AWS DX B 経由の経路
- AWS VPN からオンプレ ネットワーク A を経由した経路
AWS VPC C など Transit Gateway に接続しているネットワークからオンプレ ネットワーク B への通信は AWS DX B を経由して欲しいところですが、Transit Gateway のルートテーブルには上記の経路が同一 prefix 長で入ってきてしまいます。このため Transit Gateway のルートテーブルでは prefix 長の比較による経路選択ができません。オンプレ ネットワーク A から再広報している分は自前のルータで実施しているのである程度は制御可能ですが、積極的にやりたい作業ではありません。
普通のルータでは prefix 長の他にもパスの数やコストなどで経路選択されます。Trasnsit Gateway のルートテーブルでも同一 prefix の場合は広報された経路の種類に応じて選択される経路の優先順位があります。この場合の優先順位は VPC 由来 -> Direct Connect 由来 -> VPN 由来の順番で採用されます。
今回の場合は Direct Connect 由来の経路を優先したいので、オンプレ側で再広報する経路を変更する必要なく意図通りの経路で通信できそうです。
Transit Gateway に接続可能な Direct Connect の作成と注意点
Transit Gateway 登場以前の Direct Connect の仮想インタフェースのタイプは public と private のみでした。Transit Gateway の登場によって新しく transit という種類の仮想インタフェースが Direct Connect に追加され、Transit Gateway に接続する場合は仮想インタフェースを transit で作成する必要があります。自前で専用線を運用できる組織の場合は transit で仮想インタフェースを作ればいいだけの話ですが、弊社の場合はさくらインターネットさんの AWS 接続オプションによって Direct Connect を作成しており、AWS 接続オプションは Direct Connect の仮想インタフェースを提供するサービスだったので、提供される Direct Connect の仮想インタフェースで transit がサポートされているか、ということが重要な要件でした。
先日、AWS 接続オプションで提供される仮想インタフェースの種類に transit が追加され一安心しました。
Direct Connect を TGW に接続する場合の構成
Direct Connect を Transit Gateway に接続する場合は Direct Connect の仮想インターフェースを TGW に直接収容するのではなく、Direct Connect Gateway に仮想インターフェースを収容して Direct Connect Gateway を Transit Gateway に接続する必要があります。Direct Connect と接続しているオンプレ側の経路は Direct Connect Gateway によって Transit Gateway のルートテーブルに伝播しますが、Transit Gateway のルートテーブルの内容は Direct Connect Gateway によってオンプレ側に伝播しません。
オンプレ側に広報する経路は Direct Connect Gateway で個別に指定する必要があります。また、登録できる経路は 20 prefix までで上限を増やすことはできません。このため、ネットワーク設計時になるべく集約できるようなネットワーク設計をしておく必要があります。
また、Direct Connect Gateway は内部的に BGP を喋っているらしく、構築時に Direct Connect Gateway で使用する AS 番号を決定しておく必要があります。この AS 番号は Transit Gateway に接続している他の AWS VPN などで使用している AS 番号と重複しないように選択する必要があります。Direct Connect Gateway の AS 番号は作成後に変更はできません。重複などによって AS 番号を変更する必要がある場合は Direct Connect Gateway の作り直しが必要になります。Direct Connect Gateway の作り直しは Direct Connect の仮想インターフェースの作り直しを意味するので設計時に注意が必要です。
AWS 接続オプションとローカルルータの接続
AWS 接続オプションとはさくらインターネットさんで提供されている AWS Direct Connect の仮想インタフェースを提供するサービスです。
Direct Connect を構築する前のオンプレ ネットワーク B 内のネットワーク構成は上記のようになっていました。オンプレ ネットワーク B には4つのネットワークを作成しており、それぞれがローカルルータで接続しています。ローカルルータは接続しているローカルルータとしか経路交換しません。例えばローカルルータ A はローカルルータ D と接続しているので内部ネットワーク D の経路情報をもっていますが、ローカルルータ B とは接続していないので内部ネットワーク B の経路情報は持っていません。また、ローカルルータ A には内部ネットワーク A に存在するホストがオンプレ ネットワーク A やオンプレ ネットワーク A に接続している他のネットワークと通信できるようにデフォルトルートをローカルルータ D に向くように静的経路を追加しています。
AWS 接続オプションとは前述のさくらインターネットさんのニュースにあるとおり、ローカルルータと接続して経路交換します。また、交換される経路は接続したローカルルータが接続しているネットワークのみという制約があります。このため、Direct Connect 経由で通信させたいネットワークに接続しているローカルルータの全てと AWS 接続オプションを接続させる必要があります。
今回は内部ネットワーク C に Direct Connect 経由で通信するホスト郡がいたので、ローカルルータ C のみに AWS 接続オプションを接続させました。
AWS 接続オプションには接続しているローカルルータが接続しているネットワークの経路情報が広報されるということはローカルルータで持っているデフォルトルートも広報されててしまい、Transit Gateway のルートテーブルにデフォルトルートが Direct Connect Gateway に向くような経路が追加されました。我々の使い方では Transit Gateway にデフォルトルートが追加されても通常時は困らない構成だったのですが、本来は不要な経路が追加されることになります。
Transit Gateway ではルートテーブルにプロパゲートしたときに経路が流れ込んできますが、アソシエートしただけであれば通信は可能ですが経路情報は流れてきません。今回はこの仕様を利用して Direct Connect Gateway のアタッチメントはルートテーブルにアソシエートするだけに止めて、ルートテーブルには Direct Connect Gateway 向けの経路は静的経路として登録しました。
We are hiring !!!
このようにオンプレとクラウドの両方の知識を活かして、ネットワークや基盤を一緒に整備していく仲間を募集しています。web サービスと同様に基盤も構築したら終わりではなく、常に変化し続けています。これからもオンプレとクラウドの両方の知識を活かして基盤の開発をしていきます。そんな我々と一緒に仕事をしてみませんか?
カジュアル面談などで気軽に話を聞いてみたいでも大歓迎です。
