どーも！shihopowerです！
今回はAWS SAP（Solutions Architect Professional）の対策をしていて出くわした、Client VPNについてまとめます。
模擬問題を解いていたら急に登場してきて、「あれ、これなんだっけ…？」となった方、私もそうでした笑。というわけで、AWS公式ドキュメントをベースにしっかり調べてみたので、同じ状況の方のお役に立てれば嬉しいです！
目次
1. Client VPNとは？
AWS公式ドキュメントによると、こんなサービスです。
AWS Client VPN は、マネージド型のクライアントベース VPN サービスです。AWS リソースやオンプレミスネットワーク上のリソースへのセキュアなアクセスを実現します。OpenVPN ベースの VPN クライアントを使用することで、どのロケーションからでもリソースにアクセスできます。
要するに、**「個人のPCからAWSやオンプレミスのリソースに安全に接続するための仕組み」**です！
主な特徴
| 特徴 | 説明 |
|---|---|
| セキュアな接続 | OpenVPN クライアントを通じて TLS 暗号化された接続を確立 |
| マネージドサービス | AWS が完全管理。自前で VPN サーバーを運用する必要なし |
| 高可用性・スケーラビリティ | 接続ユーザー数の増減に応じて自動でスケール |
| 柔軟な認証方式 | Active Directory連携・フェデレーション認証・証明書ベース認証に対応 |
| 詳細なアクセス制御 | ADグループ単位・セキュリティグループ単位でアクセスルールを設定可能 |
2. Client VPNの主要コンポーネント
Client VPN を理解するうえで欠かせないコンポーネントを紹介します。
① Client VPN エンドポイント
クライアント VPN セッションを管理するリソースです。すべての VPN セッションの**終端点（ターミネーションポイント）**になります。特定の VPC のサブネットと関連付けて使います。
② ターゲットネットワーク（Target Network）
Client VPN エンドポイントに関連付ける VPC のサブネットのことです。高可用性のために複数のサブネットを関連付けることもできますが、以下のルールがあります。
- すべて同一 VPC 内のサブネットであること
- 各サブネットは異なるアベイラビリティゾーンに属していること
③ ルートテーブル（Route Table）
Client VPN エンドポイントが持つルートテーブルで、トラフィックの転送先を決定します。
サブネットを関連付けると、その VPC へのルートは自動で追加されます。一方、ピアリングされた VPC やオンプレミスネットワークへのルートは手動で追加する必要があります。これが後述のユースケースで重要なポイントになります！
④ 認可ルール（Authorization Rules）
ネットワークにアクセスできるユーザーを制限するルールです。デフォルトでは認可ルールが存在しないため、明示的に設定しないとアクセスできない点に注意！
⑤ クライアント CIDR レンジ
VPN に接続したクライアントに割り当てる IP アドレスの範囲です（例：10.2.0.0/16）。接続ごとにこの範囲内から一意の IP が割り当てられます。
3. Site-to-Site VPNとの違い
SAPの試験でよく混同しがちなのが Site-to-Site VPN との違いです。一言でいうと、
Site-to-Site VPN = 拠点（ネットワーク）同士をつなぐ
Client VPN = 個人（端末）とAWSをつなぐ
です！
AWS VPN 全体の位置づけ
AWS の VPN サービスは2種類あります。
- Site-to-Site VPN → あなたのネットワークと Amazon VPC / AWS Transit Gateway の間に暗号化トンネルを作成
- Client VPN → VPN ソフトウェアクライアントを使って、ユーザーを AWS またはオンプレミスリソースに接続
比較表
| 比較軸 | Site-to-Site VPN | Client VPN |
|---|---|---|
| 接続の主体 | 拠点（ネットワーク同士） | 個人（端末） |
| プロトコル | IPsec | OpenVPN（TLS） |
| 主な用途 | オフィス ↔ AWS | 個人PC ↔ AWS |
| 必要なデバイス | カスタマーゲートウェイデバイス（物理/ソフトウェア） | OpenVPN クライアントアプリ |
| トンネル本数 | 2本（冗長構成） | 接続ユーザー数に応じてスケール |
| エンドポイント | 仮想プライベートゲートウェイ（VGW）またはTGW | Client VPN エンドポイント |
Site-to-Site VPN の冗長構成について
Site-to-Site VPN は、各接続に2本のトンネルが含まれます。一方のトンネルがダウンした場合（メンテナンスなど）、もう一方に自動でフェイルオーバーします。それぞれのトンネルは異なるアベイラビリティゾーンで終端するため、可用性が担保されています。
4. 実際の構成図・ユースケース
ここからは、実際のSAP模擬問題に近いシナリオをもとに、Client VPN の使いどころを見ていきます。
シナリオ
ある会社が、感染症や自然災害などでオフィスに出社できない状況でも業務を継続できるよう、在宅勤務を許可する新しいポリシーを導入することになりました。
既存のインフラ構成はこんな感じです：
- 内部アプリケーションは サブアカウントの VPC（VPC A） にホストされている
- 現在はオフィスのオンプレミスネットワークから Site-to-Site VPN 経由でアクセスしている
- メインアカウントの VPC（VPC B） と VPC A の間には、すでに VPC ピアリング接続が確立されている
求められるのは：
在宅勤務の従業員が VPC A のアプリケーションにアクセスできるよう、スケーラブルかつコスト効率の良いソリューションを設計すること。
構成図
【オフィス出社時（既存）】
オフィスのオンプレミスネットワーク
↕ Site-to-Site VPN（IPsec）
VPC A（サブアカウント）← 内部アプリケーション
【在宅勤務時（新規追加）】
在宅従業員の個人PC
↕ Client VPN（OpenVPN / TLS）
VPC B（メインアカウント）
↕ VPC ピアリング（既存）
VPC A（サブアカウント）← 内部アプリケーション
なぜこの構成なのか？
ポイント①：Client VPN エンドポイントは VPC B（メインアカウント）に1つだけ作る
VPC ピアリングはすでに存在するので、Client VPN エンドポイントのルートテーブルに VPC A 宛のルートを手動追加するだけで、VPC A のアプリケーションにトラフィックを転送できます。エンドポイントを複数作る必要はありません。
ポイント②：エンドポイントを複数作るのはコスト増
Client VPN の料金はエンドポイントの関連付け数と VPN 接続時間に基づき時間単位で発生します。各アカウントにエンドポイントを作ると、その分コストが増えます。
ポイント③：Transit Gateway は不要
Transit Gateway は複数の VPC やオンプレミスネットワークを一元管理する強力なサービスですが、今回はすでに VPC ピアリングがあります。「最もコスト効率の良いソリューション」という観点では、既存インフラを活用するのがベストです。
各選択肢の考え方
| 選択肢 | 内容 | 評価 |
|---|---|---|
| A | 各アカウントに Client VPN エンドポイントを作成 | ❌ 過剰・コスト増 |
| B | メインアカウントに Client VPN エンドポイントを1つ作成し、ルーティングを設定 | ✅ 最もコスト効率が良い |
| C | メインアカウントにエンドポイント＋Transit Gateway を追加 | ❌ VPCピアリングがあるので過剰 |
| D | Client VPN ↔ Site-to-Site VPN を接続 | ❌ VPC A へのアクセス手段として不適切 |
5. まとめ
最後に要点を振り返ります！
- Client VPN は個人端末から AWS やオンプレミスリソースに安全に接続するマネージドサービス
- Site-to-Site VPN との最大の違いは「拠点（ネットワーク）同士」か「個人（端末）」かという接続の主体
- Client VPN エンドポイントは特定のサブネット（VPC）に関連付ける
- ピアリング先 VPC やオンプレミスへのルートは手動でルートテーブルに追加が必要
- コスト最適化の観点では、エンドポイントは可能な限り1つに集約するのが基本
SAP対策としては、「どのシナリオでどのVPNサービスを選ぶか」「なぜTransit Gatewayではなく VPC ピアリングで十分なのか」という観点を意識しておくと、本番でも迷わず答えられると思います💪
以上、Client VPN についてまとめてみました。参考になれば嬉しいです！