Direct Connect（DX）について勉強したことまとめ

基本的な話

単純な専用線サービスでは無い

AWS 顧客が調達した専用線を Direct Connection ロケーション（DX ロケーション）まで持ってくれば AWS Cloud との間を接続するよ、というサービス。DX ロケーションに機器類を設置すればやってくれる

耐障害性

DX ロケーション2つ以上に対して専用線をもち、各 DX ロケーションから DX でつなぐ。これで SLA 99.9

DX ロケーション2つ以上に対して2本の専用線を持ち、各 DX ロケーションから 2 つの DX でつなぐ。これで SLA 99.99

LAG（Link Aggregation Group）

複数の接続を集約して単一の接続として扱う。
ううん・・・・・・サラマンダーより、ずっとはやい！

論理的な接続とかの話

仮想インターフェース　Virtual Interface（VIF）

物理的な接続を通して AWS にアクセスする論理インターフェース。VLAN ID を持っている。AWS とルータ間で BGP ピアを確立・経路交換するのに使うよ
プライベート・パブリック・トランジットの3種類がある。

クロスアカウントで使う

Connection を持っているアカウントが他のアカウントのそれぞれに VIF を提供することができる。通信の課金は各アカウントにされる。Connection を持つアカウントが負担するわけではない

プライベート VIF

VPC へプライベート IP を介して接続

DX ゲートウェイ（DXGW）経由で AWS に入る手法がオススメ。DXGW 経由で各 VPC の VGW につなぐ。この場合、各 VPC の CIDR が AWS から広告される。MTU 9001 もサポートするが、ルーター側で BGP, MD5認証, IEEE802.1q VLAN のサポートが必要

VGW に直に繋いでそれを経由で AWS に接続することも可能。「Cloud Hub 構成」が必要ならこれを取るのも手段だが非推奨。複数の VPC に繋ぎたい場合は複数のプライベート VIF が必要となる。各接続先毎にルーターや設定を分けたいといった場合には有効か。

パブリック VIF

AWS の全リージョンに対してパブリック IP を介して接続

中国以外の全リージョンに対してパブリックサービスでの接続が可能。オンプレミスのプライベートアドレスが Pbulic IP アドレスに NAT される。この場合、AWS から AWS のサービス対象リージョンのパブリック IP が広告される。

VIF があればプライベート VIF との併用も可能。ただ、S3 にプライベート接続ができるようになったので S3 につなぐためにこれを無理に使う必要はない（別途 Private Link 転送料必要）

トランジット VIF

Transit Gateway（TGW） 用の DX ゲートウェイへ接続

DXGW 経由で TGW に接続。この場合、広告されるのは DXGW で「許可されたプレフィックス」の CIDR のみ。MTG 8500 をサポート。プライベート VIF のみよりちょっと小さい？ この場合、VPC 側に VGW がいらない！

TGW の話

注意点あり

総じてサービス仕様をきっちり確認しような

トランジット VIF は「共有型接続」だと使えない。だが、パートナーによって「共有型接続」の表現が異なる。なので確認の際は技術窓口に問い合わせよう

パートナーによっては利用可能な経路数に上限を設けていたり、AWS のサービスクォータがあったり。今後の増減計画に配慮して決めようね

トランジット VIF と TGW のつよみ

単一リージョンで数千の VPC をアタッチできる

オンプレミス・VPC のインターネット接続を VPC につけた IGW に集約なんてことも可能

VIF と DXGW が同じ AWS である必要がある。が、それ以外の Connection や TGW、接続先 VPC はアカウントを問わない。Connection と DXGW だけ中央が管理し、接続先の TGW や VPC は各アカウント管理とかできる

DX GW

概要

単一のプライベート VIF で中国以外の全リージョンの VPC と閉域で接続

利用は無料。同一リージョンなら遅延もない

ただ、ハブめいて DXGW 経由でオンプレ間や各 VPC 間で通信できるわけではない

ポイント

最大10の VPC に DXGW から接続可能

利用料不要

アカウント・リージョン関係なく利用可能（先述の通り）

TGW と DXGW とどっちが良いんですか？

基本 TGW の方が機能が豊富。だが、1Gbps以上の接続とかホスト接続とか必要

DXGW の方が少し安いし接続要件もゆるい。互いに通信できるという TGW の利点は裏側で TGW で VPC 間を相互に繋いだりすることで別途実現も可能。こういうことをしたほうが安い場合もあるから脳死で TGW というのはいい方法ではない

パートナー

パートナー - AWS Direct Connect | AWSに一覧。

提供サービスは2種類。Connection が誰のものなのかに注意

専有型：Connection をユーザに提供。VIF はユーザが好きに設定。物理帯域（1G / 10G）を専有。帯域制御はユーザ機器で

共有型：Connection はパートナーが保持。ユーザのリクエストに応じてパートナーが VIF をユーザに払い出し。物理帯域はシェア。帯域制御・保証はパートナー毎にまちまち

AWS Direct Connect サービスデリバリープログラム

AWS による審査を受けた大容量ホスト接続を提供できるパートナー。豊富なメニューから要件にあった帯域を選択できる。おいしい

ホスト接続だと次のような作業が楽になる利点が

• VGW から DXGW に切り替える際に既存 VIF を消して新しい VIF を作成した際に DXGW に接続しなおす
• 別の DXGW に繋いで検証用 VPC に通信を切り替え

要件は先のパートナー一覧みて考えよう

ホスト接続

仮想的な Connection である Hosted Connection をパートナーが提供

Hosted Connection はパートナーが作り、ユーザが受け入れる（受け入れ手順）

VIF をその中に1つだけユーザが任意に作成・削除可能

ただ、パートナーによって VPC への経路広報のタイプが違うことがある。異なる回線サービスで冗長化する場合に予期せぬ経路偏りや冗長設計の妨げになったりするのでご注意！「会社もわけて冗長化すれば無敵だぜ！」はよくよく考えて実施しないといけない

回復とモニタリング

DX ロケーションを2つ以上に分散させる

DX ロケーションそのものを離れた場所に配置するのも Good。と東京と大阪とか

さらに DXGW の向こう側もリージョン分けておくとか

冗長構成の経路制御

VGW に複数の VIF が紐づく。これを BGP のパス属性で経路制御（雛´-`）.｡ｏＯ（これ自体は普通の話に聞こえる）

ユーザのルーターで色々制御することになる。AWS to オンプレミスの通信は「サブネットマスクが小さいルート」「BGP Local Preference Community タグ」「BGP AS Path 属性」の順で判断。どれか1つで制御したい場合は他の値は揃えようね

ルーティングポリシーと BGP コミュニティ - AWS Direct Connect

経路制御を考える

Active / Active：ゲートウェイ側で複数の DX 接続に対してトラフィックをロードバランスしてくれる。この場合、 AWS への送信 BGP ルートの AS パス長や LP コミュニティ、 MED、AWS から受信する BGP ルートに付与する LP 値を等しくしないと偏る。また、通信形態によってはトラフィックが均等じゃなくなるかもなので注意

Active / Standby：どちらかを優先するように使う。障害発生時は Standby に切り替える。AWS で Active / Standby を制御する機能はないので Standby の AS パス長を長くし、Standby 側の LP 長を短くする必要あり

DX + VPN：DX 回線を予算的に2本調達がきつい場合の選択肢。ただ、VPN と DX の性能差でパフォーマンス差が出るのでご注意。また、Active / Active の様に併用はできない点もご注意。DX が必ず優先される

非対称ルーティング

冗長構成だと行きと帰りで経路が異なることがある。避けたいならルータで設定が必要

FW を使う場合は非対称ルーティングに対応していないクラスタを使うとパケット破棄されることがあるよ！！

VPN を Standby に使う場合は非対称ルーティングは避けてレイテンシーの違いは避けておいたほうがいい

障害検知

Bidirectional Forwarding Detection（BFD）を使って障害を検知するのがオススメ。ユーザのルータで BFD パケットを使った監視をすると AWS 側でも同様の機能が有効になる。これでダウンを検知したら AWS 側でインターフェイスを止めてくれる。300msec・3回の返答が得られなかった場合にダウン検知

有効にする話は FAQ に記載あり

BFD が使えないルータの場合は BGP の keepalive / Hold Timer をチューニングしよう。AWS デバイス側はユーザのルータの設定に合わせて稼働。Holdtime は 20-30秒程度がおすすめ

Cloud Watch でモニタリング！

Cloud Watch でモニタリングできるよ！

接続のメトリクスを監視可能。Connection の状態、データ転送量・パケットレートや MAC レベルのエラー

VIF のメトリクスを監視可能。データ転送量・パケットレート

フェイルオーバーテストVIF を AWS Console からダウンさせることができるこれを用いてフェイルオーバーテストが可能設定した時間後に自動回復してくれるクォータについてユーザのルータから広告できるネットワークは100まで。これは上限開放できないのでご注意