AWS / SAP-C02

セクション 01 · タスク 1.1 · SAP-C02-008

VPNと冗長ハイブリッドネットワーク

AWS Site-to-Site VPN / 仮想プライベートゲートウェイ / Transit Gateway / カスタマーゲートウェイ / BGP / Direct Connect + VPN / フェイルオーバー

このページのゴール

AWS Site-to-Site VPNを採用した後、VGW / Transit Gateway、2 トンネル、固定 / BGP、Direct Connectとの併用、ルート優先度、フェイルオーバーを一続きで設計できる状態を目指します。

VPNのAWS側終端は?
↓
2本のトンネルをどう利用する?
↓
静的 / BGP?
↓
Direct Connectも使う?
├─ バックアップが目的
└─ 暗号化が目的
↓
ルート優先順位 / 戻り経路 / 障害ドメインを確認

1. Site-to-Site VPNの構成要素

全体構造

AWS Site-to-Site VPNはAWS側の仮想プライベートゲートウェイまたはTransit Gateway、カスタマー側のカスタマーゲートウェイリソース / カスタマーゲートウェイデバイスで構成され、その間に2本のVPNトンネルが作成されます。

AWS側
→ 仮想プライベートゲートウェイ
   または
   Transit Gateway

カスタマー側
→ カスタマーゲートウェイリソース
→ カスタマーゲートウェイデバイス

VPNトンネル1
VPNトンネル2

顧客ゲートウェイ機器

カスタマーゲートウェイデバイスはオンプレミス側に存在する実際のルーター、ファイアウォール、VPNアプライアンス、ソフトウェアVPNなどです。ユーザー側で所有または管理します。

顧客ゲートウェイリソース

カスタマーゲートウェイリソースはAWS上に作成する論理リソースです。

AWS側のカスタマーゲートウェイリソース
        │
        │ 表現
        ▼
オンプレミスのカスタマーゲートウェイデバイス

AWSリソース側にはカスタマーゲートウェイデバイスのIPアドレスやBGP ASNなどの情報を登録します。カスタマーゲートウェイリソースと実機そのものを同一視しません。

2. VGW / Transit Gatewayを選ぶ

仮想プライベートゲートウェイ

仮想プライベートゲートウェイ(VGW)は、1つのVPCへアタッチするAWS側VPNエンドポイントとして利用できます。

オンプレミス
     │
     │ VPN
     ▼
仮想プライベートゲートウェイ
     │
     ▼
    VPC

Transit Gateway

多数VPCをTransit Gatewayで集約している場合は、Site-to-Site VPNをTransit Gatewayへ接続できます。

オンプレミス
     │
     │ VPN
     ▼
Transit Gateway
     │
 ┌───┼────┐
VPC-A VPC-B VPC-C

Site-to-Site VPNのAWS側ターゲットとして仮想プライベートゲートウェイまたはTransit Gatewayを利用できます。

選択基準

構成選択の方向
単一VPCへ比較的単純にVPN接続仮想プライベートゲートウェイ
多数VPCを中央接続Transit Gateway

多数VPCを中央接続するTransit Gateway設計と組み合わせます。

IPv6の差

現行仕様では、仮想プライベートゲートウェイを使用するSite-to-Site VPNはIPv6トラフィックをサポートしません。

IPv6 Site-to-Site VPN
→ Transit Gateway
   または
   AWS Cloud WAN

VPNでIPv6を使うならVGWでも同じとは考えません。

3. 2 トンネルで高可用性を作る

1 VPN 接続 = 2 トンネル

Site-to-Site VPN接続には常に2本のVPNトンネルがあります。各トンネルは異なるAWS側インフラストラクチャで終端されるため、AWSは両方を設定することを推奨しています。

トンネル1
トンネル2

両方を構成する

カスタマーゲートウェイデバイス側でトンネル1だけ設定しトンネル2を未設定にすると、AWS側のメンテナンスなどで通信断が発生する可能性があります。VPN接続を作っただけでは高可用性は完成しません。

トンネルフェイルオーバー

AWS側のトンネルエンドポイント障害やメンテナンスで1 トンネルが利用できなくなった場合、カスタマーゲートウェイ側のルーティングが適切なら利用可能なもう一方へフェイルオーバーできます。

トンネル1 ×
トンネル2 ○
   │
   ▼
トラフィック継続

4. 固定ルーティング / BGPを選ぶ

ルーティング方式

Site-to-Site VPNでは静的ルーティングまたは動的ルーティングを選択できます。動的ルーティングではBGPを使用します。

方式特徴
静的ルーティングプレフィックスを明示。BGP不要
動的ルーティングBGPで経路交換

固定ルーティング

静的ルーティングではオンプレミスCIDRをVPN接続へ明示し、BGPによる自動経路交換は行いません。カスタマーゲートウェイデバイスがBGPをサポートしない場合などに利用できます。

動的ルーティング / BGP

動的ルーティングではBGPによってAWSとカスタマーゲートウェイデバイスの間で経路を交換します。

カスタマーゲートウェイ
ASN 65000
     │
     │ BGP
     ▼
AWS側ゲートウェイ
ASN 64512等

プレフィックス広告、ルート撤回、フェイルオーバーを動的に処理しやすくなります。

各トンネルのBGP セッション

BGPを使用するSite-to-Site VPNでは、各トンネルにBGPピアリングがあります。

VPN接続

トンネル1
└─ BGPセッション

トンネル2
└─ BGPセッション

BGPとフェイルオーバー

2トンネルから経路を広告している場合、トンネル1がダウンするとそのルートが撤回され、利用可能なトンネル2のルートへ切り替えられます。静的ルーティングでもトンネルフェイルオーバーは可能ですが、大規模・冗長ネットワークではBGPが動的な経路管理に向きます。

5. VGWでDirect Connectをプライマリにする

VGWのルート選択

VGWでは、すべてのエンドポイントが正常ならまず最長プレフィックス一致が適用されます。またトンネルエンドポイントの正常性は、ほかのルーティング属性より優先されます。

つまりBGP属性上は優先でも、トンネルがダウンしていればダウンした経路を使い続けるわけではありません。

DXとVPNの優先関係

同じプレフィックスが仮想プライベートゲートウェイへDirect ConnectとSite-to-Site VPNの双方から届く場合、主な優先関係は次のとおりです。

1. Direct ConnectのBGP伝達ルート
2. VPNの静的ルート
3. VPNのBGP伝達ルート

この性質により、Direct Connectをプライマリ、BGP VPNをバックアップにする構成を作りやすくなります。

Direct Connect + VPN バックアップ

代表的なアクティブ / パッシブのハイブリッド構成です。

                プライマリ
オンプレミス ─ Direct Connect ─┐
                              │
                              ▼
                             AWS
                              ▲
オンプレミス ───── VPN ────────┘
                バックアップ

通常はDirect Connectを利用し、DX経路が失われたときVPN経路を利用します。

バックアップはルーティングまで設計する

VPNトンネルがUPでも、ルーティングポリシーによってVPNを選択できなければバックアップとして機能しません。

プライマリルート
+
バックアップルート
+
障害時のルート撤回 / 選択

まで設計します。

6. Transit GatewayでDirect Connectをプライマリにする

TGWのルート優先度

Transit Gatewayでも、まず最長プレフィックス一致で宛先ルートを選びます。同じCIDRの候補がある場合は、静的ルートが伝播ルートより優先されます。

ハイブリッド設計では、同一プレフィックスの伝播ルート同士でDirect Connect ゲートウェイ由来がSite-to-Site VPN由来より優先される関係も、DX プライマリ / VPN バックアップの設計に影響します。

最長プレフィックス一致
↓
同一CIDRなら 静的 / 伝播 を確認
↓
必要なハイブリッドルートの優先関係を確認

アタッチメント種別すべての詳細順位を暗記するのではなく、設計に必要な優先関係を判断します。

固定 VPNの落とし穴

DXGWからのルートが伝達、VPN側が静的ルートの場合、TGWでは静的ルートが優先されます。

192.168.0.0/16
→ Direct Connectゲートウェイ / 伝達ルート

192.168.0.0/16
→ Site-to-Site VPN / 静的

DXをプライマリにしたいのにVPNの静的ルートが選ばれる可能性があります。

BGP VPNを使う理由

Transit GatewayでDirect ConnectゲートウェイアタッチメントをVPNアタッチメントより優先させたい場合、BGP Site-to-Site VPNを利用しルートを伝達します。

Direct Connectゲートウェイから伝達されたルート
>
Site-to-Site VPNから伝達されたルート

同一プレフィックスでDXをプライマリにしやすくなります。

VGWとの違い

構成同一プレフィックスでDXをプライマリを作る考え方
VGWDXのBGPルートがVPNより優先
TGWBGPを使用する動的VPNを伝達しDXGWルートを優先
TGW + 静的ルーティングVPN静的ルートがDXより優先する可能性あり

7. VPN ECMPとアクティブ-アクティブ

VGWではECMPなし

仮想プライベートゲートウェイではSite-to-Site VPN接続に対するECMPはサポートされません。複数トンネルがあっても、全トンネルをECMPで帯域集約する構成ではありません。

TGWではVPN ECMPを利用可能

Transit GatewayではVPN ECMPを有効化できます。動的ルーティングを使用し、同じCIDRを同等条件で広告するトンネル間でトラフィックを分散できます。

VPNトンネルA ─┐
VPNトンネルB ─┤
VPNトンネルC ─┼─ Transit Gateway
VPNトンネルD ─┘

ECMPにはBGPが必要

Transit GatewayのVPN ECMPには動的ルーティング / BGPが必要です。静的ルーティングのVPN接続ではECMPを利用できません。

ECMPの条件

同じプレフィックスを複数VPNトンネルから広告してECMPする場合、BGP ASN、AS_PATHなどのBGP属性を等価にする必要があります。異なるASNを利用した経路間でBGPマルチパスのAS_PATH緩和は利用できません。

帯域の水平拡張

Transit Gatewayへ複数の動的ルーティングVPNを接続し、等価なBGP経路としてECMPを利用すると、複数VPNトンネルへトラフィックを分散できます。

1 トンネルの帯域幅では不足
↓
Transit Gateway
+
複数動的 VPN
+
ECMP
↓
複数トンネルを並列利用

現在は広帯域幅VPNトンネルも利用できますが、SAP-C02では具体的なGbps値の暗記より、単一トンネルの容量不足をTGW + 動的 VPN + ECMPで水平拡張できることを判断できるようにします。

複雑化とのトレードオフ

VPN ECMPで大きな帯域幅を得られても、性能の一貫性、インターネット依存、運用負荷、コストまで含めてDirect Connectと比較します。

アクティブ-アクティブ / アクティブ-パッシブ

方式意味例
アクティブ / パッシブプライマリを通常使用しバックアップは障害時のみDirect Connect + インターネットVPNをバックアップ
アクティブ / アクティブ複数経路を同時利用TGW + VPN ECMP

8. 非対称ルーティングと戻り経路

非対称ルーティング

AWSはVPNトンネルについて非対称ルーティングを許容できるようカスタマーゲートウェイデバイスを構成することを推奨しています。

往路 → トンネルA
復路 → トンネルB

ステートフルファイアウォールなどをカスタマーゲートウェイとして利用する場合は、機器側が非対称ルーティングへ対応できるか確認します。

顧客側ルーティング

AWS側でDXをプライマリ、VPNをバックアップにしても、カスタマールーター側が常にVPNを優先していれば方向によって経路が異なります。AWS → オンプレミスとオンプレミス → AWSの双方のルーティングポリシーを確認します。

9. Direct Connect + VPNの2つの目的

バックアップと暗号化を分ける

① 可用性のためのバックアップVPN

Direct Connect
→ プライマリ経路

インターネット Site-to-Site VPN
→ バックアップ経路

目的はDirect Connectとは別の障害ドメインを持つバックアップ経路を用意することです。

② Direct Connect上を暗号化するVPN

Direct Connect
→ アンダーレイ / トランスポート

プライベート IP Site-to-Site VPN
→ IPsec オーバーレイ

目的はDirect Connect上の通信をIPsecで暗号化することです。

同じ「Direct Connect + VPN」でも、可用性と暗号化では責任が異なります。

Direct Connect上のプライベートIP Site-to-Site VPN

プライベートIP Site-to-Site VPNでは、Direct Connectをアンダーレイとして利用し、その経路上にIPsec VPNをオーバーレイとして構成します。

アンダーレイ / トランスポート

顧客ゲートウェイ機器
        │
Direct Connect
        │
Transit VIF
        │
Direct Connect ゲートウェイ
        │
Transit Gateway

          +

オーバーレイ

顧客ゲートウェイ機器
        ║
        ║ IPsec トンネル
        ║
Transit Gateway

VPN トンネルエンドポイントへパブリック IPを使用せず、Direct Connect上の通信をIPsecで暗号化できます。

主目的は暗号化

Direct Connectはデフォルトでは通信内容を暗号化しません。

プライベート接続性
+
IPsec 暗号化
↓
Direct Connect上のプライベートIP Site-to-Site VPN

したがって主目的は、Direct Connectのプライベート接続性を維持しながらIPsec暗号化を追加することです。

DX バックアップではない

プライベートIP VPNはDirect Connectをアンダーレイ / トランスポートとして利用します。そのためDirect Connect経路自体を失うと、上に構成したIPsec VPNも影響を受けます。

Direct Connect上のプライベートIP VPN
↓
DX障害とは独立していない

DX障害時のバックアップが必要
↓
インターネットVPNや別DXなど
異なる障害ドメインを用意

構成要素

主に次の要素を組み合わせます。

Direct Connect
↓
Transit VIF
↓
Direct Connect ゲートウェイ
↓
Transit Gateway
↓
プライベート IP Site-to-Site VPN

仮想プライベートゲートウェイを利用するプライベート IP VPN構成ではありません。

10. 障害ドメインの確認

エンドツーエンドで分離する

Direct ConnectとバックアップインターネットVPNが同じキャリア / 物理経路へ依存していれば、共通障害で両方を失う可能性があります。

DX → キャリア A / DXロケーション A
VPN → ISP B

→ 障害ドメインを分離

確認ポイント

VPN トンネルが2本あるだけでは、エンドツーエンドで十分な冗長性があるとは限りません。共通障害が残っていないかを確認します。

確認対象例
顧客機器ルーター / ファイアウォール
アクセスネットワークISP / 通信事業者
接続Direct Connect / VPN トンネル
場所Direct Connect 場所 / AWS エンドポイント
ルーティングBGP / ルート優先度
AWS側終端VGW / Transit Gateway

一部だけを二重化しても、別の箇所に単一障害点が残れば高可用性は完成しません。

11. 混同ポイント

失敗1:VPN接続を作りトンネル1だけ設定

誤り。 2トンネル両方をカスタマーゲートウェイ側で設定します。

失敗2:カスタマーゲートウェイ = オンプレミスルーターそのもの

厳密にはAWS上のカスタマーゲートウェイリソースと実機のカスタマーゲートウェイデバイスを区別します。

失敗3:VGWでVPN ECMP

不可。 VPN ECMPはTransit Gatewayで利用します。

失敗4:TGWでVPN ECMP + 静的ルーティング

不可。 ECMPには動的ルーティング / BGPが必要です。

失敗5:TGWでDXをプライマリなのにVPNの静的ルート

静的ルートがDXGWから伝達されたルートより優先されるため、意図どおりにならない可能性があります。

失敗6:DX + プライベートIP VPN = 独立バックアップ

誤り。 VPN自体がDirect Connect上を通ります。

失敗7:VGWでIPv6 Site-to-Site VPN

不可。 IPv6トラフィックにはTransit Gatewayまたはクラウド WANを利用します。

失敗8:VPNトンネルが2本なら必ずアクティブ / アクティブ

誤り。 VGWではECMPを使えず、TGWでも動的ルーティング等の条件があります。

12. SAP-C02判断フロー

ハイブリッド VPNを設計
       │
       ▼
AWS側エンドポイントは?
       │
 ┌─────┴──────────┐
 │                │
1 VPC / IPv4    多数VPC / IPv6 / ECMP
 │                │
 ▼                ▼
VGW              TGW
       │
       ▼
2 トンネルを両方構成
       │
       ▼
ルーティングは?
       │
       ├─ 単純 / BGP不可
       │      → 固定
       │
       └─ 動的フェイルオーバー / ECMP
              → BGP
       │
       ▼
Direct Connectあり?
       │
       ├─ いいえ → VPN単独
       │
       └─ はい
            │
            ▼
VPNの目的は?
       │
 ┌─────┴─────────┐
 │               │
DX障害バックアップ      DX通信の暗号化
 │               │
インターネットVPN     Direct Connect上のプライベートIP VPN
 │               │
独立障害ドメイン     DXをアンダーレイに利用
       │
       ▼
DXをプライマリにする?
       │
       ▼
VGW / TGWそれぞれの
ルート優先度を確認
       │
       ▼
VPN帯域幅を水平拡張?
       │
       ▼
TGW + 動的 VPN + ECMP
       │
       ▼
AWS側とオンプレミス側の
両方向ルーティング / 障害ドメインを確認

13. 設計要素の比較

項目VGWTransit Gateway
主用途単一VPC VPN多数VPC中央VPN
Site-to-Site VPN○○
IPv6 VPN トラフィック×○
2トンネル○○
静的ルーティング○○
BGP○○
VPN ECMP×○
複数VPNによる帯域集約×○
Direct Connectとの組み合わせ○○
プライベートIP DX経由のVPN×○

14. まとめ

顧客ゲートウェイ機器
→ オンプレミスの実機

顧客ゲートウェイリソース
→ AWS側で機器を表現

VGW
→ 単一VPC向けの基本構成
→ VPN ECMPなし
→ Site-to-Site VPNのIPv6なし

TGW
→ 多数VPC
→ VPN ECMP
→ IPv6 VPN

Site-to-Site VPN
→ 1接続に2 トンネル
→ 両方構成

動的ルーティング
→ BGP
→ フェイルオーバー / ECMP向き

Direct Connect + インターネットVPN
→ DX障害時の独立バックアップ

Direct Connect上のプライベートIP VPN
→ DXをアンダーレイとして利用
→ IPsec 暗号化のオーバーレイ
→ DX障害の独立バックアップではない

フェイルオーバー
→ ルート優先度
→ BGP
→ 双方向ルーティング
→ 障害ドメインまで設計

最重要ポイント:冗長ハイブリッドネットワークでは、経路が複数あることではなく、障害時に期待した経路へ実際に切り替わることまで設計します。

主要AWS公式資料

理解確認

このページの内容を18問で確認します。

理解確認18問へ →