TorqueNap LogoTorqueNap Blog
← Techに戻る

AWS Transit GatewayとDirect Connectで実現するオンプレミス接続のルーティング秘訣

2025-08-28
#AWS#Network
BGPを活用したAWSとオンプレミスのシームレスなルート交換を解説！効率的なハイブリッドネットワーク構築の鍵を掴もう！

1. 基本的な接続構成の概要

  • Direct Connect (DX):
    • オンプレミスネットワークをAWSに直接プライベート接続するためのサービス。DXでは、仮想インターフェース（VIF: Virtual Interface）を作成し、これをTGWやDirect Connect Gateway（DXGW）と関連付けます。特に、プライベートVIFやトランジットVIFがオンプレミスとのルーティングに使われます。
  • Transit Gateway (TGW):
    • AWS内のVPC、DX、VPNなどを一元的に接続するハブのようなサービス。TGWは複数のネットワークを接続し、ルートテーブルでトラフィックを管理します。
    • DX経由でオンプレミスをTGWに接続する場合、DXGWを介してTGWにアタッチメントを作成します。これにより、オンプレミスとAWS側のネットワーク（VPCなど）が相互に通信可能になります。

この構成では、静的なルート設定ではなく、BGPを使って動的にルートを交換・伝播します。これがオンプレミスのルーターにAWS側のルーティング情報（例: VPCのCIDRブロック）が伝わる鍵です。

2. BGPの役割とセッションの確立

  • BGP(Border Gateway Protocol)は、インターネットや大規模ネットワークで使用されるルーティングプロトコルで、ネットワーク間のルート情報を「広告（advertise）」し合って交換します。DXとTGWの接続では、BGPピアリングセッションが必須です。
    • オンプレミスのルーター（例: CiscoやJuniperのルーター）とAWS側のVIF（DXの仮想インターフェース）がBGPピアとして接続されます。
    • BGPセッションが確立されると、両側が互いのルート情報を交換します。AWS側はデフォルトでASN（Autonomous System Number）として7224を使用し、オンプレミス側は独自のASN（パブリックまたはプライベート）を指定します。
    • 冗長性のために、通常2つのBGPピアリングセッションを設定（アクティブ/アクティブまたはアクティブ/パッシブ）。これにより、1つのセッションがダウンしてもルーティングが継続されます。
  • TGWの場合、DXからの接続（トランジットVIF経由）がTGWにアタッチされると、BGPセッションが自動的に確立され、ルートテーブルに情報が伝播します。TGWのデフォルトルートテーブルでは、アタッチメント（DXやVPN）のルートが自動的に伝播されるようデフォルトで有効化されています。

3. ルーティング情報の伝播メカニズム

  • AWS側からオンプレミスへのルート広告:
    • TGWのルートテーブルに登録されたルート（例: 接続されたVPCのCIDR、または他のTGWアタッチメントのネットワーク範囲）が、BGP経由でDXのVIFに広告されます。
    • これがオンプレミスのルーターに伝わり、ルーターのルーティングテーブルに追加されます。例えば、AWS側のVPCが10.0.0.0/16の場合、このプレフィックスがBGPで広告され、オンプレミスルーターが「このネットワークへはDX経由でルーティングせよ」と学習します。
    • AWSはEqual-Cost Multi-Path (ECMP)ルーティングをサポートし、同じAS_PATH長のプレフィックスに対して複数のパスで負荷分散します。これにより、効率的なルーティングが可能。
  • オンプレミス側からAWSへのルート広告:
    • 逆に、オンプレミスのルーターが自ネットワークのプレフィックス（例: 192.168.0.0/16）をBGPで広告すると、TGWのルートテーブルに伝播され、AWS側のVPCなどがそれを知ります。
  • 伝播の条件と制御:
    • BGPコミュニティタグを使ってルートの優先度やスコープを制御可能。例えば、7224:7300（高優先）や7224:7100（低優先）でアクティブ/パッシブを構成。
    • Longest Prefix Match（最長プレフィックス一致）でルートを選択。より具体的なプレフィックス（例: /24）が優先されます。
    • TGWでは、ルート伝播（propagation）を有効化することで、自動的にルートが共有されます。デフォルトで有効ですが、手動で設定可能。

4. なぜオンプレミスのルーターに伝わるのか（まとめ）

  • 静的ルーティングの場合、手動でルートを追加する必要がありますが、BGPは動的であるため、ネットワークの変更（例: 新しいVPC追加）が自動的に反映されます。これが「ルーティングが伝わる」理由です。
  • トラブルシューティングのポイント: BGPセッションがアップしているか、ルート広告が正しいか、ポリシー（コミュニティタグ）が適切かを確認。AWSコンソールでBGPステータスをモニタリングできます。

この仕組みにより、ハイブリッド環境でのスケーラブルなルーティングが実現します。詳細はAWSドキュメントを参照してください。

簡易図: 全体構成とBGPルート交換の流れ

以下は、AWS側とオンプレミス側の接続を表した図です。矢印はBGPによるルート広告の方向を示しています。

aws_tgw_dx_egress

BGPルート広告の流れ:

  • AWS側 → オンプレ: VPCのCIDR (例: 10.0.0.0/16) を広告 → オンプレルーターが学習
  • オンプレ → AWS側: 自ネットワークのCIDR (例: 192.168.0.0/16) を広告 → TGWが学習

詳細説明（図に基づいて）

  1. 接続のセットアップ:

    • オンプレミスルーターとDXの仮想インターフェイス（VIF）間でBGPピアリングを確立。AWS側ASNはデフォルト7224、オンプレ側は独自のASN。
    • DXGWを介してTGWにアタッチ。これで物理的な専用線が論理的なネットワーク接続に変わる。

  2. BGPによるルート伝播:

    • TGWのルートテーブルにVPCなどのプレフィックスが登録されると、BGPでDX経由でオンプレミスルーターに「広告」される（図のAWS側→オンプレの矢印）。
    • 逆に、オンプレミスルーターが自ネットワークのルートを広告すると、TGWがそれを学習し、接続されたVPCに伝播（図のオンプレ→AWS側の矢印）。
    • これにより、手動設定なしで動的にルーティングが同期。例: 新しいVPCをTGWに追加すると、自動的にオンプレ側にルートが伝わる。

  3. なぜ伝わるのか？（メカニズムのポイント）:

    • BGPは「パスベクター」プロトコルで、ネットワークの変更を検知して自動更新。
    • TGWのデフォルト設定でルート伝播（propagation）が有効化されているため、接続されたアタッチメント間のルートが共有される。
    • 制御: BGPコミュニティタグ（例: 7224:730

以下のように追記すると自然です。トラブルシューティングの観点で「デフォルト経路が通らない」ケースとして独立した小見出しを追加すると、読者が課題に直面したときにすぐ参照できます。

5. デフォルト経路 (0.0.0.0/0) がうまく伝わらない場合

結論から言うと、受信側（オンプレミスのルーターやファイアウォール）で 0.0.0.0/0 が特別扱いされるケースが多いです。具体的には、以下のような挙動が原因になります。

  • ポリシーで拒否される: 多くのネットワークでは、BGPでのデフォルト経路受信を禁止するポリシー（prefix-listやroute-map）があらかじめ設定されています。0.0.0.0/0 は「すべての経路」を意味するため、セキュリティや運用上の理由でフィルタリングされることがあります。

  • RIB（ルーティングテーブル）に載らない: 受信はしているものの、既に静的デフォルトや他の経路が存在し、優先度（管理距離）が勝てないために 0.0.0.0/0 が採用されないことがあります。

  • ベンダ固有の制約: 一部のネットワーク機器では、BGPのデフォルト経路受信は明示的な許可が必要な場合があります。

/1 に二分割する回避策

このような場合、0.0.0.0/1 と 128.0.0.0/1 の2つに分けて広告すると、通ることが多いです。 理由は、/1 は通常の経路として扱われ、「デフォルト」という特別な扱いを受けないためです。さらに、最長一致ルールにより /1 は静的デフォルトより優先されやすく、経路選択で強くなります。