まず全体像をつかもう ── 高速道路ネットワークのたとえ

このガイドでは「高速道路ネットワーク」のたとえで一貫して説明します。まず、全体の対応関係を図で把握しましょう。

🗺️ たとえ話マップ ── ネットワーク用語 × 高速道路のたとえ 🖥️ LAN(ローカルエリアネットワーク) 建物内のPC・サーバー・プリンタを接続する社内ネットワーク 技術用語 🏙️ 街の中の一般道路 1つの街(オフィス)の中だけで使える道路。狭いけど速い。 たとえ 🌐 WAN(ワイドエリアネットワーク) 離れた拠点(LAN)同士を接続する広域ネットワーク 技術用語 🛣️ 都市間をつなぐ高速道路 街(LAN)と街(LAN)を結ぶ長距離の道路。ISPが管理。 たとえ 🏷️ MPLS(ラベルスイッチング) ラベルで経路を制御。QoS対応の高品質WAN回線(高コスト) 技術用語 🏗️ 優先レーン付き有料高速道路 重要な荷物は優先レーンで高速配送。でも料金が高い。 たとえ 💡 SD-WAN(ソフトウェア定義WAN) ソフトウェアで全回線を自動最適化。MPLS+Internet+LTEを併用 技術用語 🧠 AIカーナビ付きの全道路システム 高速・一般道・県道を全監視し、最速&最安ルートを自動選択 たとえ 🔀 AWS Transit Gateway VPC・VPN・DXを一元接続するAWSのリージョナルハブ 技術用語 🔀 巨大インターチェンジ(JCT) すべての高速道路が集まるAWSクラウド内の中央交差点 たとえ 💡 このガイドでは上記の対応関係を使い、すべての概念を「高速道路ネットワーク」で一貫して説明します

図1: たとえ話の全体対応マップ ── 技術用語と高速道路のたとえを一目で把握

WAN(ワイドエリアネットワーク)とは?

WANとは、地理的に離れたオフィスやデータセンター、クラウドアプリケーションを相互に接続するネットワーク技術です。1つの建物内に閉じた LAN を「街」に例えると、WAN は「街と街をつなぐ高速道路」です。

🛣️ たとえ話:高速道路ネットワーク

あなたの会社が東京・大阪・福岡に支社を持っていると想像してください。各支社の社内ネットワーク(LAN)は「街の中の一般道路」です。でも支社間でデータをやりとりするには「高速道路(WAN)」が必要です。この高速道路をNTTやKDDIなどの通信事業者(ISP)から借りて使うのがWANの基本構造。インターネットは世界最大のWAN── すべての国と都市をつなぐ「地球規模の高速道路ネットワーク」です。

WAN の全体像 ── 3つの都市をつなぐ高速道路ネットワーク 🏙️ 東京本社(LAN-A) = 街の中の一般道路 🖥️ 社員PC (50台) 📁 ファイル サーバー 🖨️ プリンタ 複合機 📞 IP電話 システム 🔀 ルーター 🛣️ WAN (都市間の高速道路) 専用線 / MPLS / VPN ISP が管理・提供 🏙️ 大阪支社(LAN-B) = 別の街の一般道路 🖥️ PC群 📁 サーバー 🔀 ルーター 🏙️ 福岡支社(LAN-C) = さらに別の街の道路 🖥️ PC群 📁 サーバー 🔀 ルーター WAN回線 WAN回線 WAN回線 💡 LAN = 各街の中の一般道路(高速・狭い) ┃ WAN = 街をつなぐ高速道路(広域・ISP提供) ┃ ルーター = インターチェンジの入口

図2: WANの全体像 ── 3つの支社LANを高速道路(WAN)でつなぐ構造

WANの主な用途

📞
音声・ビデオ通信
拠点間のWeb会議やIP電話をWAN経由で実現
📂
リソース共有
ファイルサーバーやアプリを全拠点で共有
☁️
クラウド接続
AWS等のクラウドへのセキュアなアクセス
💾
バックアップ
遠隔地へのデータ複製とDR

LAN と WAN の違い ── ひと目でわかる比較

🏠 LAN(ローカルエリアネットワーク) = 街の中の一般道路 📏 範囲:建物・施設内 ⚡ 速度:1〜10 Gbps 💰 コスト:低い 🔧 管理:自社で管理 📡 技術:Ethernet/Wi-Fi ⚙️ 設計:シンプル 🏠 ← 1つのオフィスの中だけ → 🏠 🌐 WAN(ワイドエリアネットワーク) = 都市間の高速道路 📏 範囲:都市間〜国際 ⚡ 速度:〜数Gbps 💰 コスト:高い 🔧 管理:ISPから借用 📡 技術:複数種の組合せ ⚙️ 設計:複雑 🏙️ ← 東京─大阪─福岡─世界中 → 🌍

図3: LAN vs WAN ── 範囲・速度・コスト・管理方式の違いを一覧比較

WAN はどのように機能しますか?── 4つの接続方式

WANには用途やコストに応じた複数の接続方式があります。ここでは主要な4方式を「高速道路のグレード」にたとえて図解します。

🛣️ たとえ話:高速道路の「グレード」

高速道路にも種類があります。①「自社専用の私道」(専用線)②「優先レーン付きの有料高速」(MPLS)③「一般道の中の暗号化トンネル」(VPN)④「AIカーナビが全道路を最適化」(SD-WAN)── 企業は用途とコストに応じて使い分けます。

4つのWAN接続方式 ── 高速道路のグレード比較 🏢 拠点A (東京) LAN 🏢 拠点B (大阪) LAN 🔒 ① 専用線(Leased Line) ISPから借りる完全専用の直接回線。他ユーザーと共有しない。 ━━━━━ 🚗 自社だけの専用道路 🚗 ━━━━━ 高コスト 高品質 低遅延 🏷️ ② MPLS(Multiprotocol Label Switching) ラベルで経路制御。優先レーンで重要トラフィックを優先配送。 🏷️ 優先レーン 🚗 一般レーン 中〜高コスト QoS対応 🚇 ③ VPN トンネリング 公衆インターネット上に暗号化トンネルを構築。低コストだが品質は不安定。 🌐 公衆インターネット(一般道) 🔐 暗号化トンネル 低コスト 品質は回線依存 💡 ④ SD-WAN(次世代 ── ソフトウェア定義WAN) 上記3つの回線を全て束ね、ソフトウェアで自動最適化。AIカーナビが最速ルートを選択。 MPLS Internet VPN LTE / 5G 🧠 SD-WAN コントローラーが自動選択 低コスト 高柔軟 クラウド対応 💡 SD-WAN は①②③のすべてを束ねる「上位概念」── MPLS の品質 + VPN のコスト効率を両立

図4: 4つのWAN接続方式 ── 高速道路のグレードに例えた視覚比較

WAN 技術の進化 ── 高速道路はどう進化したか?

WAN技術は数十年にわたり進化してきました。「道路の歴史」として振り返りましょう。

WAN 技術の進化タイムライン ── 道路の歴史 1 🛤️ フレームリレー 1990年代 初期の広域接続 = 砂利道 2 📦 ATM 1990〜2000年代 固定サイズセル転送 = 整備された国道 3 🏷️ MPLS 2000〜2010年代 ラベル制御・QoS対応 = 優先レーン高速道路 4 🚇 IPsec VPN 2000年代〜 暗号化トンネル = 一般道の専用トンネル 5 💡 SD-WAN 2015年代〜現在 ソフトウェア自動最適化 = AIカーナビ全道路 6 ☁️ AWS Cloud WAN 2022年〜 グローバルWAN管理 = 世界統合管制塔 ─────────── 💡 ハードウェア制御 → ソフトウェア制御 → クラウドネイティブ へ進化 ─────────── 💰 コスト削減 & ☁️ クラウド親和性 & 🧠 自動化 が時代と共に向上

図5: WAN技術の進化 ── フレームリレーからCloud WANまでの道のり

SD-WAN とは?── Before / After で理解する

SD-WAN(Software-Defined WAN)は、従来のMPLS中心のWANをソフトウェアで制御する次世代ネットワーク技術です。まず「従来型」と「SD-WAN」の決定的な違いを図で見てみましょう。

❌ BEFORE: 従来型WAN(MPLSベース) すべてのトラフィックが本社を経由する「ハブ&スポーク」型 🏢 本社(ハブ) ファイアウォール集約 ☁️ クラウド AWS / SaaS 🏢 支社A 大阪 🏢 支社B 福岡 MPLS MPLS ⚠️ 従来型の問題点 ❌ すべてが本社経由 → ボトルネック化 ❌ クラウドも本社経由(ヘアピンルーティング) ❌ MPLS専用線のコストが高額 ❌ 回線追加にISP工事が必要(数週間〜数ヶ月) ❌ 固定帯域 → 柔軟な配分ができない 📍たとえ:「すべての車が本社JCTを必ず通る」  → 渋滞が集中し、遠回りルートが多い  → 新しい道路を作るのに数ヶ月かかる ✅ AFTER: SD-WAN ソフトウェアが最適経路を自動選択する「メッシュ」型 🧠 SD-WANコントローラー 全拠点を一元制御 ☁️ クラウド AWS / SaaS ローカルブレイクアウト 🏢 支社A SD-WAN Edge 🏢 本社 SD-WAN Edge 🏢 支社B SD-WAN Edge メッシュ接続(直接通信) ポリシー配信 ✅ SD-WAN のメリット ✅ 複数回線(MPLS+Internet+LTE)を自動最適化 ✅ クラウドへ直接接続(ローカルブレイクアウト) ✅ コスト大幅削減(高額MPLS依存を軽減) ✅ ソフトウェアで即座に設定変更(数分) ✅ アプリ別の動的帯域制御 📍たとえ:「AIカーナビが全道路を監視し、  各車(アプリ)に最速&最安ルートを自動案内」  → 渋滞を自動回避、新ルートは即日開通  → 重要な荷物は高速道路、軽い荷物は一般道

図6: Before/After ── 従来WAN vs SD-WAN の決定的な違いを視覚比較

SD-WAN はどのように機能しますか?── 4ステップ図解

SD-WANは「コントロールプレーン」(頭脳)と「データプレーン」(実際の道路)を分離し、中央コントローラーから全拠点を一元管理します。

SD-WAN の動作 ── 4ステップで理解する仕組み Step 1: 監視 🔍 ネットワーク状態を リアルタイム監視 各エッジ装置が遅延・ パケットロス・帯域を 中央コントローラーに報告 📍 全道路の交通情報を収集 Step 2: 識別 🏷️ アプリケーションを 識別・分類 DPI等でトラフィックの 種類を判別。Web会議? ファイル転送?Web閲覧? 📍 荷物の中身を確認して仕分け Step 3: 選択 🧠 最適経路を ポリシーで決定 「Web会議→MPLS優先」 「Web閲覧→Internet」等の ポリシー+リアルタイム品質 📍 AIカーナビが最速ルート計算 Step 4: 転送 🚀 動的にトラフィック を転送 選択した経路でデータ転送。 障害・品質劣化を検知すると 自動で別経路にフェイルオーバー 📍 渋滞→自動で迂回ルートへ 🏗️ SD-WAN アーキテクチャ概要 🧠 コントロールプレーン(頭脳) 🏷️ MPLS回線 🚇 Internet VPN 📡 LTE / 5G 🔌 Direct Connect ───── データプレーン(実際の道路群) ─────

図7: SD-WANの4ステップ動作フロー ── 監視→識別→選択→転送の自動化サイクル

AWS Transit Gateway + SD-WAN ソリューション

AWS Transit GatewayはVPC・VPN・Direct Connectを一元接続するリージョナルハブです。Transit Gateway Connect Attachmentを使えば、IPsec VPN不要でSD-WANをAWSにネイティブ統合できます。

🛣️ たとえ話:AWSの巨大インターチェンジ

Transit Gatewayは「AWSクラウド内にある巨大JCT(インターチェンジ)」です。各VPC(クラウド上の街)、Direct Connect(専用高速道路)、VPN(トンネル)がすべてこのJCTに集まります。Connect Attachmentは「SD-WANのAIカーナビと直接つながる専用接続口」── GREトンネルという特別なゲートで高速接続し、従来のVPN設定が不要になります。

AWS Transit Gateway + SD-WAN ── 2つの統合パターン 🏢 オンプレミス環境 🏢 本社 SD-WAN Edge 🏢 支社 SD-WAN Edge 🧠 SD-WANコントローラー ポリシー管理・経路制御 ▼ パターン1: VPCアタッチメント経由 🌐 Internet / VPN → Appliance VPC SD-WAN仮想アプライアンスをVPCに配置 ▼ パターン2: Direct Connect経由 🔌 AWS Direct Connect 追加インフラ不要で SD-WAN を AWS へ拡張 📍 たとえで理解 パターン1 = JCT内にAIカーナビ  中継所を設置して接続 パターン2 = 既存の専用高速道路に  JCT接続口を直接追加 ☁️ AWS クラウド 🔀 Transit Gateway リージョナルネットワークハブ = AWS内の巨大JCT(インターチェンジ) VPC / VPN / DX を一元接続 SD-WAN仮想 アプライアンス Connect Attach. GRE+BGP Connect Attach. GRE+BGP VPC-A Webアプリ VPC-B DB VPC-C 共有サービス VPC-D 開発環境 VPC Attach. 📊 TGW Network Manager グローバル可視化・メトリクス・テレメトリ ⚡ Connect Attachment 仕様 • GREトンネルあたり最大 5Gbps • Connect ピア最大 4つ / アタッチメント • BGP必須(静的ルート非対応)・IPv6対応 🗺️ TGW Route Table アタッチメントごとに経路を制御 ルート伝播(Propagation)でBGP経路反映 パターン1 (VPC経由) パターン2 (DX経由) VPCアタッチメント 管理・監視通信 💡 Connect Attachment = GRE + BGP でSD-WANをTGWにネイティブ接続。IPsec VPN設定不要。

図8: AWS Transit Gateway + SD-WAN ── 2つの統合パターンの全体アーキテクチャ

Connect Attachment の主な仕様

🔗
GREトンネル対応
汎用ルーティングカプセル化(GRE)をサポート。VPN接続より高帯域パフォーマンス。
🔄
BGP動的ルーティング
BGPによる動的ルート更新とヘルスチェック。静的ルート非対応(BGP必須)。
最大5Gbps/トンネル
GREトンネルあたり最大5Gbps。複数Connectピア(最大4つ)でECMP帯域拡張。
🌍
IPv6 / MP-BGP対応
マルチプロトコルBGP拡張によるIPv6動的ルートアドバタイズをサポート。
📊
Network Manager統合
グローバルトポロジ、パフォーマンスメトリクス、テレメトリの高度な可視性。
🔧
IPsec VPN不要
従来のIPsec VPN設定なしでSD-WANをAWSに拡張。運用コスト削減。

設定コード例

# 1. Transit Gateway Connect Attachment の作成
aws ec2 create-transit-gateway-connect \
  --transport-transit-gateway-attachment-id tgw-attach-0abc123def456 \
  --options "Protocol=gre" \
  --tag-specifications 'ResourceType=transit-gateway-attachment,Tags=[{Key=Name,Value=sdwan-connect}]'

# 2. Connect ピア(GREトンネル)の作成
aws ec2 create-transit-gateway-connect-peer \
  --transit-gateway-attachment-id tgw-attach-connect-0xyz789 \
  --peer-address 10.0.1.100 \
  --transit-gateway-address 10.0.1.200 \
  --inside-cidr-blocks "169.254.100.0/29" \
  --bgp-options "PeerAsn=65000"
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  TGWConnect:
    Type: AWS::EC2::TransitGatewayConnect
    Properties:
      TransportTransitGatewayAttachmentId: !Ref VPCAttachment
      Options:
        Protocol: gre
      Tags:
        - Key: Name
          Value: sdwan-connect-attachment
  TGWConnectPeer:
    Type: AWS::EC2::TransitGatewayConnectPeer
    Properties:
      TransitGatewayAttachmentId: !Ref TGWConnect
      PeerAddress: 10.0.1.100
      TransitGatewayAddress: 10.0.1.200
      InsideCidrBlocks:
        - 169.254.100.0/29
      BgpOptions:
        PeerAsn: 65000
resource "aws_ec2_transit_gateway_connect" "sdwan" {
  transport_attachment_id = aws_ec2_transit_gateway_vpc_attachment.main.id
  protocol               = "gre"
  tags = { Name = "sdwan-connect-attachment" }
}

resource "aws_ec2_transit_gateway_connect_peer" "peer" {
  transit_gateway_attachment_id = aws_ec2_transit_gateway_connect.sdwan.id
  peer_address                 = "10.0.1.100"
  transit_gateway_address      = "10.0.1.200"
  inside_cidr_blocks           = ["169.254.100.0/29"]
  bgp_asn                      = 65000
}

どれを選ぶ?── WAN接続方式 選定フローチャート

要件に応じた最適なWAN接続方式を、フローチャートで判断しましょう。

🗺️ WAN接続方式 選定フローチャート クラウド(AWS等)を主に利用する? Yes 複数拠点を接続する必要がある? Yes AWS内VPC間接続が中心? Yes 🔀 Transit Gateway VPC一元接続ハブ No コスト最適化が最優先? Yes 💡 SD-WAN + TGW Connect 自動最適化 + AWS統合 No 最高品質&低遅延が必要? Yes 🔌 Direct Connect + MPLS 専用線で高品質接続 No 🚇 Site-to-Site VPN 低コスト・手軽な暗号化接続 No LAN / 単一拠点で十分 No 🚇 シンプルVPN / 専用線 2拠点間のP2P接続

図9: WAN接続方式の選定フローチャート ── 要件に応じた最適解を判断

BGP AS_PATH Prepending ── ルート優先度制御の仕組み

Transit Gateway Connect Attachmentや Direct ConnectではBGPが必須です。複数経路がある場合、どの経路を優先するかを制御するのがAS_PATH Prependingです。ここではBGPのルート選択メカニズムとAS_PATH Prependingの仕組みを図解します。

🛣️ たとえ話:料金所の数で「遠回りルート」を演出

BGPは「経由する料金所(AS)の数が少ないルート」を自動的に優先します。AS_PATH Prependingは、あえてスタンバイ側のルートにダミーの料金所を追加して「遠回りに見せかける」テクニックです。重要なポイント:Prependingの設定はオンプレミス側のBGPルーターで「OUT方向」に適用しますが、実際に制御されるのはAWS→オンプレミスの入方向データ通信です。オンプレミスがBGP広告でAWSに「Route Bは遠いですよ(AS_PATHが長い)」と伝え、AWSが「ならRoute Aで送ろう」と判断する仕組みです。

BGP ルート選択の優先順位

BGPは以下の順序でベストパスを決定します。上位が一致した場合のみ、次のステップで比較が行われます。

BGP ルート選択の優先順位マップ 上にあるほど優先度が高い。同一の場合のみ次のステップへ進む STEP 0 📍 最長プレフィックスマッチ(絶対優先) 最も具体的な宛先が全てに優先(例: /24 は /16 に常に勝つ) たとえ: 「東京都千代田区丸の内1丁目」は「東京都」より詳しいので優先 優先度:最高(絶対) 同一プレフィックスなら ▼ STEP 1 ⭐ Local Preference(最高値を優先) 自分側のルーターで設定 → 出方向(オンプレ→AWS)を確実に制御 たとえ: ドライバーが「ルートAを優先的に使う」と自分で設定 優先度:高 同一なら ▼ STEP 2 🔗 AS_PATH(最短を優先)← Prependingで操作! 通過するAS数が少ないルートを選択。Prependingで意図的にASを追加→優先度を下げる たとえ: 料金所が少ないルートを自動選択。ダミーの料金所を追加して「遠回りに見せる」 優先度:中 ★ 本セクション 同一なら ▼ STEP 3 📩 MED(最低値を優先) 相手ASへの「提案」値。入方向の補助的な制御に使用(採用は相手任せ) たとえ: 道路標識の「推奨ルート」表示。ドライバーが従うとは限らない 優先度:低 同一なら ▼ STEP 4+ ⚙️ Origin / eBGP優先 / Router ID 等のタイブレーク ここまで全て同一の場合の最終判定 ✓ ベストパス決定!

図A: BGPルート選択の優先順位マップ ── STEP 0が絶対優先、以降は段階的に評価

AS_PATH Prepending の仕組み ── Active/Standby の実現

2つの接続経路がある場合、スタンバイ側のBGP広告(OUT方向)でAS番号を繰り返し追加します。AWSはAS_PATHが長い経路を「遠い」と判断し、短い経路を優先── 結果としてAWS→オンプレミスの入方向データ通信がActive経路に集中します。

AS_PATH Prepending ── 入方向(AWS→オンプレ)の経路優先度を制御 ✅ Route A(Active)── AS_PATH: 65000 ── 📦 AWS→オンプレ 優先 ✓ 🏷️ 料金所 ×1 🏢 オンプレミス BGPルーター(AS 65000) ⚙️ ここでPrepending設定 ☁️ AWS TGW / Direct Connect AS 64512 🧠 AWSがベストパス選択 ─ BGP広告(通常) → AWSへ ─ ─ BGP広告(+Prepend: AS水増し) → AWSへ ─ ×3(Prependingで水増し) 🏷️ 料金所 🏷️ 料金所 🏷️ 料金所 待機 ❌ Route B(Standby)── AS_PATH: 65000 65000 65000(Prepended)── 障害時のみ使用 📖 図の読み方 ── 2つの矢印の違いを理解する 太い矢印 = 実際のデータ通信(AWS → オンプレ) AS_PATH Prependingが制御する対象。AWSがAS_PATHの短いRoute Aを優先して通信。 細い点線 = BGPルート広告(オンプレ → AWS) オンプレ側でPrepending設定をOUT方向に適用。AWSにルートを広告する際にAS番号を水増し。 💡 核心:Prependingは「オンプレのBGP広告(OUT)に設定」するが、制御されるのは「AWSからの入方向データ通信」

図B: AS_PATH Prepending ── 太い矢印がデータ通信(AWS→オンプレ)、細い点線がBGP広告(オンプレ→AWS)。設定はOUT方向だが制御対象は入方向。

方向別の制御手段 ── 出方向 vs 入方向

📤 出方向(オンプレ → AWS)の制御
  • Local Preference を使う(STEP 1)
  • ✅ 自分のルーターだけで完結 → 確実に制御可能
  • ✅ 例: VIF1=Local Pref 200(高)、VIF2=100(低)
  • 📍 たとえ: ドライバーが「この道を使う」と自分で決める
📥 入方向(AWS → オンプレ)の制御
  • AS_PATH Prepending が最も確実(STEP 2)
  • ✅ Standby側で自AS番号を2〜3回繰り返し追加
  • ⚠️ MED は補助手段(相手のポリシーに依存)
  • 📍 たとえ: ダミー料金所で「遠いルート」に見せる

⚠️ 最重要ルール:最長プレフィックスマッチは全てに優先します。/24 と /16 が同時に広告されている場合、AS_PATH の長さに関係なく /24 が常に選択されます。AS_PATH Prepending が有効なのは、同一プレフィックス長のルート間のみです。

AS_PATH Prepending の設定例

! === Active/Standby 構成の BGP 設定例 ===

router bgp 65000

 ! VIF 1(Active)── 通常設定(Prependingなし)
 neighbor 169.254.100.1 remote-as 64512

 ! VIF 2(Standby)── AS_PATH Prepending 適用
 neighbor 169.254.200.1 remote-as 64512
 neighbor 169.254.200.1 route-map PREPEND-OUT out

! route-map でAS番号を2回追加(AS_PATH長 = 3に)
route-map PREPEND-OUT permit 10
 set as-path prepend 65000 65000
# VIF 2(Standby)── AS_PATH Prepending
set protocols bgp group DX-STANDBY
  neighbor 169.254.200.1 peer-as 64512
  neighbor 169.254.200.1 export PREPEND-POLICY

set policy-options policy-statement PREPEND-POLICY
  term prepend then
    as-path-prepend "65000 65000"
    accept
# AWS側ではAS_PATH Prependingの直接設定は不可
# オンプレミス側のBGPルーターで設定する

# ただし、AWS側のルート伝播状態は確認可能:
aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id tgw-rtb-0abc123 \
  --filters "Name=type,Values=propagated"

# BGPピアの状態確認:
aws ec2 describe-transit-gateway-connect-peers \
  --transit-gateway-connect-peer-ids tgw-connect-peer-0xyz
📝 AS_PATH Prepending の試験頻出ポイント(ANS-C01)
  • 「Active/Standbyを実現するには?」→ 答えは AS_PATH Prepending。Standby側のAS_PATHを長くする。
  • 「/16と/24が同時に広告されたらどちらが選択?」→ 常に /24(最長プレフィックスマッチ)。AS_PATHに関係なく。
  • 「出方向の制御手段は?」→ Local Preference。「入方向は?」→ AS_PATH Prepending(最確実)/ MED(補助)。
  • ⚠️ ひっかけ:「AS_PATHが最優先」は誤り。Local Preferenceの方が先に評価される(STEP 1 > STEP 2)。
  • ⚠️ ひっかけ:MEDは同一隣接ASからのルート間でのみ比較される。異なるASからのルートでは比較されない(デフォルト)。

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

✅ ベストプラクティス
  • ✅ Connect Attachmentを使い、IPsec VPNを不要化して運用をシンプルに
  • ✅ BGPで動的ルーティングを構成し、障害時の自動フェイルオーバーを実現
  • ✅ 複数Connectピアを使い、ECMP(等コストマルチパス)で帯域拡張
  • ✅ Network Managerで全拠点のネットワーク状態を一元監視
  • ✅ SD-WANローカルブレイクアウトでSaaS/クラウド直接接続を活用
  • ✅ TGW Route Tableでトラフィックセグメンテーション
❌ アンチパターン
  • ❌ Connect Attachmentで静的ルートを使おうとする(BGP必須・静的ルート非対応)
  • ❌ 1つのGREトンネルで5Gbps以上のスループットを期待する
  • ❌ SD-WANなしで全トラフィックを単一VPN経由にする(ボトルネック化)
  • ❌ VPC同士を個別ピアリングで接続(TGWで一元化すべき)
  • ❌ 監視なしでSD-WAN+AWSを運用(障害検知が遅れる)
  • ❌ 全トラフィックを本社経由にする(ヘアピンルーティング)

トラブルシューティング

❓ Connect Attachment作成後、BGPセッションが確立しない
SD-WANアプライアンス側のGREトンネル設定(ソース/宛先IP)と、Inside CIDRブロックが正しいか確認。BGP ASNがConnect Peerの指定値と一致しているか確認。セキュリティグループ/NACLでGRE(プロトコル47)が許可されていることも確認。
❓ 帯域幅が期待値(5Gbps)に達しない
GREトンネルあたりの上限は5Gbps。それ以上の帯域が必要な場合は、同じConnect Attachmentに対して複数のConnect ピアを作成し、同プレフィックスをアドバタイズしてECMPで負荷分散。
❓ ルートが伝播されない
TGWのRoute Tableで、Connect Attachmentからのルート伝播(Propagation)が有効か確認。BGPのプレフィックスフィルターやルートマップが意図しないルートを除外していないかも確認。
❓ オンプレミスからAWS VPCへの通信がタイムアウトする
VPCのRoute Table → TGW Route Table → SD-WANアプライアンスのルーティング設定の順に確認。TGWルートテーブルで正しいアタッチメントに経路が向いているか、VPCサブネットルートテーブルにTGW向けルートがあるかがポイント。

試験対策ポイント(ANS-C01 / SAP-C02)

📝 ANS-C01(Advanced Networking)頻出ポイント
  • Connect Attachment = GRE + BGP:IPsec VPNとの違いを理解。Connect AttachmentはGREトンネル使用、BGP必須(静的ルート非対応)。
  • 帯域幅の制約:GREトンネルあたり最大5Gbps。5Gbps超はECMP(複数Connectピア)で対応。1アタッチメントあたり最大4ピア。
  • 2つのトランスポート:VPCアタッチメント経由 or Direct Connect経由。問題文の構成図で判断。
  • SD-WAN vs VPN:「簡素化」「コスト削減」「動的最適化」がキーワードならSD-WANが正解選択肢。
  • Network Manager:グローバルネットワーク一元監視・可視化が出題される場合の正解。
📝 SAP-C02(Solutions Architect Professional)頻出ポイント
  • ハイブリッドアーキテクチャ:「複数拠点+AWS+SD-WAN」でTransit Gatewayを中央ハブとして選択するシナリオ。
  • コスト最適化:MPLS専用線をSD-WAN+インターネットで置き換え、コスト削減と柔軟性を両立。
  • 可用性設計:複数Connectピア(ECMP)、複数AZへのSD-WANアプライアンス配置による冗長化。
  • Cloud WAN vs TGW:グローバル規模(マルチリージョン)ならCloud WAN、単一リージョン内ならTGW。
📝 試験で問われる接続方式の比較まとめ 接続方式 プロトコル ルーティング 帯域幅 ユースケース たとえ 🚇 Site-to-Site VPN IPsec 静的 or BGP 最大1.25 Gbps 少拠点・低コスト接続 一般道の暗号化トンネル 🔌 Direct Connect Ethernet (802.1Q) BGP 1/10/100 Gbps 高品質・大容量接続 専用有料高速道路 🔗 TGW Connect GRE BGP必須 5 Gbps/トンネル SD-WAN + AWS統合 JCT専用高速接続口 ☁️ Cloud WAN TGW統合管理 BGP / ポリシー マルチリージョン グローバルWAN管理 世界統合管制塔 ⚠️ 試験頻出: Connect Attachmentは「静的ルート非対応・BGP必須」を覚えておく!

図10: 試験で問われる接続方式の仕様比較 ── プロトコル・ルーティング・帯域を一覧で把握

よくある質問

インターネットは世界最大のWANです。企業が使う「WAN」は通常、インターネットの一部を借りたり(VPN)、専用回線(MPLS、専用線)を使って構築するプライベートな広域ネットワークを指します。たとえでいえば、インターネットは「世界の全道路網」、企業WANは「その中の自社専用ルート」です。

完全に不要になるとは限りません。SD-WANはMPLSの上位レイヤーとして動作し、MPLSとインターネットVPNを組み合わせて最適化します。ミッションクリティカルなアプリ向けにMPLSを維持しつつ、一般トラフィックをインターネットに分散させるハイブリッド構成が一般的です。

いいえ、Transit Gateway Connect Attachmentは静的ルートをサポートしていません。BGPによる動的ルーティングが必須です。SD-WANアプライアンス側もBGPに対応している必要があります。

Transit Gatewayはリージョン単位のネットワークハブ。Cloud WANはグローバル規模のWAN管理サービスで、複数リージョンのTransit Gatewayを一元管理します。単一リージョン内ならTGW、マルチリージョンのグローバルWANならCloud WANが適しています。

同じConnect Attachmentに複数のConnect ピア(GREトンネル)を作成し、同じプレフィックスをアドバタイズ。ECMPでトラフィックを分散。最大4ピアで理論上20Gbps(5Gbps×4)まで拡張可能です。

📋 用語チートシート
WAN
Wide Area Network。離れた拠点を接続する広域ネットワーク。= 都市間の高速道路
LAN
Local Area Network。建物内のネットワーク。= 街の中の一般道路
MPLS
ラベルベースの高品質ルーティング技術。= 優先レーン付き有料高速
SD-WAN
ソフトウェアでWANを自動最適化する次世代技術。= AIカーナビ全道路
Transit Gateway
AWSのリージョナルネットワークハブ。= 巨大JCT(インターチェンジ)
Connect Attachment
TGWとSD-WANをGRE+BGPでネイティブ接続。= JCT専用接続口
GRE
Generic Routing Encapsulation。パケットカプセル化トンネルプロトコル
BGP
Border Gateway Protocol。ネットワーク間の動的経路交換プロトコル
ECMP
Equal-Cost Multi-Path。同コストの複数経路に分散するルーティング手法
ローカルブレイクアウト
拠点から直接クラウドに接続し本社経由を回避。= 最寄りICから直接目的地へ
AS_PATH Prepending
自AS番号を繰り返し追加して経路優先度を下げるテクニック。= ダミー料金所追加
Local Preference
BGPの出方向制御。自ルーターで設定し、値が大きいルートを優先
MED
Multi-Exit Discriminator。入方向の補助制御。値が小さいルートを推奨(提案値)
最長プレフィックスマッチ
最も具体的な宛先(/24 > /16)が全BGP属性に優先する絶対ルール

Created by SSuzuki1063

AWS SAP Learning Resources