2025年7月17日に公開された AWS 公式ブログ「Amazon WorkSpaces Personal を AWS PrivateLink で接続する」をご存知でしょうか？
この記事を見かけたとき、ふとある期待がよぎりました。 「もしかして、手元の端末から VPN 経由（プライベート IP アドレス）のみで WorkSpaces に接続できるのでは？」
もしこれが可能なら、インターネットへのアウトバウンド通信を厳しく制限している環境でも WorkSpaces が導入しやすくなります。 早速検証してみたところ、「認証」と「ストリーム通信」の仕様の違いにより、完全な閉域化には一筋縄ではいかない課題が見えてきました。
本記事では、PrivateLink を利用した WorkSpaces 接続の検証結果と、構成上の注意点を共有します。
結論：完全な閉域化は（現時点では）難しい
先に結論からお伝えすると、PrivateLink を使っても インターネット経由の通信を完全にゼロにすることはできませんでした。
理由は WorkSpaces の通信仕様にあります。WorkSpaces の通信は大きく分けて以下の2つで構成されています。
- 認証 (Authentication): ログイン画面の表示や ID/PW の送信
- ストリーム通信 (Streaming): 実際のデスクトップ画面転送や操作
今回の検証で、PrivateLink に対応しているのは「2. ストリーム通信」のみ であり、「1. 認証」に関しては従来通りインターネット経由で行う必要があることが判明しました。
検証環境と構成図
PrivateLink を利用した構成（検証構成）
検証のために構築した構成は以下の通りです。VPN 経由で AWS 環境に接続し、そこから PrivateLink 経由で WorkSpaces にアクセスすることを想定しています。
まず、名前解決に関しては Route 53 Resolver Inbound Endpoint 等を利用することで、プライベートに行うことができます。
ただし、PrivateLink 用の DNS 設定（Route 53 Inbound Endpoint や Private DNS）で解決されるのは、「ストリーム通信用（highlander）」のドメインだけ です。
認証に使われるドメイン（API エンドポイント）は、引き続き パブリック DNS で解決され、パブリック IP アドレスが返ってきます。
実際の通信に関しては以下の構成図の通り、ストリームセッション（青線）は PrivateLink を通って VPN 内で完結しますが、認証 API へのアクセス（赤線）はインターネット経由 となります。 これは、現在 WorkSpaces の認証 API 用の VPC エンドポイント (PrivateLink) が提供されていないため です。
通常のインターネット接続構成（比較用）
参考までに、通常の WorkSpaces 利用時の構成は以下のようになります。認証もストリームもすべてインターネット経由です。
名前解決の経路：
認証とセッション接続の経路：
構築してわかった3つの「壁」
実際に構築を進める中で、いくつかの重要な制約（壁）にぶつかりました。
1. プロトコルの制約：PCoIP は非対応
まず前提条件として、この PrivateLink 機能は Amazon DCV (旧 WSP) プロトコルの WorkSpaces でのみ利用可能です。PCoIP を利用している既存の WorkSpaces では利用できません。
VPC エンドポイント機能は、Amazon DCV を使用する WorkSpaces に対してのみ使用できます。[...] 同じディレクトリにある PCoIP WorkSpaces のインターネットストリーミングを有効にできます。
2. 名前解決の壁：Route 53 Inbound Endpoint が必須
ここが構築で一番手間がかかるポイントです。 WorkSpaces の VPC エンドポイント（PrivateLink）を作成すると、プライベート DNS 名が発行されますが、これはパブリックには解決できません。
VPN 接続しているクライアント端末が、「WorkSpaces のストリーミング用ドメイン」を「VPC エンドポイントのプライベート IP」として解決するためには、以下の仕組みが必要になります。
- Route 53 Inbound Endpoint の作成
- オンプレミス（またはクライアント側）の DNS サーバーから、WorkSpaces 関連ドメインを Inbound Endpoint へ転送する設定（条件付きフォワーダ等）
一方、インターネット接続の場合は、パブリック DNS を使うだけなので非常にシンプルです。
3. IP 制限の仕様：IP アクセスコントロールグループは「使用不可」
セキュリティを重視する環境では「IP アクセスコントロールグループ」を用いて接続元 IP を制限するのが一般的です。しかし、PrivateLink 構成においては、この機能自体が 強制的に無効化（適用対象外） になります。
VPC エンドポイントがディレクトリに設定されている場合、そのディレクトリに指定された IP アクセスコントロールグループは適用されなくなります。
つまり、PrivateLink 利用時のアクセス制御は、WorkSpaces 機能の IP 制限ではなく、VPC エンドポイントにアタッチする「セキュリティグループ」 で行う必要があります。
これは、「認証（インターネット）」フェーズの IP 制限を行う手段がなくなる（ID/PW/MFAのみに依存する）ことを意味しており、セキュリティ設計上の大きな注意点です。
その他、導入前に知っておくべき制約事項
今回の検証で判明した点以外にも、PrivateLink 構成にはいくつかの重要な前提条件があります。特にネットワーク設計に関わる以下の点には注意が必要です。
- WorkSpaces Personal 専用: WorkSpaces Pools (旧 WorkSpaces Web 等) はサポートされていません。
- 共有 VPC (Shared VPC) は非対応: ディレクトリと VPC エンドポイントは同じ AWS アカウントにある必要があります。他のアカウントから共有された VPC にエンドポイントを作成する構成はサポートされていません。
- FIPS 暗号化 / Global Accelerator 非対応: これらの機能と併用することはできません。
検証
実際に構築を行い、どこで躓くかを確認しました。
1. VPC エンドポイントの作成
まず、VPC エンドポイントで使用するセキュリティグループを用意しました。 ルールは HTTPS (TCP 443) に加え、DCV プロトコルで利用される UDP 443 も許可しておきます。
次に、VPC に com.amazonaws.ap-northeast-1.highlander の VPC エンドポイントを作成しました。
highlander は Amazon WorkSpaces のストリーミング通信用のサービス名（おそらく内部コードネーム）です。
2. ディレクトリ設定の変更
ディレクトリの設定で「VPC エンドポイントを使用する」設定に変更します。 これにより、インターネット経由ではストリームセッションが使用できなくなります（PrivateLink 必須化）。
3. IP アクセスコントロールグループによる接続不可の確認
ここからが検証の本題です。 試しに IP アクセスコントロールグループ (IP ACG) に、「VPC の CIDR からの通信のみを許可する（パブリックIPを含まない）」ものを作成し、ディレクトリに関連づけてみます。
接続を試したところ、「認証」画面に行けずエラーになりました。
この時、PowerShell で以下のコマンドを実行して通信先を確認しました。
Get-NetTCPConnection -RemotePort 443 -State Established ...
結果、WorkSpaces のサービスエンドポイントへの通信は確立されていませんでした（認証サーバーに到達する前に IP 制限で弾かれている状態）。
4. パブリック IP を許可しても...？
次に、IP アクセスコントロールグループに私のクライアントのパブリック IP アドレスを追加しました。 すると、「認証」画面には接続できるようになりました。
WorkSpaces のサービスエンドポイントへの通信を確認すると、パブリック IP アドレスへの通信（認証トラフィック）が確認されました。
しかし、認証に成功した後、今度はストリームセッションの接続でエラーになりました。 ドキュメントの記載通り、PrivateLink 有効化環境では IP アクセスコントロールグループが正常に適用されない（あるいは競合して拒否される）挙動となるようです。
5. 解決策：IP アクセスコントロールを外す
IP アクセスコントロールグループの関連付けを解除します。 その代わり、アクセス制御は VPC エンドポイントにアタッチしたセキュリティグループ で行います。
これで無事に接続できました！
この状態で、インターネット経由（VPN を切断した状態）では接続できないことも確認し、PrivateLink 経由での接続制限が効いていることを確認しました。
まとめ：WorkSpaces PrivateLink vs Windows EC2
今回の検証結果を踏まえ、WorkSpaces (PrivateLink) と、単純な Windows EC2 (RDP over VPN) の違いをまとめました。
| 項目 | WorkSpaces (PrivateLink) | Windows EC2 (推奨) |
|---|---|---|
| 通信経路 | 一部インターネットを経由 (認証) | 100% プライベート (VPN内) |
| IP 制限 | IP ACG は使用不可(VPC EP の SG で制御) | プライベート IP のみで完結(EC2 の SG で制御) |
| 追加インフラ | Inbound Endpoint / DNS転送設定が必要 | 一切不要 |
| 構築・運用 | 複雑 (仕様による制約が多い) | シンプル (標準的なRDP接続) |
所感
「WorkSpaces を閉域網で使いたい」というニーズに対して、PrivateLink 対応は大きな一歩ですが、現時点では「認証の壁」により完全な閉域化までは至っていません。
もし、「インターネットに一切出たくない」「社内ネットワークからプライベート IP だけで完結させたい」 という要件が最優先であれば、無理に WorkSpaces を使うよりも、EC2 (Windows) を立てて VPN 経由で RDP 接続する構成 の方が、構築も運用も圧倒的にシンプルになります。
WorkSpaces の採用を検討する際は、この「認証の通信経路」を許容できるかが大きな判断ポイントになりそうです。
余談
今日の山。群馬県の平標山です。夏の写真です。(今は豪雪の中です。)
