AWS PrivateLinkで異なるAWSアカウント間の重複するVPCレンジ間で通信してみる(その2:PrivateLink作成) #reInvent

2017.12.04

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

こんにちは!
re:Invent2017期間限定で投稿させていただいてる 久住(くすみ)です。

今回はAWS PrivateLinkの新機能である 異なるAWSアカウント間の重複したVPCレンジ同士の通信 を試す全2回の投稿の第2回として実際にPrivateLinkを作成していきたいと思います。

前回の記事はこちら
AWS PrivateLinkで異なるAWSアカウント間の重複するVPCレンジ間で通信してみる(その1:NLB作成) #reInvent

全体構成(一部更新)

Web/APを提供するサービサーアカウントへ、それを利用するユーザアカウントから通信をすることを想定し、下記の構成を作ります。

※ 前回の構成図から今回作成するPrivateLinkに関連する部分を一部更新しています。
全体構成

まずはPrivateLink作成の全体の流れについて簡単に説明します。

  1. [サービサーアカウント] NLBの作成(前回作成済)
  2. [サービサーアカウント] VPCエンドポイントサービスの作成(NLBと紐付け)
  3. [サービサーアカウント] ユーザアカウントからのアクセスを許容するホワイトリストの追加
  4. [ユーザアカウント] VPCエンドポイントの作成
  5. [サービサーアカウント] ユーザアカウントからのリクエストの承認

1.NLB作成

AWS PrivateLinkで異なるAWSアカウント間の重複するVPCレンジ間で通信してみる(その1:NLB作成) #reInvent

2.[サービサーアカウント] VPCエンドポイントサービスの作成

まずはじめにサービサーアカウント側にVPCエンドポイントサービスを作成します。

VPCからエンドポイントサービスに入り、エンドポイントサービスの作成 をクリック

エンドポイントサービス作成1

エンドポイントサービスはNetwork Load Balancer(NLB)に関連付けます。
ここでは前回作成したNLBを選択します。

エンドポイントの承諾が必要にチェック
※ チェックを入れない場合、ユーザアカウント上で エンドポイントを作成後、自動承認されます。

エンドポイントサービス作成2

作成が完了するとステータスがAvailableとなります。
詳細タブに記載されているサービス名はユーザアカウントがVPCエンドポイントを エンドポイントサービスと関連付けるために必要な項目となります。

エンドポイントサービス作成3

3.[サービサーアカウント] ユーザアカウントからのアクセスを許容するホワイトリストの追加

異なるアカウント間で通信をする場合、 ユーザアカウントのIAMやルート権限からのアクセスを許容するホワイトリストを サービサーアカウント上に追加する必要があります。 今回はユーザアカウントのルート権限を許容するホワイトリストを追加します。

エンドポイントサービスのホワイトリストに登録されたプリンシパルから ホワイトリストに登録されたアイデンティティの登録をクリック

ホワイトリスト作成1

追加するアイデンティティに「arn:aws:iam::[ユーザアカウントID]:root」を入力

ホワイトリスト作成2

4.[ユーザアカウント] VPCエンドポイントの作成

エンドポイントサービスの作成が完了したら、ユーザアカウント側でVPCエンドポイントを作成します。

ユーザアカウントにログインし、VPCのエンドポイントからエンドポイントの作成をクリック

VPCエンドポイント作成1

下記項目を入力します。

  • サービスカテゴリ:サービスを名前で検索
  • サービス名:サービサーアカウント上で作成したVPCエンドポイントサービスのサービス名
  • VPC:対象のVPC

検証をクリックしてVPCエンドポイントサービスが見つかるとサービス名が見つかりました と表示されます。

VPCエンドポイント作成2

サービサーアカウントでVPCエンドポイントサービスの作成時にエンドポイントの承諾が必要 にチェックを入れていないため、ステータスが承諾保留中(pending acceptance)の状態で表示されます。

VPCエンドポイント作成3

5.[サービサーアカウント] ユーザアカウントからのリクエストの承認

VPCエンドポイントの作成が完了したら、ユーザアカウントからの承認依頼がサービサーアカウント に飛んでいるので、リクエストの承認を実施します。

サービサーアカウント上のエンドポイントサービスに入り対象のエンドポイントを選択します。 エンドポイント接続タブにユーザアカウントからの承認依頼が来ていますので アクションのエンドポイント接続リクエストの承諾をクリック

リクエストの承認

数分待つと状態が利用可能に変わります。

リクエスト承認済み

ユーザアカウント上のVPCエンドポイントのステータスも使用可能に遷移していることが 確認できます。

VPCエンドポイント承認済み

以上でPrivateLinkの作成手順は全て完了しました。

疎通確認

それでは、ユーザアカウントからサービサーアカウントのサーバにアクセスできるか 確認してみましょう。

ユーザアカウントからのアクセスにはVPCエンドポイントのDNS名を利用します。
※プライベートDNSはサポートされていません。

$ curl http://vpce-0403d3792ac9ce794-gnoin9do.vpce-svc-0ea65532bd255b468.ap-northeast-1.vpce.amazonaws.com
<html>
<body>
<p>AWS PrivateLink TestPage</p>
<p>IP address : 172.31.23.89</p>
</body>
</html>

単純なWebページですが、VPCレンジが重複している場合でも無事サービサーの提供するサービスへアクセスできることを確認できました!

まとめ

2回に渡ってAWS PrivateLinkを使った異なるAWSアカウントの重複したVPCレンジ間の 通信を試してみました。

発表でも「It's a big deal(これはすごいことだ)!」と言ってたのですが、その時はあまり実感がわきませんでした。 実際に試してみると今後のサービスの提供形態に大きなインパクトを与える新機能だと感じます。
※実際に複数のサービサーがPrivateLinkの新機能に対応しているようです。

また、NLBを使っていることでDX経由でオンプレミスにあるサービスへのアクセスを提供することも 可能となるということも一つの大きな特徴ではないでしょうか。

最後に

計4回の投稿に渡ってゲスト投稿をさせて頂きましたが、 re:Invent2017も(これを書いている現在)終わりが近づいてきました。

ブログを書かせていただくことで、新しい機能に深く向き合うことが できてre:Invent期間を充実したものに出来ました。

この場をお借りして、機会を下さったクラスメソッドの皆様に感謝と御礼をさせていただきます。
機会があれば(来年のre:Invent?笑)またいつでもすぐに登場できるよう力を蓄えておきます。

ありがとうございました!