クラウドインテグレーション部の手塚です。
今日は1年以上ぶりにオフィス出社をしました。帰りはお土産を買いに寄り道する予定です。
はじめに
タイトルの通り「Direct Connectロケーションから大阪リージョンを経由して東京リージョンVPCに接続する」方法を解説します。
本記事ではこれを「検討構成」と定義します。
まとめ
記事が長いので、先に検討構成についてのまとめです。
- Direct Connectロケーションから大阪リージョンを経由し東京リージョンへ接続できます。
- Direct Connect GatewayとTransit Gatewayが必須です。
- Transit Gatewayを利用可能なDirect Connect回線が必要です [*]
- 迂回路でRTTが16 [ms] 追加されるため、これが許容できるか? 対処できるか? について事前検証が必須です。
- 2021/9/2にDirect Connectで発生した事象に対して有効であったと考えられ、サイト間のVPN接続が不要というメリットがあります。
[*] Trasnit VIFを作成できないDirect Connect回線では本検討構成を作成できません。日本国内で利用が多い共有型や1Gbps未満のDirect Connect接続はTransit VIF未対応のため注意が必要です。
[2023/3/31 更新] 2022年8月8日、500 Mbps 以下の AWS Direct Connect 回線で、AWS Transit Gateway への接続がサポートされました 🎉 aws.amazon.com
検討構成
具体的には次の通常時と迂回時の経路を切り替え可能な構成について検討します。
通常時
- オンプレミス
- Dircect Connectロケーション
- Direct Connect Gateway
- 東京リージョンTransit Gateway
- 東京リージョンVPC
迂回時
- オンプレミス
- Dircect Connectロケーション
- Direct Connect Gateway
- 大阪リージョンTransit Gateway
- Transit Gatewayリージョン間ピアリング
- 東京リージョンTransit Gateway
- 東京リージョンVPC
必要なリソース
次は検討構成を図示したものです。
構成にはDirect Connect GatewayとTransit Gatewayを設置する必要があります。
Direct Connect GatewayとTransit Gatewayの接続
Direct Connect Gatewayは1本のDirect Connect接続を複数リージョンで共有可能とするグローバルサービスです。これを用いて次の2つの経路を作成します。
- Direct Connectロケーション > Direct Connect Gateway > 東京リージョンTransit Gateway
- Direct Connectロケーション > Direct Connect Gateway > 大阪リージョンTransit Gateway
通常時は前者の東京リージョンTransit Gatewayへの経路を利用し、迂回時は後者の大阪リージョンTransit Gatewayへの経路を利用します。 またこの経路切り替えは手動で実施します。
Transit Gatewayのリージョン間ピアリング
大阪リージョンTransit Gatewayと東京リージョンTransit Gatewayのそれぞれにピアリングアタッチメントを経由して2つのTransit Gatewayを相互接続します。 本記事ではこの接続をTransit Gatewayのリージョン間ピアリングと定義します。 リージョン間ピアリングへの経路切り替えは手動で実施します。
その他、これらのDirect Connect GatewayとTransit Gatewayは相互接続されるため、お互いのBGP AS番号は重複しない値が必要です。
次に検討構成の経路設計例を挙げます。
経路設計例
本経路設計について、検証用Direct Connect回線を手配できなかったためDirect Connect Gateway経由の動作確認が取れていません。 もし不備やベターな手法があればフィードバックを頂けるとありがたいです。
通常時の経路
下図はオンプレミスと東京リージョンVPC間を最短で接続する経路設定です。 迂回経路の設定も事前に行います。
以下は各リソースの経路設定です。
Direct Connect Gateway
通常時はDirect Connect Gatewayから東京リージョンTransit Gatewayにトラフィックを転送します。 このとき大阪リージョンTransit Gatewayからオンプレミス側への経路広報は不要ですが「許可されたプレフィックス」の値を空にできないため、オンプレミスに広報しても影響がないCIDRを設定します。
ゲートウェイ | 許可されたプレフィックス | 備考 |
---|---|---|
東京リージョンTransit Gateway | VPC CIDR | VPC CIDRをオンプレミス側に広報する |
大阪リージョンTransit Gateway | L3ネットワーク上で未使用のCIDR | 空欄としたいが値は必須のため、オンプレミスに広報しても影響が無い値を指定する |
東京リージョンTransit Gateway
Direct Connect GatewayとVPC間にトラフィックを転送する設定とします。Transit Gatewayのピアリングアタッチメントには事前に迂回路を設定します。
VPCアタッチメント
CIDR | アタッチメント | ルートタイプ | 備考 |
---|---|---|---|
オンプレミスCIDR | Direct Connect Gateway | Propagated | 通常時のみ有効 |
Direct Connect Gatewayアタッチメント
CIDR | アタッチメント | ルートタイプ | 備考 |
---|---|---|---|
VPC CIDR | VPC | Propagated | 通常時のみ有効 |
Transit Gatewayピアリングアタッチメント
通常時は使用されないため、事前に迂回路を設定します。 Transit Gatewayピアリングアタッチメントが関連する経路のルートタイプはStaticのみ設定できます (Propagatedにできません)。
CIDR | アタッチメント | ルートタイプ | 備考 |
---|---|---|---|
オンプレミスCIDR | VPC | Static | 迂回時のみ有効 |
大阪リージョンTransit Gateway
通常時は使用しないため、事前に迂回路を設定します。 Transit Gatewayピアリングアタッチメントが関連する経路のルートタイプはStaticのみ設定できます (Propagatedにできません)。
Direct Connect Gatewayアタッチメント
CIDR | アタッチメント | ルートタイプ | 備考 |
---|---|---|---|
VPC CIDR | Transit Gatewayピアリング | Static | 迂回時のみ有効 |
Transit Gatewayピアリングアタッチメント
CIDR | アタッチメント | ルートタイプ | 備考 |
---|---|---|---|
オンプレミスCIDR | Direct Connect Gateway | Static | 迂回時のみ有効 |
迂回時の経路
下図は迂回時の設定です。通常時の設定からDirect Connect Gatewayと東京リージョンTransit Gatewayに対して設定変更が必要です (大阪リージョン側の設定変更はありません)。
以下は各リソースの経路設定です。
Direct Connect Gateway
Direct Connect Gatewayから大阪リージョンTransit Gatewayへトラフィックを転送するよう設定変更します。
ゲートウェイ | 許可されたプレフィックス | 備考 |
---|---|---|
東京リージョンTransit Gateway | L3ネットワーク上で未使用のCIDR |
空欄としたいが値は必須のため、オンプレミスに広報しても影響が無い値を指定する。 |
大阪リージョンTransit Gateway | VPC CIDR |
VPC CIDRをオンプレミス側に広報する。 |
東京リージョンTransit Gateway
オンプレミス宛トラフィックを大阪リージョンに転送するよう設定変更します。
VPCアタッチメント
CIDR | アタッチメント | ルートタイプ | 備考 |
---|---|---|---|
オンプレミスCIDR | Transit Gatewayピアリング |
Static |
Propageted経路は削除せずStatic経路を追加してよい。より明示的なStatic経路が優先される。 |
Direct Connect Gatewayアタッチメント
CIDR | アタッチメント | ルートタイプ | 備考 |
---|---|---|---|
VPC CIDR | VPC | Propagated | 通常時のみ有効 |
Transit Gatewayピアリングアタッチメント
CIDR | アタッチメント | ルートタイプ | 備考 |
---|---|---|---|
オンプレミスCIDR | VPC | Static | 迂回時のみ有効 |
大阪リージョンTransit Gateway
経路変更は不要です。
Direct Connect Gatewayアタッチメント
CIDR | アタッチメント | ルートタイプ | 備考 |
---|---|---|---|
VPC CIDR | Transit Gatewayピアリング | Static | 迂回時のみ有効 |
Transit Gatewayピアリングアタッチメント
CIDR | アタッチメント | ルートタイプ | 備考 |
---|---|---|---|
オンプレミスCIDR | Direct Connect Gateway | Static | 迂回時のみ有効 |
検討・考察
まず検討構成の懸念事項を挙げます。
懸念事項
Transit Gateway対応のDirect Connect回線が必要
Trasnit VIFを作成できないDirect Connect回線では本検討構成を作成できません。
日本国内で利用が多い共有型や1Gbps未満のDirect Connect接続はTransit VIF未対応のため注意が必要です。
[2023/3/31 更新] 2022年8月8日、500 Mbps 以下の AWS Direct Connect 回線で、AWS Transit Gateway への接続がサポートされました 🎉 aws.amazon.com
迂回時の遅延
迂回時のRTTは通常時のRTTより約16 [ms] 増えます。
東京-大阪間のRTTは約8 [ms]ですが、迂回路の往復通信1回につき、東京-大阪間の通信が2往復発生するためです。
これによる通信レスポンスやTCPスループットの低下が懸念されます。
懸念事項への対策
Transit VIFを作成できないDirect Connect回線経由でオンプレミスとTransit Gateway間を接続する方法
技術的には可能です。次の記事ではTrasnit VIFを作成できないDirect Connect回線経由で、オンプレミスとTransit Gateway間をL3接続する方法が解説されています。 aws.amazon.com
次は記事内のOption 1の図で、Transit VPCを介して仮想プライベートゲートウェイ (VGW) とTransit Gatewayを接続し、オンプレミスとVPC間をL3接続する構成です。
本構成はおそらく検討構成にマージ可能と考えますが、東京リージョンと大阪リージョンの両方にTransit VPCが必要なため、EC2 VPNルータ計4台の追加が必要となります。
迂回路の遅延対策
RTT増の影響は通信レスポンスの悪化とTCPスループットの低下です。
前者はRTT以上には速くならないため根本対策が難しいですが、後者は TCPスループット [bit/s] = TCP受信ウィンドウサイズ [bit] / RTT [s]
であるため、TCPコネクション数の追加やTCP受信ウィンドウサイズを大きくすることで改善する可能性があります。
この構成は何の役に立つのか?
今となっては確認ができませんが、2021/9/2にDirect Connectで発生した事象 に対して有効であったと考えます。
上記の事象に対して、弊社はサイト間のVPN接続への経路切り替えを提案しましたが、本記事の検討構成ではサイト間のVPN接続の設置が不要になります。
もし本記事の懸念事項がクリアできる環境であれば対策案の一つになると考えます。
まとめ [再掲]
検討構成についてのまとめです。
- Direct Connectロケーションから大阪リージョンを経由し東京リージョンへ接続できます。
- Direct Connect GatewayとTransit Gatewayが必須です。
- Transit Gatewayを利用可能なDirect Connect回線が必要です [*]
- 迂回路でRTTが16 [ms] 追加されるため、これが許容できるか? 対処できるか? について事前検証が必須です。
- 2021/9/2にDirect Connectで発生した事象に対して有効であったと考えられ、サイト間のVPN接続が不要というメリットがあります。
[*] Trasnit VIFを作成できないDirect Connect回線では本検討構成を作成できません。日本国内で利用が多い共有型や1Gbps未満のDirect Connect接続はTransit VIF未対応のため注意が必要です。
[2023/3/31 更新] 2022年8月8日、500 Mbps 以下の AWS Direct Connect 回線で、AWS Transit Gateway への接続がサポートされました 🎉 aws.amazon.com
最後に
先月開催のウェビナー後、大変ありがたいことに多くのフィードバックを頂きました。誠にありがとうございます!
その中で、ある参加者の方より「サイト間のVPN接続が無くとも、Direct Connect Gatewayから大阪リージョンのTransit Gateway経由で東京リージョンに接続すれば、Dirrect Connectロケーションから東京リージョンまでの区間を迂回できますが、この構成について何か懸念事項はありますか?」というお問い合わせを頂きました。
事象発生時、上記についての弊社実績がなかったため、実現性の検討と懸念事項をまとめたのが本記事となります。
同様に「サイト間のVPN接続はどうしても必要ですか?」「諸事情でVPNを敷設できないのですが?」「いつ使用するかわからない構成のためにVPNルータを用意することは難しい」等のお問い合わせもありましたので、本記事が構成案の一つになれば幸いです。
参考資料
- Summary of AWS Direct Connect Event in the Tokyo (AP-NORTHEAST-1) Region
- (復旧済み)2021年9月2日に発生したAWS Direct Connect (東京リージョン) 障害に関してのご報告 - 株式会社サーバーワークス
- 【10月7日】『2021年9月2日に発生した AWS Direct Connect の障害を振り返る 本障害の背景、原因を理解しクラウド活用時に注意すべきポイントを解説』ウェビナーを開催します - 株式会社サーバーワークス
- 障害対応時に AWS Direct Connect を手動で VPN へとフェイルオーバーする手法について - サーバーワークスエンジニアブログ
- DX障害を受けてオンプレミスと AWS 間の接続の冗長構成について再考してみる - サーバーワークスエンジニアブログ
- “共有型”AWS DirectConnectでも使えるAWS Transit Gateway | Amazon Web Services ブログ
- Integrating sub-1 Gbps hosted connections with AWS Transit Gateway | Networking & Content Delivery
手塚 忠 (Tadashi Tetsuka) 記事一覧はコチラ
カスタマーサクセス部所属、2019 年 2 月入社のネットワークエンジニア。シリアルコンソールがマネジメントコンソールに変わったが、スイッチ愛は今も変わらず。 2023 Japan AWS Top Engineers (Networking), 2023 AWS ALL Certifications Engineers