AWS の VPC 間をネットワーク接続する方法はいくつかあります。
地方自治体がガバメントクラウドの閉域 AWS 環境に基幹業務システムを構築する場合、地方自治体のオンプレミス環境と複数の AWS アカウントの VPC を接続するケースが多いため、Transit Gateway を使って VPC 間の接続をすることが多いです。
しかし、中にはシステムの VPC をオンプレミスへのルートがある VPC（オンプレミスと Direct Connect で接続している VPC で、ここでは共有リソース VPC とします）に直接接続せず、共有リソース VPC にサービスエンドポイントを作成し、PrivateLink でシステムの VPC 内のサービスをオンプレミスへ提供するケースもあります。
この場合、オンプレミスからシステムの VPC のサービスへアクセスすることはできますが、逆にシステムの VPC からオンプレミスのリソースへアクセスすることはできません。
この PrivateLink を使った構成、つまり共有リソース VPC を介してオンプレミスと直接ルーティングできない VPC 構成は、後からオンプレミス側のリソースへアクセスしなければならなくなった時に困ります。（後から LGWAN へ接続したいケースなど）
そこで、逆にオンプレミス側のリソースを PrivateLink でこういったオンプレミスと直接ルーティングできない VPC へ提供できないか、検証してみました。
実運用でありそうな環境に合わせて、オンプレミス側のリソースへのアクセスは名前解決が必要（IP アドレスが不定の可能性）とし、ガバメントクラウドではよくあるマルチアカウントでクロスアカウントアクセスするようにしています。
Network Load Balancer が不要なリソースゲートウェイを使う方式を試す
今回の検証では、Network Load Balancer (NLB) が必要だった従来の PrivateLink の構成ではなく、NLB のいらないリソースゲートウェイを使う PrivateLink を採用しました。概要は次のとおりです。
- オンプレミスへルーティング可能な共有リソース VPC で、オンプレミスのリソースに対する名前解決ができるよう、Route 53 アウトバウンドエンドポイントとリゾルバールールを設定
- 共有リソース VPC にオンプレミスのリソースと接続するリソースゲートウェイを作成
- リソース設定を Resource Access Manager (RAM) で別アカウント（オンプレミスのリソースを使いたい側のアカウントで、以降利用側アカウントとします）へ共有
- 利用側アカウントでリソースゲートウェイの共有を受け入れ、利用側アカウントの VPC にリソース VPC エンドポイントを作成
- 利用側アカウントの VPC 上のリソースは、リソース VPC エンドポイント経由でオンプレミスのリソースに DNS 名でアクセスが可能になる
なお、各 VPC は全て東京リージョンにあるとします。
構成図は次のとおりです。
それでは具体的な手順を見ていきます。
事前準備
オンプレミス側に Web サービスを起動する
オンプレミス側に適当な Web サーバーを起動します。ここでは Python で簡単な HTML ファイルを返すだけの Web サーバーを起動し、TCP 8000 番ポートでサービスを待ち受けるようにしました。
オンプレミスのフルリゾルバー DNS サーバーの設定する
オンプレミスのフルリゾルバー DNS サーバーで、起動した Web サーバーのプライベート IP アドレスを名前解決できるようにします。ここでは Web サーバーの FQDN を dev.intra.morori.jp とし、IP アドレスは 10.1.1.4 としました。
なお、オンプレミス内だけでなく、共有リソース VPC 上のリソースからも名前解決要求を受け付けるようにします。
これで FQDN でオンプレミスの Web サーバーが公開する HTML ファイルにアクセスできるようになりました。
共有リソース VPC に Route 53 アウトバウンドエンドポイントを作成する
共有リソース VPC にオンプレミスのフルリゾルバー DNS サーバーと連携するよう Route 53 アウトバウンドエンドポイントを作成します。
また、Web サーバーのドメインに対する名前解決要求を Route 53 アウトバウンドエンドポイントへ転送するようにリゾルバールールも作成します。
共有リソース VPC からオンプレミスの Web サーバーの名前解決をしてアクセスできるか、このタイミングで EC2 を使うなどして確認しておくとよいです。確認ができたらリソースゲートウェイの作成に進みます。
共有リソース VPC にリソースゲートウェイを作成する
リソースゲートウェイの作成
VPC のマネジメントコンソールから、「リソースゲートウェイを作成」を開きます。
「リソース設定 DNS 解決タイプ」は今回閉域のオンプレミスのリソースを共有リソース VPC から名前解決できるようにしていることから「VPC 内」に設定します。
セキュリティグループは、オンプレミスのリソースに対するアクセス許可（ここでは TCP 8000 番ポートに対する アウトバウンド方向 へのアクセス許可）を設定し、リソースゲートウェイを作成します。
リソース設定の作成
リソースゲートウェイができたら、「リソース設定を作成」へ進みます。
「設定タイプ」は「リソース」を、「リソースゲートウェイ」は先ほど作成したリソースゲートウェイを設定します。
「カスタムドメイン名を使用」にチェックし、「ドメイン名」にはオンプレミスのリソースの FQDN を設定します。「検証 ID」は空でも作成できますが、本番環境であれば設定した方がよいでしょう。
「ポート範囲」はオンプレミスのリソースの待ち受けポート（TCP 8000 番ポート）とし、「リソース設定を共有」は一旦空のままリソース設定を作成します。（後で RAM で利用側アカウントへ共有します。）
リソース設定のリソース共有を作成する
共有リソース VPC 側のアカウントから、作成したリソース設定を RAM で利用側アカウントへ共有します。
共有する「リソースタイプ」は「VPC ラティスのリソース構成」を選択します。
後は通常の RAM 共有の手順でリソース共有を作成します。
ここまでできたら共有リソース VPC 側アカウントの作業は完了です。次は利用側アカウントでリソース VPC エンドポイントを作っていきます。
リソース設定のリソース共有を承認する
利用側アカウントの RAM で、共有リソース VPC 側アカウントから共有されたリソース設定を承認します。
リソース VPC エンドポイントを作成する
RAM でリソース共有を承認したら、リソース VPC エンドポイントを作成します。
VPC のマネジメントコンソールから「エンドポイントを作成」に進みます。
「タイプ」は「リソース」を、「リソース設定」には先ほど RAM で承認したリソース設定を、「ネットワーク設定」の「VPC」はオンプレミスのリソースにアクセスしたい VPC を設定します。
「ネットワーク設定」の「追加設定」から、「プライベート DNS 名を有効化」にチェックし、「プライベート DNS の詳細設定」は「指定ドメインのみ」としました。
「プライベート DNS 指定ドメイン」にはオンプレミスのリソースの FQDN を設定します。
「サブネット」は、共有リソース VPC のリソースゲートウェイの AZ と合わせる必要があるので注意しましょう。
「セキュリティグループ」は、オンプレミスのリソースが公開しているポート（ここでは TCP 8000 番ポート）をリソース VPC エンドポイントのインバウンド方向で許可）を設定し、リソース VPC エンドポイントを作成します。
リソース VPC エンドポイントを作成すると、裏側でプライベート DNS 指定ドメインに設定した FQDN を名前解決できるよう Route 53 プライベートホストゾーンが作成されるようです。
ここまでできたら利用側アカウント VPC の準備も完了です。
利用側アカウント VPC からオンプレミスのリソースへアクセスする
利用側アカウント VPC に EC2 インスタンスを起動し、オンプレミスのリソースにアクセスできるか確認してみます。なお、ルーティングできない閉域ネットワークにいる EC2 インスタンスなので EC2 Instance Connect エンドポイントから接続して作業しています。
利用側アカウント VPC はオンプレミスのフルリゾルバー DNS サーバーとも共有リソース VPC の Route 53 アウトバウンドエンドポイントとも直接接続していないのに、設定したオンプレミスのリソースの FQDN を名前解決できています。ただし、返ってくる IP アドレスは作成したリソース VPC エンドポイントの IP アドレスになっています。
また、オンプレミスの Web サーバーが公開している HTML ファイルも取得できています。
まとめ
以上でリソースゲートウェイを使った PrivateLink で、オンプレミスとルーティングできない VPC からオンプレミスのリソースへアクセスできることを確認できました。
ただし、実際に使うにはオンプレミスのリソースごとにリソースゲートウェイを作る必要がありそうですし、地方自治体のガバメントクラウドの AWS 環境では素直に Transit Gateway で VPC を相互接続した方が楽だと思いますので、無理にこういった構成を採用しない方がいいのではないでしょうか。