コスト削減と管理要素の集約が目的で、開発/検証/本番アカウントの各 VPC ごとに作成して参照していた VPC エンドポイント (以下、VPCE と略) を、共有リソース VPC で作成したそれに切り替える対応を行いまして、その際のメモになります。
前提知識のおさらい
通常、VPC 内から AWS サービスへアクセスする際の経路は、他インターネット接続と同様に IGW を通ります。
下図は Lambda から非 Private タイプの API Gateway (以下、API GW と略) にアクセスする経路例です。
Lambda の ENI ををインターネットに到達できない VPC 内に配置して S3 とか参照できなくなっちゃったの原因あるあるです。
インターフェース型の VPCE を作成した場合、
特定サービスを指すドメイン名であれば VPCE の ENI へ通信を向ける Private Hosted Zone によって
IGW ではなく VPCE を経由するようになります。
下図は Private タイプの API GW にアクセスする経路例です。
突然出てきた Private Hosted Zone は、VPCE 作成時にある追加設定より「DNS 名を有効化」を選択すると自動で用意されます。
ホストゾーンの関連付けという機能で、内部的に用意された Private Hosted Zone を Route 53 Resolver (旧: Amazon Provided DNS) が参照できるようになります。
また、このホストゾーンの関連付けを手動で行うことで、他アカウントの VPCE を参照することもできます。
今回は、「DNS 名を有効化」によって作成された execute-api.[region name].amazonaws.com の VPCE を、共有リソース VPC で作成した別のそれに切り替える対応をしました。
参照する VPCE 切り替え時の問題
IGW を立ててはいけないなどの制約がないなら、参照先切替アカウントで
- NAT GW などによるインターネットへの通信経路を確保
- 切替アカウントにある 旧 VPC エンドポイントでホストゾーンの関連付けを削除
- 共用リソース VPC の VPCE を参照するホストゾーンの関連付けを行う
- トラフィック切り替えの確認後、旧 VPCE を削除
で可能ですが、Private タイプの API GW は VPCE 経由でのみ参照可能なため、
特に、DNS 名を有効化より Private Hosted Zone を用意されている場合で素直に同様の方法で行うと
ホストゾーンの関連付けを無効化した直後から API GW を参照するアプリの機能が止まってしまいます。
最終的に execute-api.[region name].amazonaws.com すべての通信を 共有リソース VPC へ向けるためには、
同じ名前でホストゾーンの関連付けはできないので、旧 VPCE にて関連付けの削除を行う必要があります。
対応方法
この環境では Private API の参照を [API GW ID].execute-api.[region name].amazonaws.com のドメイン名正引きで行われていました。
なので、名前解決の優先順位を利用できます。
API GW の ID まで含めた FQDN でならホストゾーン名が重複せずに関連付けでき、
DNS 名を有効化によって用意されるホストゾーン名よりこちらのルールが優先されるので、
これを関連付けすれば、トラフィック断なしで VPCE の参照先を変更できます。
具体的には
- [API GW ID].execute-api.[region name].amazonaws.com の Private Hosted Zone を作成
- 同ホスト名解決時に、移行先 VPCE を指すエイリアスレコード作成
- このホストゾーンを VPCE 参照先切り替え元 VPC に関連付け
- トラフィックが共有リソースへ切り替わったことを確認したら通常の関連付け入れ替え対応
でおこなえました。
実際の作業内容......はやってしまったので、後日、再現してまとめたいと思います。