11
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【Direct Connect】Private VIFトラブルシューティング

Last updated at Posted at 2025-07-28

この記事は「2025 Japan AWS Jr. Champions 夏のQiitaリレー」の25日目です。
過去の投稿(リンク集)はこちらからご覧ください!

はじめに

こんにちは。株式会社野村総合研究所の原です!
普段、AWS Direct Connectを利用して、お客様のオンプレミス環境からAWSへの閉域接続をご提供する、ネットワークプロバイダ業務に従事しています。

今回は、Direct Connectの中でもPrivate VIFを利用したオンプレミス・AWS間ネットワークにおいて、通信が確立できない場合のAWSコンソール上での確認ポイントに焦点を当ててご紹介します。

Direct Connect概要

AWS Direct Connectは、お客様のオンプレミス環境とAWSを専用のネットワーク接続を介して接続することで、安定した、よりセキュアな閉域網通信を実現するクラウドサービスです。このサービスにより、インターネットを経由せずにデータ転送を行うことが可能となり、ネットワークパフォーマンスや安全性の向上などのメリットを享受できます。
Direct Connectロケーションにおいて、お客様のルータとAWS Direct Connectルータ間を物理的な専用回線で接続することで、閉域接続が確立されます。

image.png
(What is AWS Direct Connect? より引用)

ここからは、Direct Connectに関する代表的な用語について簡単に説明します。

用語 概要
Connection (接続) 顧客側の終端ルータとAWS側の終端ルータを接続する物理的な専用回線
Direct Connect Gateway (DXGW) Direct Connectを利用して複数のVPCに接続するためのグローバルリソースであり、AWSリージョンを跨いだ接続集約ポイント
1つのDXGWあたり、最大20のVGWと紐付け可能 (=20のVPCに接続可能)
Transit Gateway (TGW) 複数のVPCやオンプレミス環境を接続するための、AWSが提供するルーティング集約ハブサービス
1つのTGWあたり、最大5000のアタッチメントを作成可能 (=5000のVPCと接続可能)
Private Virtual Interface (Private VIF) VGWまたはDXGWと紐づけることで、VPC内のリソースにアクセスするための仮想インタフェース
Transit Virtual Interface (Transit VIF) DXGWに紐づけることで、DXGWに関連づけたTGWを介してVPC内のリソースにアクセスするための仮想インタフェース
Public Virtual Interface (Public VIF) AWSサービスのパブリックIPエンドポイントへアクセスするための仮想インターフェイス

Private VIFとTransit VIFはどちらも、オンプレミスからAWSのVPC内リソースに閉域で通信するために利用されます。
違いとしてはTGWの利用有無になります。DXGWに関連付けできるVGWの最大数は20ですが、TGWは最大5000のアタッチメントを作成できるため、DXGWと比較するとTGWは多くのVPCに接続できます。
そのため、1つのVIFで多くのVPCに接続する用件がある場合はTransit VIFを利用することがあります。

また本記事で扱うPrivate VIFは、VGWに直接紐づけることも、VGWを関連づけたDXGWに紐づけることもできます。

image.png

接続先のVPCが2つ以上の場合や異なるアカウントのVPCに接続する場合は、VIFをDXGWに紐づけた上で接続先VPCのVGWをDXGWにアタッチする必要があります。

疎通NG時の確認観点

ここからは、オンプレミスとAWS間で通信ができない場合のAWSコンソール上での確認観点を順に挙げていきます。

本記事では、Private VIFを利用しDXGW経由でVPC内リソースにアクセスする、以下の構成パターンを想定します。

image.png

疎通トラブル時の確認観点は、大きく以下の二つに分けられます。

  • VIFのBGPステータスがupになっているか
  • Gatewayやルートテーブルなどの各ネットワークリソースの設定が正しいか

VIFのステータス確認

はじめに、対象のVIFのステータスを確認します。

image.png

Direct Connectのコンソール画面から対象のVIFを選択し、以下の項目を確認します。

状態

状態とは、VIFのライフサイクルを表すパラメータです。
Private VIFを作成後、状態がpendingとなっている場合は、そのVIFがDXGWまたはVGWに関連づけられていないことを意味します。この状態の場合、まずVIFを適切なGatewayに関連付ける必要があります。
VIFをGatewayに関連付けて、状態がavailableに変化したことを確認します。

BGPステータス

BGPステータスは、顧客の終端ルータとAWSの終端ルータ間のBGPピアのステータスを表します。
VIFの状態がavailableであるにも関わらず、BGPステータスがdownから変わらない場合は、顧客ルータとAWS間でBGPピアリングの設定に誤りのある可能性が高いです。

例えば、上記のコンソール画面に記載されたBGPピアリングのパラメータを図示すると以下になります。

image.png

上記のパラメータに関して、顧客ルータの設定とAWSコンソール上の設定が一致することでBGPピアリングを張れるようになり、BGPステータスがupになります。

もしBGPピアリングのパラメータ不一致が発覚した場合、以下の方法で修正する必要があります。

  • 顧客ルータ内のBGPピアリングに関する設定の変更
  • 正しいBGPピアリングのパラメータでVIFを再作成

VIF作成後のBGPピアリングの設定変更は現状不可になります。
そのため、BGPピアリングの設定を修正する場合は、VIFの削除と再作成が必要になります。

また、BGPピアリングの設定が正しいにも関わらずBGPステータスがdownのまま改善しない場合は、顧客ルータからAWSへBGPで広報する経路数を確認する必要があります。
Direct Connectでは、Private VIFまたはTransit VIFを利用して顧客ルータからAWSへ広報できる経路の数に関して、VIFあたり100の上限があります。
こちらに関しては、AWSのコンソールではなく顧客ルータのBGPテーブルを確認し、AWSへ広報している経路数が100を超えている場合は、経路集約等により100以下に抑える必要があります。

ネットワークリソースの設定確認

VIFのBGPステータスがupしているにも関わらず、オンプレミスとAWS間で通信ができない場合は、Direct Connect Gateway (DXGW) やVPCのルートテーブルなど、各ネットワークリソースの設定を確認します。

接続先VPCのVGWがDXGWにアタッチされているか

すでに述べたように、VIFはGatewayに紐づけられることでavailable状態になります。
もしVIFを直接VGWに紐づける場合は、「VIFの状態がavailableであるか」=「VIFがVGWに紐づけられているか」を意味しますが、VIFをDXGWに紐づける場合は注意が必要です。

VIFをDXGWに紐づけた段階で、VIFの状態はavailableになりBGPステータスはupになりますが、VGWをDXGWに紐付け忘れている場合は依然としてVPCへの通信は不可になります。

image.png

DXGWのゲートウェイの関連付けから、対象のVGWを追加してあげましょう。

VPCのルートテーブルでルート伝播が有効になっていることを確認

DXGWとVGWが正しく関連づけられているにも関わらず、VPCセグメントがオンプレミスへBGPで広報されない場合は、対象VPCのルートテーブルの設定を確認します。

image.png

ルートテーブルのルート伝播において、伝播が「いいえ」になっている場合は「はい」に変更する必要があります。
ルート伝播は、VGWからVPCへ広報される経路をVPCの対象ルートテーブルに反映するかを指します。

伝播を「はい」にすることで、VPCのルートテーブルにオンプレミスの経路情報が載るようになり、AWSからオンプレミスへの通信や、オンプレミスからAWSへの通信の戻りの通信ができるようになります。

image.png

こちらの画像は、ルート伝播を「はい」にする前と後のルートテーブルの比較です。
ルート伝播を有効化することで、VGWがターゲットの経路情報が追加されました。
また、該当の経路情報は「伝播済み」の項目が「はい」になっており、VGWから伝播されたことが分かります。

DXGWのプレフィックスフィルタの確認

DXGWには、関連づけたVGWごとに、オンプレミス側へ広報するセグメントを許可するプレフィックスリストの設定があります。

image.png

各VGWごとに設定することができ、初期設定ではVGWがアタッチされたVPCのセグメントが自動で入力されます。

プレフィックスリストとVPCのセグメントと、その時のオンプレミスへの経路広報の有無について、例を挙げてみます。

許可されたプレフィックス VPCセグメント オンプレミスへの経路広報
192.168.0.0/23 192.168.0.0/24 192.168.0.0/24が広報される
192.168.0.0/24 192.168.0.0/24 192.168.0.0/24が広報される
192.168.0.0/25 192.168.0.0/24 広報されない
192.168.1.0/24 192.168.0.0/24 広報されない

VPCセグメントが、許可されたプレフィックスに完全に内包されている場合のみ、オンプレミスへVPCセグメントが広報されます。
そのため、プレフィックスリストを手動で設定している場合や、VPCのセグメントを後から追加した場合などは、プレフィックスリストのセグメントを確認・設定する必要があります。

その他の切り分け方法

もしVIFのBGPステータスが正常にupしており、各ネットワークリソースが正しく設定されているにも関わらず通信できない場合は、Direct Connect障害が発生している可能性もあります。
ここでは詳細は割愛しますが、以下のサービスを利用するとDirect Connect障害を検知することが可能です。

  • AWS Health Dashboard: ユーザの環境に影響を及ぼす可能性のあるAWSイベントが通知されます。
  • Amazon CloudWatch Network Synthetic Monitor: VPC内のサブネットからオンプレミスのユーザ指定IPアドレスに向けて継続的に疎通確認することで、オンプレミス・AWS間のネットワークパフォーマンスを監視できるほか、AWSの責任範囲での通信品質低下が発生していないか確認できます。

おわりに

今回は、Direct ConnectのPrivate VIFを利用したオンプレミス・AWS間ネットワークに関して、トラブル時の確認観点を紹介しました。

  • VIFのBGPステータスがupしない場合は、BGPピアに関する設定が顧客ルータとAWSコンソールで一致しているかを確認する
  • VIFのBGPステータスがupしているにも関わらず通信できない場合は、各種Gatewayやルートテーブルの設定を確認する

最後まで読んでいただきありがとうございました!
この記事がAWSのネットワークで困っている方の助けになれば幸いです。

参考

11
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
11
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?