AWS Direct Connect は何を接続するのか – Connection / VIF / DXGW / TGW の責務分界

AWS Direct Connect は、オンプレミス環境と AWS を専用線で接続するサービスです。ただし、設計上の本質は「専用線を引くこと」だけではありません。物理接続、論理インターフェース、AWS 側ゲートウェイ、BGP 経路制御を分けて理解しないと、構成図を見ても責務分界が曖昧になります。

この記事では、Direct Connect を Connection / VIF / DXGW / VGW / TGW の関係として整理します。特に、Public VIF、Private VIF、Transit VIF の違いと、Direct Connect Gateway がどこに入るのかを中心に見ていきます。

Outposts、閉域接続、ハイブリッドクラウド、クラウド側のネットワーク集約を考える場合、Direct Connect は単なる回線ではなく、クラウドとオンプレミスの責任境界をどう接続するかという設計要素になります。

まず結論

Direct Connect を読む時は、最初に次の 3 層へ分けると分かりやすくなります。

層	見る対象	役割
物理接続	Connection / LAG	オンプレミス側ルータと Direct Connect location の間にある物理的な接続単位
論理接続	Public VIF / Private VIF / Transit VIF	VLAN と BGP で分離される用途別の論理経路
AWS 側の収容先	VGW / DXGW / TGW	VPC、複数 VPC、Transit Gateway 集約へつなぐためのゲートウェイ

AWS 公式ドキュメントでも、Direct Connect を使い始めるには VIF を作成する必要があり、Private VIF、Public VIF、Transit VIF が用途別に分けられています。さらに、Direct Connect Gateway は VPC や Transit Gateway との関連付けに使われます。つまり、Direct Connect は Connection を作るだけでは完成しない ということです。

Connection は物理接続の単位

Connection は、オンプレミス側ルータと AWS Direct Connect location の間にある物理 Ethernet 接続の単位です。AWS 公式では、Direct Connect の connection には Dedicated Connection と Hosted Connection があります。Dedicated Connection は単一顧客向けの物理接続で、Hosted Connection は Direct Connect Partner が顧客向けに提供する物理接続です。

この時点では、まだ VPC に接続したわけではありません。Connection はあくまで土台です。その上に、VIF を作成して、AWS のどのリソースへ向かうのかを決めます。

項目	Dedicated Connection	Hosted Connection
提供単位	単一顧客向けの物理 Ethernet 接続	AWS Direct Connect Partner が提供する接続
代表的な帯域	1 / 10 / 100 / 400 Gbps	50 Mbps から 25 Gbps まで
契約・提供経路	AWS コンソール、CLI、API などからリクエスト	Direct Connect Partner 経由で提供
設計上の見方	自社専用の物理接続を明示的に持つ	パートナー提供の接続を使う

帯域や提供条件は変わる可能性があるため、実際の設計では最新の AWS 公式情報と Direct Connect Partner の条件を確認する必要があります。

VIF は論理接続の単位

VIF は Virtual Interface の略で、Connection または LAG の上に作成する論理インターフェースです。AWS 公式では、Direct Connect connection を使うには Private VIF、Public VIF、Transit VIF のいずれかを作成すると説明されています。

VIF では VLAN、BGP ASN、ピア IP、アドレスファミリなどを扱います。したがって、VIF は単なる画面上の設定項目ではなく、どの経路を、どの用途で、どの AWS 側ゲートウェイへ向けるかを決める論理境界です。

VIF 種別	主な接続先	用途
Public VIF	AWS public services	Amazon S3 や AWS API エンドポイントなど、AWS のパブリックサービスへ到達する
Private VIF	VGW または DXGW	VPC へプライベート IP で接続する
Transit VIF	DXGW 経由の TGW	Transit Gateway に接続された複数 VPC や VPN へ集約接続する

ここで重要なのは、同じ物理 Connection 上でも用途の違う VIF を分けて設計できることです。物理回線の本数と、論理経路の数は同じではありません。

Public VIF は AWS パブリックサービス向け

Public VIF は、AWS のパブリックサービスへ到達するための VIF です。AWS 公式ドキュメントでは、Public VIF は public IP addresses を使って AWS public services にアクセスできるものとして説明されています。

これは VPC 向けの経路とは別物です。Amazon S3 や AWS API エンドポイントへ Direct Connect 経由で到達したい場合に使うものであり、VPC のプライベートアドレスへ接続するためのものではありません。

また、Public VIF は BGP で広告する public prefix や AWS 側から広告される prefix の扱いが関係します。インターネット向けの通常経路と混同せず、AWS パブリックサービスへ向かう閉域的な経路として見る必要があります。

Private VIF は VPC 向け

Private VIF は、VPC へプライベート IP で接続するための VIF です。接続先は大きく分けて Virtual Private Gateway (VGW) または Direct Connect Gateway (DXGW) です。

単一 VPC へ素直につなぐ場合は VGW を直接使う構成が分かりやすいです。一方で、複数 VPC や複数リージョンへの拡張を考える場合は、DXGW を介した構成を検討します。

構成	見方
Private VIF → VGW	特定 VPC へ接続する素直な構成
Private VIF → DXGW → VGW	複数 VPC やリージョンを見据えて Direct Connect Gateway に集約する構成

Private VIF を TGW に直接接続する、という理解は避けた方がよいです。Transit Gateway を使う場合は、次の Transit VIF と DXGW の関係を見る必要があります。

Transit VIF は TGW 集約向け

Transit VIF は、Transit Gateway を使って複数 VPC や VPN を集約するための VIF です。ただし、設計上は Transit VIF が TGW に直接ぶら下がる と見るより、Transit VIF → DXGW → TGW と理解した方が正確です。

AWS 公式ドキュメントでも、Direct Connect Gateway を Transit Gateway に関連付け、その Direct Connect connection に対して Transit VIF を Direct Connect Gateway 向けに作成する流れとして説明されています。

接続の流れ	意味
Connection / LAG	物理的な Direct Connect 接続の土台
Transit VIF	Transit Gateway 用の論理接続
DXGW	Direct Connect と Transit Gateway の間に入る関連付け単位
TGW	複数 VPC、VPN、オンプレミス接続を集約するネットワークハブ

この関係を押さえておくと、「TGW に Direct Connect を直接つなぐ」という曖昧な表現を避けられます。Direct Connect と TGW の間には DXGW が入り、Transit VIF はその DXGW へ向かう論理接続として扱います。

DXGW はデータパス上の箱ではなく関連付けの中核

DXGW は Direct Connect Gateway の略です。AWS 公式では、Direct Connect Gateway は globally available resource であり、Direct Connect の virtual component として、distributed set of BGP route reflectors のように振る舞うと説明されています。

ここが重要です。DXGW は、物理的なネットワーク装置のように単一箇所に置かれる箱ではなく、Direct Connect と VPC / TGW / Cloud WAN などの関連付けを扱うグローバルなコンポーネントとして見る方が近いです。

• Private VIF から複数 VPC / 複数リージョンへ拡張する時に DXGW が関係する
• Transit VIF から TGW へ接続する時にも DXGW が関係する
• DXGW 自体は、単純な単一 VPC 接続だけを考える場合には必須ではない
• DXGW の allowed prefixes や association は、経路設計と責任分界に直結する

VGW・DXGW・TGW を混同しない

Direct Connect の設計で混乱しやすいのは、VGW、DXGW、TGW がどれも「ゲートウェイ」に見えることです。しかし、役割はかなり違います。

用語	正式名称	主な役割
VGW	Virtual Private Gateway	VPC 側にアタッチされるゲートウェイ。Private VIF の接続先になれる
DXGW	Direct Connect Gateway	Direct Connect と VPC / TGW などの関連付けを扱うグローバルなコンポーネント
TGW	Transit Gateway	複数 VPC、VPN、オンプレミス接続を集約するリージョナルなネットワークハブ

単一 VPC へ接続したいのか、複数 VPC を集約したいのか、複数リージョンを考えるのか、Transit Gateway を中核にしたいのか。この目的によって、どのゲートウェイを見るべきかが変わります。

Hosted Connection と Hosted VIF は別物

パートナー経由の Direct Connect では、Hosted Connection と Hosted VIF も混同しやすい用語です。Hosted Connection は、Direct Connect Partner が顧客向けに提供する接続単位です。一方 Hosted VIF は、別アカウント向けに作成する仮想インターフェースです。

AWS 公式ドキュメントでは、Hosted VIF は通常の VIF と同じように動作し、public resources または VPC に接続できると説明されています。また、Hosted Connection は 1 つの VIF のみをサポートします。

項目	Hosted Connection	Hosted VIF
何の単位か	パートナーが提供する接続そのもの	他アカウントなどに割り当てる仮想インターフェース
所有・提供の見方	Direct Connect Partner が関与する物理接続側の話	VIF の所有者・利用者を分ける話
設計上の注意	帯域、上位接続、Partner 条件を確認する	接続先、アカウント、BGP、VLAN を確認する

名前が似ているため、設計資料では「Hosted Connection なのか Hosted VIF なのか」を明確に書いた方がよいです。ここが曖昧だと、誰が何を提供し、どこから利用者の責任になるのかが読みにくくなります。

冗長化は Connection と VIF の両方で見る

Direct Connect は閉域接続のように見えるため、一本引けば安心と思われがちですが、実際の可用性設計では Connection、location、device、VIF、BGP、経路優先度を分けて見ます。AWS 公式にも Direct Connect Resiliency Toolkit があり、複数の resiliency model が用意されています。

• 物理回線を複数にするのか
• Direct Connect location を分けるのか
• オンプレミス側ルータを分けるのか
• VIF を冗長化するのか
• BGP 経路制御で active / passive や prefer path をどう扱うのか
• VPN backup を併用するのか

これは単に「Direct Connect があるか」ではなく、どの障害点を許容しない設計にするかという話です。ネットワーク設計としては、Connection の冗長性と VIF / BGP 経路の冗長性を分けて確認する必要があります。

Outposts やハイブリッドクラウドとの関係

AWS Outposts やハイブリッドクラウドを考える時、Direct Connect は単なる接続手段ではなく、クラウド側の責任境界とオンプレミス側の責任境界をつなぐ設計要素になります。

Outposts では Service Link、Local Gateway、オンプレミスネットワークとの接続、AWS リージョンとの関係が問題になります。Direct Connect を使う場合も、どこまでが AWS 側のサービス境界で、どこからが顧客側のネットワーク設計なのかを分けて考える必要があります。

これは、以前書いた クラウドという言葉の本質 や AWS だけでクラウドを理解しない という話ともつながります。クラウドは場所だけではなく、責任分界、運用モデル、接続モデルで理解する方がよいです。

実務で確認するポイント

Direct Connect の構成を見る時は、次の順番で確認すると迷いにくくなります。

確認項目	見ること
物理接続	Dedicated / Hosted、帯域、location、Partner、LAG、冗長化
VIF 種別	Public / Private / Transit のどれか
VLAN / BGP	VLAN ID、BGP ASN、peer IP、MD5、IPv4 / IPv6、advertised prefixes
AWS 側ゲートウェイ	VGW、DXGW、TGW のどこに関連付けるか
経路設計	オンプレミスから AWS、AWS からオンプレミス、複数 VPC 間、failover
責任分界	AWS、Direct Connect Partner、キャリア、顧客ルータ、顧客 LAN のどこを見るか

特に障害時は、Direct Connect 自体、Partner 側回線、顧客側ルータ、BGP、VIF、AWS 側 gateway association のどこで切れているのかを分けて見ないと、調査が長引きます。

まとめ

AWS Direct Connect は、単にオンプレミスと AWS を専用線で接続するサービスとして見ると、設計上の重要な部分を見落としやすいです。重要なのは、Connection は物理、VIF は論理、VGW / DXGW / TGW は AWS 側の収容先 と分けて読むことです。

Public VIF は AWS パブリックサービス向け、Private VIF は VPC 向け、Transit VIF は DXGW 経由で TGW 集約向けです。DXGW は単なる中継装置ではなく、Direct Connect と VPC / TGW などの関連付けを扱うグローバルなコンポーネントとして見ると理解しやすくなります。

Direct Connect を設計するということは、回線を引くことではなく、クラウドとオンプレミスの境界をどの論理経路で接続し、どの責任分界で運用するかを決めることです。

参考資料

• AWS Direct Connect dedicated and hosted connections
• AWS Direct Connect connection options
• Direct Connect virtual interfaces and hosted virtual interfaces
• Direct Connect gateways
• Direct Connect gateways and transit gateway associations
• What is AWS Transit Gateway
• AWS Direct Connect FAQ

関連記事

• AWS Outposts racks と Outposts servers は別物として評価すべき
• AWS Outposts の本質は「オンプレ AWS」ではなく、責任分界を変えるインフラである
• AWS VPC に L2 は存在しないのか – オンプレネットワーク設計者から見たクラウドネットワークの抽象化
• AWS EC2 のネットワーク帯域をどう読むか – baseline / burst / flow 制約と NFV 設計
• パブリッククラウド上で NFV 型ネットワーク機能は成立するのか