AWS / SAP-C02

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

AWS Direct Connect設計

AWS Direct Connect / 専用接続 / ホスト接続 / 仮想インターフェイス / Direct Connectゲートウェイ / BGP / 冗長性

このページのゴール

AWS Direct Connectを採用した後、専用 / ホスト型、VIF、Direct Connect ゲートウェイ、BGP、冗長性を一続きの設計判断として選べる状態を目指します。

Direct Connectを採用
↓
専用接続 / ホスト接続
↓
接続対象からVIFを選択
↓
必要ならDirect Connectゲートウェイ
↓
VLAN + BGPでルート交換
↓
接続 / デバイス / ロケーションの障害ドメインを確認

1. Direct Connectの基本構造

AWS Direct Connectでは、オンプレミス側のルーターからDirect Connectロケーションへ接続し、その物理接続上に仮想インターフェイスを作成してAWSネットワークへ接続します。

オンプレミスルーター
        │
        │ ネットワークプロバイダー
        ▼
Direct Connectロケーション
        │
        │ Direct Connect接続
        ▼
仮想インターフェイス
        │
        ▼
AWSリソース

Direct Connect接続を作成しただけではVPC通信は完成しません。仮想インターフェイスを作成して、どのAWSネットワークへ接続するかを決めます。

2. 専用 / ホスト型の選択

接続タイプ

現行Direct Connectの主要な接続タイプは次の2種類です。

専用接続
ホスト接続

専用接続

専用接続は、顧客向けの専用物理ポートをDirect Connectロケーションで利用する方式です。

現在の主な専用ポート速度
1 Gbps / 10 Gbps / 100 Gbps / 400 Gbps

SAP-C02では速度一覧を暗記することより、高帯域・専用ポート・複数VIFが必要なら専用接続が有力と判断できることを重視します。

接続作成後にポート速度自体を変更する場合は、新しい接続を作成します。

ホスト型接続

ホスト接続はAWS Direct Connect パートナーから提供される接続です。

現在は50 Mbpsから25 Gbpsまで複数の帯域幅が提供されます。すべてのパートナーがすべての帯域幅を提供するわけではないため、利用可能な速度はパートナーとロケーションも確認します。

SAP-C02では、パートナー提供の小〜中帯域接続が必要ならホスト接続も候補と判断します。

選択基準

要件主な候補
高帯域・専用ポートが必要専用接続
同一接続で複数VIFを利用したい専用接続
Direct Connect パートナーから提供を受けたいホスト接続
25 Gbps以下の帯域でパートナー提供が要件に合うホスト接続も候補
必要帯域幅
+
専用ポートが必要か
+
複数VIFが必要か
+
パートナー提供を利用するか
↓
専用 / ホストを選択

ホスト型接続の制約

現行仕様では、1つのホスト接続につき仮想インターフェイスは1つです。一方、専用接続では複数VIFを利用できます。

1つの接続で
プライベート VIF
+
パブリック VIF
など複数VIFを利用したい
↓
ホスト型接続 1本では満たせない

帯域幅だけではなく、必要なVIF数も接続タイプの決定打になります。

専用接続と複数VIF

専用接続では1本の物理接続上に複数のVIFを作成できます。VIF数にはクォータがありますが、SAP-C02では上限値そのものより、次の差を理解することが重要です。

専用接続
→ 複数VIFを利用可能

ホスト接続
→ 1接続 = 1 VIF

具体的なクォータ値が設計条件になる場合は、最新のDirect Connectクォータを確認します。

ホスト型接続とホスト型 VIFの違い

ホスト接続はDirect Connect パートナーから提供される接続そのものです。一方、ホスト 仮想インターフェイスは別AWSアカウントへVIFを提供する仕組みです。同じ意味ではありません。

3. 接続先からVIFを選ぶ

仮想インターフェイス

Direct Connect接続をAWSで利用するためにはVIFを作成します。VIFは現在3種類です。

VIF接続対象
プライベートVIFVPCのプライベートIP
パブリックVIFAWSパブリックサービス
トランジットVIFTransit Gateway

ここはSAP-C02で非常に重要です。

プライベート VIF

プライベートVIFはVPCへプライベートIPでアクセスするために使います。

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

プライベートVIFを仮想プライベートゲートウェイへ直接接続する場合、Direct Connect接続と同じリージョン側のVPCへ接続します。

プライベート VIF + Direct Connect ゲートウェイ

複数リージョンへ拡張したい場合はDirect Connectゲートウェイを利用できます。

オンプレミス
     │
Direct Connect
     │
プライベートVIF
     │
Direct Connectゲートウェイ
     │
 ┌───┴───────┐
 ▼           ▼
VGW         VGW
│            │
VPC 東京   VPC シドニー

Direct ConnectゲートウェイはプライベートVIF経由で、同一または異なるAWSアカウント・リージョンの仮想プライベートゲートウェイを関連付けられます。

Direct Connect ゲートウェイ

Direct Connectゲートウェイはグローバルに利用できるリソースで、AWS中国リージョンを除き異なるリージョンへの接続に利用できます。またDirect Connectゲートウェイ自体はデータ経路に存在する中央ルーターではなく、分散したBGPルートリフレクターとして設計されています。

したがって、Direct Connectゲートウェイ自体の障害対策として同じものを2台作るという考え方は基本ではありません。

Direct Connect ゲートウェイとTransit Gatewayの違い

名前は似ていますが役割が異なります。

Direct Connectゲートウェイ
→ Direct ConnectとAWS側ゲートウェイを接続するための論理リソース

Transit Gateway
→ VPC / VPN等の中央ルーター

Direct Connectゲートウェイを一般的なVPC間中継ルーターとして考えません。VPC間の中央ルーティングはTransit Gatewayの役割です。

Transit VIF

多数VPCをTransit Gatewayで集約している場合はトランジットVIFを使用します。

オンプレミス
     │
Direct Connect
     │
トランジットVIF
     │
Direct Connectゲートウェイ
     │
Transit Gateway
     │
 ┌───┼────┐
VPC-A VPC-B VPC-C

Direct Connect接続をTransit Gatewayへ接続する場合、トランジットVIF + Direct Connectゲートウェイ + Transit Gatewayという構成になります。

Transit VIFと接続タイプ

トランジットVIFは専用接続 / ホスト接続のどちらでも、サポートされる帯域幅で利用できます。

Transit Gatewayを使うなら専用接続必須ではありません。

パブリック VIF

パブリックVIFは、AWSのパブリックIPを使用するパブリックサービスへDirect Connect経由でアクセスするために利用します。

  • Amazon S3 パブリックエンドポイント
  • AWS APIエンドポイント
  • パブリックEC2アドレス

パブリックVIFはインターネットトランジットではない

パブリックVIF経由ではAmazonプレフィックスを受信します。一方、Amazon以外の一般インターネットプレフィックスにはアクセスできません。

パブリックVIF ≠ 一般インターネットへのトランジット

ここは非常に重要です。

パブリック VIFのシナリオ

例えばオンプレミスのバックアップシステムからAmazon S3 パブリックエンドポイントへ、VPCのプライベートIPではなくAWSパブリックサービスへの専用経路側からアクセスしたい場合にパブリックVIFが候補になります。

オンプレミスバックアップシステム
        │
        │ Direct Connect
        ▼
     パブリックVIF
        │
        ▼
Amazon S3 パブリックエンドポイント

VIF選択の整理

要件VIF
1 VPCのプライベートIPプライベートVIF
VGW + DXGWで複数リージョンのVPCプライベートVIF
Amazon S3等AWSパブリックサービスパブリックVIF
Transit Gateway配下の多数VPCトランジットVIF

4. VLANとBGPで論理接続を完成させる

BGP

Direct Connectでは、AWSと顧客ルーター間の動的ルーティングにBGP(ボーダーゲートウェイプロトコル)を使用します。

カスタマールーター
ASN 65000
    │
    │ eBGP
    ▼
AWS側ルーター

BGPにより、オンプレミスプレフィックスをAWSへ、AWSプレフィックスをオンプレミスへ広告して経路交換します。

物理接続だけでは完成しない

物理接続がavailableでもBGPセッションがDOWNなら正常な経路交換はできません。

物理接続
+
VLAN
+
VIF
+
BGP

まで成立してDirect Connectによるルーティングが機能します。

VLAN

各VIFは802.1Q VLANを利用します。Direct Connectを利用するネットワークデバイスは802.1Q VLANカプセル化とBGPをサポートする必要があります。

物理Direct Connect接続
│
├─ VLAN 100 → プライベートVIF
├─ VLAN 200 → パブリックVIF
└─ VLAN 300 → トランジットVIF

1つの専用接続上で複数の論理接続を分離できます。

5. 現行仕様として確認する制約

IPv4 / IPv6

1つの仮想インターフェイスではBGPピアリングセッションとしてIPv4、IPv6、またはIPv4 + IPv6を使用できます。同じアドレスファミリーについて複数BGPセッションを1 VIFに作ることはできません。

BGP MD5

Direct ConnectではBGPセッションでMD5認証が有効化されます。認証キーは顧客が指定するかAWSに生成させることができます。

SAPでは設定文字列を暗記する必要はありませんが、Direct Connectのルート交換はBGPセッションとして成立することを理解します。

ルートプレフィックスクォータ

プライベート VIF / Transit VIFでは、オンプレミスからAWSへ広告できるBGPプレフィックス数にクォータがあります。

現在のデフォルト値やプレフィックス制御による拡張値はAWS公式クォータで確認できますが、SAP-C02では数字の暗記より、大量のオンプレミスプレフィックスを広告する設計ではクォータ超過によりBGPセッションへ影響し得ることを判断できるようにします。

多数のオンプレミスプレフィックスを広告
↓
VIFのルートプレフィックスクォータを確認
↓
必要なら集約 / プレフィックス制御等を検討

パブリック VIFのプレフィックス

パブリックVIFでは顧客側から最低1プレフィックスをBGP広告する必要があり、最大1,000プレフィックスです。広告するパブリックプレフィックスは顧客が所有している必要があります。

プライベート RFC1918をとりあえず広告すれば使えるというものではありません。

Direct Connect ゲートウェイとASN

トランジットVIF構成ではDirect ConnectゲートウェイとTransit Gateway双方がASNを持ちます。

重要な制約として、Transit GatewayのASNとDirect ConnectゲートウェイのASNは異なる必要があります。

例えば両方をデフォルト64512にすると関連付けに失敗します。

MACsecと接続タイプ

Direct Connect リンクそのものをレイヤー 2で暗号化する要件ではMACsecを評価します。現行仕様では、MACsecは対応する専用接続およびMACsec対応の専用接続で構成したLAGで利用できます。

ホスト型接続ではMACsecを利用できません。したがって、ホスト型接続を前提にしながら「Direct Connect物理リンクをMACsecで暗号化する」という設計は成立しません。レイヤー 2 MACsecが必須なら対応する専用接続 / LAGを選び、別レイヤーの暗号化が要件ならSite-to-Site VPNやTLS等を別途比較します。

接続MACsec判断
対応専用接続利用可能Direct Connect リンクのレイヤー 2暗号化を実装できる
対応専用接続で構成したLAG利用可能LAGを構成する接続側のMACsec対応を確認する
ホスト型接続非対応MACsec前提の設計には採用しない

6. 冗長性は障害ドメインで考える

Direct Connectの冗長性

単一Direct Connect接続は接続障害、デバイス障害、ロケーション障害の影響を受け得ます。そのためミッションクリティカル環境では複数接続を設計します。

レジリエンスツールキット

モデル設計上の意味
最大回復性複数ロケーション・複数デバイスまで障害ドメインを分離
高い回復性複数ロケーションへ接続を分散
開発とテスト同一ロケーション内でデバイス障害へ備える

SLA値を暗記するのではなく、どの障害ドメインまで耐える必要があるかでモデルを選びます。

最大 レジリエンス

最大回復性では、複数のDirect Connectロケーションと別デバイスへ接続を分散し、接続・デバイス・ロケーション障害への耐性を高めます。

ロケーションA
├─ 機器 A
└─ 機器 B

ロケーションB
├─ 機器 C
└─ 機器 D

ミッションクリティカルな要件でロケーション障害まで分離したい場合の基準になります。

高 レジリエンス

高い回復性では、複数のDirect Connectロケーションへ接続を分散します。

単一ロケーションだけに依存する構成より障害ドメインを分離できますが、必要なSLAやメンテナンス時の容量要件まで含めて最終構成を決めます。

開発とテスト

開発とテストモデルでは、同じロケーション + 別デバイス + 別接続を利用します。デバイス障害には耐えられますが、Direct Connectロケーション全体の障害には耐えられません。

接続が2本あるだけで最大回復性とは限りません。

接続数だけで判断しない

同じDirect Connectロケーションに2本あってもロケーション全体の障害で同時に失う可能性があります。

接続1 ─┐
              ├─ 同一Direct Connectロケーション
接続2 ─┘

一方、異なるロケーションへ配置すれば障害ドメインを分離できます。

接続1 → DXロケーション A

接続2 → DXロケーション B

SAPでは本数より「どこで終端しているか」まで見ることが重要です。

DXGWを増やしても物理冗長にはならない

Direct Connectゲートウェイはグローバルリソースで、データ経路の物理回線そのものではありません。そのためDirect Connectゲートウェイを2つ作っただけではファイバー、カスタマールーター、プロバイダー、Direct Connectロケーションの冗長化にはなりません。

冗長化すべきなのは実際の接続 / デバイス / ロケーションです。

マルチリージョン

1本のDirect Connect接続から別リージョンへもアクセスできます。

東京 DXロケーション
      │
      ▼
Direct Connectゲートウェイ
      │
 ┌────┴────┐
東京シドニー
VPC        VPC

別リージョンへのデータ転送には別リージョン側の料金なども考慮します。

7. 混同ポイント

失敗1:400 Gbps → ホスト接続

誤り。 ホスト接続最大は25 Gbps。400 Gbpsは専用接続です。

失敗2:ホスト接続で複数VIF

誤り。 ホスト接続で利用できるVIFは1つです。

失敗3:パブリックVIF → 一般インターネットへ接続

誤り。 パブリックVIFで到達するのはAWSパブリックプレフィックスで、一般インターネットへのトランジットではありません。

失敗4:多数VPC + Transit Gateway → プライベートVIF

基本構成ではトランジットVIF → Direct Connectゲートウェイ → Transit Gatewayを使います。

失敗5:Direct Connectゲートウェイ → VPC間中継ルーター

誤り。 VPC間中央ルーティングにはTransit Gatewayを使用します。

失敗6:物理Direct Connect接続がUP → 通信できる

VIF / VLAN / BGP / ルートまで確認します。

失敗7:TGWとDXGWへ同じASN 64512

トランジットVIF構成では関連付けに失敗します。

失敗8:DX接続を2本 → 最大回復性

デバイス / ロケーション障害ドメインまで分離されているか確認します。

8. SAP-C02判断フロー

Direct Connectを採用
        │
        ▼
接続タイプは?
        │
        ├─ 高帯域 / 専用ポート / 複数VIF
        │      → 専用接続
        │
        └─ パートナー提供 / 小〜中帯域
               → ホスト型接続も候補
        │
        ▼
接続対象は?
        │
 ┌──────┼──────────┐
 │      │          │
VPC    AWS パブリック  Transit Gateway
 │      サービス     │
 ▼      ▼           ▼
プライベートパブリック  トランジット
 VIF     VIF        VIF
 │                  │
 ▼                  ▼
VGW / DXGW         DXGW
                    │
                    ▼
                    TGW
        │
        ▼
VLAN / BGPで経路交換
        │
        ▼
ルートプレフィックスクォータは十分?
        │
        ▼
どの障害まで耐える?
        │
        ├─ 接続
        ├─ 機器
        └─ ロケーション
        │
        ▼
障害ドメインを分離

9. 設計要素の比較

項目設計判断
専用1 / 10 / 100 / 400 Gbps
ホスト50 Mbps〜25 Gbps
ホスト接続VIF 1つ
プライベートVIFVPCのプライベートIP
パブリックVIFAWSパブリックサービス
トランジットVIFTransit Gateway
Direct Connectゲートウェイマルチリージョン / VGW / TGW接続の論理ゲートウェイ
BGPAWSとオンプレミスのルート交換
最大回復性デバイス / 接続 / ロケーション障害へ対応
高い回復性複数ロケーションの2接続
開発/テスト同一ロケーション内のデバイス冗長

10. まとめ

専用接続
→ 高帯域 / 専用ポート
→ 複数VIFを利用可能

ホスト型接続
→ Direct Connect パートナー提供
→ 1接続 = 1 VIF

接続先がVPCのプライベート IP
→ プライベート VIF

AWS パブリックサービス
→ パブリック VIF

Transit Gateway
→ Transit VIF + Direct Connect ゲートウェイ

Direct Connect ゲートウェイ
→ 複数リージョンのAWS側ゲートウェイへ接続可能
→ 一般的なVPC間ルーターではない

Direct Connectのルート交換
→ VLAN + BGP

冗長性
→ 接続本数だけでなく
   機器 / ロケーションまで障害ドメインを確認

最重要ポイント:Direct Connectを採用した後は、接続タイプ → VIF → AWS側ゲートウェイ → BGP → 障害ドメインの順に設計します。

主要AWS公式資料

理解確認

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

理解確認22問へ →