AWS Direct Connect冗長化について、回避できる障害や構成パターンについて解説します。

はじめに

AWS Direct Connectを利用していても、障害発生に関して万能ではありません。万一の障害発生に備えて、システムの可用性を高めるためには、どのような冗長化を行うべきか検討する必要があります。

この記事では、現在、AWS Direct Connectを利用されている、あるいは今後導入しようと検討されている方に向けて、AWS Direct Connectの冗長化の方法やパターンを具体的に取り上げています。

実際に発生した東京リージョンの障害についても例に挙げながら、AWS Direct Connectに関してどのレベルの冗長化を行えばこうした障害に対応できるのか、またAWS Direct ConnectのSLA（サービスレベルアグリーメント）との関係についても具体的に解説を行なっていきますので、AWS Direct Connectを利用するにあたり、冗長化を検討するお客さまにとっては有益な情報になると思います。

目次

• ■AWS Direct Connectとは？
• ■AWS Direct Connectの冗長化とは？
• ・なぜ冗長化する必要があるのか？そのメリット
• ・冗長化することのデメリットとは？
• ・2021年9月2日に発生したAWS東京リージョンの障害に関して
• ■AWS Direct Connect経由での接続において障害が発生する可能性のある個所
• ・【ケース①】通信キャリアネットワーク(アクセス回線・中継網)で起こる障害
• ・【ケース②】通信キャリア設備(クラウド接続設備)で起こる障害
• ・【ケース③】AWS Direct Connectロケーションのデータセンター自体で起こる障害
• ・【ケース④】AWS Direct Connectロケーション内のAWS機器で起こる障害
• ・【ケース⑤】AWS Direct Connectロケーションと各リージョン間で起こる障害
• ・【ケース⑥】各リージョン内で起こる部分的な障害
• ・【ケース⑦】リージョン全体に影響する障害
• ■AWS Direct Connect冗長化の構築パターン
• ・【パターン①】シングル構成
• ・【パターン➁】シングルロケーションでの冗長構成―1つのAWS Direct Connectロケーションと2つのAWS Direct Connectを用いる
• ・【パターン③】デュアルロケーションー2つのAWS Direct Connectロケーションと2つのAWS Direct Connectを用いる
• ・【パターン④】4接続確保―2つのロケーションを利用、それぞれのロケーションで2つのdirect connectを用いる方法
• ・【パターン⑤】デュアルロケーション+インターネットVPNを用いる方法
• ・【パターン⑥】マルチリージョンー東京リージョンと大阪リージョンを用いた冗長化
• ・TIPS! 冗長化構成で使うべきBFD対応ルータ
• ■障害発生個所とそれを回避するための冗長化構成一覧表
• ■AWS Direct Connect SLA要件を満たしている接続パターン
• ■アット東京の「ATBeX」を使えばさまざまな冗長化パターンの構築が可能
• ・ATBeXで構築できる冗長化構成一覧表

　

AWS Direct Connectとは？

　AWS Direct Connectは、AWSが提供するクラウドサービスソリューションの１つであり、オンプレミス環境等クラウドの外部からAWS内へ専用ネットワーク接続を構築できるサービスです。

社内のオンプレミスネットワーク環境からAWSまでの経路を、インターネットを経由せずにプライベートな接続を確立することができます。

AWS Direct Connectでは、直接AWSのサーバーの配置されたデータセンターへ接続するのではなく、AWSが特定のデータセンターに配置した相互接続ポイント（AWS Direct Connectロケーション＝アクセスの中継地）を介して接続する仕組みになっています。

AWS Direct Connectロケーションとなるデータセンターは日本国内にアット東京CC1（中央センター）、エクイニクスTY2、エクイニクスOS1の3カ所のみであり、必ず、このいずれかのデータセンターロケーションへ接続し、AWSに接続する必要があります。

AWS Direct Connectロケーションへ接続するためには、これらのデータセンターと直接契約するか、お客さま拠点からAWS Direct Connectロケーションまで、通信事業者の専用線サービスなどを利用して接続します。

AWS Direct Connectでは、通信速度は最低 50 Mbps から最大 100 Gbps までさまざまな帯域で接続することが可能です。

＜AWS Direct Connectに関する詳しい記事はこちら↓＞

【保存版】AWS Direct Connectとは？概要やVPNとの違い、接続タイプについて詳しく解説！

AWS Direct Connectの冗長化とは？

　デジタルトランスフォーメーションが進展する現代の企業システムは、クラウド利用などにより外部のITサービスへの依存度が高い状況となっており、ネットワークの可用性を高めることが重要です。

ネットワークの可用性とは、ネットワーク機器や回線を含めたネットワーク経路を、災害や障害などで停止させることなく通信経路を確保し続けることを意味しています。

クラウド上でシステムを稼働させ、大量のデータを保管することが当たり前になっている時代であり、オフィス内のネットワーク機器の故障や大規模な回線障害でネットワークが突然切断されるケースに備えた対策をとらなければなりません。

そのためには、クラウドやデータセンターまでのネットワーク設計において冗長構成を考慮することが極めて重要になってきます。

　AWS Direct Connectは、通信帯域が確保された状態でダイレクトにAWSへネットワーク接続でき、インターネットVPNと比較してセキュアで品質の高いネットワークサービスです。

しかし、AWS Direct Connectを利用して、ユーザー拠点とAWS間を専用線で接続し、セキュアで高品質な環境を構築していても、事故などで専用線が切断したり、AWS Direct Connectロケーション自体に障害が発生して機能しなくなる場合には、やはり利用できなくなってしまいます。障害はいつでも、どんなときにでも、発生するということを忘れずに設計しなければなりません。

なぜ冗長化する必要があるのか？そのメリット

（１）可用性を高め、障害が発生した際の停止時間を短縮する

　AWS Direct Connectを利用してAWSに接続する場合、必ず物理的なネットワーク回線、通信機器、接続ポイントとなる物理的なロケーションがあり、それが１つだけだと障害が発生したときにネットワークが止まってしまいます。

これを冗長化することによって、たとえ一方の回線や機器、物理的なロケーションに障害が発生しても、予備の経路やロケーションを経由して接続することにより、停止時間を縮小化することができ、可用性を高めることが可能できます。

（２）計画停止（メンテナンス）時の迂回経路として

　ネットワークの停止は、障害が発生した場合だけでなく、クラウドサービス事業者や通信キャリアによる計画停止（メンテナンス）のときにも発生します。

クラウドサービスも通信キャリア設備も実際は物理的なネットワークやサーバーで構成されているため、計画停止を行うこともあります。

障害が突発的に発生するのに比べ、計画停止はネットワークがいつ停止するのか、どれくらい停止するのか、事前に停止時間が分かります。

しかし、特にクラウドサービスを利用している場合は、その時間帯は止めてほしくないといった場合でも、個々の顧客単位での時間調整には応じてもらえません。

そのような場合にも、冗長構成を採用していれば、メンテナンスの発生していない経路を迂回経路として切り替えることで、ネットワークの停止を避けることができます。

冗長化することのデメリットとは？

　このようにAWS Direct Connectを冗長化することには可用性を高めるメリットがありますが、デメリットについても整理しておきましょう。

（１）コストが高い

　AWS Direct Connectロケーションと社内との経路を冗長化するためには、複数の専用線やネットワーク機器を用意しなければなりません。完全に別の経路で準備する場合、費用が2経路分必要となります。

（２）管理業務の増加

冗長化により構成が複雑化することにより、AWS Direct Connectロケーションや、ユーザー側環境で用意するネットワーク機器が増えることが考えられ、管理業務が増加する可能性があります。

（３）障害に対して万能ではない

　AWS Direct Connectロケーションまでの経路を冗長化していても、あらゆる障害に対して万能ではありません。

次の項で述べるように、AWS Direct Connectロケーションまでの通信回線を複数敷設して冗長化を行っていても、さらにその上位の部位で障害が発生する場合があります。

また、リージョン障害のような大規模障害が起きたときには、冗長化だけでは対応ができません。

2021年9月2日に発生したAWS東京リージョンの障害に関して

　ここで2021年9月2日に発生した、東京リージョンのAWS Direct Connect全域（全てのAZ=Availability Zone）で発生した障害について、振り返ってみたいと思います。

2021年9月2日の7時半頃より、AWS Direct Connectを通じたAWSリソースへの接続不可とパケットロスの増加が観測されました。

これは、AWS Direct Connect のネットワークトラフィックを、東京リージョンの全てのAZに接続するために利用されるコアネットワークデバイスに問題が発生したことが原因でした。

AWSの発表によれば、同日午後 1 時 42 分に接続の問題は完全に解決されましたが、この障害は、AWS Direct Connectの利用と障害に対する備えに関して大きな教訓を残しました。

　注目すべきなのは、このケースでは、障害が発生したポイントがAWS内部の「AWS Direct Connectロケ―ション～AWS東京リージョンへのネットワークパスでの障害（リージョン内のコアネットワークデバイスの障害）」であったため、お客さま拠点からAWS Direct Connectロケーションまでの接続を複数経路で冗長化していても、障害回避をすることができなかったということです。

障害発生時、パケットロスが頻発しましたが、AWS内部のネットワーク構成で、主系が完全にダウンしたわけではなかったため、主系から副系への切り替えを行うことができなかった不安定な通信状況となりました。

AWSでは、本障害の回避策としては、AWS Direct Connectではなく、AWS Site-to-Site VPN（インターネットVPN）への迂回を行い利用することが有効であったとしています。

　では、このような障害を回避するための冗長化構成についても解説していきましょう。

（参考）AWS公式メッセージ

AWS Direct Connect経由での接続において障害が発生する可能性のある個所

具体的に、AWS Direct Connectにおいて、どのような箇所でどんな障害の発生可能性があるのでしょうか。この項では、そこを詳しく見ていくことにしましょう。

　　　

【ケース①】通信キャリアネットワーク(アクセス回線・中継網)で起こる障害

　お客さま拠点やお客さまの利用されているデータセンターから、AWS Direct Connectロケーションまでの通信経路で起こる障害です。

障害を回避するためには、AWS Direct Connectロケーションへ接続する、通信キャリアの専用線を異なる経路で2本準備して冗長化することが対策となります。

お客さま拠点からキャリアネットワークまでの光ファイバーアクセス回線は物理的な回線区間であり、NTTダーク、電力ダーク、CATV等の異なる光アクセス回線事業者を利用し同時障害を回避する方法があります。

キャリアネットワーク内についても、単一経路とならないように、中継局や中継網は１つの通信サービス事業者内でも異経路での設計をしてもらったり、異なる通信サービス事業者2社のサービスを利用することで、違う経路での接続を確保することができるようになります。

　また、ネットワーク停止リスクを極力避けたい場合、お客さまの重要なサーバーは、お客さま拠点やお客さまが利用されているデータセンターではなく、AWS Direct Connectionロケーションとなっているデータセンター内に移設して設置することがお勧めです。

アット東京のデータセンター、CC1(中央センター)はAWS Direct Connectロケーションとなっており、重要なオンプレミスのサーバーを同ロケーションに置くことで、この障害を回避することができます。

CC1にはAWS Direct Connectの接続ポイント設備があり、データセンター内で構内での光ケーブルで直接つなぐことが可能で、それにより、お客さま拠点からの通信キャリアネットワーク回線が必要なくなるため、AWSとの接続の可用性が高まります。

また、可用性の向上以外にも、ネットワークコストが安価になる、ネットワーク遅延が最小限に抑えられる、キャリア区間がなくなるため障害の切り分けが容易になる、といったメリットがあります。

【ケース②】通信キャリア設備(クラウド接続設備)で起こる障害

　AWS Direct Connectロケーション内に設置されたキャリア設備で起こる障害です。具体的にはキャリア伝送設備の故障、通信関連機器の故障、人為的な設定ミス、メンテナンスなどが考えられます。

せっかくAWS Direct Connectロケーションまでの通信ネットワークを完全二重化したとしても、ここはAWS Direct Connectの入口までのラストワンマイルの部分なので、ここで同じ設備を経由すると、同時に障害の影響を受ける可能性があります。

障害を回避するためには、単一の通信キャリアへ依存せず、異なる通信キャリアを選択し接続する方法が考えられます。

また、同一キャリアの利用の場合でも、異なるAWS Direct Connectロケーション経由で接続する構成（マルチPOP接続）を行うことでキャリア設備も異なる設備を経由することが実現できます。

【ケース③】AWS Direct Connectロケーションのデータセンター自体で起こる障害

　AWS Direct Connectロケーションとなっているデータセンター設備自体で起こる障害です。具体的には、データセンターでの電源の喪失や火災、地震、洪水や津波などの天災被害や、構内配線の老朽化や不良などが考えられます。

AWS Direct Connectでは、物理的なロケーションの冗長化のために、日本国内3カ所のAWS Direct Connect ロケーションが設置されています。

異なるAWS Direct Connectロケーションに接続する構成（マルチPOP接続）を行うことで、単一のロケーションに依存しない構成が実現でき、データセンター障害に起因するAWSへの接続障害の際の迂回経路を確保してデータセンター障害を回避することができます。

【マルチPOP接続とは】

　クラウド環境への「出入口」となるネットワークの物理的な接続拠点のことを「クラウドPOP（Points Of Presence）」と呼んでいます。

ユーザー企業が自社拠点のデータセンターから専用線経由でPOPに接続することで、自社環境とのプライベートネットワークによるダイレクト接続が可能になります。

このクラウドの出入り口となるPOPを異なる複数のロケーションに分けて接続することが、マルチPOP接続です。

回線の冗長化を行う場合、このマルチPOP接続をすることにより、ダイレクト接続サービスの可用性を高めることができます。

単一のPOP経由で接続している場合、ネットワーク機器などの障害が利用中のPOPで発生した場合に通信できなくなりますが、マルチPOP接続で迂回することが可能となります。

AWSにおいても複数のAWS Direct Connectロケーションが設置されており、異なる複数のPOPへ接続することにより、POPへの冗長接続を実現できます。

マルチPOP接続は、サーバーロケーションを冗長化するMulti-AZ化と同じように、ネットワーク接続の物理的なロケーションの障害に対応する対策となります。

【ケース④】AWS Direct Connectロケーション内のAWS機器で起こる障害

　AWS Direct Connectロケーション内のAWS Direct Connect設備で起こる障害です。具体的には、AWS側の収容機器の故障や設定ミス、メンテナンスなどが考えられます。

AWS内部の機器構成については非公開ですので、この部分はAWSにお任せするしかありません。

しかし、同一のロケーション内で冗長構成での接続を行う場合は、最低限の対応として、冗長化目的で2本の物理接続を行うAWS側の収容機器が同じ機器になっていると同時に障害になるリスクがあるので、異なる機器になっているかどうかを接続プロバイダーもしくはAWSに確認し進めるとよいかと思います。

異なるAWS Direct Connectロケーションに接続し冗長構成する場合（マルチPOP接続）は、必然的にロケーションが異なりAWS機器も異なる設備になるため、この障害リスクは解消されます。

【ケース⑤】AWS Direct Connectロケーションと各リージョン間で起こる障害

　AWS Direct ConnectロケーションからAWSの各リージョン間の通信経路上のネットワーク機器や回線で起こる障害です。2021年9月2日の障害はこのケースでした。

このケースでは障害の部位により影響範囲が異なりますが、上述のさまざまなお客さま側ネットワークでの冗長構成の対策を実施していても、AWS内部での障害であり影響を受ける可能性があります。

障害を回避する方法としては、AWS Direct Connect以外の接続手段としてインターネットVPN経由の経路を想定しておく方法があります。

9月2日のケースではインターネットVPNは利用可能であったため、障害の回避手段としてインターネットVPN経由での接続が推奨されていました。

ただし、障害の部位や状況によりインターネットVPNも利用不可となる可能性も考えられるので、インターネットVPNの経路を準備しておけば万全というわけでもないと考えられます。

【ケース⑥】各リージョン内で起こる部分的な障害

　それぞれのリージョン内における通信機器やネットワーク機器、サーバー障害に起因する障害です。単一のAZ（アベイラビリティゾーン）で起きている障害であれば、リージョン内の複数のAZを利用するMulti-AZ構成によって回避できる場合があります。

【ケース⑦】リージョン全体に影響する障害

　リージョン全体に影響する障害です。広域災害による電力供給の停止などで、障害の範囲がリージョン内の全てのAZに及び、リージョン全体に及ぶケースです。リージョン全体が利用できない事態となるので、複数のリージョンで冗長化するマルチリージョン構成を行うことが回避策になります。

AWSでは2021年11月現在、全世界に25の地理的リージョンがあり、それぞれ他リージョンの影響を受けない独立した構成で提供されています。

日本国内には東京リージョン、大阪リージョンの２つの独立したリージョンが設置されており、国内での地域分散に対応したマルチリージョンによる運用も可能です。

＜AWS大阪リージョンに関する詳しい記事はこちら↓＞

AWS大阪リージョンとは？生まれた背景と、そのメリットについて詳しく解説します！

AWS Direct Connect冗長化の構築パターン

では次に、AWS Direct Connectを冗長化する場合に、どんな構築パターンがあるかについて見ていくことにします。

【パターン①】シングル構成

　まずシングル構成ですが、これはお客さま拠点からAWS Direct Connectロケーションまでの接続を、いずれも１つのネットワークリンクで構成するパターンです。

ネットワークリンクは1つですから、利用している経路のどこかに障害が発生した場合は、ネットワーク接続は停止してしまいます。ケース①〜ケース⑦いずれの障害に対しても回避できません。

この構成における障害ケース回避について

ケース① 通信キャリア	ケース➁ キャリア設備	ケース③ DC自体	ケース④ AWS機器	ケース⑤ DCLとリージョン間	ケース⑥ リージョン内部分	ケース⑦ リージョン全体
×	×	×	×	×	×	×

　　

【パターン➁】シングルロケーションでの冗長構成―1つのAWS Direct Connectロケーションと2つのAWS Direct Connectを用いる

　お客さま拠点からAWS Direct Connectロケーションまでの回線を冗長化する構成で、１つのAWS Direct Connectロケーションに対し、２つのAWS Direct Connectの接続を構成する方法です。

ユーザー拠点とロケーションを接続する専用線や、双方のルータなど通信機器に障害があった場合でも、AWS Direct Connectロケーションまでの経路が冗長化されているため利用が継続できます。

とはいえ、AWS Direct Connectロケーション自体で障害が発生した場合には、ネットワーク接続が停止してしまいます。

従来、AWS Direct Connectの冗長化方式として、この方法が一般的でしたが、現在はAWS Direct Connectロケーション自体も複数ロケーション冗長する構成をとることができるようになり、AWSにおいても次のパターン③のマルチPOP接続によるロケーションの冗長化（デュアルロケーション）を推奨しています。

この構成における障害ケース回避について

ケース① 通信キャリア	ケース➁ キャリア設備	ケース③ データセンター自体	ケース④ AWS機器	ケース⑤ DCLとリージョン間	ケース⑥ リージョン内部分	ケース⑦ リージョン全体
〇	〇	×	×	×	×	×

 

【パターン③】デュアルロケーションー2つのAWS Direct Connectロケーションと2つのAWS Direct Connectを用いる

　2つのAWS Direct Connectロケーションに対し、それぞれAWS Direct Connectの接続を行う方法です。

通信キャリアの専用線や通信機器に障害があった場合でも、AWS Direct Connectロケーションで障害が発生した場合でも、単一障害ポイントの場合に影響なく稼働できるというメリットがあります。

かつて東京リージョンにはAWS Direct Connectロケーションが1つしかなく、東京内だけでこの構成をとることはできませんでしたが、現在は東京にもアット東京CC1とエクイニクスTY2の2つのDirect Connectロケーションが構築されており、このデュアルロケーション構成をAWSが冗長化構成として推奨しています。

　アット東京CC１内のハウジングスペースからもアット東京のクラウド接続サービスATBeXを利用することで、このデュアルロケーションの冗長化構成を構築することが可能です。

ATBeXの相互接続パートナー、PCCW Global社のConsole Connectを使うことによってエクイニクスTY2への論理回線を構築することができます。

この構成における障害ケース回避について

ケース① 通信キャリア	ケース➁ キャリア設備	ケース③ DC自体	ケース④ AWS機器	ケース⑤ DCLとリージョン間	ケース⑥ リージョン内部分	ケース⑦ リージョン全体
〇	〇	〇	〇	△	×	×

　

【パターン④】4接続確保―2つのロケーションを利用、それぞれのロケーションで2つのdirect connectを用いる方法

　2つのAWS Direct Connectロケーションそれぞれに、2つのAWS Direct Connectを用いて冗長化し、計４つの接続ルートを確保する方法です。

物理的な障害に対して一番回復性が高く、偶発的な二重障害発生のケースも対応できる可能性があり、耐障害性の計算をしたときに、99.99%の可用性があるとされます。

AWSはこの方法をもっとも可用性が高くなる方法として推奨していますが、コストがかかるため導入は容易ではありません。

また、この構成をとっていたとしても、2021年9月2日のAWS Direct Connectの障害は、回避できなかったと考えられます。

この構成における障害ケース回避について

ケース① 通信キャリア	ケース➁ キャリア設備	ケース③ DC自体	ケース④ AWS機器	ケース⑤ DCLとリージョン間	ケース⑥ リージョン内部分	ケース⑦ リージョン全体
◎	◎	◎	◎	△	×	×

（参考）シングルロケーション、デュアルロケーション、4接続確保の構成は、「AWS Direct Connect回復性に関する推奨事項」のページに解説があります。

【パターン⑤】デュアルロケーション+インターネットVPNを用いる方法

　AWS Direct Connectをデュアルロケーションで構築し、かつ接続方式もSite to Site VPN(インターネットVPN)を第３の手段として確保することによって冗長化する方法です。

AWS Direct Connectロケーション経由以外に、ユーザー拠点とAWSを直接インターネットVPNで接続する経路も確保し、AWS Direct Connectロケーションに障害が発生したときには、インターネットVPN接続に切り替えます。

この構成であれば、2021年9月2日のAWS Direct Connect障害は、インターネットVPN経由で直接AWSと接続する運用に切り替えることによって、障害が回避できたのではないでしょうか。実際、VPN経由接続でAWSとの経路を冗長化している企業は、障害の影響を受けませんでした。

　この冗長化方式のデメリットとしては、インターネットVPNを利用するためセキュリティリスクがある点です。

緊急時以外には使用しないとはいえ、インターネットに接続する経路が存在している以上、その経路のセキュリティリスクを担保する運用が求められます。

２番目には、インターネット接続はベストエフォートになることから、速度低下のリスクが存在することです。特にこの副系を利用しなければならない障害が発生しているケースでは、AWSのインターネットVPNはトラフィックが増加し輻輳している可能性も大いに考えられます。この方法をとる場合には、それでも完全に経路が遮断されるよりはいいという割り切りも必要でしょう。

また、インターネットVPN経由での接続は１接続あたり最大1.25Gbpsまでという制限があり、広帯域通信のバックアップとしては帯域要件を満たさないこともあります。

パターン⑤を採用するなら、こうしたデメリットや、前提条件を十分考慮した上で利用することが必要でしょう。

この構成における障害ケース回避について

ケース① 通信キャリア	ケース➁ キャリア設備	ケース③ DC自体	ケース④ AWS機器	ケース⑤ DCLとリージョン間	ケース⑥ リージョン内部分	ケース⑦ リージョン全体
〇	〇	〇	〇	〇	×	×

　

【パターン⑥】マルチリージョンー東京リージョンと大阪リージョンを用いた冗長化

　東京リージョン以外に、大阪リージョンにバックアップDR（ディザスタリカバリ）サイトを構築し、かつ東京と大阪それぞれのAWS Direct Connectロケーションを用いて冗長化する方法です。

東京のAWS Direct Connectロケーション(アット東京CC1)と大阪のAWS Direct Connectロケーション(エクイニクスOS1)から、それぞれ、Direct Connect Gatewayを用いて、東京リージョン、大阪リージョンに接続する構成とします。

この方法であれば、例えば東京全域に震災のような大災害が発生した場合でも、大阪のAWS Direct Connectロケーションを経由して、大阪リージョンに接続し、稼働を継続しているDRサイトを利用することができます。

東京リージョンと大阪リージョンは別のクラウドとしてとらえてもよく、極めて高い可用性を維持することができる構成です。

ただし、東京と大阪の両リージョンを常時アクティブにしておくと、コストが２倍かかることになりますので、大阪はスタンバイ状態にしておき、利用時のみサーバーをアクティブにする方法が現実的でしょう。この場合稼働するサーバーの構成によりますが、1.2〜1.3倍のコストで収まる可能性があります。

この構成における障害ケース回避について

ケース① 通信キャリア	ケース➁ キャリア設備	ケース③ DC自体	ケース④ AWS機器	ケース⑤ DCLとリージョン間	ケース⑥ リージョン内部分	ケース⑦ リージョン全体
〇	〇	〇	〇	〇	〇	〇

　

TIPS! 冗長化構成で使うべきBFD対応ルータ

BFD対応ルータとは？

　BFD（Bidirectional Forwarding Detection　＝双方向フォワーディング検出）機能とは、2台の隣接するルータ間で、転送パスの生存状況を調べて高速に障害を検知してルーティングプロトコルに通知する機能で、隣接するルータとの間にL2スイッチなどが存在していて、リンクのステータスが伝わらないような障害が発生した場合に、効果を発揮します。

冗長化構成ではBFD対応ルータを使いましょう

　AWS Direct Connectへの接続ではBGPというルーティングプロトコルに対応すること、IEEE802.1Q VLANタグに対応することが必要要件となっており、冗長接続の場合は、BFDにも対応するルータを手配することが効果的です。

BFD対応ルータは、定期的にBFDパケットを送受信し、対向ルータから一定時間内にBFDパケットを受信できなかった場合には、自律的に対向ルータとの経路に障害が発生したと判断して高速でバックアップ経路に切り替わるので、ネットワークの切替時間を短縮することができます。

特にデュアルロケーションのような冗長化構成で運用している場合には、利用ロケーションを高速に切り替える必要があるため、BFD対応ルータの利用が効果的です。

障害発生個所とそれを回避するための冗長化構成一覧表

	障害① 通信キャリア	障害② キャリア設備	障害③ DC自体	障害④ AWS機器	障害⑤ DCLとリージョン間	障害⑥ リージョン内部分	障害⑦ リージョン全体
①シングル構成	×	×	×	×	×	×	×
➁シングルロケーションでの 冗長構成	〇	〇	×	×	×	×	×
③デュアルロケーションでの 冗長構成	〇	〇	〇	〇	△	×	×
④4接続確保	◎	◎	◎	◎	△	×	×
⑤デュアルロケーション+ インターネットVPN	〇	〇	〇	〇	〇	×	×
⑥マルチリージョン	〇	〇	〇	〇	〇	〇	〇

　

AWS Direct Connect SLA要件を満たしている接続パターン

AWS Direct Connect SLAとは？

　SLAとは「Service Level Agreement（サービスレーベルアグリーメント）」のことで、サービスの提供事業者とその利用者の間で結ばれるサービスのレベル（定義、範囲、内容、達成目標等）に関する「合意サービス水準」「サービス品質保証」のことです。

サービスを提供する事業者が契約者に対して、どの程度まで品質を保証できるかを明示したもので、多くのネットサービスでは個別のSLAを顧客に対して提示しています。

AWSも各サービスに関して内容の異なるSLAを個別に提示しており、利用しているサービスでどこまでのサービス水準や品質の保証がされているかを確認することが必要です。

AWS Direct Connectサービスに関してもSLAがあり、細かな要件が定められています。SLAの水準をサービス提供側が満たすことができなかった場合には、返金保証などの対象になります。

（参考）AWS Service Level Agreement

（参考）AWS Direct Connect Service Level Agreement

接続パターンSLA対応比較表

接続パターン	Direct Connect SLA
パターン①シングル構成	なし
パターン➁シングルロケーションでの冗長構成	なし
パターン③デュアルロケーションでの冗長構成	99.9%
パターン④4接続確保	99.99%

　

アット東京の「ATBeX」を使えばさまざまな冗長化パターンの構築が可能

アット東京の接続サービス「ATBeX」を使えば、さまざまな冗長化パターンの構築が可能です。以下の一覧表を、ぜひ参考にしてください。

ATBeXで構築できる冗長化構成一覧表

冗長化構成	ATBeXで構築可能なパターン
①シングル構成	〇
➁シングルロケーションでの冗長構成	〇
➂デュアルロケーションでの冗長構成	〇（CC1とOS1でのデュアルロケーション） CC1とTY2でのデュアルロケーションはPCCW Globalサービス併用で可能
④4接続確保	〇（CC1とOS1でのデュアルロケーション）
⑤デュアルロケーション+VPN	〇（インターネット回線が別途必要）
⑥マルチリージョン	〇

AWS Direct Connectの冗長化をご検討の方は是非お問合せください！

• 問い合わせる

またATBeXポータルでは、設問に答えるだけで簡単にクラウド接続の推奨構成をご提案する「クラウド接続デザインツール」をご用意しております。ATBeXを利用してどのような構成ができるのか詳しく知りたい方や、各構成の費用について知りたい方は「クラウド接続デザインツール」をぜひご利用ください。

• クラウド接続構成を作ってみる

この記事を書いた人　チータ

監修　すぎちゃん

同じカテゴリーの記事