AWS PrivateLinkに「Tunnel Endpoint」が登場
AWS PrivateLinkに、別VPC・別アカウントのネットワークセグメントへプライベートに接続する新しいエンドポイントタイプ、Tunnel Endpointが追加されました。
従来のAWS PrivateLinkでは、公開したいロードバランサーやデータベースなど、個別のリソースごとにResource Configurationを作成する設計が中心でした。今回の機能では、提供側がネットワーク内のCIDR範囲を1つのResource Configurationとして表現し、AWS Resource Access Manager(RAM)で共有できます。利用側はTunnel Endpointを作成し、GENEVEカプセル化を用いたトンネル経由で、そのCIDR範囲に含まれるリソースへアクセスします。
これは、外部ベンダー連携やマルチアカウント環境で、接続対象が複数あるケースの設計を簡素化するものです。
従来方式との違い
従来のリソース単位のPrivateLink接続と、Tunnel Endpointの違いは次のとおりです。
| 観点 | 従来のリソース単位の接続 | Tunnel Endpoint |
|---|---|---|
| 共有単位 | 個別のリソース | CIDR範囲 |
| Resource Configuration | リソースごとに作成 | ネットワークセグメント単位で作成可能 |
| 複数リソースへの対応 | 対象ごとに設定が必要 | CIDR範囲内の複数リソースをまとめて対象化 |
| 主な用途 | 特定サービスの公開 | 外部組織へのネットワークセグメント共有 |
| 通信方式 | PrivateLinkによるプライベート接続 | GENEVEカプセル化によるトンネル接続 |
たとえば、外部ベンダーが利用するリソースとして、API、内部管理画面、データベース、監視用エンドポイントなどが同じネットワークセグメントに存在するとします。従来はリソースごとに公開設定を用意する必要がありましたが、Tunnel Endpointでは対象CIDRを共有することで、接続構成をまとめやすくなります。
接続の基本的な流れ
構成の概念は次のようになります。
- 提供側のVPCで、共有対象のCIDR範囲をResource Configurationとして定義する
- AWS RAMを使って、外部ベンダーや別アカウントへ共有する
- 利用側のアカウントでTunnel Endpointを作成する
- 利用側からGENEVEカプセル化された通信をトンネル経由で送信する
- 提供側のCIDR範囲内にある対象リソースへ到達する
利用側アカウント
アプリケーション
|
v
Tunnel Endpoint
|
| GENEVEトンネル
v
提供側アカウント
Resource Configuration
|
v
共有対象CIDR
├─ API
├─ データベース
└─ 内部サービス
重要なのは、これはVPC全体を無条件に接続する機能ではなく、提供側がResource Configurationで示したCIDR範囲を接続単位として扱う点です。適切なCIDR設計を行えば、VPC PeeringやTransit Gatewayで広範囲のルートを共有するよりも、接続対象を限定しやすくなります。
外部ベンダー連携での実務上のメリット
外部ベンダーに複数の内部リソースを利用させる場合、Tunnel Endpointには次のメリットがあります。
- リソースごとに接続公開の構成を作る運用を減らせる
- ベンダーごとに共有対象のCIDR範囲を分けやすい
- VPCやアカウントをまたぐ接続を、インターネット経由にせず構成できる
- 既存のネットワークセグメントにある複数リソースをまとめて扱える
- SaaS事業者が顧客アカウントへ接続する際の構成パターンを標準化しやすい
特に、接続先リソースが増減する環境では、個別リソースを都度公開する方式よりも、セグメント単位で接続契約を設計できる点が有効です。
一方で、CIDRを共有することは、個別リソースだけを公開するよりもアクセス範囲が広くなる可能性があります。接続が簡単になることと、アクセス制御が自動的に細かくなることは別なので、設計時には注意が必要です。
セキュリティ設計で押さえるポイント
CIDR範囲を最小化する
Resource Configurationに指定するCIDRは、外部ベンダーが実際に利用するリソースだけを含む専用サブネットや専用セグメントに分離するのが基本です。既存の広いCIDRをそのまま共有すると、将来その範囲に追加されたリソースまで接続対象になり得ます。
ネットワーク構成を次のように分けると、公開範囲を管理しやすくなります。
- ベンダー接続専用サブネット
- ベンダーごとに分離した接続用CIDR
- アプリケーション用サブネット
- データベース用の非公開サブネット
IAMとネットワーク制御を分担させる
AWS RAMによる共有操作やTunnel Endpointの作成は、IAMで許可する管理操作です。一方、実際にどの通信を許可するかは、対象リソース側のセキュリティグループ、ネットワークACL、ルート、アプリケーション認証などを含めて設計します。
IAMで共有を許可しただけで、アプリケーション上の認証認可が不要になるわけではありません。ネットワーク到達性、ポート単位の許可、アプリケーションレベルの認証を分けて考える必要があります。
ベンダー単位で境界を設ける
複数の外部組織に接続する場合は、次のような単位で管理すると、契約終了時の切り離しや監査が容易になります。
- ベンダーごとのAWSアカウント共有
- ベンダーごとのResource Configuration
- ベンダーごとの専用CIDRまたはサブネット
- ベンダーごとの接続用IAMロール
- ベンダーごとのログ、監視、変更管理
Tunnel Endpointは接続方式を簡素化しますが、誰にどの範囲を共有したかという台帳管理は引き続き必要です。
Transit GatewayやVPNとの使い分け
Tunnel Endpointは、既存のネットワーク接続方式をすべて置き換えるものではありません。接続要件に応じて使い分けるべきです。
| 方式 | 向いているケース | 注意点 |
|---|---|---|
| Tunnel Endpoint | 外部ベンダーに特定CIDRのリソース群を共有したい | CIDR単位のため公開範囲を慎重に設計する |
| リソース単位のPrivateLink | 特定のサービスだけを公開したい | リソースが増えると構成管理が増える |
| Transit Gateway | 複数VPC・複数ネットワークを広域に接続したい | ルーティングと接続範囲の管理が複雑になりやすい |
| Site-to-Site VPN | 拠点や外部ネットワークと暗号化トンネルを張りたい | VPN装置、経路、冗長化などの設計が必要 |
| VPC Peering | 少数のVPC間を直接接続したい | 大規模な多対多接続では管理が難しくなる |
外部ベンダーに限定した範囲だけを提供するなら、Tunnel Endpointは候補になりやすい構成です。反対に、組織全体のネットワークを相互接続したい場合や、拠点ネットワークをAWSへ延伸したい場合は、Transit GatewayやSite-to-Site VPNの方が適する可能性があります。
料金面での注意
Tunnel Endpointには、次の料金が発生します。
- Tunnel Endpointの利用時間に応じた時間単位の料金
- Tunnel Endpointを通過するデータ処理量に応じた料金
接続先が複数のベンダーに分かれる場合や、開発・検証・本番でエンドポイントを分ける場合は、エンドポイント数が増えて固定的な時間料金も増加します。また、大容量データをデータベースやファイルサービスへ転送する用途では、データ処理量に基づく料金が無視できない場合があります。
設計段階では、次の項目を見積もるとよいでしょう。
- ベンダー数と環境数
- 常時稼働させるTunnel Endpoint数
- 月間の通信量
- 大容量転送の有無
- 接続対象を個別PrivateLinkにする場合との料金差
- Transit GatewayやVPNを利用した場合の関連コスト
具体的な単価はリージョンや料金体系によって異なるため、導入時にはAWS PrivateLinkの料金情報を基に見積もります。
導入時のチェックリスト
Tunnel Endpointを採用する場合は、次の順で設計すると整理しやすくなります。
- 外部組織に公開するリソースを一覧化する
- 公開対象を専用CIDRまたは専用サブネットへ分離する
- Resource Configurationで共有する範囲を定義する
- AWS RAMの共有先アカウントと管理者を決める
- 利用側のTunnel Endpoint作成権限をIAMで制限する
- 対象リソース側でポート、送信元、認証方式を制御する
- 通信量とエンドポイント数から料金を見積もる
- ベンダー契約終了時の共有解除とエンドポイント削除手順を用意する
まとめ
Tunnel Endpointの重要な点は、AWS PrivateLinkを個別リソースの公開機能から、CIDR単位でネットワークセグメントを共有する接続手段へ拡張することです。
外部ベンダーや別アカウントへ複数の内部リソースを提供する場合、Resource ConfigurationとAWS RAMを組み合わせることで、接続構成の標準化と運用負荷の削減が期待できます。GENEVEトンネルによるプライベート接続であることも、インターネットに公開せず連携したいシステムにとって実務的な利点です。
ただし、CIDR単位の共有は利便性と引き換えに、個別リソース公開より広い到達範囲を持つ可能性があります。専用セグメント、IAM、ネットワーク制御、アプリケーション認証、料金管理を一体で設計することが、Tunnel Endpointを安全かつ効果的に利用するポイントです。
本機能は、米国、アジア太平洋、欧州などの対象リージョンで提供されています。利用可能なリージョンや詳細な設定方法は、AWS PrivateLinkのドキュメントで確認できます。
出典: AWS What’s New
