はじめに
DMMグループ Advent Calendar 2021 13日目の記事になります。
インフラ部所属の松野が担当します。
本ブログの内容は2021/12現在の情報になります。
（AWSはアップデートが早いため、変わる可能性があります）
DMMではAWSの接続方法の一つとして、DirectConnect接続を利用しています。
DirectConnect接続には
・専用接続
・ホスト型接続
がありますが、ここでは専用接続について調べて検証した結果わかったことについて記載をしています。
これからTransitGatway（TGW）やDXGW-VGW構成を構築する方でお役に立てば幸いです。
結論
先にTGWとDXGW-VGWを利用した場合の結論を書いておきます。
-
移行は通信影響なしで可能
DirectConnectをVGW接続からTGW、DXGW-VGWへの移行する場合は通信影響無しで行える -
運用が楽になる
DirectConenctにVGW接続で利用されている方は、DXGW-VGW構成に変更すると運用が楽になる
TGW構成もVGWに比べてAWS内だけの作業になるため運用が楽になる
TGWやDXGWは別のアカウントに共有が可能なため、１箇所で管理しての運用が可能 -
DXGWの許可されたプレフィックスに注意
TGW、DXGW-VGW構成をする場合はDXGWを利用する必要がある
DXGWには必ず許可されたプレフィックスというオンプレに通知する機能が存在し、設定できるCIDRの制限が20個までのため、考慮して設計と運用していく必要がある
許可されたプレフィックスは設定変更に時間がかかるので何度も検証する場合は注意
DirectConnectの専用接続について
DirectConnectの専用接続には下記３つの方法があります。
-
VGW接続
-
DXGW-VGW接続
-
TGW接続
メリット、デメリットについて
では、それぞれのメリット、デメリットについて書いていきます。
VGW接続
構成 
メリット
-
VPCのCIDRをそのままオンプレに伝えることが可能
DXGWを使うと許可されたプレフィックスで集約が必要になるため -
VGW接続毎の通信制御（Filter、帯域制）が可能
Private-VIF毎に制御をかけられる
メリット
-
VGWと接続するためのPrivate-VIFの数が最大50本（上限変更不可）
50VPCまでしかDirectConnect接続ができない
51VPC目はAWSとの物理線を増やす必要がある -
開通までのリードタイムが長くなる
DirectConnectを接続する際にオンプレのネットワーク機器にPrivate-VIFを接続構築が必要になるため
DXGW-VGW接続
構成 
メリット
-
VGWに直接Private-VIFを接続した構成よりもVPCの数を多く接続可能
DXGWは200台作成可能（ただし、物理線1本あたりのPrivate-VIFの数は50本のため 物理線1本の場合はDXGWは50台までとなる）
DXGW1台あたり10個のVGWを接続することが可能なため500VPCまで収容可能 -
VGW接続と同じ料金のまま利用可能
DXGW自体は料金がかからない -
DirectConnect利用時の構築手順を少なくでき、直ぐに開通できる
オンプレからDXGWまでを構築して開通しておけば、VGWからはDXGWに接続するだけになるため -
DXGWの許可されたプリフィックスでオンプレへの経路を制御できる
オンプレ側でAWSからの経路制御をする必要がなくなる （もちろんオンプレ側でFilterをかけて2重で管理するのもありだが手間が増えてしまう） -
VGW接続と同じ用にネットワーク設計が可能
DXGWを利用するとVPCのCIDRがオンプレに流れてくるのではなく、DXGWの許可されたプリフィックスで設定をする必要がある
DXGWの許可されたプリフィックスは設定できるCIDR数は20個までになるが、 1台のDXGWに接続できるVGWは10個までになるため、許可されたプレフィックスにVPC毎のCIDRを記載しても特に問題がない
デメリット
-
VPC間通信はDXGWではできない
DXGWに接続されたVGW間の通信（VPC間の通信）をDXGWで折り返し通信はできない
VPC間の通信をしたい場合はVPC-PeerLinkかオンプレで折り変えす通信をする必要がある -
どのDXGWにVGWを接続するかの管理が必要
1台のDXGWにVGWは10個までしか接続できないため、複数DXGWを作成した場合はどのDXGWにVGWを接続するかを管理する必要がある
TGW接続
構成 
メリット
-
VPCへの接続数を気にしなくて良くなる
TGWは5,000のアタッチメントが可能なため*1 -
VPC間の通信が可能になる
TGWに接続したVPC間はTGWで通信することが可能 -
TGW毎に用途を分けて構築することも可能
１つのVPCに複数のTGWを接続することが可能なためVPC間用の通信とオンプレ用の通信を分けて構築することが可能 -
DirectConnectを提供する時間が短縮できる
オンプレからTGWまでを構築しておけば、AWS側の操作だけでDirectConnectを提供可能になる
デメリット
-
DXGW-TGWの構成は１つだけ
１本の物理回線に作成できるTransit-VIFは1本だけになるため、 別のDXGW-TGWの構成を作りたい場合は物理線を別途引く必要がある。ただし、DXGWには最大3個のTGWを接続可能なためDXGWを共有させて利用することも可能 この構成の場合は、TGWで利用するCIDRはお互いに被らないように構築をする必要がある -
利用料金が高くなる
VGW接続の時からTGWの利用料金が発生するため高くなる
詳細：料金 - AWS Transit Gateway | AWS -
AWSからオンプレには集約した経路を通知することになる
DXGWで許可されたプレフィックスを設定する必要があり、設定数が20個までとなっているたAWSからオンプレに告知する経路を集約する必要がある。VGW接続のようにVPC毎にセグメントをオンプレに通知していた場合は同じ設計ができなくなるため注意
共有について
TGWやDXGWは別のアカウントに共有させて利用することが可能
DXGWの共有方法
-
VGWを作成したアカウント側でDXGWに接続申請を行う
接続申請の際に下記が必要になる
・Direct Connect ゲートウェイ ID
・Direct Connect ゲートウェイ所有者
・許可されたプレフィックス*2 -
DXGWを作成したアカウント側で承認をおこなう
承認をするときに許可されたプレフィックスを修正することが可能
TGWの共有方法
-
TGWを所持しているアカウントからResource Acccess Manager（RMA）で利用者側にTGWを共有する
-
利用者側のアカウントで共有されたTGWを承認する
-
利用者側で共有されたTGWを使ってVPCにAttachementを行う
-
TGWを所有しているアカウント側でAtacchementの承認を行う（Atattcimentの自動も可能）
-
RouteTableへのassociateを行う（自動でルートテーブルにassociateすることも可能）
-
TGWを所有しているアカウント側でVPCに対してStaticRouteの設定を行う（Probacationした場合は自動になるし、Probacationも自動にしていた場合はVPCに対して自動でStaticRouteが追加される）
移行について
Private-VIFが大量に余っていれば問題ないが、VGWで消費し少なくなったPrivate-VIFを回収するためにTGWかDXGWーVGWに移行する 移行は通信断なく切り替えが可能（ただし、実際の環境は企業毎に変わるため検証はした方が良い）
VGWからDXGW-VGWに移行する場合
前提
DXGW-VGW構成が構築されていて、DXGWにVGWを接続するとオンプレと通信ができること
移行方法
経路が同じなのでBGPのLP値を利用して経路を切り替える
移行手順
-
VGW接続への経路を優先するためにオンプレ側でVGW接続とのBGP接続のLP値を高めに設定する
-
利用者側のVGWからDXGWに接続する申請を行う
-
DXGW側でVGWの接続を承認する
この時点で、オンプレからの通信はVGW接続を通りAWSからはVGWとDXGW-VGWの両方の回線を利用することになる -
DXGW-VGWに接続されているTrafficを優先するためにオンプレ側の機器でVGW接続のLP値をDXGW-VGW接続より低くする
-
オンプレ側でVGWの通信設定を削除する
-
AWS側で不要になったVGWを削除する
AWSの参考資料： https://aws.amazon.com/jp/premiumsupport/knowledge-center/migrate-traffic-direct-connect/
VGWからTGWに移行する場合
（TGWでVGWの時に利用していた時と同じCIDRを利用）
（DXGWで経路を集約しないケース）
前提
TGWとDXGWは構築済みの状態。
VGWでは10.0.0.0/16のネットワークを利用し、TGWでも10.0.0.0/16のまま同いセグメントで利用したいケース
移行方法
経路が同じなのでBGPのLP値を利用して経路を切り替える
移行手順
-
VGW接続への経路を優先するためにオンプレ側でVGW接続とのBGP接続のLP値を高めに設定する
-
TGW(DXGW）の許可されたプレフィックスに集約された経路を設定する
-
VPCにTGWをアタッチメントする
-
TGWのRouteTableにアソシエーションする
-
TGWのRouteTableにVPC向けのStaticRouteを設定する
-
サブネットに紐づいているルートテーブルにオンプレセグメント向けをTGW宛に設定する
-
TGWへの経路を優先するためにオンプレ側でVGWとのBGP接続のLP値を低めに設定する
-
オンプレ側でVGWの通信設定を削除する
-
AWS側で不要になったVGWを削除する
手順の詳細
-
手順1でTGWから同じ経路が流れてきても利用されてないようにする
-
手順2でオンプレにVGWと同じ経路を流す
-
手順3と4はわかりやすく手動の方法を記載しているが、ルートテーブルへのアタッチメントとルートテーブルへのプロバケーションを自動設定にしても良い
-
手順6でオンプレとの通信がオンプレからはVGW接続を利用するが、AWSからの通信はTGW接続の方を利用して戻るため、行きと戻りでAsymmetricな通信になるが問題なく通信が可能
-
手順7で削除する前にLP値を低くしてVGWを利用している通信を無くす
-
手順8で消すことでTGWのみの通信になる
移行注意点
- TGWに接続しているDXGWで設定可能な許可されたプレフィックスの数は最大20個までになるため、集約経路が増えたりすることを考慮するとTGWに移行可能な数は10~15個までにしたほうが良い
VGWからTGWに移行する場合
（TGWでVGWで利用していた時のCIDRを集約して利用）
（DXGWで経路を集約するケース）
前提
VGWでは10.0.0.0/16のネットワークを利用し、TGWでは10.0.0.0/8で経路を集約して利用する場合のケース
移行方法
ロンゲストマッチを利用して経路を切り替える
移行手順
-
TGW(DXGW）の許可されたプレフィックスに集約された経路を設定する
-
VPCにTGWをアタッチメントする
-
TGWのRouteTableにアソシエーションする
-
TGWのRouteTableにVPC向けのStaticRouteを設定する
-
サブネットに紐づいているルートテーブルにオンプレセグメント向けをTGW宛に設定する
-
オンプレ側でVGWの通信設定を削除する
-
AWS側で不要になったVGWを削除する
手順の詳細
-
手順1の時点でオンプレに経路が告知されるが経路を集約していないため、VGW接続の方がロンゲストマッチで優先される
-
手順3,4はわかりやすく手動の方法を記載しているが、ルートテーブルへのアタッチメントとルートテーブルへのプロバケーションを自動設定にしても良い
-
手順5でオンプレとの通信がオンプレからはロンゲストマッチでVGW接続を利用するが、AWSからの通信はTGW接続の方を利用して戻るため、行きと戻りでAsymmetricな通信になるが問題なく通信が可能
-
手順6で消すことでTGWのみの通信になる
構成の注意点
DXGW-VGW
-
VGWはVPCに1個しかアタッチできない
VGWからDXGW-VGWに移行の際は、新規にVGWを構成するのではなく利用しているVGWを利用する -
ASNはDXGWとVGWとで同じでも問題ない
異なるDXGWも同じASN番号で問題ない（VGW構成の時のVGW側のASN番号は全て同じASN番号で問題ない） -
AWSからオンプレへの告知は許可されたプレフィックスを利用する
TGW
-
TGW間を接続するピアリング機能は異なるリージョンとしかできない
同じリージョン間で異なるTGWとのピアリングはできない
例えば、アカウントAの東京リージョンで作成したTGWを、アカウントBの東京リージョンで作成したTGWには接続できない -
AWSからオンプレへの告知は許可されたプレフィックスを利用する
本文中に何度も出てきているが、DXGWに接続したTGWに設定可能な「許可されたプレフィックス」は20経路までしか設定できない制限がある VGW接続時にVPCのCIDRをオンプレに伝えていた運用方法でTGWも同じように利用したい場合は、20VPC接続までしかできなくなる。そのため経路集約は必要になる -
許可されたプレフィックスが反映されるまで７〜９分ほどかかる
（許可されたプレフィックスを何度も変更して検証する場合は結構時間がかかります。ここを何度も行う試験が一番時間かかります） -
TGWに接続する用のサブネットを作成しておくこと
トランジットゲートウェイ設計のベストプラクティスに
各トランジットゲートウェイ VPC アタッチメントに個別のサブネットを使用します。
と記載があるのですが、理由は下記になります。TGWのENIからパケットがでていくとき（TGW向けではなくTGWから出ていく通信）にサブネットにくっついているルーティングテーブルによってどこにパケットを通信するかを制御しています。
そのためインスタンスやコンテナとかのインターフェースを作ると TGWのENIがあるサブネットのルートテーブルのNextHopの挙動のところで影響をインスタンスやコンテナとかが受けてしまいます。
TGWのENIがあるサブネットに紐づいているルートテーブルのNextHop設定をかえるとインスタンスもその方に通信をしてしまうので、ネットワーク管理する際にトラブルシューティングが難しくなります。*3全てのTGWの構成で起こるわけではないのですが、各VPCからインターネットへのアウトバウンド通信を 1つのNATゲートウェイ 経由にしたい（GIPを全て同じにしたい）場合とかの構成を組むケースだとこの状況になります。
サブネットを分けた場合はTGWに向けるルーティングの設定はインスタンスが存在するサブネットのルートテーブルで作成する必要があります。
-
TGWとDXGWは同じASN番号を利用できない
（接続するとエラーになる） -
DXGWに複数TGWを接続した場合のTGW側のASNは同じでも良い *4
最後に
TGWの検証を一緒にやって頂いた、 ネットワークグループの皆様、SREの皆様、AWSの皆様 ありがとうございました。
からの記事と詳細 ( AWS TGWとDXGWを検証してみた結果わかったこと - DMM inside )
https://ift.tt/3pXtxfY
No comments:
Post a Comment