この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Direct Connect Gatewayを経由して接続する構成に変更したい
こんにちは、のんピ(@non____97)です。
皆さんはDirect Connect好きですよね? 私はもちろん好きです。
最近Direct Connectを使われた方はDirect Connect Gatewayを使用されていることが多いと思います。
Direct Connect Gatewayを使うことによって、最大10個のVPCをオンプレミス環境に接続することが可能です。1つのPrivate VIFしかなくても複数のVPCをオンプレミス環境に接続することができるため、VPC毎にPrivate VIFを用意する必要がなくなります。加えてDirect Connect Gatewayは無料というのが、また素晴らしいです。
しかし、Direct Connect Gatewayがリリースされる前からDirect Connectを使用されている方は、現在もPrivate VIFとVGWを直接接続している構成も多いのではないでしょうか。
Private VIFとVGWの直接接続をしている構成ですと、回線速度の変更などPrivate VIFを作り直す場合に、オンプレミス環境との接続が完全に切れてしまうため、それなりのダウンタイムが発生します。
一方でDirect Connect Gatewayを使用していれば、新しいPrivate VIFをDirect Connect Gatewayに関連付けてから、古いPrivate VIFを削除するステップを踏むことでダウンタイムを最小限にすることができます。(古いPrivate VIF削除前にオンプレミス側のルーターでLocal PreferenceやAS-Path Prependで事前に新しいPrivate VIFにトラフィックを寄せておくのがベスト)
現在ではDirect Connect Gatewayを使わない理由がないと思うので、Private VIFとVGWの直接接続をしている構成から、Direct Connect Gatewayを経由する構成への切替作業を紹介したいと思います。
作業の流れ
実はAWS公式ドキュメントでも以下のようにDirect Connect Gatewayを経由した接続への切替方式が紹介されています。
- 新しい Direct Connect Gateway を作成します。
- 新しいプライベート仮想インターフェイスを作成します。
- 重要: 作成する際、仮想インターフェイスは必ず、前のステップで作成した Direct Connect Gateway に関連付けます。
- 作成した Direct Connect Gateway に、仮想プライベートゲートウェイ (VPC) にアタッチ済みの仮想プライベートゲートウェイを関連付けます。
- (オプション) ダウンタイムを最小限に抑えるには、ネットワークデバイス上で、新しい Direct Connect Gateway に関連付けられた新しい仮想インターフェイスの事前設定を行います。
- BGP を使用して、アドバタイズする新しい仮想インターフェイスを設定しているのと同じプレフィックスで、さらに長い AS_Path ルーティングポリシーを設定します。このステップにより、AWS からのアウトバウンドトラフィックは、(より短い AS_Path を持つ) 既存の仮想インターフェイスのルートを優先するように設定します。
- 注: ネットワークデバイスからのトラフィックが既存の仮想インターフェイスから引き続き出力されるようにするには、ネットワークデバイスのローカル設定の BGP 属性を使用します。
- メンテナンスウィンドウで、ネットワークデバイスの既存の仮想インターフェイスの BGP セッションを停止します。
- AWS のネットワークトラフィックが、Direct Connect Gateway に関連付けられた新しい仮想インターフェイス全体に伝達されるまで待ちます。
- トラフィックが新しい仮想インターフェイスからネットワークデバイスに送信されていることを確認します。
図示すると以下の通りです。
こちらの方式だと、後述する「VGWごと切り替える方式」よりもダウンタイムを短くすることが可能だと考えます。 一方で作業はAWSマネージメントコンソールで完結せず、Local Preferenceの設定やBGPセッションの停止などオンプレミス環境側のルーターの操作が必要となります。
そのため、30分から1時間程度のダウンタイムを許容できる場合は今回紹介する「VGWごと切り替える方式」での切り替えが良いかと考えます。
作業の流れは以下の通りです。
- Direct Connect Gatewayの作成
- 新Private VIFの用意
- Direct Connect Gatewayと新しいPrivate VIFの関連付け
- テスト用VPCを使ったオンプレミス環境との疎通確認
- 新VGWの作成
- VPCのルートテーブルから旧VGWへのルーティングを削除
- 旧VGWをVPCからデタッチ
- 新VGWをVPCにアタッチ
- 新VGWとDirect Connect Gatewayの関連付け
- VPCのルートテーブルで新VGWへのルーティングを追加
- VPC上のEC2インスタンスからオンプレミス環境のリソースに疎通確認できるか確認
- 旧Private VIFの削除
- 旧VGWを削除
ここで「Direct Connect Gatewayと既存のVGWを接続して通信が継続してできることを確認した後、既存のVIFとVGWの接続を削除すればダウンタイムがもっと短くなるのでは?」と思われるかもしれません。
それはその通りです。
しかし、「Direct Connect Gatewayと既存のVGWを接続して通信が継続してできることを確認した後、既存のVIFとVGWの接続を削除する」という方式の場合、既存のVIFのパターンによっては切り戻しにかなり時間を要します。(Direct Connect デリバリーパートナーが提供しているサービスによってはVIFの再作成に1週間かかるケースもあります)
「既存のVIFとVGWの接続を削除する」 = 「VIFの削除」になります。そのため、VIFを削除した後に通信ができず、切り戻したいとなった場合はVIFを再作成する必要があります。
この時ポイントとなるのが、ホスト型VIFかどうかです。Direct ConnectのConnectionを保持していない = ホスト型VIFを使っていた場合には、Direct ConnectのConnectionの管理者にVIFの再作成を依頼をする必要があります。
一方で、こちらの「VGWごと切り替える方式」では、切り戻し作業含めてAWSマネージメントコンソールだけで作業が完結するメリットがあります。
図示すると以下の通りです。
切り戻し時は以下のように、切り替え時と逆の操作を行います。
- VPCのルートテーブルで新VGWへのルーティングを削除
- 新VGWをVPCからデタッチ
- 旧VGWをVPCにアタッチ
- VPCのルートテーブルで旧VGWへのルーティングを追加
以降、各作業の詳細な内容を説明していきます。
1. Direct Connect Gatewayの作成
まず、Direct Connect Gatewayを作成します。
Direct ConnectのコンソールからDirect Connect ゲートウェイ - Direct Connect ゲートウェイを作成するから行います。
名前とAmazon 側の ASNを入力して、Direct Connect ゲートウェイを作成するをクリックします。
Direct Connect Gatewayの作成は待ち時間なく、すぐに完了します。
作業後の構成を図示すると、以下のようになります。
2. 新Private VIFの用意
次に、新規にPrivate VIFを用意します。
Direct Connectの仕様上、現在VGWと接続しているPrivate VIFに対して、一旦VGWとの接続を解除して、Direct Connect Gatewayに繋ぎ直すという操作はできません。
VGWとPrivate VIFの関連付けを解除するには、必ずPrivate VIFの削除が必要になります。そのため、新しくDirect Connect Gatewayに接続に使用するためのPrivate VIFを用意する必要があります。
Direct ConnectのConnectionを自分で管理している場合は、自分でPrivate VIFを作成できます。以下の(2)、(3)のようにパートナー経由のDirect Connectで、共有型接続をしている場合はパートナーにVIFの作成を依頼する必要があります。
Private VIFを自分で作成する場合は、Direct Connectのコンソールから仮想インターフェイス - 仮想インターフェイスを作成するから行います。
タイプはプライベートを選択し、仮想インターフェイス名やDirect Connect Gateway、VLAN ID、BGP ASNなどのパラメーターを入力した後、仮想インターフェイスを作成するをクリックします。
Private VIFの作成が完了した後は、使用しているルーターのモデルを指定して、ルーターのサンプル設定をダウンロードします。ダウンロードしたルーターのサンプル設定をベースにBGPネイバーを確立させます。
参考:
BGPネイバーが正常に確立されると、状態がavailable、BGPステータスがupとなります。
作業後の構成を図示すると、以下のようになります。
3. Direct Connect Gatewayと新しいPrivate VIFの関連付け
次にDirect Connect Gatewayと新しいPrivate VIFの関連付けを行います。
こちらの作業は自分でPrivate VIFを作成した場合、Private VIF作成のウィザードでDirect Connect Gatewayを指定することになるのでスキップして問題ありません。
キャリア側でPrivate VIFを作成した場合は、手動でDirect Connect Gatewayと新しいPrivate VIFの関連付け作業を行います。
Direct Connectのコンソールで関連付けたいPrivate VIFを選択し、承諾するをクリックします。Private VIFを関連付けるDirect Connect Gatewayの選択を求められるので、作成したDirect Connect Gatewayを選択して、仮想インターフェイスを承諾するをクリックします。
5分程度待ち、Direct Connect Gatewayから仮想インターフェイスのアタッチメントタブを開くと対象のPrivate VIFの状態がattachedになっていることが確認できます。
また、Private VIFの状態を確認すると、状態がavailable、BGPステータスがupとなっていることが確認できると思います。
作業後の構成を図示すると、以下のようになります。
4. テスト用VPCを使ったオンプレミス環境との疎通確認
次にテスト用VPCを使ったオンプレミス環境との疎通確認を行います。
いざ、本番切替! というときに実は設定が足りずオンプレミス環境と通信できないなんてことになると、目も当てられません。ですので事前にテスト用VPCを使って、Direct Connect Gateway及び新Private VIFの経路の疎通確認を行います。
疎通確認はテスト用VPCにEC2インスタンスを立てて、そこからオンプレミス環境のリソースへping及び、tracerouteで確認すると良いかと思います。
作業後はテスト用のVPCは不要なので削除しておきます。
5. 新VGWの作成
次にDirect Connect Gatewayと関連付けるためのVGWを作成します。
VPCのコンソールから仮想プライベートゲートウェイ - 仮想プライベートゲートウェイの作成をクリックします。
VGWのNameタグと、ASNを入力して仮想プライベートゲートウェイの作成をクリックします。なお、ASNはDirect Connect GatewayのASNと同じでも同じでなくても、どちらでも良いです。
Q.AWS Direct Connect ゲートウェイと仮想プライベートゲートウェイ用に異なるプライベート ASN を使用できますか?
はい、Direct Connect ゲートウェイと仮想プライベートゲートウェイ用に異なるプライベート ASN を使用できます。受信する AWS 側の ASN はプライベート仮想インターフェイスの関連付けに依存します。
Q.AWS Direct Connect ゲートウェイと仮想プライベートゲートウェイ用に同一のプライベート ASN を使用できますか?
はい、Direct Connect ゲートウェイと仮想プライベートゲートウェイ用に同一のプライベート ASN を使用できます。受信する AWS 側の ASN はプライベート仮想インターフェイスの関連付けに依存します。
VGWの作成が完了すると、以下のように表示されます。
作業後の構成を図示すると、以下のようになります。
ここまでが下準備です。本番切替作業前日までにこちらの作業までを完了していると、当日はスムーズに切替作業が進むと思います。
6. VPCのルートテーブルから旧VGWへのルーティングを削除
次にVPCのルートテーブルから旧VGWへのルーティングを削除します。
この作業からダウンタイムが発生します。
また、こちらの作業はルート伝播が有効であり、全てのVGWへのルートが動的ルートなのであれば、この手順はスキップします。動的ルートについては以下記事で紹介されているとおり、VGWをVPCからデタッチしたタイミングで削除されます。
VPCのコンソールから対象VPCのルートテーブルを選択して、ルートを編集をクリックします。その後ターゲットがVGWとなっており、伝播済みがいいえになっているルートを削除して、変更を保存します。
こちらの作業を実施しない場合、旧VGWをVPCからデタッチしたタイミングで、ターゲットがVGWのルートのステータスがblackholeになります。
7. 旧VGWをVPCからデタッチ
次に旧VGWをVPCからデタッチします。
1つのVPCに複数のVGWをアタッチすることはできないので、新VGWをVPCにアタッチするためには、事前に旧VGWをデタッチする必要があります。
VPCのコンソールから旧VGWを選択して、アクション - VPCからデタッチをクリックします。デタッチ対象のVGWを確認してデタッチするをクリックします。
10分程度待つとVGWのデタッチが完了します。デタッチ完了後はVGWの状態がdetachedになっていることを確認します。
なお、VGWをデタッチしてもPrivate VIFとの関連付けはされたままです。もし、以降の作業でDirect Connect Gatewayを経由して通信ができない事象が発生した場合は、こちらのVGWを使用して、作業前の状態にリカバリーするので、このタイミングではPrivate VIF及びVGWは削除しません。
作業後の構成を図示すると、以下のようになります。
8. 新VGWをVPCにアタッチ
次に新VGWをVPCにアタッチします。
VPCのコンソールから新VGWを選択して、アクション - VPCにアタッチをクリックします。アタッチ対象のVGWを確認してはい、アタッチしますをクリックします。
アタッチは数秒ほどで完了します。アタッチ完了後はVGWの状態がattachedになっていることを確認します。
作業後の構成を図示すると、以下のようになります。
9. 新VGWとDirect Connect Gatewayの関連付け
次に新VGWとDirect Connect Gatewayの関連付けを行います。
Direct Connect Gatewayを選択し、ゲートウェイの関連付けタブからゲートウェイを関連付けるをクリックします。
ゲートウェイで新VGWを選択して、ゲートウェイを関連付けるをクリックします。
10分程度待つとVGWとDirect Connect Gatewayの関連付けが完了します。関連付け完了後はVGWの状態がassociatedになっていることを確認します。
作業後の構成を図示すると、以下のようになります。
10. VPCのルートテーブルで新VGWへのルーティングを追加
次にVPCのルートテーブルで新VGWへのルーティングを追加します。
対象ルートテーブルを選択して、ルートタブからルートを編集をクリックします。ターゲットが新VGWとなるルートを追加して、変更を保存します。
オンプレミス環境から伝播されたルートを動的に追加したい場合は、ルートテーブルを選択し、ルート伝播タブからルート伝播の編集をクリックします。伝播の有効化にチェックを入れて保存をクリックすると、オンプレミス環境から伝播されたルートが動的に追加されます。
11. VPC上のEC2インスタンスからオンプレミス環境のリソースに疎通確認できるか確認
次にVPC上のEC2インスタンスからオンプレミス環境のリソースに疎通確認できるか確認します。
VPC上のEC2インスタンスかららオンプレミス環境のリソースへping及び、tracerouteを実行してDirect Connect Gateway及び新Private VIFを通ってオンプレミス環境と通信できることを確認します。
新Private VIFを経由していれば、tracerouteを実行すると新Private VIFのピアリングのルーターのピア IPとAmazon ルーターのピア IPを通っていることが確認できます。
12. 旧Private VIFの削除
次に旧Private VIFの削除を行います。
自分でConnectionを管理していない場合にPrivate VIFを削除してしまうと、すぐにPrivate VIFを作成し直すことは難しいので、旧Private VIFの削除は慎重に行う必要があります。
Direct Connectのコンソールから旧Private VIFを選択して、削除するをクリックします。
確認のウィンドウが表示されます。内容をよく確認して、フィールドに削除すると入力し、削除するをクリックします。
10分程度待つと旧Private VIFの状態がdeletedに変わります。
作業後の構成を図示すると、以下のようになります。
旧Private VIFと接続していた専用線は不要であれば、撤去・解約します。
13. 旧VGWを削除
最後に旧VGWを削除します。
VPCのコンソールから旧VGWを選択して、アクション - 仮想プライベートゲートウェイの削除をクリックします。削除対象のVGWを確認してはい、削除しますをクリックします。
VGWの削除はすぐに完了します。削除した旧VGWを見ると状態がdeletedになっていることが確認できます。
作業後の構成を図示すると、以下のようになります。
Direct Connect関連の作業は計画的に
Private VIFとVGWの直接接続構成からDirect Connect Gatewayを経由する構成への切替作業をまとめてみました。
Direct Connect関連の作業は影響範囲が大きくなりがちです。場当たり的に作業するのではなく、どのような作業項目があるのか事前に洗い出しておくことで、リスクを把握することができます。また、トラブルが発生しても落ち着いて対処出来ると思います。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
3
