[図解]AWS Direct ConnectのShared Virtual Interfacesとは

directconnect_1
109件のシェア(ちょっぴり話題の記事)

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ども、大瀧です。
本日、Direct Connectの大規模アップデート(英語ブログ/日本語ブログ)がありました。その中で機能として可視化されたのが、今回のテーマであるShared Virtual Interfacesです。"可視化"というのは、以前この構成を取るためにはメールでAWSとやり取りしなければいけなかったのが、今回のアップデートでAWS Management Consoleの画面上で構成できるようになったことを示します。

このShared Virtual Interfacesの構成自体の知名度がかなり低かった(私はAWSのフォーラムで知りました)ので、この機会に「こんな構成も組めるんだよ〜」という参考として温かい目で見てください。

Shared Virtual Interfacesとは

前段階としてDirect ConnectのVirtual Interfaceを理解しておく必要があります。まずは、Direct Connectの概要図を。

dx01_1

この図にあるように、AWS側の接続先のことをDirect ConnectではVirtual Interfaceと呼びます。最もシンプルな構成であれば、お客様ルーターとVPCは1対1、1つのVirtual Interfaceで構成します *1。冗長構成を取るのであれば、物理接続とVirtual Interfaceを2つづつ構成するという感じです。そして、複数のVPCと接続する場合は、Virtual Interfaceを増やし物理接続1本の上で、論理接続をそれぞれ確立します。

dx02_2

クラウドデザインパターンで言うと、@j3tm0t0さん作の「Hairpin dx pattern」がこれに当たります。


同じAWSアカウント内でのVPCであれば上記対応で問題ないのですが、別のAWSアカウントのVPCと接続するために今回のShared Virtual Interfacesが必要になります。

設定方法

イメージとしては、AMIやS3オブジェクトを特定のAWSアカウントに公開するのと同じです。

具体的にはVirtual Interfaceの作成時に、利用を許可するAWSアカウントIDを入力して対応します。ただし、Shared Virtual Interfacesではセキュリティを考慮しているのか、許可設定に加えて許可を確認するAcceptプロセスが必要です。Acceptプロセスでは、Virtual Interfaceを所有するAWSアカウントをオーナーアカウント、Virtual Interfaceを利用するAWSアカウントをゲストアカウントと呼びます。この区別はあくまでDirect Connect上でのものなので、AWSアカウント自体の設定に特別な区別はありませんし、他のAWSサービスに影響があるものでもありません。構成図で示すと、以下のようになります。

dx03_2

手順を以下に示します。

1. Shared Virtual Interfacesの作成

オーナーアカウントのAWS Management ConsoleのDirect Connect画面で、[Virtual Interfaces]を選択し、[Create Virtual Interface]ボタンをクリックします。

svif01

Virtual Interface画面では、物理接続(dxcon-XXXXXXXX)などの要件を選択しつつ、[Interface Owner]を[Another AWS Account]に変更し、[Account ID]にゲストアカウントのアカウントIDを入力、[Continue]で決定します。

svif02

作成したVirtual Interfaceの[State]列がpending acceptanceになっていれば、準備OKです。

svif03

2. Shared Virtual Interfacesの受け入れ(Acceptプロセス)

ゲストアカウントのDirect Connectの画面での操作を行います。Direct Connectの物理接続を持たないAWSアカウントでも、[Virtual Interfaces]の一覧にマスターアカウントが許可した、Virtual Interfaceがリストされます。▼印をクリックし、詳細を表示します。一番下に受け入れの説明が表示されるので、[understand (以下略)]のチェックボックスをオンにし、[Accept Virtual Interface]ボタンをクリックします。

svif04

すると、ゲストアカウントのVGW(VPCの仮想プライベートゲートウェイ)の選択ダイアログが表示されるので、接続したいVPCにひもづくVGWを選択します。

svif05

3. Shared Virtual Interfacesの確認

オーナーアカウントの画面を確認し、[State]列がpending acceptanceから変わっていれば完了です(pendingの場合は、接続中を指します)。

svif06

ユースケース

「こんな大掛かりな構成、どんなときに使うんだ?」と思いがちですが、Direct Connectを採用することが前提であれば、それなりに高い確率で検討することになると考えてください。

1ユーザーでAWSアカウントを分けるケースとしては、開発環境本番環境を分けるケース、アカウント毎に請求額が決まるので部署ごとプロジェクトやシステムごとに分けるケースといったものがあります。それぞれのAWSアカウントのVPCに、オンプレミス環境から安全に接続したい。。。そんなニーズ、ありそうな気がしてきませんか?

また、Direct Connectの費用は物理接続でカウントするため、論理接続およびVirtual Interfaceの追加は無償です。Direct Connectの導入が決まっているもしくは導入済みの方であれば、検討する価値アリです!

まとめ

たまたま実案件で本構成を組むためにAWSとメールでやり取りしていたら、たまたま今回のアップデートに出くわした次第です *2。実際の案件で出くわすことはレアだと思いますが、Direct Connectの設計はなかなかイメージしづらい&公開情報が少ないと思うので、何かの助けになれば幸いです。

脚注

  1. Direct Connectは、VPCへの接続以外にもう一つ、S3などインターネット上のAWSサービスにアクセスするためのPublic向け論理接続を作成することもできます。今回は割愛します。
  2. メールのやり取りが結果、無駄になったのは気にしません(滝汗)

AWS Cloud Roadshow 2017 福岡

コメントは受け付けていません。