AWS Direct Connect のトラフィックコントロールと大阪リージョンとの接続

はじめに

AWS は、2024年12月13日に大阪リージョンに属する初のAWS Direct Connect ロケーションであるTelehouse OSAKA2(以後、OSAKA2)の開設を発表しました。これにより、AWS Direct Connect を利用して関西地域に閉じたロケーション冗長を行うことが可能になり、AWS クラウドの大阪リージョンをメインリージョンとしたワークロードおよびハイブリッドネットワークをより最適化することができます。もちろん、東京や海外など他のリージョンへの接続にも利用できます。

関西地域のDirect Connect ロケーションは、Equinix OS1(以下、OS1)に続いて二つ目となります。しかし、ご存じでしょうか。OS1 は古くからあるため、東京リージョンに属しています。本記事では、この二つのDirect Connect ロケーションを活用したオンプレミスネットワークとAWS クラウドとの接続に関するアーキテクチャと、その考慮点について解説します。他のリージョンやDirect Connect ロケーションをお使いになる方も、参考となるよう記述しています。

なお、この記事はDirect Connect とeBGP の基礎知識を有した方を対象としています。

ロケーション冗長について

Direct Connect では、お客様ネットワークとの接続点をDirect Connect ロケーションと呼称しています。これは、データセンター内で光ファイバーによる直接接続を行う物理的な場所を示しています。こちらのページを参照すると、そのリストを確認することができます。

ネットワークの物理レイヤーを検討する際、Direct Connect ロケーションの選定は重要です。WAN サービスなどのお客様ネットワークとAWS クラウドを接続する場合、地理的に近いほど高いパフォーマンスを期待できるためです。関西地域にデータセンターや本社機能を持つお客様や、大阪リージョンを主に利用しているお客様は、OSAKA2 の開設により、OS1と組み合わせてロケーション冗長を構成することが可能になりました。

Direct Connect では、お客様のルーターと、AWS のルーターとの間でeBGP を構成します。お客様のルーターは、ご利用の回線サービスにより、Direct Connect ロケーションと同一のデータセンターに設置することも、離れた別のデータセンターやオフィスなどに設置することもできます。この構成に関わる技術要件は、AWS ルーターとお客様ルーターをレイヤー2で接続し、eBGPピアを構成するためのPoint to Point の通信を行えることになります（eBGP マルチホップを利用することはできません）。

図1では、OS1 とOSAKA2 の二つのDirect Connect ロケーションと、4つのDirect Connect 接続を組み合わせて、データセンターレベルの障害にも対応できる可用性を実現する際の構成例を示しています。Direct Connect では、回復性に関する推奨事項やサービスレベルアグリーメント(SLA)にも示しているとおり、重要なワークロードに対しては複数のロケーションを活用することを推奨しています。

図1. 最大回復性を満たすアーキテクチャー例

シナリオ1 アクティブ /スタンバイ構成

複数のDirect Connect を活用して可用性を高めるには、きめ細かいトラフィックコントロールが必要になります。ここでは、理解しやすいよう4つのDirect Connect 接続にそれぞれ優先度を設定し、アクティブの接続が切断された場合、優先度順にフェイルオーバーを行うことを要件とします。つまり、4重の冗長をとる構成となります。図2は、その設計を示しています。なお、経路ごとに優先順位を制御することも可能です。

図2.アクティブ/スタンバイ構成の各接続の優先度設計

シナリオ1-1 AWSからお客様ネットワークに向かうトラフィックのコントロール

AWS のBGP ルーターがお客様のBGPルーターから受信した経路情報は、図2の構成の場合Direct Connect Gateway やAWS Transit Gateway に伝搬されます。4つの回線のうちどの回線がベストパスとして採用されるかについては、受信した経路情報のBGP アトリビュートに依存します。なお、Direct Connect では、AWS ルーターのBGP アトリビュート値を明示的に設定をすることはできないことに注意してください。したがって、図2のような優先度になるようにBGP アトリビュートの設定をお客様ルーターで行う形になります。

では、具体的にどのようにアトリビュートを設定するべきでしょうか。ここで、BGP のベストパス選択アルゴリズムを振り返ります。このような構成の場合に考慮すべきは、ローカルプリファレンス、AS_PATH、Multi-Exit Discriminator (MED)の3つで、記載順で優先順位が高くなります。MED については優先度が低いことから、ドキュメントに記載の通り、積極的な活用は推奨していません。

最もシンプルな方法は、お客様側のBGP ルーターで、AWS へ広告する経路にAS_PATH Prepend を使って優先度を操作することです。AWS側で暗黙に設定しているローカルプリファレンス値が同値であると仮定し、図3に示すようにAS_PATH 長によってベストパスを決定させる狙いです。このアプローチは、これまで多くのケースで採用されてきました。

図3 AS_PATHによる優先度設計のアプローチ

ただし、注意してください。今回の構成例の場合、これだけではベストパス選択は期待通りに行われません。これは、OS1が東京リージョンに属し、OSAKA2が大阪リージョンに属することに起因します。
Direct Connect では、AWS からお客様ネットワークへのパスを最適化するため、ローカルプリファレンス値が暗黙的に設定されます。これは、通信の発信元リージョンと、宛先のDirect Connect ロケーションがどのリージョンに属するかによって決定されます。例として、大阪リージョンから発信された通信は、大阪リージョンに属するOSAKA2を優先するようにローカルプリファレンス値が設定されます。ローカルプリファレンス値はAS_PATH 属性の前に評価されるため、OSAKA2がベストパスに採用されます。

では、OS1を優先したい場合どうするべきでしょうか。Direct Connect ではこのようなケースのため、暗黙的に設定されるローカルプリファレンス値をお客様の意図通りに上書きするためのBGP Community タグ機能を提供しています。
お客様ルーターから受信した経路に、BGP Community アトリビュートの指定されたタグが設定されていると、AWS は以下のような優先順になるようローカルプリファレンスの値を上書きします。詳しくは、ドキュメントをご参照ください。

7224:7100 : 優先設定: 低
7224:7200 : 優先設定: 中
7224:7300 : 優先設定: 高

上記の通り、3段階で設定することができます。今回の例では4回線あるため、3段階では不足です。しかしながら、AS_PATH Prepend を組み合わせることで、意図した制御を行うことができます。今回は、BGP Community タグを用いてローカルプリファレンス値を全て等コストになるよう上書きし、AS_PATH による評価で優先度1の接続をベストパスとして選択させるようにします。
図4は、その設定を図示しています。

図4. Community タグとAS PATH Prepend によるトラフィックコントロール

このように、Community タグと AS PATH Prepend によってAWS からお客様ネットワークへのベストパスをコントロールできます。優先度1のBGPピアが切断された場合、優先度2にフェールオーバーします。優先2が切断されたら優先度3に・・という形で、順にフェールオーバーさせることができます。

シナリオ1-2 お客様ネットワークからAWS に向かうトラフィックのコントロール

続いて、お客様ネットワークからAWS に向かうトラフィックのコントロールについてです。優先度の要件は、前述の逆向きの通信と同様とします。

Direct Connect では、お客様のBGP ルーターに対して広告する経路のBGP アトリビュートをカスタマイズすることはできません。また、特別な設定があらかじめ行われていることもありません※1。したがって、AWS からの経路を受信するお客様のネットワークで自由にトラフィックコントロールを行うことができます。

どのように優先度を設定するかについては、お客様ネットワークの構成によってさまざまな方法が考えられます。例えば、お客様ネットワークはOSPF で構成され、Direct Connect のBGP 経路はOSPF ネットワークに再配布するようなケースも考えられます。お客様ネットワークが通信事業者のWAN サービス等である場合は、そのサービス仕様にも依存します。今回は、図に存在するCustomer WAN が、BGP アトリビュートによる制御に対応しているWAN サービスであると仮定し、AS_PATHにより制御する例をご紹介します。

図5では、AWSから受け取った経路をWANサービスに伝搬する様子を表現しています。

図5. お客様ネットワークからAWS 向けトラフィックのコントロール例

伝搬する際、AS_PATH により優先順位を設定しています。先ほどは、お客様ルーターがAWS に広告する経路に対して設定しましたが、今回はAWS から広告されてきた経路をWANサービスに伝搬する際にAS_PATH Prepend を設定しています。図5に示した表は、WAN サービスが持つBGPテーブルのイメージです。今回は特にローカルプリファレンスやMED は活用しませんでしたが、構成やご利用のWAN サービスによっては活用することもあります。

※1 Public VIFについては、AWS が広告する経路にリージョン制御のためのCommunity タグがサポートされています。詳しくはドキュメントをご参照ください。

シナリオ2 ロードバランス（ECMP）構成

Direct Connect は、Equal Cost Multi Path(ECMP) に対応しています。AWS がベストパス選択を行う際、最も優先度の高いパスが複数あった場合、それらはロードバランスされます。本シナリオは、すべてのDirect Connect 接続を等コストに設定し、トラフィックをロードバランスすることによって、突発的なトラフィック増に備えることを想定します。

Direct Connect 接続がすべて1Gbps だったとしましょう。その場合、シナリオ1では最大帯域幅は1Gbps になります。
4重の冗長構成が取られているため、障害に対して非常に堅牢な反面、スタンバイ側の回線は普段利用しないことになります。ECMP を利用すると、すべての回線を有効活用して最大4Gbps まで対応することができます。ただし、このような構成で普段から4Gbps のトラフィックを利用することは推奨しません。それは、以下のような理由によるものです。

・ECMP によるロードバランスは各接続の最大帯域を考慮しない
・ECMP によるロードバランスはネットワーク機器に実装により、ある程度の偏りが生じることが想定される
・障害やメンテナンス時に最大帯域が減少し、重要なトラフィックが欠損する可能性がある

本構成を採用する場合、「突発的に1Gbps 以上のトラフィックが発生した場合」に対応できること、を要件とすることを推奨します。また、通信経路が行きと帰りで非対称になる可能性があるため、そのようなトラフィックをフィルタリングする機器が導入されていないかどうかも考慮する必要があります。

なお、有効帯域の増加を考える場合、Direct Connect はLink Aggregation Group (LAG) にも対応しています。
詳しくはドキュメントをご参照ください。

さて、以下に示す図6は、ECMP の優先度設計の考え方を示しています。

図6 ECMPを行う際の優先度設計

全てを同じ優先度1としています。なお、例としてOS1 の二つの接続を優先度1、OSAKA2の二つの接続を優先度2として、最大帯域を 2Gbps としてロードバランスさせることもできます。要件により、さまざまな設計が可能です。

シナリオ2-1 AWSからお客様ネットワークに向かうトラフィックのコントロール

シナリオ1では、BGPのCommunity タグとAS_PATH 属性を組み合わせて優先度を決定しました。シナリオ2 では、等コストにすることを目的としますので、以下の通り、Commnunity タグのみ利用します。

図7 Community タグによる等コスト設定

この例では、Community タグによってAWS が暗黙に設定するローカルプリファレンス値を上書きし、すべて優先設定：中にすることによって等コストに設定しています。これにより、AWS からお客様ネットワークに向かうすべてのトラフィックは4 つの接続にロードバランスされます。シナリオ1で利用したAS_PATH Prepend を利用する必要はありません。

シナリオ2-2 お客様ネットワークからAWS に向かうトラフィックのコントロール

今回はWAN サービスを利用していることを想定しているため、ご利用のサービスがECMP に対応していれば、特に優先度をつけずにWAN サービスにAWS からの経路を伝搬させることでECMP を実現できます。ご利用の際は、必ずWAN サービスやルーターのサービス仕様をご確認ください。

まとめ

本記事では、大阪リージョンに属する初めてのDirect Connect ロケーションである Telehouse OSAKA2のご紹介と、これを活用した冗長構成とトラフィックコントロールの例をご紹介しました。今回ご紹介した内容は、例えば東京とアメリカであったり、異なるリージョンに属するロケーションが混在する際にも活用できます。また、例えばEquinix TY2とOS1など、同じリージョンに属するDirect Connect ロケーションのみ利用する際にも、今後の拡張に備えてBGP Community タグを利用することを推奨いたします。

本記事は、Network Specialist Solutions Architect の奥村が執筆しました。

HAQM Web Services ブログ