🔌 AWS Direct Connect × BGP

アクティブ/パッシブ BGP接続
完全ガイド

「メイン道路」と「バックアップ道路」で安全な高速道路ネットワークを構築しよう — 物流ネットワークのたとえで理解するDirect Connect冗長化設計

🎯 最初に押さえる4つのポイント

🛣

Active/Passiveとは？

2本のDX接続を「メインルート」と「予備ルート」に分け、障害時だけ予備に切り替える冗長構成。物流の「主要高速道路」と「迂回路」の関係と同じ。

🔧

3つのBGP属性で制御

Local Preference・AS_Path・MEDの3つのBGPパス属性を使って、トラフィックの「行き」と「帰り」の両方向を制御できる。

🏷

BGP Communityで帰り道を指定

AWS側の帰りのルートは、BGP Communityタグ（7224:7100/7200/7300）で優先度を指定してコントロールする。

🛡

評価順序が最重要

AWSのルート選択順は「プレフィックス長 → Local Pref → AS_Path → MED」。この評価順序を理解すればルーティング設計が自在になる。

🚚

物流ネットワークのたとえ

Direct ConnectのActive/Passive BGP設定を、身近な「物流ネットワーク」にたとえて理解しましょう。あなたは全国展開する物流会社の配送設計担当者です。

🚚 物流のたとえ	☁ AWS用語	解説
東京配送センター	データセンター1（DC1）	オンプレミスの主要拠点。本番系ネットワークの起点。
大阪配送センター	データセンター2（DC2）	オンプレミスの副次拠点。開発系ネットワークの起点。
高速道路ルートA	DX接続1（Active）	本番系トラフィックのメインルート。常に使用される道。
高速道路ルートB	DX接続2（Passive）	障害時のバックアップルート。普段は待機状態。
中央配送ハブ	Direct Connect Gateway	すべてのDX接続を束ねる中継ハブ。BGPリフレクタとして機能。
配送先の倉庫群	VPC（本番/開発）	AWS側のネットワーク。VGWまたはTGW経由で接続。
配送指示書の優先度	BGP Local Preference	社内で「どの道を優先するか」を指定するルール。値が大きいほど優先。
経由地の数	BGP AS_Path	目的地までの経由AS数。少ないほど「近い」と判断される。
受入口の優先表示	BGP MED	外部に「この入口から入ってほしい」と伝える指標。値が小さいほど優先。
相手先への配送希望書	BGP Community	AWS側に「こちらのルートを優先してほしい」と伝える仕組み。

💡 たとえのポイント

物流ネットワークでは「東京経由で本番貨物を運び、大阪経由で開発貨物を運ぶ」と役割分担します。DXでも同様に、BGP属性を使って「どのDX接続でどのトラフィックを流すか」を明確に設計できます。障害時にはバックアップルートに自動切り替えされます。

🌱

Active/Passiveの基本概念

Active/Passive構成とは、2本以上のDirect Connect接続を用意し、通常時は1本（Active）を使い、障害時にもう1本（Passive）に自動フェイルオーバーする冗長化パターンです。

🟢

Active（メインルート）

通常時に使用されるプライマリ接続

高い優先度を設定

🔴

Passive（バックアップ）

障害時にのみ使用されるセカンダリ接続

低い優先度を設定

Active/Active vs Active/Passive

🟢 Active/Active

両方のDX接続を同時に使用
ECMP（等コストマルチパス）でロードバランシング
帯域幅を最大活用できる
同じCommunityタグ（例: 7224:7200）を両方に設定

🔴 Active/Passive

通常時は1本だけ使用
障害時にPassiveへフェイルオーバー
非対称ルーティングを回避しやすい
異なるCommunityタグ（7224:7300と7224:7100）で優先度差を設定

📍 使い分けの判断基準

「帯域が足りない → Active/Active」「セキュリティ装置の都合で非対称ルーティングを避けたい → Active/Passive」が一般的な判断基準です。ファイアウォール等のステートフルデバイスがある場合は、Active/Passiveが推奨されます。

🛠

全体アーキテクチャ図

以下は、2つのDXロケーションを使ったActive/Passive構成の全体像です。DC1からのDX接続をActive（本番系）、DC2からのDX接続をPassive（バックアップ）として構成しています。

図1: Active/Passive DX構成 — 実線がActive（メインルート）、破線がPassive（バックアップ）

🔧

3つのBGPパス属性

Active/Passive制御に使う3つのBGPパス属性を、物流ネットワークのたとえで理解しましょう。

📋

Local Preference

🚚 社内配送ルールの優先度

値が大きい＝優先

iBGPピア間（同一AS内）でのみ使用。社内で「この道を優先しなさい」と指示する仕組み。最も効果的な制御手段。

🛢

AS_Path

🚚 経由する中継地点の数

経路が短い＝優先

AS番号の連結リスト。Prependingで意図的に経路を長くして、特定パスを非優先にできる。eBGP/iBGP両方で有効。

🚩

MED

🚚 受入口の優先表示看板

値が小さい＝優先

マルチホーム環境で外部ASに「この入口を使って」と伝える指標。評価順位が低いため補助的な使用が推奨される。

⚠ Local PrefとAS_Pathの関係に注意

Local Preferenceは AS_Path よりも先に評価されます。そのため、AS_Path Prependingで制御しようとしても、Local Prefが設定されていると上書きされてしまいます。両方を組み合わせる場合は、Local Prefが最優先であることを常に意識してください。

📚

BGP経路選択の評価順序

AWSがDirect Connect経由でルーティングを決定する際の評価順序です。上位の条件が優先されます。

① 最長プレフィックス一致

➤

② Local Preference

➤

③ AS_Path長

➤

④ MED

➤

⑤ ECMP

🚨 最重要ルール：プレフィックス長が最優先！

どんなにBGP属性を調整しても、より具体的なプレフィックス（例: /25 vs /24）が広告されていれば、そちらが必ず優先されます。Active/Passive設計では、両方のDX接続で同じプレフィックス長を広告することが前提条件です。

図2: BGP Best Path評価フロー — 上位条件から順に評価、同条件ならECMP

➡

Outbound制御（オンプレミス → AWS）

Outbound制御は「物流でいえば、配送センターからどの高速道路を使って荷物を出すか」を決めることです。自社のルーター（DC1/DC2）で設定します。

方法1: Local Preferenceで制御（推奨）

社内（iBGPピア間）で「本番系は東京ルートを優先、開発系は大阪ルートを優先」と指示する方法です。最も直感的で効果的な手法です。

図3: Local Preferenceで本番/開発のOutboundを分離

方法2: AS_Path Prependingで制御

AWS側から受信したルートのAS_Pathを意図的に長くすることで、「この道は遠い」とルーターに認識させます。

ルートマップ作成

非優先にしたいプレフィックスにマッチするルートマップを定義

AS_Path Prepend

受信方向（in）でAS番号を追加し、パスを長くする

ルーター適用

eBGPネイバーにルートマップを適用して経路を制御

💡 Local Pref vs AS_Path、どちらを使う？

Local Preferenceが推奨です。理由は「BGP Best Path評価でAS_Pathより先に評価される」ため、より確実に制御できるからです。AS_Path Prependingは、Local Prefが使えない場面（eBGPピア間のみの制御など）で使うのが効果的です。

⬅

Inbound制御（AWS → オンプレミス）

Inbound制御は「AWS側から戻ってくるトラフィックがどのDX接続を通るか」を決めることです。物流にたとえると「倉庫から配送センターへの返品ルートを指定する」ようなものです。

📍 Inbound制御の特殊性

Local Preferenceは通常iBGPピア間でしか使えません。しかし、AWSはBGP Communityタグ（7224:7100/7200/7300）を受け付けることで、AWS内部のLocal Preference値を間接的に設定できる仕組みを提供しています。

BGP Communityタグによるインバウンド制御

7224:7100

Low Preference

Passive（バックアップ）接続に設定。障害時のみ使われる。

7224:7200

Medium Preference

Active/Active構成でロードバランシングしたい場合に両方に設定。

7224:7300

High Preference

Active（メイン）接続に設定。最優先で使用される。

図4: BGP Communityタグで戻りトラフィックのDX接続を制御

AS_Path Prependingによるインバウンド制御

Community以外に、自社のプレフィックスをAWSに広告する際にAS_Pathを長くすることでも制御できます。Passive側のルーターで、AWS向け広告にAS番号をPrependします。

💡 推奨：Communityタグ方式

AWS公式ドキュメントでは、BGP Communityタグ（7224:7100/7200/7300）を使う方法が最も推奨されています。Local Preferenceベースの制御を直接的に行えるため、AS_Path PrependingやMEDよりも確実に動作します。

🏷

BGP Communityタグ詳細

Private/Transit VIF用ローカルプリファレンスCommunity

Communityタグ	優先度	用途	物流のたとえ
7224:7100	Low	Passive（バックアップ）VIF	🔴 「この入口は緊急時だけ使ってください」
7224:7200	Medium	Active/Active構成の両方、またはデフォルト	🟡 「通常の受入口です」
7224:7300	High	Active（メイン）VIF	🟢 「最優先の受入口です」

Active/Passive設定パターン

🟢

Active/Passive

メインに7300、バックアップに7100

7224:7300 + 7224:7100

🟡

Active/Active

両方に同じCommunityを設定

7224:7200 + 7224:7200

⚠ Communityタグ未設定時の動作

Communityタグを設定しない場合、AWS側はDXロケーションの関連リージョンに基づいてデフォルトのLocal Preference値を割り当てます。同一リージョン内のDXロケーションはMedium（7224:7200相当）が適用されます。意図しないルーティングを避けるため、明示的にCommunityタグを設定することを推奨します。

💻

設定例

Outbound制御: Local Preference（Cisco IOS）

! DC1: 本番系を優先（LP 200）、開発系を非優先（LP 100）
ip prefix-list PROD_NETS permit 10.0.1.0/24
ip prefix-list DEV_NETS permit 10.0.2.0/24

route-map SET-LP-IBGP-DC1 permit 10
 match ip address prefix-list PROD_NETS
 set local-preference 200

route-map SET-LP-IBGP-DC1 permit 20
 match ip address prefix-list DEV_NETS
 set local-preference 100

router bgp 65000
 neighbor 192.168.1.2 remote-as 65000
 neighbor 192.168.1.2 route-map SET-LP-IBGP-DC1 out

! DC2: 開発系を優先（LP 200）、本番系を非優先（LP 100）
route-map SET-LP-IBGP-DC2 permit 10
 match ip address prefix-list PROD_NETS
 set local-preference 100

route-map SET-LP-IBGP-DC2 permit 20
 match ip address prefix-list DEV_NETS
 set local-preference 200

router bgp 65000
 neighbor 192.168.1.1 remote-as 65000
 neighbor 192.168.1.1 route-map SET-LP-IBGP-DC2 out

Inbound制御: BGP Community（Cisco IOS）

! DC1 (Active): 高優先度 Community 7224:7300 を付与して広告
ip prefix-list MY_NETS permit 172.16.1.0/24
ip prefix-list MY_NETS permit 172.16.2.0/24

route-map SET-COMM-HIGH permit 10
 match ip address prefix-list MY_NETS
 set community 7224:7300

router bgp 65000
 neighbor 169.254.254.41 remote-as 65001
 neighbor 169.254.254.41 route-map SET-COMM-HIGH out
 neighbor 169.254.254.41 send-community

! DC2 (Passive): 低優先度 Community 7224:7100 を付与して広告
route-map SET-COMM-LOW permit 10
 match ip address prefix-list MY_NETS
 set community 7224:7100

router bgp 65000
 neighbor 169.254.254.33 remote-as 65001
 neighbor 169.254.254.33 route-map SET-COMM-LOW out
 neighbor 169.254.254.33 send-community

AWS CLI: VIF作成時のBGP設定

# Private VIF（Active側）の作成
aws directconnect create-private-virtual-interface \
  --connection-id dxcon-abc12345 \
  --new-private-virtual-interface \
    virtualInterfaceName=prod-active-vif,\
    vlan=100,\
    asn=65000,\
    authKey=my-bgp-key,\
    amazonAddress=169.254.254.41/30,\
    customerAddress=169.254.254.42/30,\
    directConnectGatewayId=dxgw-abc12345

# Private VIF（Passive側）の作成
aws directconnect create-private-virtual-interface \
  --connection-id dxcon-def67890 \
  --new-private-virtual-interface \
    virtualInterfaceName=prod-passive-vif,\
    vlan=200,\
    asn=65000,\
    authKey=my-bgp-key-2,\
    amazonAddress=169.254.254.33/30,\
    customerAddress=169.254.254.34/30,\
    directConnectGatewayId=dxgw-abc12345

# CloudFormation: Active/Passive VIF構成
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  ActiveVIF:
    Type: AWS::DirectConnect::VirtualInterface
    Properties:
      ConnectionId: dxcon-abc12345
      VirtualInterfaceName: prod-active-vif
      Type: private
      Vlan: 100
      Asn: 65000
      DirectConnectGatewayId: dxgw-abc12345

  PassiveVIF:
    Type: AWS::DirectConnect::VirtualInterface
    Properties:
      ConnectionId: dxcon-def67890
      VirtualInterfaceName: prod-passive-vif
      Type: private
      Vlan: 200
      Asn: 65000
      DirectConnectGatewayId: dxgw-abc12345

✅

ベストプラクティス vs アンチパターン

✅ ベストプラクティス

異なるDXロケーションを使って冗長性を確保する
Active/PassiveにはBGP Communityタグ（7224:7300/7100）を使う
同じプレフィックス長で広告し、BGP属性で制御する
OutboundはLocal Pref、InboundはCommunityと方向別に制御手段を分ける
定期的にフェイルオーバーテストを実施する
ステートフルFWがある場合はActive/Passiveを選択する

❌ アンチパターン

同じDXロケーションに2本のDXを集約する（単一障害点）
Communityタグを設定せずにActive/Passiveを期待する
Active側だけ/24、Passive側は/25で広告する（プレフィックス長の不一致）
Local PrefとAS_Path Prependingを矛盾する設定で併用する
フェイルオーバーのテストを一度もしない
MEDだけでActive/Passiveを制御しようとする（不安定）

🚧

トラブルシューティング

🔴 Passive側にトラフィックが流れる

原因: Communityタグの設定漏れ、またはプレフィックス長の不一致

🟢 対処: Communityタグ（7224:7300/7100）が正しく設定されているか確認。両方のVIFで同じプレフィックス長を広告しているか確認。

🔴 フェイルオーバーしない

原因: BGPセッションがDown検知されていない。BFDが未設定。

🟢 対処: BFD（Bidirectional Forwarding Detection）を有効化し、障害検知を高速化する。BGP Keepalive/Holdタイマーを確認。

🔴 非対称ルーティングが発生

原因: Outbound/Inboundの制御が片方だけになっている

🟢 対処: Outbound（Local Pref）とInbound（Community）の両方を設定し、行き帰りのルートを一致させる。

🔴 Communityタグが反映されない

原因: send-community設定の欠落、または不正なCommunity値

🟢 対処: neighbor設定に「send-community」を追加。Communityタグは7224:7100/7200/7300のみ有効。

確認コマンド

! BGPテーブル確認
show ip bgp
show ip bgp 10.0.1.0/24

! Local Preference確認
show ip bgp 10.0.1.0/24 | include localpref

! Community確認
show ip bgp community

! BGPネイバー状態
show ip bgp summary
show ip bgp neighbors 169.254.254.41 advertised-routes

# VIFの状態確認
aws directconnect describe-virtual-interfaces \
  --virtual-interface-id dxvif-abc12345

# BGPピアの状態確認
aws directconnect describe-virtual-interfaces \
  --query "virtualInterfaces[].bgpPeers"

# DX接続の状態確認
aws directconnect describe-connections

📚 ANS-C01 試験対策ポイント

Q: Active/Passiveを実現するために、AWS側にトラフィック優先度を伝える方法は？

A: BGP Communityタグ（7224:7100/7200/7300）を使います。Active側のプレフィックスに7224:7300（High）、Passive側に7224:7100（Low）を設定します。これはPrivateVIFとTransitVIFの両方で使えます。

Q: Local PreferenceとAS_Pathの評価順序は？

A: 評価順序は「プレフィックス長 → Local Preference → AS_Path → MED → ECMP」です。Local PrefはAS_Pathより先に評価されるため、より確実な制御が可能です。

Q: 同一プレフィックスを複数DX接続で広告した場合、デフォルトの動作は？

A: Communityタグが未設定の場合、AWSは同一リージョン内のDXロケーションに対してデフォルトのMedium Local Preference（7224:7200相当）を適用し、ECMP（ロードバランシング）になります。

Q: ステートフルファイアウォールがある環境での推奨構成は？

A: Active/Passive構成を推奨。Active/Activeだと非対称ルーティングが発生し、ファイアウォールのセッションテーブルと不整合が起きる可能性があります。

Q: Public VIFでAS_Path Prependingを使う場合の注意点は？

A: Public VIFでAS_Path Prependingが有効なのはPublic ASN使用時のみです。Private ASNの場合、AWSがASNを7224に置き換えるため、Prependingは効果がありません。

❓

よくある質問（FAQ）

BGPのKeepalive/Holdタイマーに依存します。デフォルトではBGPのHoldタイマーは90秒ですが、BFD（Bidirectional Forwarding Detection）を有効にすると、数秒〜サブ秒で障害検知が可能になります。DXではBFDがサポートされているため、有効化を強く推奨します。

はい、どちらでも設定可能です。PrivateVIF（VGW経由）でもTransitVIF（TGW経由）でも、BGP Communityタグ、Local Preference、AS_Path Prependingによるルーティング制御が使えます。TransitVIFの場合はTGWのルーティングテーブルも合わせて設定する必要があります。

技術的には可能ですが、推奨されません。MEDはBGP評価順の中で優先度が低く（Local Pref、AS_Pathの後）、動作が不安定になる可能性があります。AWSの公式ドキュメントでもMEDよりCommunityタグの使用が推奨されています。

異なるリージョンのDXロケーションを使う場合、AWSは「トラフィック送信元に近いリージョンのDXロケーション」をデフォルトで優先します。この動作はBGP Communityタグで上書きできます。

はい、DX接続がすべてダウンした場合のバックアップとしてVPN接続を併用できます。VPNはAS_Pathが長くなるため、DX接続が利用可能な間はDXが優先されます。ただし、VPN経由のスループットはDXよりも限定的である点に注意してください。

📝 DX Active/Passive BGP チートシート

➡ Outbound制御（行き）

Local Preference: 社内ルーターで設定。値が大きい方が優先。iBGPピア間で共有。最推奨。

⬅ Inbound制御（帰り）

BGP Community: 7224:7300=High、7224:7200=Medium、7224:7100=Low。Active側にHigh、Passive側にLowを設定。

📚 評価順序

プレフィックス長 → Local Pref → AS_Path → MED → ECMP。プレフィックス長が最強。同長が前提条件。

⚠ 最重要注意

異なるプレフィックス長で広告すると、BGP属性の設定がすべて無効化される。必ず同じプレフィックス長で広告すること。

🛡 Active/Passive設定

Active: Community 7224:7300 + LP 200。Passive: Community 7224:7100 + LP 100。send-communityを忘れない。

🚧 フェイルオーバー高速化

BFD有効化でサブ秒検知。デフォルトBGPタイマー（Hold 90秒）は遅すぎる場合がある。

📖

用語集

BGP — Border Gateway Protocol。AS間のルーティングプロトコル。

AS — Autonomous System。独立管理されるネットワーク単位。

Local Pref — iBGP内での経路優先度。値が大きい方が優先。

AS_Path — 経由AS番号のリスト。短い方が優先。

MED — Multi-Exit Discriminator。外部ASへの入口優先度。値が小さい方が優先。

Community — BGPルート広告に付加する追加情報タグ。

ECMP — Equal Cost Multi-Path。等コストの複数経路でロードバランス。

BFD — Bidirectional Forwarding Detection。高速障害検知プロトコル。

DXGW — Direct Connect Gateway。複数VIFを束ねる中継ゲートウェイ。

VGW — Virtual Private Gateway。VPCのDX/VPN接続口。

TGW — Transit Gateway。複数VPC/VPN/DXを集約するハブ。

Prepending — AS番号を意図的に追加してパスを長くする手法。