AWS PrivateLink で他アカウントとの通信についてまとめ

はじめに

 AWS PrivateLink とは AWS のネットワーク内で、VPCAWS のサービス、オンプレミスアプリケーション間のセキュアなプライベート接続を提供するサービスです。
特に専用線などを引かなくても、AWS PrivateLink を設定するだけでお互いの AWS アカウントを通じてインターネットに出ないプライベートな通信を可能にします。

PrivateLink のリソース

エンドポイントサービス

プライベートなサービス提供側。
エンドポイントサービスを作成することでインターネットを経由せず AWS 内通信で他アカウントにサービスを提供することができる。
なんとエンドポイントサービス自体は完全無料

エンドポイント

他サービスにプライベートな通信を行う側。
エンドポイントを作成することでインターネットを経由せず AWS 内通信で他アカウントのエンドポイントサービスに通信することができる。
時間料金とデータ処理料金が発生する。
料金 - AWS PrivateLink | AWS

この2つのリソースの通信方向は エンドポイント → エンドポイントサービス であり、エンドポイントサービス側から通信を始めることはありません。

本題

 エンドポイントとエンドポイントサービスは同じ Availability Zone ID を持つ AZ 同士でしか通信できません。
例えばエンドポイント側の ap-northeast-1a の Availability Zone ID でのみエンドポイントサービス側がサービスを提供している場合は下図のようになります。
f:id:rioner2525:20190205145718p:plain さて、ここで考えるべきは ap-northeast-1a 等の AZ 名と Availability Zone ID の連携がアカウントによって一意ではない点です。
この内容は AZ についてのドキュメントにも書いてあります。
リージョンとアベイラビリティーゾーン - Amazon Elastic Compute Cloud

アベイラビリティーゾーンは、リージョンコードとそれに続く文字識別子によって表されます (us-east-1a など)。リソースがリージョンの複数のアベイラビリティーゾーンに分散されるようにするため、アベイラビリティーゾーンは各 AWS アカウントの名前に個別にマップされます。たとえば、ご使用の AWS アカウントのアベイラビリティーゾーン us-east-1a は別の AWS アカウントのアベイラビリティーゾーン us-east-1a と同じ場所にはない可能性があります。

つまり、エンドポイントサービス側が ap-northeast-1a でサービス作るよ~といってもエンドポイント側では ap-northeast-1a ではない可能性があります。
エンドポイントサービス側の ap-northeast-1a がエンドポイント側での ap-northeast-1b であった場合はエンドポイントを作成できません。
※ap-northeast-1b は PrivateLink のリソース等は作成できません。
なので、きちんと対応した AZ での通信を行いたいなら Availability Zone ID での連携が必要になります。
f:id:rioner2525:20190205162101p:plain
↑連携するなら ap-northeast-1a とかじゃなくて apne1-az1 とかの方で連携しよう!

アカウント間通信の具体例

AWS PrivateLink で他アカウントとの通信を行う場合の具体例は3パターン考えられると思います。
以下、分かりやすいように図を作成しました。

①アカウント同士で AZ 名と Availability Zone ID が全一致。

f:id:rioner2525:20190808135405p:plain

同じ時期に作成したアカウント同士だと、このパターンが多いらしいです。

② AZ 名と Availability Zone ID がずれている場合(ap-northeast-1b の Availability Zone ID は一致パターン)

f:id:rioner2525:20190808135433p:plain

③ AZ 名と Availability Zone ID がずれている場合(ap-northeast-1b の Availability Zone ID が一致しないパターン)

f:id:rioner2525:20190808135523p:plain
※ap-northeast-1b は PrivateLink のリソース等は作成できないため。

この中で一番危惧すべきは③のパターンです。
もしもサービス提供側が2つの AZ にしかエンドポイントサービスを作成していなかった場合は通信が1本となる可能性があります。
レイテンシーと耐障害性のためにも作成できるすべての AZ でエンドポイントサービスを作成することがベストプラクティスとなるでしょう。

以上です。