AWSでアカウントをまたいだ接続を実現する
前回のNLBとRDSを組み合わせて使っていた話の続き。
設定がわかれば、ああそういうものなのか、とわかるのが多いという印象のAWSのサービス。これもその類だった。
VPC Endpointサービスでは、接続元をConsumerと呼び、接続先をProviderと呼ぶ。
その上で、設定としては、まずProvider側で"VPC Endpoint Service"を有効にする。
そうすると、Service Nameというものが発行される。これを鍵にConsumer側からは繋ぐことになる。
Consumer側では"VPC Endpoint"を有効にし、その際に先ほどのService Nameを使用する。
すると、VPC Endpointに対してアクセスすれば、別のアカウントにあるVPC Endpoint Serviceを経由してNLB、そして前回の例で行けばRDSへと接続ができる。
このとき、Consumer側でアプリがDBのアクセス先に指定するべきなのはConsumer側のVPC EndpointのDNS Name。
そこが自分の場合は勘違いしていた。VPC EndpointとVPC Endpoint Serviceでトンネルのようなものを作るので、そのトンネルの向こうのNLBの名前を指定するべきなんだろう、と思っていたが、そうではなく、あくまで自分のアカウント内のVPC Endpointを指定すると、Service Nameを介してNLBに到達できる仕組みらしい。
なので、仕組み的にはリバースプロキシーを設定しているのと同じと考えると結構わかりがいい。
細かい点としては、特にProvider側でいくつか。
* Provider側のVPC Endpoint Serviceでは接続しようとするアカウントなどを許可制にすることもできるが面倒なので自動許可にするのが楽。
* ただしそうすると、Service Nameがわかると誰でも繋げられてしまうので、それとは別にWhitelisted Principleに、ARNとして接続対象のAWSのアカウントのルートを追加すると良い。
* CloudFormationでWhitelisted Principleを指定する場合のType名はVPCEndpointServicePermissionsなので注意。AllowedPrincipalsにARNを、ServiceIdに設定対象のVPC EndpointのIDを指定する。ServiceIdはRefを活用すると楽。
わかればそんなもんか、という感じ。
あとは、今のやり方のままだと、課題があり、次の点も検討に入ってる。
少なくとも後者は確実にできるので、アプリ側で接続先のVPC Endpointを切り替えることは必要なくなりそう。
Service Nameを固定できるのかは......まだわからないので、調査と確認が必要そう。
* Provider側ではVPC Endpoint Serviceを再デプロイするとService Nameが変わってしまうので、Private DNSを使用してService Nameを固定できるようにする
* Consumer側ではVPC Endpointを再デプロイするとDNS namesが変わってしまうので、Private DNSを使用して固定できるようにする
posted on: https://blog.tkhm.dev/2020/10/aws.html