【実務・中級編】 AWS Direct ConnectにおけるプライベートVIFとトランジットVIFのルーティング分離 – クラウドインフラと仮想化ネットワーク実践ガイド

AWSとオンプレミス環境を専用線で結ぶ「AWS Direct Connect」は、もはや大規模インフラの血管とも言える極めて重要なコンポーネントです。しかし、いざ設計のテーブルについた途端、多くのインフラエンジニアが頭を悩ませるのが「プライベートVIF（Virtual Interface）」と「トランジットVIF」のルーティング制御の分離です。

「とりあえずBGPで全ルートを広告しておけば繋がるだろう」なんて安易な設計をしていると、本番稼働後のルートリークや、意図しないパスを通る通信によるレイテンシ増大、果てはマルチテナント間のセキュリティ境界の崩壊といった泥沼のトラブルに直結します。

今回は、数々の修羅場をくぐり抜けてきたシニアネットワークエンジニアの視点から、この2つのVIFの挙動の違い、パケットがルーターの背後でどうルーティングされているのか、そして実務で即座に使える設定の勘所を徹底的に解説していきます。

—

1. なぜプライベートVIFとトランジットVIFの分離が必要なのか？

オンプレミスのデータセンターからAWSへ専用線を引く際、物理回線（またはパートナー回線）の終端には「AWS Direct Connect接続（Connection）」が作成されます。その上で論理的な接続経路を作るのがVirtual Interface（VIF）です。

ここでよくある誤解が、「1本の専用線があれば、BGPでいい感じにルーティングをよしなにやってくれるはず」というものです。しかし、AWSのネットワーク設計において、VPCとTransit Gateway（TGW）はアーキテクチャ上のレイヤーが異なります。

プライベートVIF： 特定のVPC（最大1つ、VPCエンドポイントやVPCピアリング経由で拡張することは可能だが基本は直接的）にアタッチされたVPC・プライベートサブネットへの直接接続。
トランジットVIF： AWS Transit Gatewayにアタッチされ、複数のVPC、VPN、さらには別リージョンや別AWSアカウントへのルーティングを集約・制御するための接続。

これらを混同して単一のBGPセッションで強引にすべてのルートを返そうとすると、BGPの経路選択アルゴリズム（AS-Path長やLocal Preference）に依存した不安定なルーティングになり、障害時の切り分けが極めて困難になります。だからこそ、「どこへ向かうトラフィックを、どのVIFのどのBGPセッションに乗せるか」を明確に分離する設計が求められます。

—

2. 通信フローとルーティングの裏側

まずは、パケットがオンプレミス側のルーターからAWSへ飛び込み、目的のVPCやTGWに到達するまでのシーケンスを整理しましょう。

[オンプレミスルーター]
       │
       ├─ (BGP: AS 65001) ── [プライベートVIF] ──> [VPC (10.100.0.0/16)]
       │
       └─ (BGP: AS 65001) ── [トランジットVIF] ──> [Transit Gateway] ──> [複数のVPC / AWSサービス]

パケットの往復におけるルーティングの挙動

1. オンプレミスからの送信：
オンプレミスのアプリケーションサーバーから 10.100.10.5（VPC内のインスタンス）宛てのパケットが送出されます。オンプレミス側のルーターは、ルーティングテーブルに基づき、このパケットをプライベートVIF向けのBGPセッションで学習したAWS側のルーター（AmazonサイドのピアIP）へ送出します。
2. AWS側での受信（プライベートVIF）：
プライベートVIFはVPCのENI（Elastic Network Interface）に直接結びついているため、パケットはそのままVPC内のサブネットへと吸い込まれます。
3. トランジットVIFの場合の挙動：
もし宛先が複数のVPCにまたがる場合や、一元管理された共有サービスVPCである場合、オンプレミスルーターはトランジットVIF向けのBGPセッションで広告されたルート（例: 10.0.0.0/8 全体や各VPCのCIDR）に従ってパケットを送出します。パケットを受け取ったAWS側トランジットVIFは、Transit Gatewayのルーティングテーブルを参照し、適切なアタッチメント（VPCやVPN）へ転送します。

ここで重要なのは、プライベートVIFのBGPセッションで広報するプレフィックス（CIDR）と、トランジットVIFで広報するプレフィックスが重複しないように設計するという点です。ルートの重複や曖昧さ（Longest Matchの競合）が発生すると、非対称ルーティング（Asymmetric Routing）を引き起こし、AWS側のステートフルなファイアウォール（セキュリティグループやNACL）でパケットがドロップされる原因になります。

—

3. パラメーター設計とBGPピアリングの設定実例

実務でAWS CLIやTerraformを用いてDirect Connect環境を構築する際、必要となる主要なパラメーターとその意味を確認しておきます。

プライベートVIFとトランジットVIFの主要パラメーター比較

オンプレミス側ルーター（Cisco IOS-XE / BGP設定例）のサンプル

実務では、CiscoやJuniper、あるいはVyOSなどのルーターでBGPを設定します。以下に、プライベートVIFとトランジットVIFの双方へ向けたマルチホップまたはダイレクトなBGPピアリングのイメージ設定コードを示します。

! --- プライベートVIF用 BGP設定 (VPC直接接続) ---
router bgp 65001
 ! オンプレミス側のAS番号
 bgp router-id 192.168.100.1
 
 ! プライベートVIF側のAmazonピアIPへのネイバー定義
 neighbor 169.254.0.1 remote-as 7224
 neighbor 169.254.0.1 description "Direct Connect - Private VIF (Primary)"
 neighbor 169.254.0.1 timers 10 30
 
 address-family ipv4 unicast
  ! このVIFからは特定の基幹系VPCのCIDRのみを広告する
  network 192.168.10.0 mask 255.255.255.0
  neighbor 169.254.0.1 activate
 exit-address-family

! --- トランジットVIF用 BGP設定 (Transit Gateway接続) ---
router bgp 65001
 ! トランジットVIF側のAmazonピアIPへのネイバー定義
 neighbor 169.254.100.1 remote-as 7224
 neighbor 169.254.100.1 description "Direct Connect - Transit VIF (Primary)"
 neighbor 169.254.100.1 timers 10 30
 
 address-family ipv4 unicast
  ! トランジットVIF経由では広範囲の社内ネットワークや集約ルートを広告
  network 192.168.0.0 mask 255.255.0.0
  neighbor 169.254.100.1 activate
 exit-address-family

—

4. デバッグとトラブルシューティングの現場の知見

実務の現場で最も多いトラブルが、「BGPは確立しているのに、オンプレミスからAWSの特定インスタンスにパケットが届かない（あるいは返ってこない）」という現象です。

SREとしての経験則に基づく、迅速なデバッグ手順を公開します。

ステップ1: BGPアドバタイズメントの確認

まずは、AWS側（Amazon側のルーター）が意図したルートを正しく学習しているか、そしてオンプレミス側が正しいルートを受信しているかを確認します。AWS CLIを用いて、Direct ConnectのVIF状態をチェックします。

# プライベートVIFのBGPピア状態を確認するコマンド
aws directconnect describe-bgp-peers \
  --virtual-interface-id vif-xxxxxxxx \
  --region ap-northeast-1

返却されるJSONレスポンス内の bgpPeerState が available（または established）になっていることを確認します。もし down であれば、物理的なL1/L2（光回線やCPEのインターフェース）およびBGPパスワード、AS番号のミスマッチを疑います。

ステップ2: パケットキャプチャと経路追跡 (Traceroute)

オンプレミスの端末から次のように traceroute を実行し、パケットがどこでブラックホールに入っているかを特定します。

# パスの途中でパケットがドロップしていないか確認
traceroute -n 10.100.10.5

現象A：ルーターの次のホップ（Amazon側のピアIP）で応答が途絶える
*原因：* VPC側のルートテーブル（VGWへのルート、またはTGWへのルート）が設定されていない、あるいはSecurity GroupがICMPをブロックしている可能性。
現象B：AWSのルーターまでは届くが、目的のインスタンスにたどり着かない
*原因：* トランジットVIFの場合、Transit Gatewayのルートテーブルまたはアタッチメントの関連付け（Association/Propagation）が漏れている可能性が高いです。

—

5. まとめ：堅牢なネットワーク設計のために

AWS Direct ConnectにおけるプライベートVIFとトランジットVIFの分離は、単なる「設定の好み」ではなく、クラウド全体のセキュリティ境界とスケーラビリティを担保するための必須要件です。

1. 単一VPCへのシンプルな接続には「プライベートVIF」を割り当て、無駄なオーバーヘッドを排除する。
2. マルチVPC、マルチアカウント、あるいは将来的なグローバル展開を見据えたハブ＆スポーク構成には「トランジットVIF + Transit Gateway」を採用し、BGPの広告範囲を厳密に制御する。

この原則を理解し、ルーティングテーブルとBGPのプレフィックス設計を丁寧に行うことで、障害に強く、変更に柔軟なクラウド基盤を維持することができます。現場のネットワーク運用の参考になれば幸いです。