参考
- https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-aws-direct-connect-123494683
- https://aws.amazon.com/jp/directconnect/?nc=sn&loc=0
- https://d1.awsstatic.com/webinars/jp/pdf/services/20200219_BlackBelt_Onpremises_Redundancy.pdf
概要
- オンプレミス環境からAWSに対して、専用線を使用してプライベートに接続するサービス
- 一般的なインターネット接続に対して
- 安価なアウトバウンドトラフィック（AWS リージョンから AWS Direct Connect を使って送信したデータに対してのみ料金が発生）
- 安定・良好なネットワーク品質 (一般のネットワークと帯域が異なるので混雑に影響されない）
ユースケース
大規模なデータセットの使用
- Direct Connectを使用しない場合、大容量データの送信に対して、ISPへの帯域増強が必要
- 高い契約更新料
- 期間契約
― Direct Connectは、シンプルな従量課金制で一定期間の契約もなく、接続で使用したネットワークポートおよび転送したデータに対してのみの支払いのみ
リアルタイムのデータフィード
- ルーティングをユーザがコントロールできるため、一貫性のあるネットワーク体験
- 音声や動画のアプリケーションなどのネットワークの待ち時間が一定である場合に最適に機能するものに対して効果
ハイブリット環境
- プライベート接続が規制要件の場合に、活用
- ただしAWS VPNでも実施可能
物理接続
接続方法
専用接続(専有型)
- 専用線でDirect Connect Locationに接続
- 東京リージョンでは Equinix TY2(東京) / OS1(大阪) ・・・など4つ
- Connectionは 1Gbps / 10Gbps のポート速度をサポート
- 接続パターン
- Link Aggregation Group (LAG)
- Link Aggregation Control Protocol (LACP) を使用して複数の接続を 1 つの AWS Direct Connect エンドポイントに集約し、これらを 1 つのマネージド接続として扱えるようにする論理インターフェイス
- 制約
- すべての接続が専用接続
- すべての接続が同じ帯域幅
- 最大４つまで
- 同じAWS Direct Connect エンドポイントで終了
- Cloud Watch でメトリクスが扱える
- LOAの発行場所の記載
https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/lags.html
専用接続(共有型)
- Cloud Watch でメトリクスが扱えない
- LOAの発行場所の記載がなく、パートナー名が表示
ホスト接続
- Hosted Connectionと呼ぶ仮想的なConnectionをパートナーがユーザに提供
- 1Gbps以下の接続を提供する場合に利用
- 50, 100, 200, 300, 400, 500 Mbpsのいずれかの帯域を専有可能
- Hosted Connection の中のVIFを一つだけ、ユーザで自由に設定できる
- Cloud Watch でメトリクスが扱えない
- LOAの発行場所の記載がなく、パートナー名が表示
- 異なる回線サービスで冗長をとる場合、回線ごとの経路広報タイプが異なると予期せぬ経路の偏りの原因となるので注意
仮想インターフェース (Virtual Interface = VIF)
- Connection（物理接続）を通してAWSリソースにアクセスするための論理インターフェース
- AWSとユーザルータ間でBGP1ピアを確立し、経路交換するために必要
- VLAN IDを持つ
- private / public
- Private VIF: VPCへプライベートアドレスを介した接続を提供する
- Public VIF: AWSの全リージョンへパブリックIPを介した接続を提供するのがPublic VIF
接続
クロスアカウント利用
- Connection を所有すしているアカウントからほかのアカウントに対してVIFを提供することが可能
プライベート接続
- ユーザルータでBGP、MD5認証、IEEE802.1q VLANのサポートが必要
- VPC のCIDR（IPv4/v6)がAWSから広告される
- Jumbo Frame^jumboframeをサポート
- VPN接続、インターネットゲートウェイ経由のトラフィックは1500MTUに制限されてしまうので、DirectConnectが良い
Private VIFによるマルチVPC接続
- オンプレミスを複数のVPCへ接続するために複数のPrivateVIFを使用
- 複数の異なるＡＷＳアカウントのＶＰＣへオンプレミスから接続可能
- Direct Connection Location に紐づけられたリージョンのVPCのみ接続可能
オンプレミスからの接続
パブリック接続
- Public VIF を使用して中国を除く全リージョンのパブリックサービスへの接続を提供
- オンプレミスのプライベートアドレスをAWS提供のパブリックIPアドレスへNAT
- 中国を除く全リージョンのAWSサービスのパブリックIPアドレスをAWSから広告
Public VIFによるパブリックサービスへの接続
AWS Direct Connect Gateway
パートナー経由のDirect Connect
高可用性
冗長化の選択肢
https://d1.awsstatic.com/webinars/jp/pdf/services/20200219_BlackBelt_Onpremises_Redundancy.pdf
デュアルロケーション
lackbelt-directconnect-181120103042/95/aws-black-belt-online-seminar-aws-direct-connect-46-638.jpg?cb=1542709873)
複数のDirect Connectによる冗長化
- VGWは内部的に冗長化されているので冗長化の意識は不要
- 同一ロケーションの冗長化は旧来の方法。今はベストプラクティスではない
BGPパス属性を用いた経路制御
- TIPS: 一部のルーターOSでは、Graceful Restart*の機能がデフォルトで有効になっているBFDとGraceful Restartを併用すると、意図した障害検出が出来ず、切り替えに時間がかかるので、無効にしておくことを強く推奨
障害時の経路切り替え時間の短縮
コスト抑制条件に適用した冗長化
- Standbyへ切り替わり時には、通信品質の劣化を許容することも必要
- パートナーのサービスによっては、意図する経路設計が出来ない事もあるので、事前に確認が必要
- BGPのASパス属性でVPN側を優先したとしても、AWS→オンプレミス方向の通信は、必ずDirect Connectが優先される
パートナー網を経由した冗長化
Direct Connect Gatewayに対する冗長化
- 本番と開発のリソースを分ける観点から、DXGWを分けたい要望があるが、
VGWアタッチの制約で不可 - （そもそもDirectConnectGatewayは内部で冗長されている)
Transit Gatewayに対する冗長化
- TGWを分ける必要が無い理由: HyperPlane
- 大量のリソースを仮想的に分割して提供
- TIPS: TGWを分ける事で、利用するVPC CIDRごとに使う物理線を分割可能
- パートナのサービスにおいて、１つしかVPCが利用できない場合など
- パートナのサービスにおいて、１つしかVPCが利用できない場合など
障害に対する対応
ゲームデー
回復性向上
各種制限
セキュリティ
- 各アカウントで多要素認証 (MFA) を使用します。
- TLS を使用して AWS リソースと通信します。TLS 1.2 以降が推奨されています。
- AWS CloudTrail で API とユーザーアクティビティログをセットアップします。
- Amazon Macie などの高度なマネージドセキュリティサービスを使用します。これにより、Amazon S3 に保存される個人データの検出と保護が支援されます。
- コマンドラインインターフェイスまたは API を使用して AWS にアクセスするときに FIPS 140-2 検証済みの暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。
データ保護
状態監視
- AWS Direct Connect は AWS Direct Connect 接続に関する以下のメトリクスを 30 秒間隔で Amazon CloudWatch に送信
- Amazon CloudWatch は、このデータポイントを 1 分間隔または 5 分間隔に集計
Cloud Watch DX 接続メトリクス
VIFのメトリクス
使用可能なディメンション
-
BGP（Border Gateway Protocol）。パケットのあて先を正確に把握し、維持していくための経路制御技術の代表的なプロトコル。参考：https://www.nic.ad.jp/ja/newsletter/No35/0800.html ↩