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

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

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

Shared Virtual Interfacesとは

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

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

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

[slideshare id=24420364&doc=hairpindxpattern-130719070229-phpapp02]

同じ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サービスに影響があるものでもありません。構成図で示すと、以下のようになります。

手順を以下に示します。

1. Shared Virtual Interfacesの作成

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

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

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

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

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

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

3. Shared Virtual Interfacesの確認

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

ユースケース

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

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

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

まとめ

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

脚注