技術2課の大川です。
🏀JBA公認E級審判ライセンスを取得しました。
今回の投稿ではまずNetwork Load Balancer(以下、NLB)、Application Load Balancer(以下、ALB）)、 EC2インスタンスで構成された簡易的なシステムを構築します。
それに対して他VPCからVPCエンドポイント経由でアクセスを試してみます。
今回の構成
今回の構成図です。
アクセス元（左）とアクセス先（右）の２つのVPCを用意します。 それに加えてサブネット/ルートテーブル/インターネットゲートウェイ/NATゲートウェイ/踏み台用EC2（bastion）なども用意しますが、それらの方法については割愛します。
以下、手順の番号は構成図にある赤枠で示した番号と紐づいています。
構築手順
1. ターゲットとなるEC2インスタンスの用意
まずアクセス先VPCの各プライベートサブネットに１台ずつAmazon Linux2でインスタンスを立てます。 Webサーバーとして今回はNGINXを使用しています。（お好みに合わせて）
今回の検証ではトップページが表示されれば良いだけなので、次の手順でサクッとインストール＆起動＆確認までを行います。
$ sudo amazon-linux-extras install nginx1 $ sudo systemctl start nginx $ sudo systemctl enable nginx $ sudo systemctl status nginx
セキュリティグループは「default」をアタッチしています。
念のため踏み台インスタンスからcurlでアクセスして、レスポンスがあることを確認します。
$ curl 10.0.11.192 | head
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 3520 100 3520 0 0 546k 0 --:--:-- --:--:-- --:--:-- 572k
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Test Page for the Nginx HTTP Server on Amazon Linux</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<style type="text/css">
/*<
3. ALBの作成
今回はサービスをインターネットに公開しないのでスキームは「インターネット向け」ではなく「内部」でALBを構築します。
NLBとは違ってALBにはセキュリティグループをアタッチすることが可能です。それがここでのポイントとなります。
ここでは次の２つをアタッチしています。
- default
ALBがEC2（同じくセキュリティグループ「default」をアタッチ）へアクセスするため - プライベートサブネットからのアクセスを許可するセキュリティグループ
後ほどプライベートサブネットに構築するNLBからのアクセスを許可するため
NLBはVPCエンドポイント経由でアクセスされる場合はソースNATを行います。 つまりALBはVPCエンドポイント経由のアクセスをNLBを送信元としたパケットとして受け取ります。 ただしNLBはALBとは違ってセキュリティグループをアタッチできないため、アドレス指定のセキュリティグループで許可してあげる必要があります。
「リスナーとルーティング」欄で、リスナーの「デフォルトアクション」として先ほど作成したターゲットグループを指定します。
4. NLB用ターゲットグループの作成
NLBのターゲットとなるターゲットグループを用意します。 このターゲットグループには先ほど作成したALBを含めるため、ターゲットタイプを「Application Load Balancer」で作成します。 その上で先ほど作成したALBを含めるように作成していきます。
「ターゲットの登録」画面で先ほど作成したALBを指定します。
5. NLBの作成
NLBもインターネットに公開しないのでスキームは「内部」で作成します。
「リスナーとルーティング」欄でリスナーの「デフォルトアクション」の「転送先」として、先ほど作成したNLB用のターゲットグループを指定します。
6. VPCエンドポイントサービスの作成
NLBを宛先とするVPCエンドポイントサービスを作成します。
「ロードバランサーのタイプ」を「ネットワーク」とし、先に作成したNLB を選択します。
「エンドポイントの承諾が必要」にチェックすることで、当VPCエンドポイントサービスへアクセスするためのVPCエンドポイント作成時には、「承諾」が必要になります。（手順は後述）
作成すると次のように詳細を確認できます。 ここで表示されている「サービス名」は、VPCエンドポイントを作成する際にVPCエンドポイントサービスを指定する際のキーになるのでメモしておきます。
7. (オプション)アクセスを許可するAWSアカウントをプリンシパルとして許可
他のAWSアカウントにVPCエンドポイントサービスへのアクセスを許可する場合は、VPCエンドポイントに「プリンシパル」を設定する必要があります。 ※同一アカウントからのアクセスでは不要
次のようにVPCエンドポイントサービスの「プリンシパルを許可」タブから設定します。
プリンシパルをARNで指定します。
8. VPCエンドポイントの作成
アクセス元のVPCにVPCエンドポイントサービスへアクセスするためのVPCエンドポイントを用意します。
「エンドポイントの設定」欄で「その他のエンドポイントサービス」を指定します。 またVPCエンドポイントサービスの「サービス名」で先ほど作成したVPCエンドポイントサービスでメモした「サービス名」を入力します。
「サービスの検証」ボタンをクリックすると「サービス名が検証されました」と表示されることを確認します。
ただしVPCエンドポイントサービスでは「承諾が必要」で作成したため、ここで作成したVPCエンドポイントはステータス「pendingAcceptance」で保留しています。 このままでは使用できません。
使用するためには「VPCエンドポイントサービス」側で「エンドポイント接続リクエストの承諾」が必要になります。
「アクション」から「エンドポイント接続リクエストの承諾」を選択します。
承諾されると無事にステータスが「Available」に遷移し、利用可能となります。
9. アクセス確認
それではアクセスを確認してみましょう。
VPCエンドポイントのFQDNは「DNS名」で確認することができます。VPCエンドポイントが正しく作成されていれば名前解決できるはずです。
DNS名が複数ある理由はこちらのブログをご参考に。
アクセス元のVPCにあるEC2インスタンスにsshでアクセスした後に、curlコマンドでVPCエンドポイントにhttpでGETしてみます。
$ curl vpce-00000000000000000-xxxxxxxx.vpce-svc-00000000000000000.ap-northeast-1.vpce.amazonaws.com | head
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 3520 100 3520 0 0 375k 0 --:--:-- --:--:-- --:--:-- 381k
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xml:lang="en">
<head>
<title>Test Page for the Nginx HTTP Server on Amazon Linux</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<style type="text/css">
/*<