AWS Cloud WANとDirect Connectの直接接続アップデートによる影響と対応

はじめに

　re:Invent 2024が近付く中で、今年も様々なネットワークにかかわるアップデートが発表されましたが、その中でも2024年11月25日に投稿された「AWS Cloud WAN が AWS Direct Connect によりオンプレミス接続を簡素化」というアップデートについてご紹介します。

　本記事は、2024年12月16日に開催された「NW-JAWS #14 ～re:Invent 2024 re:Cap ネットワークについて語ろう～」での発表内容に当日お話しできなかった内容を付け加えているものの、本筋のお話は変わらない旨ご承知おき頂けますと幸いです。

aws.amazon.com

Cloud WANとは

　グローバルネットワークにおいて、オンプレミス拠点間やAWSと相互接続するためのマネージドサービスです。ポリシーによる接続タスク自動化、セグメント分離によるトラフィック制御、中央一元管理と監視などの特徴があります。
　（単なる相互接続サービスと捉えられがちですが、真の力はこれら特徴で発揮できます。残念ながら本記事は相互接続に関するテーマのため、別記事で特徴に関するテーマを取り上げたいと思います。）

　下の図はCloud WANの構成例ですが、Cloud WANはリージョン横断的な位置付けで、各リージョンのVPCに加えて、Direct Connect/Site-to-Site VPN/SD-WAN Applianceなどの多様な方式でオンプレミスへ接続されていることが確認できます。

　ちなみに、Cloud WANはTransit Gatewayとよく比較されますが、それぞれのメリット・デメリットは以下の記事で整理してますので、ご興味のある方はそちらをご覧下さい。

yamamototis1105.hatenablog.com

アップデートの概要

　Cloud WAN～Direct Connect間がTransit Gateway経由でなく直接接続できるようになったという大変シンプルなアップデート内容となります。

　下の図はAWS～オンプレミス間をDirect Connect接続で冗長化された構成例ですが、アップデートによってCloud WANとDXGW間がTransit Gateway経由でなく直接接続されています。

アップデートの検証・調査

　アップデートによって、どのような影響があり、どのような対応をすべきか、実際のDirect Connect接続で検証・調査した結果をもとに整理してます。

手順

　新しいオペレーションは、Cloud WAN～Direct Connect Gateway間のアタッチメント作成のみです。Cloud WANのアタッチメントの設定で、アタッチメントタイプ(=Direct Connect)、エッジロケーション(=リージョン)、Direct Connect gateway attachment(=DXGW ID)を入力するだけで作成できます。

　ちなみに、Transit Gatewayは経由しないものの、従来どおりDirect Connectを作成する場合はTransitVIFを作成してください。VPC attachmentのENIのインターフェースタイプもTranit Gatewayと表示されるなど、Cloud WANがTransit Gatewayのように取り扱われることは時々あります。

機能性

　リージョン、ルーティング、VPNへの対応が少し物足りないため、今後のアップデートへ期待です。直近でお客様要件が充足できない場合は、従来の構成も検討しましょう。

1. リージョンが対応してない
   • 東京、大阪リージョンは未対応（2024/11/25時点ではバージニア北部、オハイオ、オレゴン、カルガリー、フランクフルト、ストックホルム、アイルランド、ロンドン、シンガポール、シドニー、テルアビブリージョンのみ対応）。
2. ルーティングが制御できない
   • DXGWのゲートウェイ関連付けにて、オンプレミスにアドバタイズしたいルートを設定できるが、Cloud WANを関連付けた場合はルートを設定できない（設定ボタンが表示されず）。
   • Cloud WANのポリシーのセグメントオプションにて、静的ルートが設定できるが、DXGWをターゲットとする静的ルートは設定できない（エラーが表示される）。
   • ルーティングが制御できなくなることで、AWS～オンプレミス間のキャリア制約事項へ抵触しないか注意しましょう（ルート上限数へ達するなど）。
3. VPNが確立できない
   • Transit GatewayはDirect Connect接続のうえSite-to-Site VPN接続することでプライベートVPNが確立できるが、そもそもTransit Gatway経由でなくなったためプライベートVPNが確立できなくなった。

非機能性

　構成が簡素化されたことで、運用負荷やコストが軽減されます。一方、運用も一部の機能が無くなるため代替手段を考えておきましょう。

4. 運用負荷を軽減
   • リソースはTransit Gatewayが無くなりアタッチメントが減るため、パラメータ・ステータスの管理・確認などの運用負荷は軽減できます。
   • Cloud WANはルートやイベントログの確認は同じですが、Transit Gatewayが無くなるためVPCフローログが確認できず、トラブル時における代替手段は要検討です。
5. コストを削減
   • リソースはTransit Gatewayが無くなりアタッチメントが減るため、時間およびデータあたりの料金は軽減できます。
   • Transit Gatewayアタッチメントは単金が高く、各リージョンでDirectConnect接続していた場合はコスト効果が大きいです。

　本記事では、インパクトが大きいと自ら感じた影響のみピックアップしてますが、すべての制限事項を網羅的に確認したい場合は AWS Cloud WANユーザガイドをご参照下さい。

docs.aws.amazon.com

今後のグローバルネットワーク

　Cloud WANは接続方法の多様化/簡素化により、オンプレミス拠点が接続しやすくなり、その拠点数も増えるものと考えられます。そうした場合、オンプレミス拠点間通信もAWSネットワーク経由で通信するケースも増えるものと考えられます。

　このようにAWSネットワークをグローバルネットワークバックボーンとして利用することで、品質はAWSネットワーク水準を維持しながら、コストは海外拠点間をIP-VPN接続するケースと比べて抑える効果も期待できるのではないかと考えられます。

　※Direct Connect拠点同士で通信する場合はCloud WANでなくSiteLinkでのDXGW折り返しとなり、よりシンプルなルートが実現できます。

まとめ

　「AWS Cloud WAN が AWS Direct Connect によりオンプレミス接続を簡素化」をご紹介しました。

• 新しいオペレーションはCloud WANでDXGWアタッチメントを作成するだけでOK
• リージョン、ルーティング、VPNへの対応が少し物足りないため、今後のアップデートへ期待
• 構成簡素化で運用負荷やコストは軽減されるが、一部機能縮小の影響と対応は要注意

　今後のグローバルネットワークに関する個人の見解をご紹介しました。

• オンプレミス拠点間通信においてAWSネットワークをバックボーンとして利用拡大

おわりに

　Cloud WANはTransit Gatewayと比べると、まだまだ知名度の低いサービスですが、アップデートの勢いは強まっていますので、今後更なる利用シーン拡大も期待できるかと考えられます。

AWS Networking RoadShow Gameday 2024 制覇に向けた学習のポイント

　Quiitaのアドベントカレンダー「Japan AWS Top Engineers Advent Calendar 2024」(3日目) にて、「AWS Networking RoadShow Gameday 2024 制覇に向けた学習のポイント」というテーマで投稿させていただきます！

　AWS Networking RoadShow Gameday 2024で自らのチームが全てのクエストを制覇のうえ優勝しましたが、本記事ではイベントに先駆けて実践した学習のポイントをご紹介しますので、ご興味を持たれた方は是非ご覧下さいませ。

qiita.com

Amazon CloudWatch Network Monitor ハイブリッドネットワーキング業務から導き出したユースケースおよび仕様

はじめに

　Amazon CloudWatch Network Monitorは、2023年12月22日に一般提供開始されたサービスであり、AWS～オンプレミス間のネットワークがモニタリング可能となります。
　自らのハイブリッドネットワーキング業務から導き出した、公式ドキュメントにも載っていないNetwork Monitorのユースケースおよび仕様についてご紹介します。
　本記事でもサービス概要は触れていますが、基本的なサービス仕様は公式ドキュメントなどでご確認頂けますと幸いです。

docs.aws.amazon.com

Network Monitorとは

　Network Monitorは、AWS上のサブネットからオンプレミスにTCPもしくはICMPポーリングを行い、遅延およびパケットロス率を取得します。
　構成は、1つのモニタにつき単一もしくは複数の送信元サブネットと送信先IPアドレスを指定すると、すべての組み合わせのプローブ(=トラフィック)が作成されます。
　その他、インターバル、メッセージサイズ、ポートなどのパラメータも指定できます。詳しいパラメータは前述の公式ドキュメントをご参照下さい。

Network Monitorユースケース

グレー障害の検知および対処

従来のトラフィックに関わるログやメトリクスの課題

　従来のトラフィックに関わるログやメトリクスでも、ネットワークの切断や通信影響は確認できるのでは？と思われる方もいらっしゃるかもしれません。
　ハイブリッドネットワーキングで利用されるDirectConnet、Site-to-Site VPN、TGW (VGWのログやメトリクスは存在しない) で収集可能なログやメトリクスを以下に整理してみました。
　正常もしくは異常を示す状態、ビットレートやパケットレートなどの通信量を示す情報が多く見受けられ、一見すると充実してそうです。

メトリクス	説明
DirectConnect Connection	接続状態(UP/DOWN) 送信/受信データのビットレート[bps] 送信/受信データのパケットレート[pps] 送信/受信トラフィックのファイバー接続状態[dBm] MACレベルエラー数※CRCエラーも含む 暗号化状態(UP/DOWN)
DirectConnect VIF	送信/受信データのビットレート[bps] 送信/受信データのパケットレート[pps]
Site-to-Site VPN	トンネル状態(UP/DOWN) 送信/受信データのバイト数[byte]
Transit Gateway	blackholeルート一致によるドロップバイト数[byte] blackholeルート一致によるドロップパケット数[byte] ルート不一致によるドロップバイト数[byte] ルート不一致によるドロップパケット数[byte] 送信/受信データのビットレート(bps) 送信/受信データのパケットレート(pps)
Transit Gateway Attachment	blackholeルート一致によるドロップバイト数[byte] blackholeルート一致によるドロップパケット数[byte] ルート不一致によるドロップバイト数[byte] ルート不一致によるドロップパケット数[byte] 送信/受信データのビットレート[bps] 送信/受信データのパケットレート[pps]

ログ	説明
Site-to-Site VPN	タイムスタンプ VPN接続の識別子 VPNトンネルの外部IP DPDプロトコルの有効ステータス(True/False) CGWデバイスのNAT-T検出(True/False) IKEフェーズ1/2プロトコル状態 (確立済み/キー更新中/ネゴシエーション中/ダウン) IPsec/IKE/DPDプロトコルの詳細メッセージ

　ただ上記のログやメトリクスでは、システムが完全停止するのではなく、一部停止もしくはパフォーマンス低下するグレー障害を検知することが難しいです。
　ネットワークにおけるグレー障害は、通信機器のソフトエラーやハードエラー等によって大幅な遅延や断続的な通信断を引き起こします。

　大幅な遅延や断続的な通信断によって、業務通信はエラーが発生するがBGPは再送処理で救済されて状態が変化しない、また通信量も全部流れないわけでなく一部流れるため異常検知できません。
　また、 Amazon CloudWatch anomaly detection機能を利用する場合でも、不規則なトラフィック特性を持つ通信では誤検知が増えてしまい、かえって運用負担が大きくなる可能性があります。

Network Monitorによる対処

　対処策として、Network Monitorの遅延およびパケットロス率評価が有効です。
　グレー障害発生時におけるメトリクス変化幅が大きく、正常と異常の閾値を定義しやすいためです。理由としては、DirectConnectはトラフィック品質が安定しており、遅延が変化しにくくパケットロスも通常発生しないためです。

　閾値を超過した場合には、CloudWatchアラームでトリガーし、BGPフェイルオーバーも可能です。
　DirectConnectサービスのBGPフェイルオーバーテスト機能を利用しますが、最大72時間でフェイルバックするため、その後のアクションは予め決めておくと良いでしょう。詳しくは以下の記事でご紹介してますので、ご興味をお持ちになった方は是非ご参照下さい。

yamamototis1105.hatenablog.com

疎通テスト

Reachability Analyzerの課題

　ネットワークリーチャビリティを確認したい場合におけるAWSサービスと言えば何でしょうか？Reachability Analyzerがパッと思い浮かぶ方は多いのではないでしょうか。
　ハイブリッドネットワークを構築・運用する場合には、以下の仕様に従ってReachability Analyzerで疎通性を解析できません。

　あくまでハイブリッドネットワーキングで解析できないだけであって、VPCネットワーキングの疎通テストでは大変有用なサービスだと思います。
　とはいえ、その他にも解析できないケースもありますので、ご利用される方は以下のドキュメントをご一読されることをお勧めします。

docs.aws.amazon.com

Network Monitorによる対処

　対処策として、Network Monitorの疎通テスト活用が有効です。
　遅延やパケットロス率を取得する用途でないため賛否両論があると思いますが、送信元はマネージドサービス・送信先はエージェントレスと使い勝手も良く、労力を抑えて疎通性を確認できます。また、机上確認でなく実際にトラフィックを流すため、結果に対する信用度もより高いです。

　もしNetwork Monitorの結果がNGだった場合は設定見直しと並行し、AWSであればVPCフローログ、オンプレミスであればACLカウンターなどでパケット有無を切り分けます。
　VPCフローログは、デフォルトでなくカスタムでなければ確認できないフィールドもありますので、ご利用される方は以下のドキュメントをご一読されることをお勧めします。

docs.aws.amazon.com

Network Monitor仕様

ポーリングインターバル

　モニタ作成時に1分もしくは30秒を選択しているのでは？と思われるかもしれませんが、その選択肢はポーリングインターバルでなく集計インターバルです。
　この仕様へ気付いたきっかけは、ポーリング開始よりごく僅かな時間しか経ってないにも関わらず、パケットロス率が0.x%と細かく刻んだことでした。
　パケットキャプチャした結果、30秒あたり600発、つまりポーリングインターバルは50ミリ秒であることが確認できました。

　データの量が多いため、検知の精度が桁違いの高さです。
　例として、BGPとNetwork Monitorで検知の精度を比較した結果を以下に示します。パケットロス率が結構高めでも、BGPは中々検知できないことがお分かりいただけるかと思います。

	BGP	Network Monitor
条件	パケットロス率: 10% キープアライブ: 10秒 ホールドタイマー: 30秒	パケットロス率: 10% 集計インターバル: 30秒 アラーム閾値: 5%
30秒間で検知可能な確率	0.1%	ほぼ100%

　インターネット回線を用いたSD-WANではインターネット回線の信頼性が高くないため、このような遅延やパケットロス率に基づきフェイルオーバーします。
　DirectConnectもグレー障害で受ける影響次第で、このような仕組みの導入検討が必要と思います。

送信元ENI

　送信元ENIは、送信元サブネット数だけ必要でしょうか、もしくはプローブ数だけ必要でしょうか？答えとしては何れの数でもありません。
　この仕様へ気付いたきっかけは、サブネットの空きアドレスが少なく、アドレスが枯渇しそうな状況でENIを確認したことでした。
　ENIおよびVPCフローログを確認した結果、送信元ENIは送信元サブネット数×2で冗長化され、アドレス×2から同一の宛先へポーリングされてました。

　上記のようにアドレスが枯渇しそうな場合には注意しましょう。
　送信元ENIが冗長化される仕様は致し方ないのですが、サブネットあたりのプローブ数のクオータは上限緩和可能のためリクエストを検討してもよいかもしれません。

docs.aws.amazon.com

　2023年11月5日時点ではNetwork Monitorは東京リージョンで対応しているものの、大阪リージョンで対応していませんのでご注意下さい。
　詳しい対応リージョンは前述の公式ドキュメントをご参照下さい。

まとめ

　自らのハイブリッドネットワーキング業務から導き出した、Amazon CloudWatch Network Monitorのユースケースおよび仕様をご紹介しました。

• ユースケースとして、グレー障害の検知および対処、疎通テストを挙げました。
• 仕様として、ポーリングインターバルは50ミリ秒、送信元ENIは冗長化されることを挙げました。

おわりに

　Amazon CloudWatch Network Monitorは大変有用なサービスだと思います。より沢山の方々にご利用いただけるように、本記事が少しでも役立ちましたら幸いです。

Google Cloud SD-WAN / Routerアプライアンスを用いたハイブリッド接続：Network Connectivity Centerへの移行ポイント

はじめに

　Google Cloud上でSD-WAN / Routerアプライアンスを用いてハイブリッド接続する場合に、一昔前は一苦労のうえ構築していましたが、今ではマネージドサービスでシンプルかつスピーディに構築できるようになっています。
　本記事では、Google Cloud上でSD-WAN / Routerアプライアンスを用いたハイブリッド接続する場合において、既存の構成からNetwork Connectivity Center構成への移行ポイントなどをご紹介したいと思います。

Network Connectivity Centerとは

　Hub-Spoke構成のネットワークが構築できるサービスで、Network Connectivity CenterをHubとし、VPC、Cloud VPN、Cloud Interconnect、Router ApplianceをSpokeとして接続できます。
　トポロジやフィルタを設定することにより、アドバタイズされるサブネットやカスタムルートを制御することも可能です。

VPC間接続

　メッシュ型でなくスター型で接続でき、シンプルな構成となります。

VPC～Cloud VPN/Interconnect間接続

　複数のVPCで一つのハイブリッド接続を共用できます。

VPC～Router Appliance間接続

　ダイナミックルーティングでVPCとアプライアンスを接続できます。

　Network Connectivity Centerドキュメントは以下のリンクをご参照下さい。

cloud.google.com

移行前構成

　HAコンフィギュレーションガイドに従って冗長化されたCISCO Catalyst 8000V構成です。
HAコンフィギュレーションでは、副系ルータから主系ルータへのBFDポーリングで故障検知し、Google Cloud APIでVPC上のルートを更新することによりフェイルオーバーします。

　CISCO Catalyst 8000VからVPCルートへのGoogle Cloud APIはIOS XE上のコンフィグだけでなく、Guest Shell上でpythonパッケージをインストールのうえ設定や運用が必要となります。それらの負荷を軽減する観点では、可能な限りマネージドサービスへの置き換えが望ましいと思います。

　CISCO Catalyst 8000VのHAコンフィギュレーションガイドは以下のリンクをご参照下さい。

www.cisco.com

移行後構成

　Network Connectivity CenterでSpokeとして接続されたCISCO Catalyst 8000V構成です。
Network Connectivity Centerでは、CloudRouter～CISCO Catalyst 8000V間もBGPで制御することで、CloudRouterで故障検知からフェイルオーバーまで実施します。

　CloudRouter～CISCO Catalyst 8000V間はデフォルト2セッションと信頼性が高く、CloudRouterでMEDを制御できたりCISCO Catalyst 8000VでAS PATHを制御できたりと自由度も高いです。ただし、CloudRouter状態の一部はコンソールでなくコマンドでしか確認できないためご注意下さい。

　CloudRouter状態の確認コマンドは以下のリンクをご参照下さい。

cloud.google.com

移行時におけるポイント

　VPC PeeringからCloud VPNへ切り替えたうえでNetwork Connectivity Centerへ切り替えています。Network Connectivity Centerへ直接切り替えない理由は、VPC PeeringとNetwork Connectivity Centerが同時接続できず切断時間が長くなるためです。もっとスマートな移行方法はあるかと思います汗
　また、構築時にリソースを作成し、切り替え時にパラメータを変更しています。万が一、切り戻しが発生した場合にリソースを削除するのではなくパラメータを戻すだけで済み、切断時間が短くなるためです。

Cloud VPNへの切り替え

　Cloud VPN作成時はVPC PeeringルートよりCloud VPNルートの方が優先度を低くするようにし、切り替え時に高くなるように変更します。

Network Connectivity Centerへの切り替え

　Network Connectivity Cener切り替え時も各ルート優先度を制御するか、CloudRouterのBGPピアをOFFからONに変更することで切り替えを行います。

まとめ

• Google Cloud上でSD-WAN / Routerアプライアンスを用いてハイブリッド接続する場合には、Network Connectivity Centerによってシンプルかつスピーディに構築できます。
• 既存の構成からNetwork Connectivity Center構成に移行する場合には、切り替えおよび切り戻しは構成変更の順序やパラメータ変更の内容により切断時間を抑えることができます。

おわりに

　Network Connectivity Centerリリースから時間が大分経ってからの紹介となってしまいましたが、Google Cloud SD-WAN / Routerアプライアンスを用いたハイブリッド接続において大変有用なサービスとなっていますので、もし構築や移行を予定されている方は是非ご検討してみてください。

Google CloudとAWSのハイブリッド接続におけるルーティングの違い

はじめに

　Google Cloudのハイブリッド接続において、大体AWSと同じでしょと思ってたら痛い目に会ったという方はいらっしゃらないでしょうか？
　Google CloudとAWSはネットワークだけでもVPC構成などの様々な違いがあります。その中から、今回は実際にハイブリッド接続でハマった事例をご紹介したいと思います。
　AWS DirectConnectは触ったことはあるけど、Google Cloud InterConnectは触ったことがないという方はピッタリかもしれません。

CloudRouter～VPC間のルート優先度

　AWSの場合、オンプレミス向けのルートはオンプレミスルータにBGPメトリックとしてAS PATHを設定のうえ制御できましたが、Google Cloudの場合、同じように制御できない場合があります。
　下図の例では、パートナーネットワーク構成の違いにより上のルートより下のルートの方がAS PATHが大きいですが、下のルートが選択されています。

　理由としては、VPCはCloudRouterのAS番号をAS PATHに追加したルートがアドバタイズされるわけでなく、MEDを優先度としたルートが自動設定されるためです。更には、VPCルーティングモードがグローバルかつルートがリージョン間でアドバタイズされる場合、距離やレイテンシに応じたコストが自動加算されます。自動加算されるコストは201～9999のため、オンプレミスルータに設定するMEDは0～200にすることで、リージョン内ルートよりリージョン間ルートの方が優先されないようにしましょう。

　じゃあ一律MEDを設定すればいいのでは？と思う方もいらっしゃるかもしれません。PartnerIneterConnectでパートナーのL3サービスを利用した場合に、パートナーのルータにMEDを設定していることがあり、そのあたりも考慮しましょう。

cloud.google.com

CloudRouter～オンプレミス間のeBGPマルチホップ

　AWSの場合、BGPセッション確立にあたりeBGPマルチホップ設定を意識する必要はなかったですが、Google Cloudの場合、この設定を意識する必要があります。
　下図の例では、下のルートはパートナー経由でBGPセッションを確立できますが、上のルートは直接接続でBGPセッションを確立できていません。

　理由としては、Google Cloud仕様によりeBGPマルチホップ設定が必要となる場合があるためです。eBGPマルチホップ設定が必要となる条件は、VLANアタッチメントのDataplane バージョンが1の場合です。もしBGPセッションが確立できない場合には、公式ドキュメントを参考にしてVLANアタッチメントのDataplaneバージョンを確認し、必要に応じオンプレミスルータにeBGPマルチホップを推奨値4で設定しましょう。

　じゃあ一律eBGPマルチホップを設定すればいいのでは？と思う方もいらっしゃるかもしれません。eBGPシングルホップで無ければBFDが使えないなどの制約もありますので、不要な設定は行わないのが良いかと思います。

cloud.google.com

CloudRouterのメンテナンス

　メンテナンスは、AWS DirectConnectやGoogle Cloud InterConnetと言うよりGoogle Cloud Routerが多く、それに伴いオンプレミスルータのアラームも多くなる場合があります。
　下図の例では、下のルートはパートナー経由でアラームが少なく、上のルートは直接接続でアラームが多くなっています。

　理由としては、メンテナンス時にBGPセッションをリスタートすることで、直接接続されたオンプレミスルータでBGPセッションが切断されるためです。グレースフルリスタートがBGPセッション維持のうえで勧められてますが、フェイルオーバーが遅延する原因となる可能性もあるため注意しましょう。

　ちなみに、CroudRouterのメンテナンスは事前・事後のアナウンスが無く、ログエクスプローラーでルータIDおよび「Maintenance of router task: BGP sessions will restart.」というテキストペイロードで検索することで確認できます。

cloud.google.com cloud.google.com

まとめ

• ルート優先度は、AS PATHだけでなくMEDも用いて制御しましょう。
• eBGPマルチホップは、VLANアタッチメントのDataplaneバージョン次第で設定しましょう。
• CloudRouterのメンテナンスは、グレイスフルリスタートを検討しましょう。

おわりに

　AWSに関する知識を持った状態で、Google Cloudのハイブリッド接続に臨んだ結果、実際ハマった事例を3つ挙げさせていただきました。
　しっかりとドキュメントを読んでいれば分かることと言われたらその通りですが、自分と同じバックグラウンドの方々の参考になれば幸いです。

クラウドによりオンプレミス環境を再現：ハイブリッド接続の学習と検証の効率化

はじめに

　クラウド化が進んだことで、仮想環境での検証や学習をしやすくなりましたが、“ハイブリッド接続ならではの困り事” を感じたことはありませんか？
　本記事では、ハイブリッド接続環境で学習・検証での課題・対処の一案をご紹介します。

　2024年5月31日にJANOG Interium Meeting 53.5で「ハイブリッドクラウド接続検証環境をフル仮想化してみた」というタイトルで発表した内容をベースにしています。
　本発表はAzureのハイブリッド接続でしたが、本記事はGoogle Cloudのハイブリッド接続の話です。

janog.connpass.com

ハイブリッド接続の学習と検証における課題

　クラウド実習は手軽に環境を構築・廃止できるためイメージを深めやすいと思います。例えば、WEBサーバ構築を学習・検証したい場合にはLBとサーバとDBなどのサービスで即座に実現できます。
　ところが、ハイブリッド接続を学習・検証したい場合には以下のような課題があります。

• 従来のネットワークにおけるWANなどのように機器やシミュレータなどで代替することができず、クラウドのハイブリッド接続サービスへ接続される実回線が必要となる
• 実回線を準備する場合、最低利用期間の費用、申し込みから回線工事までの時間、日程や作業申請などのキャリア調整でかかる稼働などが必要となる
• こうした環境準備のハードルの高さにより、ハイブリッド接続の学習・検証の機会が少なくなり、十分な知識やスキルを有する人材が中々増えない

オンプレミス環境のフル仮想化による対処

　とあるプロジェクトで思い付いた解決案が「クラウドだけでなく実回線やオンプレミスまで含めて、インターコネクトサービスや仮想アプライアンスなどでフル仮想化できないか？」です。
　フル仮想化が実現すれば、クラウドだけでなく実回線やオンプレミスも学習・検証の直前に構築し、直後に廃止することもできるんじゃないかと考えました。

　フル仮想化にあたり、下記のポイントを重視のうえ具体的なサービスを選択しました。

• 課題を解決するため、費用や時間がかからないように従量課金かつ即時反映であること
• 学習・検証の目標が達成できないと意味ないので、実環境同等のBGP構成が再現できること

　上記のポイントを考慮し、下記のサービスを選択しました。

• 実回線は、NTT Communications社のFlexible InterConnect
• オンプレミスのネットワークは、Amazon Web Services社のAWS Cloud
• オンプレミスのルータは、CISCO Systems社のCatalyst 8000v

全体およびサービスの構成・設定

全体の構成・設定

　オンプレミス～クラウド間のルーティングはBGPを用い、クラウド向け通信はLocal Preference、オンプレミス向け通信はAS_PATHのメトリックで制御し、実環境同等のBGP構成を再現しました。
　誤算としては、AS_PATHはオンプレミスのルータへ相当するCatalyst 8000vで制御したかったのですが、DXGWがASオーバーライド機能で上書くため、FIC Routerで制御するようにしました。

Flexible InterConnectの構成・設定

　FIC Router・FIC Connection (Azure向け2個、AWS向け2個) で構成されます。1系と2系の通信を混在させたくないため、FIC RouterのRoutingGroupを分割してます。
　BGPのAS_PATHは1系より2系の方が多くプリペンドすることにより、ルートは2系より1系の方が優先されるように制御してます。

AWS Cloudの構成・設定

　DX・TransitVIF・DXGW・TGW・TGW Attachment (DXGW用2個、VPC用1個、Connect用2個) で構成されます。FIC Routerと同じくTGW Route Tableを分割してます。
　FICからDX・DXGW・TGW経由のうえCatalyt 8000vへBGP接続することで、実環境でFIC Routerからオンプレミスのルータへ直接BGP接続する構成と似せています。

Catalyst 8000vの構成・設定

　TGW～Catalyst 8000v 1・2系間はeBGP、Catalyst 8000v 1系～2系間はiBGPで構成されます。TGW～Catalyst 8000v間はSD-WAN製品などの接続で用いるTGW Connect Attachmenntで接続し、サービス仕様に従い、1本のGREトンネルあたり2本のBGPセッションを確立してます。

　Catalyst 8000v 1・2系の流し込みコンフィグは以下の通りです。
　eBGPネイバーはTGWとCatalyst 8000vが別ネットワークのためebgp-multihop指定が必要となり、また、iBGPネイバーは1・2系間でルート交換できるようにnext-hop-self指定が必要となります。

interface GigabitEthernet1
 ip address 10.1.1.254 255.255.255.0
!
interface GigabitEthernet2
 ip address 10.1.0.254 255.255.255.0
 no shutdown
!
interface Tunnel1
 ip address 169.254.6.1 255.255.255.248
 tunnel source GigabitEthernet2
 tunnel destination 172.16.5.1
!
router bgp 65000
 network 10.1.1.0 mask 255.255.255.0
 timers bgp 10 30
 neighbor 10.1.1.253 remote-as 65000
 neighbor 10.1.1.253 next-hop-self
 neighbor 169.254.6.2 remote-as 64512
 neighbor 169.254.6.2 ebgp-multihop 255
 neighbor 169.254.6.3 remote-as 64512
 neighbor 169.254.6.3 ebgp-multihop 255

interface GigabitEthernet1
 ip address 10.1.1.253 255.255.255.0
!
interface GigabitEthernet2
 ip address 10.1.0.253 255.255.255.0
 no shutdown
!
interface Tunnel1
 ip address 169.254.7.1 255.255.255.248
 tunnel source GigabitEthernet2
 tunnel destination 172.16.5.2
!
router bgp 65000
 network 10.1.1.0 mask 255.255.255.0
 timers bgp 10 30
 neighbor 10.1.1.254 remote-as 65000
 neighbor 10.1.1.254 next-hop-self
 neighbor 169.254.7.2 remote-as 64512
 neighbor 169.254.7.2 ebgp-multihop 255
 neighbor 169.254.7.3 remote-as 64512
 neighbor 169.254.7.3 ebgp-multihop 255

まとめ

• 費用は、Google Cloud・FIC・AWSのサービス利用料を数万円に抑えられました。
• 時間は、検証開始時に環境を即日完成させ、検証終了自に環境を即日廃止できました。
• 使用感は、実機と遜色のない動作確認ができ、イメージが深まったとの声を頂きました。
• 全ての場面で有効なわけではなく、使いどころの見極めが大事だと思いました。

当てはまるケース	当てはまらないケース
クラウドのハイブリッド接続サービスに関して、一般構成でのフィージビリティ検証や手順確認	回線やオンプレミス機器に関して、ハードウェアレベルで本番同等の品質担保

おわりに

　ハイブリッド接続を実習される方にとって、本記事内容がご参考になりますと幸いです。

Google Cloud VPCネットワーク間の限定的なルートアドバタイズの実装パターン

はじめに

　Google Cloudの異なるプロジェクト間でVPCネットワークを接続する場合、アドレス重複を回避するため限定的なルートアドバタイズが必要となる場合がありますよね。
　本記事では、VPCネットワーク間の限定的なルートアドバタイズの実装パターンをまとめました。

アドレス重複の問題

　VPCネットワーク間を接続する方法としてはVPCネットワークピアリングが先ず思い付きますが、VPCネットワーク間でサブネットのアドレスが重複している場合、VPCネットワークピアリングは作成できません。

　例えば、VPCネットワークAが10.1.1.0/24と10.3.1.0/24、VPCネットワークBが10.2.1.0/24と10.3.1.0/24のサブネットを持っているケースがあったとします。A・Bとも10.3.1.0/24を持っており、アドレスが重複するため、VPCネットワークピアリングを作成できません。

限定的なルートアドバタイズによる解決策

　そこで、そもそもVPCネットワーク間でアドレスが重複させないために限定的なルートアドバタイズを実装する方法を考えます。各方法の特徴およびそのメリット・デメリットも合わせてご紹介したいと思います。

Cloud VPN接続

　VPCネットワーク、CloudRouter、さらにVPNゲートウェイを関連付けて、VPNゲートウェイ間でVPNトンネル・BGPセッションを確立する構成です。

　特徴は、VPNトンネルで通信が暗号化され、コストが低く抑えられます。品質は、Google Cloudのサービス同士の通信ということもあり、通信がGoogle Cloudバックボーン経由となり、一般的なインターネットより信頼性や安定性が期待できるかと思います。

　ルートアドバタイズは、CloudRouterでカスタムルートというかたちでアドバタイズされるルートを自由に設定できます。

　ちなみに、VPNゲートウェイ同士は接続できますが、VPNゲートウェイとGoogle Cloudが持っているグローバルIPを割り当てた仮想アプライアンス等の間は接続できないため要注意です。

Cloud InterConnect接続

　VPCネットワーク、CloudRouter、さらにVlanアタッチメント(物理接続)を関連付けて、キャリアや相互接続業者経由でBGPセッションを確立する構成です。

　特徴は、低レイテンシかつ高信頼性である一方、コストはGoogle Cloudのほかおよびキャリアや相互接続業者のサービス利用料金かかってしまうため高いです。

　ルートアドバタイズは、CloudRouterでカスタムルートというかたちでアドバタイズされるルートを自由に設定できます。

　ちなみに、Cloud InterConnect接続はCloudRouterのASNが16550指定のためASループ防止機能によりルート破棄が懸念されるため、キャリアや相互接続業者のASオーバーライド機能によりルートがアドバタイズされることを確認する必要があります。

Private Service Connect接続

　TCPの1stパケットの送信側VPCにエンドポイント、受信側VPCに公開サービスが作成された構成です。送受信が入れ替わる可能性もある場合には、両VPCにエンドポイント、公開サービスを作成する必要があります。

　特徴は、プロトコル・ポートで制限されるためセキュアですが、通信方向ごとにエンドポイント・公開サービス、それらに関連付けたロードバランサ―・インスタンスグループも必要となり、構成・設定が複雑です。

　ルートアドバタイズは、そもそも送信元・送信先ともアドレス変換されるため、アドレス競合することはありません。

Network Connectivity Center接続

　ハブを作成したうえで、VPCをスポークとして関連付けた構成です。

　特徴は、構成・設定が集中管理できてかつシンプルで、先々にVPCネットワークのほかオンプレミスやその他サービスへの接続も拡充できます。

　ルートアドバタイズは、スポークフィルタというかたちでアドバタイズされるルートを自由に設定できます。

まとめ

　以上の説明を踏まえ、各方法は以下の特徴にまとめられると思います。具体的な環境や要件に応じて各方法を使い分けください。また、詳細コストは料金計算ツールでお見積りください。

実装パターン	特徴
Cloud VPN	暗号化、低コスト
Cloud InterConnect	低レイテンシ、高信頼性、高コスト
Private Service Connect	セキュア、複雑な構成
Network Connectivity Center	統合管理、シンプルな構成

おわりに

　Google CloudのVPCネットワーク間を接続し、限定的なルートアドバタイズを実装する必要がある方がいらっしゃいましたら、本記事がご参考になりますと幸いです。