Direct Connectで繋ぐオンプレミスとAWS
はじめに
先日、AWS Direct Connectに関する勉強会に参加しました。
とても素晴らしい発表やLTばかりで、初学者の私でも理解できることが多かったので忘れないようにアウトプットとして記事を書きます。
スライドがとてもみやすかったのいくつかパクらせて頂きました。
参加したのはこちらの勉強会です。
アーカイブ動画も置いてくださってるので是非!!
概要
まず簡単に、Direct Connectはオンプレミス環境とAWSの環境を専用の回線で繋ぐサービスです。
なぜか「DC」ではなく「DX」と訳されるようです。
オンプレミスとAWSを繋ぐ
さて、オンプレミスとAWSを繋ぐにはどのような方法があるでしょうか?
大きく分けて二つあります
- インターネットを通る
- インターネットを通らない(←今回はこっち)
インターネットを通るセキュアな通信方法としては、「VPN接続」などがあります。
今回はDirect Connectについてなので、VPNについてはまた別の記事で紹介したいと思います。
Direct Connect(専用線)に必要なリソース
では、用語がたくさん出てくるので図を交えながら解説していきます。
ですが、まず分かりやすいように先に全体像を載せておきます。
意識して欲しいのは、「専用線」を引くために何が必要か?
ということを意識してみて下さい。
VGW(Virtual Private Gateway)
AWS側の接続口です。
VPCに引っ付けるやつです。
こちらはAWSのコンソール上から作成します。
Direct Connectロケーション
オンプレミスとAWSを中継するデータセンターのこと。
これは物理的なデータセンターで、パートナー企業が保有しています。
日本国内にも東京や大阪にあります。
ここにはルーターが2つ配置されています。
- AWS側のルーター
- ユーザー側のルーター(以下から選択)
- ユーザーが用意
- パートナー企業に用意してもらう
AWS側のルーターはパートナー企業が用意したものになります。
ユーザー側のルーターはユーザーで用意することもできます。
自分たちで管理することでコストの削減が可能です。
Connection
Direct Connectロケーション内のルーター同士を繋ぐもの。
異なるユーザーやサービスプロバイダ間の接続のことを「クロスコネクト」と言うそうです。
上の図のユーザールーターとAWSルーターを繋ぐ紫の線の部分です。
これはAWS側が管理をしています。
これを新たに作成するにはAWSへ申請して、お金を払って、とにかく大変です。
とりあえず今は、Connectionを作るのはかなり大変だと理解しておいて下さい。
LAG(Link Aggregation Group)
LAGは複数のConnectionを論理的に一つにまとめる仕組みです。
私はこのLAGの理解にかなり苦戦しました。
最終的に理解できたことを図にするとこうなりました。
私は何が理解できなかったのか?
Q1. Connectionが1本の線だと思っていた
Connectionは複数の物理線でユーザールーターとAWSルーターを繋いでいる。
Q2. なんのためにまとめるのか分からなかった。
まとめることで帯域幅が増える。
例えば、1本が1Gbpsだとすると2本合わせることで1Gbps+1Gbps=2Gbpsになる。
ということは、通信速度が上がるということです。
Q3. 物理線であるConnectionを論理的にまとめるという意味が分からなかった。
物理線はくっつけても1本の線にはなりません。
なぜなら粘土ではないからです。
そこで、ネットワークの流れを制御して、あたかも1本にデータが流れているかのようにできます。
その結果、Q2のメリットが得られます。
ちょっと一息
ちょっとここでひと休みついでに思い出しましょう。
Direct Connectは何をするための機能でしたか?
そうですね、「専用線」を引くためでしたね。
何でこんなことを言ったかって?
オンプレミスとVPCを繋ぐ時に、必要なのは何ですか?
1対1を繋ぐ1本の線、つまり「専用線」です。
では、先ほどのConnectionが1本だとどうなりますか?
たくさんあるオンプレミスがみんなその1本を通りますね。
それは「専用線」ですか?違いますね。
ということは専用線が複数必要です。
なのでConnectionは複数あるのです。
さらに、その1本1本では通信速度が足りない場合にLAGを使います。
では、さらにもう一歩。
オンプレミスと繋ぐVPCは1つでしょうか?
多分ですが1つ以上のケースが多いと思います(多分..)
そうなるとConnectionがたくさん必要ですね。
しかし、思い出して下さい、Connectionは用意するのが大変でしたね。
どうしましょう?
そこで出てくるのが次のVIFです。
VIF(Virtual Private InterFace)
なんでVPIじゃないんだろう...
これはConnectionの中にさらに専用線を作るイメージです。
しかし、Virtualなので仮想的に。です。
オレンジ色の線がVIFです。
VIFにはいくつか種類があります。
- プライベートVIF
- パブリックVIF
- トランジットVIF(今回は触れません)
プライベートVIF
VPCへプライペートIPで接続するための線です。
VIFとVPCは1対1の関係で、VPCへ接続する場合はプライベートVIFを使います。
ということは、上の図はプライベートVIFの図ですね。
パブリックVIF
AWSへパブリックIPで接続するための線
S3やDynamoDBなど、パブリックリソースへ接続する場合はこちら。
パブリックVIFはこんな感じです。
こっちはあんまり使うことがないみたいです。
VIFについてもう少し詳しく
今回はプライベートVIFを見ていきます。
これはConnectionに仮想的に「専用線」を作る仕組みでしたね。
図を見ていきましょう、先ほどのConnectionをさらに拡大してみます。
では、またまた私が疑問に思ったことを書きます。
Q1. VIFはどうやって作る?
AWSのコンソール画面からポチポチして作れます。
制限数以内であればいくらでも作れるようです。
ただし、これは後述するConnectionを保有しているアカウントのみが可能です。
Q2. じゃあ、VIFいっぱい作ればいいじゃん!
VIFはConnectionの帯域幅を共有します。
ということはたくさんVIFを作ると、それだけ全体の帯域幅が圧迫されますね。
あなたが大変な思いをして作ったConnectionに気軽にVIFを作られたら嫌ですよね
Connectionの接続タイプ
Connectionにはいくつかの接続タイプがあります。
これはBlack Beltの解説が非常に分かりやすいので、リンクを載せておきます。
接続タイプは3つあります
- 占有型
- ホスト型
- 共有型
それぞれ、誰がConnectionを保有しているか?が重要です。
保有者によってVIFを作る手間が違います。
では、Black Beltの記事を読んでもよく分からなかった
残念な自分のために噛み砕いて説明します。
ConnectionとVIFの関係はアパートの賃貸契約に似ています。
Connectionは大家さん
VIFは部屋です。
占有型
これは、アパートの大家(Connection)が自分自身です。
と言うことは、部屋(VIF)は自分で用意し放題ですね。
全部自分のものパターンですね。
親戚(子会社)が来たら1部屋貸してあげることもできます。
しかし、その分管理は自分でしなければなりませ。
ホスト型
大家はパートナー企業です。
そして、部屋はユーザーが買います。
これは1部屋を大家から買うパターンですね。
部屋は自分のものなので内装を作り直す(VIFを作り直す)のは自由です。
共有型
多分これが一番多いのではないでしょうか。
大家はパートナー企業です。
部屋はユーザーが借ります。
これは、部屋を買うのではなく借りるイメージです。
賃貸だと自分のものじゃないので、内装を作り直したりできないですよね。
安い分、融通が効かない感じです。
共有型の場合、VIFを新たに作成する場合は大家さんにお願いをする必要があります。
面倒ですね。
複数のVPC
では、複数のVPCを接続するにはどうすればいいでしょうか。
前述の通り、お金をたくさん払ってVIFを増やせばいいのです。
しかし、それは効率的ではありません。
実はもっといい方法があります。
このまま書くとかなり長くなりそうなので、また別の記事として書きます。
まとめ
Direct Connectは一度勉強したはずでしたが、こんなのあったっけ?と思うような内容ばかりでした。
普段触ることがないので全く覚えてなかったです。
そして個人学習では触るようなリソースでもないので、恐らくまた忘れるでしょう。
続きのGatewayの話しもまた書きます。
Discussion
素敵なアウトプットありがとうございます!!!
1点、「カスタマーゲートウェイ」はSite-to-site VPN接続の文脈で使われることが多く、Direct Connect利用時にユーザー側のデータセンターに配置するルーターを指す表現としてはもしかすると正しくないかも知れません。私も100%の自信は持てないのですが、よければご確認ください。
(DXとS2S VPN併用時にカスタマーゲートウェイを使うケースはあるようなので、少しややこしいです)
ご指摘ありがとうございます!
調べてみたところおっしゃる通り「カスタマーゲートウェイ」はSite-to-Site VPN接続で使われるものだったんですね。
不要な箇所は削除訂正させていただきました。
自分では気づけなかった部分なのですごく助かります。
ありがとうございます。
VPNも難しいですね、今度勉強してまた記事書きたいと思います。