yamamototis1105’s tech blog

ネットワークを中心とした技術ブログです

AWS Cloud WANを用いたハイブリッド接続のBGPルーティング

はじめに

 前回記事の「AWS ハイブリッド接続のBGPパラメータ設計のポイント」を投稿後、公式ブログでも「Advanced hybrid routing scenarios with AWS Cloud WAN and AWS Direct Connect」のタイトルで、Cloud WAN+ハイブリッド接続のネタが投稿されたようです。

 Cloud WANはTransitGatewayで事足りるため、馴染みが薄いという方も多いのではないでしょうか。本記事では、前回記事のポイントを押さえつつ「AWS Cloud WANを用いたハイブリッドクラウド接続のBGPルーティング」について説明していきたいと思います。

yamamototis1105.hatenablog.com aws.amazon.com

Cloud WANとは?

 Cloud WANとは「各リージョンのVPCやオンプレミスを相互接続するためのマネージドなグローバルネットワークサービス」と言い表せるかと思います。
 冒頭で記載の通り、TransitGatewayで事足りることも多いと思いますが、個人的に気になった観点を取り入れたメリデメ表を作成してみました。

  • コストは、東京リージョンの1リソースあたりの料金であり、データ伝送の料金を含みません。
  • ロンチ時間は、コンソールでの実測値ですが、参考値としてお捉え下さい。
TransitGateway Cloud WAN
メリット
  • コストがCloud WANよりは安い
    • TGWアタッチメント:$0.07 / 時間
  • ロンチがCloud WANよりは早い
    • TGW作成:1分未満
    • Peeringアタッチメント作成:約1~2分
    • VPCアタッチメント作成:約1~2分
  • Connectアタッチメントがトンネルレス可
    • トンネルを作成する必要がなく、対向のデバイス設定がシンプル
  • すべてのアタッチメントがルート伝播可
    • VPNVPC、Conneect、TGWアタッチメントともルート伝播可
デメリット
  • Peeringアタッチメントがルート伝播不可
    • VPNVPC、Connect、DXGWアタッチメントはルート伝播可
    • 静的ルートは設定できるが、障害発生時に切り替える信頼性設計が複雑となる
  • DXGWアタッチメントがない
    • TGW経由で接続する必要があり、構成が複雑化かつコストが高い
  • コストが高い
    • コアネットワークエッジ(CNE):$0.50 / 時間
    • アタッチメント:$0.09 / 時間
  • ロンチが遅い
    • グローバルネットワーク作成:1分未満
    • コアネットワーク作成:約13~14分
    • ポリシー編集:1分未満
    • TGW作成:1分未満
    • ピアリング作成:約10~11分
    • アタッチメント作成:約5~6分

 Cloud WANは各リージョンのCNE間でルート伝播できたり、ConnectアタッチメントでトンネルレスでBGP接続できるシンプルさが売りだと思います。
 ただし、複数セグメントでアクセス制御したり、複雑な条件のアタッチメントポリシーを適用するとそのシンプルさが失われてしまうのでご注意下さい。

 個人的には、2リージョン間接続であればTransitGateway、数リージョン間接続であればCloudWANを検討するなどの使い分けかなと思います。

BGPルーティング

 以下の構成をベースに、Cloud WANを用いたハイブリッド接続のBGPルーティングを説明します。
 構成のポイントとしては、AWS側のサーバは東京・大阪リージョンのVPC間で冗長化されており、各VPCとオンプレミスがCloud WANで接続されています。

1. BGPトポロジ

 BGPスピーカーにASNを設定し、BGPピアリングを構成します。

  • ASNは64512~65535の範囲より、CNE、TGW、DXGW、ユーザ機器に異なる値を設定してeBGPを構成し、冗長化されたユーザ機器に同じ値を設定してiBGPを構成します。
  • 東京・大阪リージョンのCNEのASNは、ポリシーにより動的に割り当てられます。
  • 下図のサンプル設定では、ASNは東京リージョンのCNEに65001、大阪リージョンのCNEに65002、TGWに64512、DXGWに64513、ユーザ機器に65000を割り当てています。

2. BGPメトリック

 BGPピアリングごとのメトリックを設定し、BGPルーティングを制御します。

AWSからオンプレミスへの通信
  • CNE~DXGW間はAWSリソースへ設定されたAS Pathでルート制御し、DXGW~ユーザ機器間はユーザ機器へ設定されたAS Pathでルート制御します。
  • 下図のサンプル設定では、CNE~DXGW間のAS Pathはメインルートが64513 64512 65001の合計3パス、バックアップルートが64513 64512 65002 65001の合計4パスとなります。
  • 下図のサンプル設定では、DXGW~ユーザ機器間のAS Pathはメインルートが65000 64513の合計2パス、バックアップルートが65000 65000 64513の合計3パスとなります。
    (バックアップルートの65000 65000は、バックアップルートのユーザ機器で2パス追加するように設定します。ちなみに、メインルートとバックアップルートのユーザ機器間はiBGP接続のため、各ユーザ機器で1パスずつ追加することはできません。)
オンプレミスからAWSへの通信
  • ユーザ機器~DXGW間はユーザ機器へ設定されたLocal Preferenceでルート制御し、DXGW~CNE間はAWSリソースへ設定されたAS Pathでルート制御します。
  • 下図のサンプル設定では、ユーザ機器~DXGW間のLocal Preferenceはメインルート200、バックアップルート100となります。
  • 下図のサンプル設定では、DXGW~CNE間のAS Pathはメインルートが65001 64512 64513の合計3パス、バックアップルートが65001 65002 64512 64513の合計4パスとなります。

3. BGPタイマー

 BGPピアリングごとのタイマーなどを設定し、BGPフェイルオーバータイムを制御します。

  • DXGW~ユーザ機器間はユーザ機器へ設定されたタイマーでフェイルオーバータイムを制御し、CNE~TGW~DXGW間はAWS内のタイマーでフェイルオーバータイムを制御します。
  • AWS内のタイマーは開示されていないため、フェイルオーバータイムは確認できません。
  • 下図のサンプル設定では、BGP keepalive/hold timeは10s/30s、BFD interval/multiplierは300ms/3をユーザ機器に設定しています。




2021年9月2日 AWS 東京リージョン DirectConnect障害への有効性

 だいぶ風化してそうですが、2021年9月2日 AWS 東京リージョン DirectConnect障害[1] に対しても、本構成でバックアップのDirectConnectへフェイルオーバーすることが有効策となりえます。
 ただし、本障害は完全な切断へ至らずバタつくため、バックアップのDirectConnectへ手動フェイルオーバーする必要があります。

 [1] 障害の詳細については、ServerWorksさんのブログが大変分かり易いため、そちらをご参照下さい。
   ServerWorks - ENGINEER BLOG
     https://blog.serverworks.co.jp/dx-manual-failover-to-vpn

まとめ

 Cloud WANを用いたAWSハイブリッド接続のBGPパラメータも、以下の切り口で考えると理解しやすいです。

  • BGPスピーカーにASNを設定し、BGPピアリングを構成します。
  • BGPピアリングごとのメトリックを設定し、BGPルーティングを制御します。
  • BGPピアリングごとのタイマーなどを設定し、BGPフェイルオーバータイムを制御します。

おわりに

 Cloud WANを用いたハイブリッド接続を構築される方々にとって、本記事がご参考になりますと幸いです。