はじめに
クラウド環境は個社に閉じたシステムだけでなく、会社間や共同サービスでも利用が拡大しており、それらとのHULFT通信にAWS PrivateLinkを利用するケースが増加している様です。
こうした背景を踏まえ、ご覧頂いている皆様にお役立て頂ければと思い、何回かに分けてAWS PrivateLinkを介したHULFT通信について記載しようと思います。
以降、本記事ではAWS PrivateLinkをPrivateLinkと表記します。
PrivateLinkとは ～特徴～
「PrivateLink」という名前の機能やサービスを探してしまいそうですが、
AWSにそんなメニューがある訳ではありません。
エンドポイントとロードバランサを組み合わせた通信構成の総称を
PrivateLinkと呼んでいる様です。
このような通信の流れを定義することで、ClientがEndpointへ接続するTCPセッションが
宛先（Server）へルーティング（トンネリング）される仕組みがPrivateLinkです。
特徴：VPCからVPCへのホットライン
VPCとはAWS上のLANの様なものです。
EC2やFargate等のHULFTが動作する環境は、必ず何処かのVPC（LAN）に属します。
PrivateLinkは、このVPCからVPCへの専用線の様な通信路の構築を可能とします。
接続元／先のVPCは異なるもの同士だけでなく、同一であってもかまいません。
テストなどで試しに構築してみる場合、同一VPCでループバック通信を構築する方が簡単です。（接続元の許可を省略できます）
PrivateLinkは専用線と異なり物理的な回線や契約を必要としないため、安全でありながら柔軟で迅速な設定、構築、解除が可能です。
PrivateLinkの通信は一方通行なので、双方向に通信させたい場合は互いの受信サーバ（集信サーバ）へのPrivateLinkを、たすき掛けする様に別々に構築します。
PrivateLinkを利用できないと
PrivateLinkを利用せず、異なるVPC上のリソース同士を通信させるにはグローバルなIPを持ったサーバを立ててインターネット経由で通信する方法と、VPC PeeringやTransitGatewayを利用する方法があります。
ところが、インターネット経由となると盗聴や攻撃等の外部要因のセキュリティリスクが生じます。
またVPC PeeringやTransitGatewayはインターネットを利用しないVPC間通信が可能ですが、ルーティングのためのアドレス体系の整理や管理が必要であったり、通信させたいリソース同士以外の通信も行えてしまうことで、無用なトラフィックが他VPCへ飛んでしまうなど、管理の煩雑さや内部要因のセキュリティリスクを生じてしまいます。
これらに対し、PrivateLinkは指定サーバのみへの通信を、許可した接続元AWSアカウントからだけ通せるという安全でありながら便利な通信方法を提供しています。
またDirectoConnect接続により、PrivateLink経由でオンプレから通信先への透過的なアクセスも可能となります。
許可ユーザにしか見えない安全なサービス
PrivateLinkは接続先となるEndpointServiceに、接続元のAWSアカウントIDを登録するというホワイトリスト的な仕組みにより限定された接続元からしか通信できない仕組みになっています。（下図①）
この設定が行われていない接続元にはEndpointServiceが参照できないため、VPC Endpointの作成を完了できません。（下図②）故に、これを利用した攻撃は不可能なのです。
また、たとえ登録した接続元からの通信であっても、接続先側には初めて接続された際に通信を許可したり、一旦許可した接続も拒否できる仕組みを備えています。
これらの仕組みにより、不特定からのアクセスが抑制され、安全性が確保されています。
HULFTと相性が良い責任分解の仕組み
HULFTの設定は、配信側は配信側だけで完結し、集信側も集信側だけの設定で動作します。
これにより、配信と集信双方のプラットフォームが異なっても、それぞれの環境に応じたファイル転送やジョブ連携の最適な制御が可能となっています。
配信と集信を紐づける情報は、ファイルIDをキーとして定義をマッチングし、集信側は配信側HULFTのホスト名により転送元を識別することで整合性を確保しています。
PrivateLinkの設定も、送り側は送り側だけの設定、受け側は受け側だけの設定となっており、双方を結びつける情報はAWSアカウントIDとエンドポイントサービス名だけです。
FTPやSSH、他DB等の様にサーバがアカウントを持ち、通信元から宛先側を操作する様な仕組みではありませんので、受け側が操作されたり、設定を変えられてしまうという事はありません。
PrivateLink経由でのHULFT転送の考え方
最終的な宛先となる集信は、配信とは異なるIPアドレス体系にあるため、配信側から直接指定することはできません。
このため、配信の宛先は自身のVPCの出口となるEndpointへ通信できる様に設定します。（下図①）
この際、配信側HULFTの宛先として自身のVPCのEndpointを指すDNS名を直接指定できれば良いのですが、DNS名は100文字前後と長いためHULFTの詳細ホスト情報に設定できる最大長（68文字）を超えてしまいます。この対策についても、次回以降で説明したいと思います。
PrivateLinkの入り口となるVPC Endpointへ接続できてしまえば、あとはPrivateLinkの仕組みで集信まで通信がリレーされます。
最終宛先となる集信は、NLBのtargetGroupのtargetとして指定します。（下図②）
制約、留意事項
１、双方がAWS利用者である必要がある
２、作成できる数に制限がある
３、宛先１つあたり１本のPrivateLinkが必要なため、多対多通信に不向き
４、FTPの様に複数のポートが必要な構成にも不向き
５、DNSを利用するホスト名を宛先に指定できない（NLBの制約）
おわりに
以上、初回は概要について記載させて頂きました。
次回はHULFT転送をPrivateLink経由で行う際の、よくある「つまづきポイント」について紹介します。