[アップデート] Amazon VPC Lattice が TCP 接続に対応し、VPC 内の幅広いリソースへアクセスができるようになりました
Amazon VPC Lattice が VPC リソースをサポートし、TCP 接続で VPC 内のリソースへアクセスできるようになりました。 TCP 通信をサポートしたことでユースケースと最初に思いつくのが、VPC をまたいだデータベース接続ではないでしょうか。データベース接続を VPC Lattice を利用してどう接続するのかを例にして新要素を解説していきます。
画像引用: AWS re:Invent 2024 - Amazon VPC: Advanced design and what’s new (NET301) - YouTube
VPC Lattice を利用したデータベース接続の構成
VPC Lattice を利用した VPC をまたいだデータベース接続には、以下の新登場のリソースが必要です。
- Resource Configuration
- Resource Gateway
- サービスネットワークタイプの VPC エンドポイント
新登場リソースの解説
VPC Lattice による TCP 接続を実現するために必要な 3 つのリソースついて解説します。
Resource Configuration
VPC 内のリソースを他の VPC と共有するための論理的な管理単位です。RDS/Aurora などの VPC 内にあるリソースを登録して使います。
登録可能なリソースの指定方法
- IP アドレス
- DNS 名
- ARN(Amazon Resource Name)
Resource Configuration は作成時に、後述する Resource Gateway の指定が必須です。
どこで必要なリソース?
Resource Configuration は、アクセス先のターゲット VPC 側のリソースの指定で使います。
Resource Gateway
Resource Configuration に登録した VPC 内のリソースに対するアクセスの受入口として機能します。
主な特徴
- 複数の Resource Configuration を同一の Resource Gateway へ紐付けけ可能
- AZ(Availability Zone)ごとに ENI が作成される
- ネットワークアクセスの制御はセキュリティグループの設定が必要
- VPC 内のリソースへのアクセス元は Resource Gateway の IP アドレス
どこで必要なリソース?
Resource Gateway は、アクセス先のターゲット VPC 側に配置する必要があります。
サービスネットワークタイプの VPC エンドポイント
EC2 などのクライアントは VPC エンドポイントに表示される DNS 名を使ってターゲット先の VPC 内リソース(Aurora など)へアクセスします。
主な特徴
- AZ(Availability Zone)ごとに ENI が作成される
- ネットワークアクセスの制御はセキュリティグループの設定が必要
- データ転送量に応じた従量課金
- VPC エンドポイント自体の時間単位の課金は発生しない
- 他の VPC 内リソースへアクセスする際の DNS 名は、VPC エンドポイントが持っている DNS 名
どこで必要なリソース?
サービスネットワークタイプの VPC エンドポイントは、アクセス元のクライアントがある VPC 側に配置します。
VPC リソースへアクセス構成時の課金要素
VPC Lattice で VPC リソースを利用時の課金要素は以下の 2 つです。
- 時間課金: サービスネットワークに関連付けた VPC リソースの利用料金
- データ転送料金: 転送されるデータ量に応じた課金
現時点では東京リージョンは利用できません。バージニア北部リージョンの価格を基に説明します。最新情報は公式サイトをご確認ください。
Simplified Application Networking – Amazon VPC Lattice Pricing – Amazon Web Services
時間単価比較
従来から提供されている VPC Lattice サービスと比較すると、時間課金の単価は 4 倍高く設定されています。
コンポーネント | 用途 | 時間単価 |
---|---|---|
VPC Lattice サービス | HTTP/HTTPS などの通信(API 向け) | $0.025 |
サービスネットワークへ VPC リソース追加 | TCP 通信(DB 接続など) | $0.10 |
VPC リソースを 1 つあたり 1 か月(744 時間)使うと$74.4 の費用になります。VPC Lattice サービスで HTTP/HTTPS アクセスを提供するマイクロサービスの様な構成で利用方法する場合は 1 つあたり $18.6/月です。比べてみるとなかなかお高いですね。
データ転送料金比較
API 向けの通信と比べるとデータ通信量が増えることを踏まえてか単価は 6 割引の設定です。ただ、非常に安価ではありますが、Resource Gateway のデータ転送料も発生します。
コンポーネント | 用途 | 単価(GB あたり) |
---|---|---|
VPC Lattice サービス | HTTP/HTTPSなどの通信(API 向け) | $0.025 *2 |
VPC リソース | TCP 通信(データベース接続など) | $0.01 *2 |
Resource Gateway | VPC 内リソースアクセスに必須 | $0.006 |
ここまでは新リソースの概要を解説しました。次に、実際に VPC を跨いだ Aurora への接続方法を紹介します。
やってみた
以下の手順で、EC2 から VPC Lattice 経由で Aurora に接続する環境を構築します。
- サービスネットワークの作成
- Resource Gateway の作成
- Resource Configuration の作成
- VPC エンドポイントの作成
- 接続テスト
サービスネットワークの作成
まずは従来からある VPC Lattice のサービスネットワークを作成します。サービスネットワークは、リソース同士を接続するためのハブの役割をします。サービスネットワークの作成時点では特別な設定は不要です。後ほど必要なリソースを作成し、サービスネットワークへ関連付けします。
Resource Gateway の作成
次に、Aurora が起動しているターゲット側の VPC に Resource Gateway を作成します。Resource Gateway のセキュリティグループを事前に作成しておき、必要なアクセス権限を付与します。
セキュリティグループの設定
インバウンドの許可ルールは必要ありませんでした。
Resource Configuration の作成
次に、Aurora クラスターへの接続を設定するために Resource Configuration を作成します。
- ARN 指定: Aurora クラスターの ARN を指定します。クラスターエンドポイントとリーダーエンドポイントなど必要なエンドポイントは自動的に登録されます。
- Resource Gateway の指定: 前のステップで作成した Resource Gateway を指定します。
ARN 指定すると RDS は、RDS/Aurao のリソースが一覧で表示されます。上に表示されているクラスターを選択しました。
ポートは Lower bound のみ指定しました。Upper bound も同じポート番号を入力すると作成時にエラーで作成できませんでした。
すると、3 つの Resource Configuration が追加されました。
クラスターエンドポイントと、リーダーエンドポイントが登録されていました。
以下は Aurora の設定画面から確認したエンドポイント名です。
作成した Resource Configuration をサービスネットワークに関連付けます。タイプが ARN となっている Resource Configuration を関連付けすると、Child タイプの Resource Configuration も自動的に関連付けられます。
サービスネットワーク側から確認
サービスネットワーク側からも関連付けたリソースを確認できます。
DB のセキュリティグループの設定変更
Aurora クラスターのセキュリティグループにインバウンドルールを追加します。具体的には、Resource Gateway のセキュリティグループからデータベースポート(例: 5432)へのアクセスを許可します。
サービスネットワークタイプの VPC エンドポイントの作成
最後に、アクセス元の VPC 側にサービスネットワークタイプの VPC エンドポイントを作成します。このエンドポイントを通じてターゲットリソースに接続します。
セキュリティグループを事前に作成しておき、必要なアクセス権限を付与します。
セキュリティグループの設定
アクセス元の EC2 インスタンスのセキュリティグループからの通信を許可する必要があります。
サービスネットワーク側から確認
VPC エンドポイントが関連付けられています。
EC2 からデータベースへ接続
サービスネットワークの VPC エンドポイントが提供する DNS 名を利用して Aurora クラスターに接続します。
サービスネットワークの VPC エンドポイントから DB アクセスに必要な DNS 名を確認します。クラスターエンドポイントの DNS 名に該当する DNS 名はこの長い DNS 名を使って VPC Lattice を利用した DB 接続が可能です。
接続テスト
以下のコマンドを使用して接続を確認しました。
$ psql --host=vpce-0c6288af9ac0c9de9-snra-0d636d8f66af6d41d.rcfg-0873e1ff6edba74b5.4232ccc.vpc-lattice-rsc.us-east-1.on.aws --port=5432 --username=postgres
Password for user postgres:
psql (15.8, server 15.4)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.
データベースに接続し、テーブル作成やデータ挿入、確認が正常に行えました。
postgres=> CREATE TABLE items(item_id int, item_cat varchar, val int, item text);
CREATE TABLE
postgres=> INSERT INTO items (item_id, item_cat, val, item)
VALUES
(1, 'AAA', 101, '111'),
(2, 'BBB', 102, '222'),
(3, 'CCC', 103, '333'),
(4, 'DDD', 104, '444'),
(5, 'EEE', 101, '111'),
(6, 'FFF', 102, '222'),
(7, 'GGG', 103, '333'),
(8, 'HHH', 104, '444');
INSERT 0 8
postgres=> SELECT * FROM items;
item_id | item_cat | val | item
---------+----------+-----+--------
1 | AAA | 101 | 111
2 | BBB | 102 | 222
3 | CCC | 103 | 333
4 | DDD | 104 | 444
5 | EEE | 101 | 111
6 | FFF | 102 | 222
7 | GGG | 103 | 333
8 | HHH | 104 | 444
(8 rows)
postgres=>
VPC Lattice を利用して VPC をまたいだ Aurora への接続が成功しました。これにより、VPC Lattice の新機能である TCP サポートが、データベース接続のユースケースにおいても利用可能であることが確認できました。
まとめ
VPC Lattice が VPC リソースをサポートしたことで、以下の新しいコンポーネントが追加されました。
-
Resource Configuration
- VPC 内のリソースを論理的に管理
- IP アドレス、DNS 名、ARN による指定が可能
-
Resource Gateway
- VPC 内リソースへのアクセス受入口として機能
-
サービスネットワークタイプの VPC エンドポイント
- エンドポイントが提供する DNS 名による接続先の VPC 内リソースの名前解決
- データ転送量に応じた従量課金
おまけ
最近の VPC Lattice のアップデートをまとめておきます。
TLS パススルーをサポートしました。今現在では、VPC Lattice で一度復号化せずにターゲットまで暗号化されたままトラフィックを転送できるようになっています。
Amazon ECS とのネイティブ統合をサポートしました。今現在では、ターゲット側の VPC 内に Internal ALB の作成が不要となっています。
おわりに
VPC Lattice のアップデートは最近多かったのですが、VPC 内のリソースへの TCP 接続をサポートしたことにより活用場面が増えたのではないでしょうか。東京リージョンは現時点では利用できませんが近日中にリリースされるそうです、アップデートを待ちましょう。
引用: AWS Black Belt Online Seminar 2024 年 AWS re:Invent 速報 #AWSDevLiveShow #AWSBlackBelt - YouTube
Private Link との使い分けについても触れたかったのですが、私の筆が遅くアップデート記事をポストできなくて申し訳ないプレッシャーに苛まれたため、今回の文量で切り上げました。踏み込んだ話は、2024 年 12 月 12 日開催のAWS re:Invent ふりかえり勉強会「クラスメソッド re:Growth 2024 札幌」でお話できればと考えております。