はじめに
システム間連携において、接続方式や名前解決方式の決定は重要な要素の一つです。AWS上では様々な連携方式が存在しており、それぞれ特徴が異なります。本記事では、特にPrivateLinkに着目し、制約や方式など特徴を解説します。（ちょっとがバクラ要素もあり）
ガバメントクラウドにおけるシステム間連携
以下に解説されています。
従来の基本的なシステム連携のパターンとしては、ファイル転送、ディスク共有、データベース共有、PRCやWebサービスなどのアプリケーション連携、メッセージングなどであるが、これらの連携方法のアーキテクチャは互いのシステムの依存関係が強く密結合しているケースが多く、1つのシステムの障害や変更の影響が全体に及びやすい。そのため比較的規模の小さいシステム間の連携の際に活用することを推奨する。一方でガバメントクラウドにおいてはモダン化の観点からAPI連携の使用を推奨する。
とのことです。
つまり原則として、ファイル共有や独自のプロトコルでの共有などは変更時の影響が大きいため、APIベースでの連携を原則とするということです。APIベースでの連携を行うことにより、各システムはAPIを公開すれば良いだけですので、APIとの通信のみを考慮すればよいだけです。APIの先は構成がどうであろうと考える必要はありません。以下にアーキテクチャ例が公開されているように、APIGatewayを他システムに共有することで連携を行うという推奨構成になっています。
では、今回解説するPrivateLinkはどうでしょうか。APIGatewayを利用しないケースや、APIベースではないものを共有したいケースも少なからずあるはずです。その場合、VPCPeeringやTransitGatewayが選択肢に入るでしょう。しかしながら、いずれの場合も、IPアドレスの重複は許されず、通信ルールの制御は送信元、送信先でコントロールする必要があります。ルールを間違えれば、想定外の通信が可能になるなど、場合によっては過剰かつリスクになることもあります。そこで今回はPrivateLinkに注目して解説を行います。
ネットワーク接続の想定ケース(復習)
以下に解説しているのですが、ちょっとだけ復習です。
ガバメントクラウドの利用において、以下のようなネットワーク接続が想定されます。
想定される接続ケース
- 省庁職員からVPCへのアクセス
- 同一システム内の別VPCアクセス
- クロスリージョンVPC接続
- 他システムとのVPC接続
- オンプレミス拠点との接続
- 運用拠点との接続
- 国民等の一般利用者アクセス
- 他CSP（クラウドサービスプロバイダー）とのVPC接続
接続方式と考慮点
以下のような方式が考えられます。
特徴を踏まえてそれぞれのパターンを適切に選定することが重要です。
ガバメントクラウドにおける接続指針
国の行政機関においてはガバメントクラウドでの一般ユーザー・各府省拠点からの接続やシステム間連携の接続はセキュリティが十分担保された上でインターネット経由での接続を基本とし、同一CSP間のシステム連携は、CSPサービスの利用を検討すること。ただし、各府省拠点からの接続について、インターネット経由での接続を許容できない場合は、デジタル庁ガバメントソリューションサービス（以下GSSネットワークとする）経由での接続や専用線を用いた閉域網での接続を検討すること。利用組織共通で利用するサービスがガバメントクラウドで稼働する場合の拠点やデータセンタからの接続や、共通サービスへのガバメントクラウド上のシステムからの利用で使用する接続も提供される。
インターネット経由での接続に際しては、ゼロトラストの原則とCSPが提供する各種提供サービスを利用して安全でスケーラブルなアーキテクチャを構築することを推奨する。
一方で、VPC間の接続については以下のように触れられています。
VPCPeeringやPrivateLink方式など、AWSのマネージドサービスを利用した方式が推奨されていると考えてよいでしょう。
そもそもPrivateLinkとは
おまたせしました。いよいよ本題のPrivateLinkです。
PrivateLinkは以下のような特徴を持つものです。
- コンシューマからプロバイダーにプライベートに通信可能
- コンシューマとプロバイダーのCIDR重複があっても通信可能
- コンシューマからプロバイダーへの片方向通信で、必要な通信に絞ることが可能
従来のPrivateLink
従来PrivateLinkというと上記のような構成を想像すると思います。
コンシューマーにはVPCEndpointを用意し、プロバイダー側にはエンドポイントサービスと紐づけるNLBを用意する構成です。対応プロトコルは、TCP、UDPで、クロスリージョン接続がサポートされます。
制約
ただし以下のような制約があります。
前段にはNLBが必須であり、コンシューマのVPCエンドポイントとプロバイダー側のAZは一致させる必要があります。例えば、３AZ構成のコンシューマが２AZ構成のプロバイダーに接続しようとしても、１AZでは通信ができません。
制約に対する解決アプローチ
このような構成を取るケースがあるかと思います。
間に中継となるVPCを配置します。ここで、VPCピアリングを行い、ピアリング先にVPCエンドポイントを配置することで、AZ差があるVPCともPrivateLinkで接続が可能となります。また、コンシューマ、プロバイダーはそれぞれ中継するVPCとしか通信ができないため、不要な通信が許可されるリスクもありません。ただし、VPC、Peeringが増えるため、構成が複雑となることがデメリットとなります。
最新のPrivateLink事情
いっぱいありますね。従来のと言っていたものが上から２番目です。GatewayVPCや、ResourceGateway、Latticeなど様々なものが追加されています。
今回はResource型、Lattice型を深堀りしてみます。
Resource型
まずコンシューマにはResource型のVPCエンドポイントを作成します。
プロバイダー側には、ResourceConfigurationでターゲット情報を設定、各AZにはResourceGatewayを配置し、そこから任意のリソース（RDS、ALBなど）に接続します。従来のNLBのみという制約はありません。ただし、ResourceGatewayにはロード・バランシング機能はありません。マッピング先にロードバランシング機能を持ったものをマッピングすれば利用可能です。
制約は？
先程のAZ制約は、この場合ありません。VPCエンドポイントとリソースゲートウェイのAZが少なくとも１つ一致すれば通信が可能です。また、NLBを配置する必要もありません。
一方で、対応プロトコルは、TCPのみ、クロスリージョン接続不可、VPCエンドポイントがインターフェースタイプより少し高額という特徴があります。
Lattice
次にLatticeを見ていきます。
VPCLatticeは、Latticeサービスネットワークというものをコンシューマに紐づけ、そのネットワーク空間を利用して登録したサービスに通信するものです。ただし、サービスネットワークは１VPCあたり１つのみです。サービスネットワークはコンシューマ、プロバイダーどちらのアカウントに作成しても問題ありません。管理する側に作成することが一般的でしょう。Latticeサービスを定義し、サービスネットワークに紐づけます。対応プロトコルは、HTTPS、HTTP、gRPC、TCPです。カスタムドメイン、デフォルトドメインどちらでも通信が可能で、デフォルトドメインでもHTTPS通信が可能です。Latticeサービスネットワークには、複数のサービスが定義できるため、通信先、元が複数ある場合、大活躍するでしょう。また、IAM認証を利用することができ、セキュアな接続制御が可能です。さらに、サービス単位で、L7，L4のロード・バランシングも利用可能です。
制約は？
従来型と比較し、サービスネットワークを利用すため、AZ制約はありません。クロスリージョン接続が利用不可であることはResource型と同じです。
また、サービスやデータ処理に費用がかかります。一概に高くなるとは言えませんが、費用見積もりや費用対効果の算出は必要です。
適用ケース
このように複数のコンシューマ、プロバイダーが存在し、統合管理したいケースに向いているでしょう。
TransitGatewayと似ている？と言われることもあるかと思いますが、TransitGatewayは推移的な接続や、ルーティング、専用線接続などの統合などを担っているのに対し、Latticeは、一つ上のサービス単位でのルーティング、接続制御などを行うことが特徴です。TransitGatewayが本当に必要か、VPC間の接続であれば、Latticeを利用することで、IPレンジの一致が不要となるため、検討するとよいでしょう。
方式比較
比較すると、特徴が見えてきます。従来型は、UDPやクロスリージョン接続をサポートしていますが、ResourceGateway型はTCPのみです。一方でAZ制約の緩和や接続先にNLB接続が不要です。Latticeはもっと高度で、接続先が多い場合などに適しているでしょう。
選定ポイント
まとめ
VPC 間通信の方式は、これまで主に VPC ピアリング や Transit Gateway が使われてきましたが、現在では PrivateLink（Interface / Resource Gateway / Lattice） も有力な選択肢として検討すべき段階にあります。各方式で コスト構造・通信レイヤー・セキュリティ要件・運用負荷 が異なるため、単に「接続できるか」ではなく、要件・セキュリティ・コストを総合的に比較したうえで最適な方式を選定することが重要です。