こんにちは、AWSグループのナガトモです 🙋♀️
前回、DMSで見事にハマったばかりなんですが、 傷が癒える間もなく、またDMSで事件が起きました。
（前回の記事をまだ見てないよーって方は、ぜひこの記事も見てやってください🙏 ） techblog.forgevision.com
今度はなんと、
「クロスアカウントでDMSレプリケーションしたい。でもVPC Peeringは禁止で」というご要件。
なるほど、ムズい。いや、めちゃムズい。
というわけで、今回も先輩に手伝ってもらいながら、 あーでもないこーでもないと試行錯誤して、なんとか形にできたのでブログに残しておきます。
ミッション：「VPC PeeringなしでDMSを成立させろ」
まずは前回の構成図をチラ見ください↓
VPC Peeringを使って、スマートに DMS がレプリケーションする構成でした👇
が、社内からこんな声が…。
「VPC Peering使うと、VPC内の全リソースにアクセスできるからちょっとセキュリティ的に…」
「Peeringやめて、もっと閉じた接続にできない？」
というわけで、今回は方針をチェンジ。
PrivateLink（＋カスタムエンドポイント） を活用して、クロスアカウントかつPeeringなし構成にチャレンジです。
先に結論：構成図はこうなった
検証の結果、最終的にはこんな構成に落ち着きました👇
順を追って整理しながら、ポイントを解説していきます。
そもそも、VPC Peeringってセキュアじゃないの？
VPC Peering は、その名のとおり「VPC と VPC をつなぐ」仕組みです。
ただし、つなぐだけでは“フルアクセス”になるわけではありません。
実際には、ルートテーブルを調整することで、通信範囲を限定できます。
たとえば、こんなルート設定を入れれば
192.168.2.14/32 → VPC Peering
→ DMSインスタンスだけが通信できる、という構成もできます。
（戻りの通信は割愛。）
私としては、「このやり方で十分セキュアなのでは？」と、けっこう力説したんですが、残念ながら、却下されました。
「いや、VPC Peering自体をやめたい」
「もっと閉じた通信経路でいこう」
そんな声がありまして、今回の検証に踏み切ることになります。
料金比較：PrivateLinkはお高いのか問題
「VPC Peeringを使うな」と言われたからには、
“じゃあコスト的にどうなの？” という点はしっかり確認しておきたいところ。
ということで、PrivateLink 構成と VPC Peering 構成でのコスト感をざっくり比較してみました。
まず、VPC Peering という便利なサービスを選択肢から捨てることでどのような恩恵がなくなるのか調べてみました。
Private Link の場合
まず、PrivateLinkを使うと、データ提供元（レプリケーション元）で「エンドポイントサービス」用のロードバランサーが必要になります。
- $0.0243/h → 月額ざっくり $18 USD
ただし、この「エンドポイントサービス料金」は、どうやらロードバランサーに含まれているようで、検証した環境では追加課金が発生していませんでした。
気になって料金表を何度も見直しましたが、請求には載ってきませんでした。
加えて、DMSをホストする側（レプリケーション先）の RDS が存在するサブネットにも、Interface VPC エンドポイントが必要になります。
ここはしっかり課金されます。
- Interface エンドポイント：$0.014/h（月で約 $10 USD）
- データ転送料金：$0.01/GB
この「データ転送料の青天井感」は、ちょっと怖い。
VPC Peering構成の場合
一方、VPC Peeringならどうか？
- 接続料金 → 無料✨
- 同じ AZ 内のデータ転送 → 無料✨
つまり、うまくやれば「接続コスト・転送コストの両方が実質タダ」になるパターンもできるわけです。
コストメリットの結論としては...
セキュリティ要件がクリアできるなら、VPC Peeringのほうが明らかに安い！
でも、より限定的なアクセスコントロールを求めるなら PrivateLink も有力な選択肢、というバランス感。
『意外と PrivateLink いいのでは？』
と私の中の気持ちは傾きかけておりました。
デプロイ編
ではここからは、実際にどう構成したか？ をざっくりご紹介します。
（ハマりポイント込みで正直に書きます🫣）
NLB（ネットワークロードバランサー）の設定
使うDBは PostgreSQL で、ポートはデフォルトの 5432 を指定。
シンプルですね。特に悩むところはありませんでした。
PrivateLink の設定
今回の肝はここです。
DMS のターゲットとなる DB に、クロスアカウントでセキュアに接続するため、PrivateLink（インターフェース型VPCエンドポイント） を使いました。
構成イメージとしては、
- センパイのアカウントで、NLB を通じた「エンドポイントサービス」を作って、
- わたしの AWS アカウントのVPCエンドポイントでそれを参照して接続する！
という流れです。
ステップ①：エンドポイントサービスの作成
先輩アカウントで、以下のように操作してもらいました。
「エンドポイントサービスを作成」ボタンをポチッとすると、こんな画面が出ます。
ここでポイントなのが：
- NLBが前提になっている（DMS のエンドポイントを直接指定できない）
- 使用可能なロードバランサーにちゃんと対象の NLB が表示されていれば OK
ステップ②：プリンシパル（接続許可）を設定
PrivateLink 作成後は、「プリンシパルを許可」タブで接続元データベースが起動する AWS アカウントのアカウント ID を指定します。
いわゆる「この人なら入っていいよ」設定です。
この設定を入れることで、接続元アカウント側で「VPCエンドポイント作成」のときに、対象のエンドポイントサービスがちゃんと候補として出てくるようになります。
EC2 インスタンスから接続テスト
EC2 インスタンスを起動して、 接続できるか試したみたところ、接続先のエンドポイントが分からずに見事にハマりました。
ナガトモ VPC に EC2 インスタンスを起動して、以下を試していきました。
- センパイのRDS エンドポイントに向けて psql コマンドを投入 → タイムアウト
- NLB の FQDN に向けて psql コマンドを投入 → タイムアウト
- ナガトモ VPC の PrivateLink エンドポイントに向けて psql コマンドを投入 → 名前解決失敗😞
ということで、なかなか繋がらず、、、
正解は、ナガトモ VPC のエンドポイントに向けた psql コマンド投入でした。（なのでDMSのソースエンドポイントもナガトモVPCのエンドポイントを設定する感じでした🤫）
まとめ
PrivateLink構成、やってみたら意外とアリ！
今回は「VPC Peering禁止」という制約のもと、 PrivateLink＋NLB＋カスタムエンドポイント を組み合わせて、 クロスアカウントでDMSレプリケーションを成立させる構成にチャレンジしてみました。
やってみて思ったのは：
• 構築手順はちょっと手間。でも仕組みを理解すればシンプル。
• 接続テストではハマりどころが多いので要注意。
• コストは少しかかるが、セキュリティ要件には応えられる。
ということ。
個人的には、 「DMS構成って、こんな自由度高かったっけ？」という新しい発見もあり、 なかなか面白い検証になりました。
もし似たような状況で悩んでいる方に この記事が少しでもヒントになれば嬉しいです！⭐️
それではまた🙋♀️
