Transit Gatewayなしで複数のVPCにDirect Connectで接続をした際の設計備忘録

初めに

少し前にDirect Connectで１拠点に対し複数のVPCに繋ぐ機会がありました。

割とよくある構成かとは思いますがDirect Connectの設計・構築する機会が少ないの整理を兼ねて備忘録として残しておきます。

要件

今回データセンターからAWS上の２つのVPCに向けて通信する必要がありました。

データセンター(以降DC)は単一であるものの内部は部門単位でネットワークが分割されておりそれぞれが干渉しないように排他制御が行われています。

今回AWS側との通信もこれを遵守する必要があり、部門Aおよび部門Bを跨ぐ通信は行われないように設定する必要があります。

なお通信要件として分割は必要ですが、費用分割等それ以外の部分はそこまで細かい要件はありません。

Direct Connect周辺のリソースの概念

この辺りはレイヤー３周りの話を普段から扱ってる人にとっては当たり前の部分もあるかもしれませんが、普段触ってないとイメージできない部分もあるかと思いますので合わせて整理していきましょう。

なお今回はDirect Connect Gateway(以降DXGW)を使う方式を前提としており、概念理解のために抽象化しているため正確には異なる可能性がある点ご注意ください。

全体像

大枠のイメージとしてはDXGWはDCとVPCを中継するルータであり、VGW及びVIFについてはそのルータに結びつくネットワークIFとイメージしてもらうとわかりやすいかと思います。
VIFについてはDC向け、VGWについてはVPC向けのネットワークIF(ゲートウェイ)となります。

それぞれの視点

Direct Connectの設計をするにあたり全体の像をまず書くことも多く勘違いされやすいのですが、データセンター側視点からすると接続先と指定するのはVIF及びそのASとなるDXGWまでありその先となるVPCは見えないという点は注意が必要となります。

この構成はデータセンターから見た場合以下のようになります。

https://aws.amazon.com/jp/blogs/news/creating-active-passive-bgp-connections-over-aws-direct-connect/
上述のアーキテクチャでは、いずれの場合も BGP の ASN が DXGW の先 (図中の上部) にもあることにお気づきになったかもしれません。これらの ASN は DC1/DC2 から見た時には AS_Path のリストに存在しません。つまり、DXGW は AWS 側にある AS 群のリフレクタとして動作するものなのです。

VGWをDXGWと結びつけた構成を取る場合、AWS側ではDXGWをルートリフレクターとして働きVGWはそのクラスタのクライアントとして働くような形となります。

そのためたとえVPCがいくつ結びついていようがDC側としては見えるASはDXGWだけであり、その裏にどのようなASがいるかは見えません。
正確にいえば図上で「？」を記載していますが、何か存在するということは直接認知できないというのが正確です。

仮に結びつくVPCが増えた場合、そのVPCのCIDRが伝播されるルートに増えるためDC側でも何かネットワークが増えたな？ということは認知できます。
ただ受け渡される情報として増えるのはそのCIDRのみでVGWのAS番号が渡るわけではありません。そのため本当にVPCが増えたのか既存VPCにセカンダリCIDRが増えたのかそれ以外のなんらかの起因で増えたのか...と言ったことは認知できません。

これは逆(VPC)側も現時点では似たような形となります（起因は違いますが）。

厳密にいえばASの情報が渡ってきてるかもしれませんが、本記事執筆時点での仕様ではDXGWで渡ってきた具体的なルートを見れる機能はありません。その先となるVGW側でもその伝播先となるルートテーブルで具体的に渡ってきたCIDRは見えるもののルート先はVGWという情報のみとなります。

そのためVPC側から見た場合既存の拠点のまま伝播されるルートが増えたのか、VIFが増えてDXGWに繋がる拠点が増えたのか等は把握することができません。

設計全体像としてはこれら全体を把握する必要はありますが、DXGWが中継点となりそれよりAWS側、DC側である意味完全に分かれていると言えるかもしれません。

構成案

さて前置きが長くなりましたが本記事先頭に記載したように複数のVPCとの接続をそれぞれ分離できるようなルーティングを実現する構成を検討します。

結論から言えば今回は構成案2となりました。

構成案1(DXGW1つ)

シンプルに1つのDXGWで配置を行うパターンです。

管理するリソースが少なく、レイヤー３でデータセンター側から見た場合１つのASとなるためとりあえずそこに流しておけばよしなに設定できるのがメリットです。

また仮にVPC側が増えてもフィルタリングの方針によってはDC側のルーターの設定を変更なしで対応できる場合もありますのでDC側AWS側でベンダーが分かれてたとしても片側で済む可能性もあります(逆も然り)。

一方でルート自体は集約されてしまうため上記のような設定は概要図レベルでは見えない詳細部分での設定が必要となりその部分は若干複雑になります。

AWS側で行うのであれば個別にルート情報は落とせないのでNACLによってフィルタリング、DC側で行うのであればルータに機能があれば受け取ったルートをフィルタリング、もしくは受け取ったルート自体はそのまま受け取りフィルタリングする形となります(Yamahaルータで言えばbgp export filterですね)。

構成案2(DXGW分離)

こちらはDXGWをルート情報を共有して問題ない集合単位で分離しAS自体を別にしてしまう形です。

こちらであればDCから見た場合に完全に対抗先のASが分かれているため独立してルートを制御することができます。
今回の場合はVPCとDXGWが1:1としていますが、ルート情報をセットで取り扱って良いのであればその単位でDXGWに結びつけグループ化してしまっても良いでしょう。

こちらの方が柔軟性も高く全体像的に直感的にわかりやすい部分があるため、多くの場合こちらの形の方がマッチするのではないかと個人的には思います（個別の事情もあるため一概には言えないですが...）。

一方で新しいVPCが増えてそちらはそちらで別の経路セットを使いたい場合AWS側の追加に加えて、DC側のルータでも設定を追加することが必須となります。
複数ベンダーが絡む場合はこの辺りの作業タイミング等の調整が必要となりますのでこの辺は少しネックになるとは思います。

終わりに

Direct Connect経由で複数のリソースと接続をした際に考えていたとことを備忘録として整理してみました。

実のところ単一のリソースと繋ぐか、複数繋ぐ場合はTransit Gateway入れた方が良いケースが多く制御はそちらで...となるDirect Connectの利用ケースを見るのが主だったので、今回のようにある程度整理しようとするとできはするけどレイヤー３周りを含め意外と正確に理解はしていないというのは思うので良い機会になったとは思います。

今回記載したような構成はいずれの場合でも接続先がどんどん増えていくと管理は辛いことになりますので、あくまで構成上そこまで接続数が増えない（増えたとしてもかなり先）というところが前提となります。

数が増える・複雑になりそうであればTransit Gatewayを導入しておきそこを中核として制御を組み上げる方が管理しやすいためそちらも選択肢に入れて検討しましょう。