こんにちは！
BFT名古屋支店の佐野です。
今回はPrivateLinkに使用するVPCエンドポイントについてのお話です。
今まで筆者が携わった案件でも度々使用してきたPrivateLinkおよびVPCエンドポイントですが、知らないと勘違いしやすいポイントもあるかなという印象がありました。
そういった、軽く使う分には意識しないけれども、込み入って使おうとすると悩んでしまうような引っかかりポイントについて、触れていきます。
はじめに：そもそもPrivateLinkとか、VPCエンドポイントって？
まずPrivateLinkについては、以下のサービスページに何者であるかについての記述があります。
AWS PrivateLink は、トラフィックをパブリックインターネットに公開することなく、VPC、AWS のサービス、およびオンプレミスネットワーク間のプライベート接続を提供します。
この記述が示すように、利用することで通信内容を公のインターネットに出すことなく、AWS内のネットワークのみを通じてAWSのサービスや他のVPCとのやりとりが可能となるというのがPrivateLinkというサービスであり、このサービスを利用してプライベートな通信を実現するための機能がVPCエンドポイントになります。
「PrivateLinkを使ってAWS内のみの通信を行なう」という場合、おおよそはこのVPCエンドポイントを配置して実装すると考えてよいでしょう。
ただし、PrivateLink = VPCエンドポイントかというと、そうではありません。
VPCエンドポイントにはGateway型とInterface型があり、PrivateLinkとして利用できるのはInterface型のみとなります。
Gateway型とInterface型の違いについては、以下の記事が詳しいので、そちらを参照ください。
VPCエンドポイントの制約
PrivateLinkとは少々話がずれてしまいますが、VPCエンドポイントの機能で「DNS名の有効化（DNS names enabled）」というものがあります。
これを有効化した場合と無効化した場合では、どこのDNSからアクセスするかによって通信の経路が変わってきます。
特に有効化した場合、サービスのデフォルトのDNSホスト名をVPCエンドポイント経由で使えることが大きく、通信時にエンドポイントURLの指定をしなくともVPCエンドポイントからサービスへの通信をすることができます。
無効化した場合、インターネットに通ずるパブリックセグメントからの通信ではインターネットを経由してしまいますし、プライベートセグメントからは通信時にエンドポイントURLの指定をしないと通信ができなくなってしまいます。
これら、エンドポイントの作成をした際にエンドポイントに設定されるDNSや、先に述べた通信経路については、以下の情報が詳しいため、ご参考ください。
（なお「DNS名の有効化」＝「プライベートDNS名を有効にする」になります）
……さて、この「DNS名の有効化」ですが、通信時のエンドポイントURLの指定を行なうことができないサービスから通信を飛ばすような時には、有効化がほぼ必須と言えます。
しかしながら「DNS名の有効化」がされているエンドポイントは、サービスのエンドポイント毎に、1つのVPCに1つしか配置することができません。
つまり、以下の図のように「DNS名の有効化」をしたエンドポイントを複数のサブネットに置きたかったとしても、それは仕様上不可能なのです。
ですが、この図のように複数のサブネットに設置した同サービスから、エンドポイントを経由して通信を行ないたいという状況は多いかと思います。
ではこういった場合は、どうすればよいのか。
「DNS名の有効化」がされていないエンドポイントであれば複数置くことも可能なので、どこかの部分でそれを使うか……
VPCエンドポイントは他のサブネットの通信も出せる
エンドポイントは置く場所にセグメントを指定するため、一見すればそのサブネット内にあるAWSリソースからの通信のみ受けるものであると思ってしまいますが、実はそうではありません。
実はエンドポイントは、通信元のAWSリソースからルーティングが可能なサブネットに配置されていれば、そこから通信を出してくれるのです。
例えば、以下の図のような配置にしたとしても、エンドポイントのあるサブネットへのルーティング、そしてネットワークACLやセキュリティグループでの通信許可さえ通っていれば、問題なくエンドポイントを経由してAWSのネットワークへ行ってくれます。
これならば、どのサブネットからも通信が通っているようなサブネットにエンドポイントを置いておけば、すべてのAWSリソースがエンドポイントを経由した通信を行なえます。
他のサブネットからの通信も完全に断った、本当に孤立したサブネットにあるAWSリソースからエンドポイントに通したい、というような厳しいケースであれば例外となりますが、そのような時以外はこれでエンドポイント関連の問題は解決に至れるかと思います。
またエンドポイントのこの特徴を鑑みて、どのサブネットにエンドポイントを置くかは、実は設計段階でよく検討しておくべきこととも言えます。
単純に対応するAWSサービスのあるサブネットにエンドポイントを置けばいい！ だと唐突にハマってしまうこともあるかもしれません。
さいごに
PrivateLinkを意識した場合、インターネットへ出てしまう可能性や通信不可となる可能性を考えれば「DNS名の有効化」はしておくべきかと思います。
ただし手動でコマンドを打って通信を行なうといったような場合であれば、DNS名の有効化をしなかったエンドポイントも十分使うことができます。
主要なシステム向けには「DNS名の有効化」をしたエンドポイントを、先に述べた孤立したサブネットにあるAWSサービスに対しては、「DNS名の有効化」をしていないエンドポイントを配していくというような、使い分けが重要となる場面もありそうです。
というわけで、今回はここまで。
また別の記事でお会いしましょう！
