Direct Conectについて考えてみた

インフラ担当の柴田です。先日AWSの大阪オフィスでDirect Conect(DX)のハンズオンを体験してきました。 普段なかなか触れることのないDXについて学べる機会ということで楽しみにしていました。 しかし、実際にハンズオンをしてみると、スムーズにハンズオンができるように準備された状態だとSite to Site VPNの設定とあまり変わらないなという印象でした。

今回は、ハンズオンをきっかけにDXについて少し考えたことを書いてみようと思います。

Direct Conect = 専用線接続?

DXといえば「専用線によるプライベートな接続」というイメージがありますが、実はAWSは「専用接続」とか「プライベート接続」とは言ってますが「専用線」とは言っていません。 では「専用線によるプライベートな接続」って言っている人たちは間違ったことを言っているのでしょうか。実は必ずしもそうではありません。

まずは、この「専用線」というキーワードとDXについておさらいしてみましょう。

シンプルにDXを説明する時の構成図は以下のような感じで、会社から専用線でAWSに接続しているように描きます。

単純なDXの構成図、左側のお客様の会社からAWSの環境に専用線で接続する

これを、もう少し詳細に描くと以下のようになります。

少し詳細なDXの構成図、左側のお客様の会社のルーターから複数のルーターを経由する

ここで注目すべきは、会社からAWS Direct Connectロケーションのパートナー管理のルーターへの接続部分は実はDXの一部でありません。 DXは、AWS Direct Connectロケーションでお客様のネットワークとAWSのネットワークを接続し、VPCへのプライベートな通信を提供するサービスなのです。 では「専用線」と呼んでいるのは何かというと、お客様の会社からAWS Direct Connectロケーションまでの通信部分で、DXを提供しているパートナーさんが提供しているサービスになります。

Direct Connectをいつ使うの?

DXを覚えた頃は、「オンプレミスとAWSを繋ぐといえばDX!」ぐらいの勢いでおすすめをしていたのですが、最近はDXを使わなくても良いのではと考えることが増えました。 特に「安全な通信」のためにDXを使いたいという場合は、求められているのはDXではないのではと考えています。 DXが安全ではないと言っている訳ではないのですが、お客様が考える安全とかけられるコストのバランスが難しいと思っています。 DXは通信を暗号化しないため、安全ということを考えるならDXで流れる通信を暗号化するためにHTTPSやVPNを組み合わせた提案をします。そうなると、インターネット経由のHTTPS通信やSite to Site VPNでも良いのではないかと思います。 そのため最近は、オンプレミスと低いレイテンシーで安定した通信環境が欲しいという場合や、オンプレミス側のシステムにアクセスしたいという場合以外はDX最初に提案することは少なくなってきました。

まとめ

DXを使う機会があまりなかったため参加したハンズオンですが、思いがけずDXについての考えを整理する機会にもなりました。 実際DXを使う機会が少ない理由の一端は、DXを提案していないことにあるなと気づいてしまいました。