「AWS PrivateLink」というボタンはどこ？ 実機を触って理解した、セキュアな閉域網接続のつくりかた

AWSを触っていれば一度は聞いたことのあるAWS PrivateLink。

今回は、その不思議な仕組みについて、実機検証を交えてお話しします。

■ 目次 

1.コンソール上にPrivateLinkが存在しない？

2.PrivateLinkの正体は「リソースの組み合わせ」

3. 検証準備

3.1. 検証環境の構成紹介

3.2. 構築手順

4. 検証

4.1. IPアドレスが重複していても接続できるか？

4.2. インターネットを経由せず、セキュアに接続できるか？

4.3. 特定のサービスだけを公開できるか？

5．IP重複が許容される仕組み

5.1. Source NAT とは？

5.2. ログで見る「正体」

6. まとめ

■ 1.コンソール上にPrivateLinkが存在しない？  

AWSの資格学習をしていると、必ずと言っていいほど登場する「AWS PrivateLink」。

試験対策のテキスト、問題集には、以下のようなメリットが記載されています。

• IPアドレスが重複していても接続が可能
• VPC間をインターネットを経由せず、セキュアに接続できる
• VPC全体ではなく、特定のサービスだけを安全に公開できる

AWS PrivateLinkというサービスを置くだけで、簡単にメリットを享受できるものだと思っていました。

しかし、いざ構築してみようとするも AWSのサービス一覧にPrivateLinkが存在しない…

■ 2.PrivateLinkの正体は「リソースの組み合わせ」 

PrivateLinkとは単体のサービス名ではなく、「接続の仕組み」の総称でした。

ここでは、一般的な構成を例に、PrivateLinkを構成する3つの要素を紹介します。

1. VPC Endpoint：利用側VPC内に作成される「サービスへの入り口」
2. VPC Endpoint Service：その実体をPrivateLinkとして「公開するための設定」
3. Network Load Balancer (NLB)：提供側VPCでトラフィックを転送する「サービスの実体」

コンソール上で「PrivateLink」が見つからなかったのは、この3つを組み合わせた仕組だからでした。

■ 3.検証環境準備

サービスは存在しなかったが、試験で学んだあのメリットは、本当に実在するのか？

検証環境を作って、メリットは実際に存在しているのか検証してみようと思います。

3.1. 検証環境の紹介

以下のような検証環境を作成しました。VPC AとVPC BでIPが完全に重複しているため、

通常のネットワーク接続が利用できない構成となっています。

● 接続元(VPC A)

VPC CIDR：10.100.0.0/24（重複）。
EC2：接続元として利用するEC2。

● 接続先(VPC B)

VPC CIDR：10.100.0.0/24（重複）。
NLB：EC2（Webサーバー）をターゲットグループとして設定。
EC2（Webサーバー）：接続先として利用するEC2。NLBに紐付ける。
EC2（未公開サーバー）：接続先として利用するEC2。NLBに紐付けない。

それでは、この重複した環境でも本当に通信が可能になるかを検証するため、
「VPC Endpoint」と「VPC Endpoint Service」を作成していこうと思います。

3.2.構築手順

● VPC エンドポイントサービスの作成

接続先（VPC B）のエンドポイントサービスを作成していきます。

NLBをほかのエンドポイントから見えるサービスとして公開する設定をしていきます。

VPC ＞ エンドポイントサービス ＞ エンドポイントサービスの作成 の順に押下します。

まずは、任意の「名前」を入力します。今回は「WebEndpointService」と入力しました。

今回は、NLBを使用する為、ロードバランサーのタイプは「ネットワーク」を選択します。

使用可能なロードバランサーが表示されるので、既存のNLBを選択をします。

「エンドポイントの承諾が必要」にチェックを入れ、作成をします。

これにより、エンドポイントの作成後に承認作業を行うフローが発生します。

作成が正常に完了しました。

サービス名(com.amazonaws.vpce.…)　は後ほど使用するので、メモをしておきます。

②VPC エンドポイントの作成

次に、接続元（VPC A）から接続先（VPC B）のエンドポイントサービスに接続するための「窓口」を作成します。この設定を行うことで、エンドポイントサービスを利用できるようになります。

VPC ＞ エンドポイント ＞ エンドポイントの作成 の順に押下します。

まずは、任意の「名前」を入力します。今回は「VpcA-to-VpcB-Endpoint」と入力しました。

NLBを使用するため、タイプは「NLBとGWLBを使用するエンドポイントサービス」を選択します。

サービス名に 先ほどメモしておいた「エンドポイントサービスのサービス名」を入力します。

「サービスを検証」を押下し、「サービス名が検証されました。」と出ればOKです。
誤ったサービス名を入力した際は「サービス名を検証できませんでした。」と表示されます。

「VPC」は、接続元（VPC A）のVPCを選択します。  

サブネットは、エンドポイントを配置するアベイラビリティーゾーンとサブネットを選択します。

今回は「apne1-az1」のサブネットを選択します。

SGは、作成しておいたEndpoint用SG（VPC A内EC2→エンドポイント：TCP/80）を選択します。

最後に「エンドポイントを作成」を押下します。

 VPC Aの中にVPC エンドポイント（10.100.0.69）が作成されました。 

③承諾作業

接続元（VPC A）でエンドポイントを作成すると、接続先（VPC B）にリクエストが届きます。

エンドポイントサービス ＞ エンドポイント接続タブ ＞ アクション ＞ エンドポイント接続リクエストの承認 の順に押下し、承認を行います。

リクエストを承諾し、ステータスが「Available」に変われば、すべての設定が完了です。

これで、PrivateLinkを介したセキュアな通信環境が整いました。

■ 4.検証  

4.1. IPアドレスが重複していても接続できるか？

本来、同じIPを持つVPC同士を繋ぐことはできませんが、PrivateLinkなら可能です。

利用側のEC2にログインし、 VPCエンドポイント（10.100.0.69）に対してcurl を実行します。

【結果】

同じ 10.100.0.0/24 に居ながら、Webサーバーからレスポンスが返ってきました。

利用側はエンドポイントという「ローカルな出口」を叩いているだけなので、衝突がおこらないのです。

4.2. インターネットを経由せず、セキュアに接続できるか？

【結果】

今回の構成は、利用側・提供側ともにPrivate Subnetで構築しており、インターネットゲートウェイ（IGW）等のインターネットを通るルートは一切存在しません。

①が成功した時点で、この②も同時に証明されています。

インターネットへの出口が存在しない環境下で通信が成立したという事は、パケットがインターネットを経由せず、VPCエンドポイントを介してAWSの内部ネットワークのみを直接通っていることを示しています。

4.3. 特定のサービスだけを公開できるか？

NLBに紐づけていない「未公開サーバー（10.100.0.88）」へのアクセスを試みました。

【結果】

もちろん繋がりませんでした。 今回の構成では、「エンドポイント」から「NLB」という定められた特定のルートだけをパケットが通る仕組みになっています。

この仕組みにより、特定のサービスだけを公開させる、安全な設計であることが確認できました。

■ 5.IP重複が許容される仕組み（Source NAT）

5.1. Source NAT とは？

「パケットの送信元IPを書き換える技術」のことです。

PrivateLinkでは、パケットがNLBを通過する際に、利用側EC2のIPアドレスを提供側NLBのIPアドレスへ書き換えます。これにより、提供側のEC2からは「同じVPC内にいるNLBからの通信」に見えるようになり、IP重複の影響を受けずに返信ができるようになります。

① EC2（VPC A） → VPC Endpoint

内部同士の通信の為、衝突は発生しません。

VPC内の閉じた環境で、自身エンドポイントへパケットを届けるフェーズです。

② VPC Endpoint → VPC Endpoint Service

情報がカプセル化されます。 AWSの内部基盤（Hyperplane）で専用IDを用いて転送を行うため、他VPCとIPが重複していても影響を受けず、IPの重複は発生しません。

③ VPC Endpoint Service → NLB

カプセル化された状態でNLBへ渡されます。 専用IDで管理されている為、他VPCとIPが重複していても影響を受けず、IPの重複は発生しません。

④ NLB → EC2（VPC B）

ここでカプセル化が解除され、同時に送信元IPがNLB自身のIPに書き換えられます（Source NAT）。

VPC BのEC2からは、同じVPC内のNLBから通信が来たように見えるため、送信元VPCとのIP重複の影響を受けずにレスポンスを返すことができます。

5.2. ログで見る「正体」

理屈がわかったところで、実際のログを確認してみましょう。

まずは、NLBのIPを確認します。以下のログの通り、10.100.0.165 であることがわかります。

次に、EC2（Webサーバー）のログを見てみます。

Source NATの仕組み通り送信元はNLB（10.100.0.165）になっていますね。

NLBがIPを書き換えることで、IP重複を解消して接続を可能にしてくれていることが確認できました。

■ 6.まとめ

「できる」ことはわかっていても、その裏側の仕組みまで調べてみることは、なかなかありませんでした。資格の知識だけでは見えない部分が、実際に手を動かすことでたくさん見えてきました。

「資格試験の知識」を疑い、調べてみる。そんな遠回りが、理解への一番の近道なのかもしれません。

まだまだ気になるサービスは沢山あるので、また深堀してご紹介しようと思います。