2025年にWorkSpacesのPrivate 接続（Private Endpoint）がGAされました。
GA時に検証した記事はこちら
https://qiita.com/s-niim/items/2c7fbe002a0f84c43d13
待望の機能でしたが、実際に検証したところ、DNS周りの仕様が原因で、思った以上に構成上の制限があることがわかりました。
この記事では、特に重要なポイントである
「WorkSpaces Private Endpointの DNS名がリージョン単位で固定されている」
という仕様がどんな問題を生むのかを整理します。
制約のまとめ
WorkSpaces Private接続のPrivate Endpointは、以下の4つの制約があります。
・EndpointのDNS名はリージョンで一意（固定）
・Private DNSなのでオンプレからの接続にはDNSフォワードが必須
・Endpointのドメイン「aws.a2z.com」はパブリックDNSの一部 → Proxy除外が必要
・Private Endpoint に紐づけられる WorkSpaces Directory は 同一アカウントのみ
その結果
同じリージョン内で、複数AWSアカウントのWorkSpacesに対してPrivate 接続を利用することができない
なぜこうなるのか、以下で詳しく解説します。
イメージ図
1. WorkSpaces Private Endpoint のDNS名はリージョン単位で固定
WorkSpaces Private接続で作成されるPrivate Endpointには、次のようなPrivate DNSが割り当てられます。
privatelink.prod.(region).highlander.aws.a2z.com
重要なのは、あるリージョン内でどのアカウント、どのVPCでEndpointを作成しても、このDNS名は同じという点です。
つまり：
・WorkSpaces A 用にEndpointを作っても
・WorkSpaces B 用にEndpointを作っても
→ 同じ DNS 名になる
これは後述するフォワード設定にも大きく関係します。
2. Private DNS 名なのでオンプレからは DNS フォワードが必須
このDNS名はPrivate DNSであり、名前解決できるのはVPC内のみです。
WorkSpacesがクラウドVDIであることから、通常WorkSpacesのクライアント端末はオンプレミスでVPC外にあると考えられます。
オンプレミス環境からWorkSpaces Private接続を利用する場合、
オンプレ DNS → Route 53 Inbound ResolverまたはVPC内DNS
というDNSフォワード設定が必ず必要になります。
フォワードを行わないと、オンプレ側のWorkSpacesクライアントはPrivate EndpointのDNS名を解決できず、接続できません。
3. 「aws.a2z.com」はAWSの使用するパブリックドメインの一部 → Proxy除外が必要
WorkSpaces Private Endpointのドメイン名は「aws.a2z.com」のサブドメインです。
このドメインは一般に「AWSのパブリックサービス向けDNS」として扱われることが多く、企業ネットワークでは外部接続としてProxyで名前解決する対象になっているケースがあります。
しかしPrivate接続では、Proxy経由の外部接続ではなく、端末からの内部への接続(端末でのDNS解決)が必要です。
そのため、
・「privatelink.prod.(region).highlander.aws.a2z.com」をProxyから除外
・内部のDNSフォワードの経路を優先
といった特別なDNS／Proxyの調整が必要になります。
4. Private Endpointは複数Directoryに関連付け可能だが同一アカウント限定
1つのPrivate Endpoint に対し、複数のWorkSpaces Directory を関連付けることは可能です。
しかししようとして、関連付けができる範囲は同一AWSアカウント内のみに限られます。
別アカウントのDirectoryをEndpointに紐づけることはできません。
結論：複数アカウントの WorkSpaces を同リージョンでPrivate接続することは不可能
ここまでの仕様を組み合わせると、以下の状況が生まれます。
・DNS 名はリージョン内で固定（複数アカウントでも同じ）
・オンプレDNSは同一ドメインを複数のVPC Endpointにフォワードできない
・Endpoint はアカウントをまたいで共有できない
これによって、オンプレ側のDNSは
「privatelink.prod.(region).highlander.aws.a2z.com をどのEndpointに向けるか」
をアカウントごとに切り替えることができません
つまり
同一リージョン内に複数のAWSアカウントでWorkSpacesを構築している場合、そのすべてにPrivate 接続を構成することは仕様上不可能、という結果になります。
これはどのような時に問題になるでしょうか。
例えば、東京リージョンでWorkSpacesを使用しているが、用途が複数に分かれているため、管理者が別々におり、それぞれが別アカウントでWorkSpacesを展開しているようなケースが該当すると考えます。
改善してほしいポイント
今回の検証で、WorkSpaces Private 接続には構造的な制限があることがわかりました。
特に DNS 名がリージョンで固定されている点 が、アーキテクチャの柔軟性を大きく損なっています。
以下の改善が実現されると、企業ネットワークにより適した形になると考えています。
1. DNS 名にディレクトリ固有の識別子を入れてほしい
現在のDNS名
privatelink.prod.(region).highlander.aws.a2z.com
は、リージョン内で完全に共通です。
これを例えば次のように変更し、Directory ごとに一意の DNS 名となるようにしてほしいです。
privatelink.(directory-id).(region).highlander.aws.a2z.com
これにより
・オンプレ DNS のフォワード設定を Directory ごとに分離
・複数アカウント／複数ディレクトリで Private 接続を併用可能
といった構成が可能になります。
2. Private DNS ではなく、ELB と同様に「グローバルアクセス可能な DNS 名」にしてほしい
ALB/NLB のように、Private 接続用 Endpoint もグローバルに引ける DNS 名を持つようにすれば
（例：private-workspaces-(directory-id).amazonaws.com）
DNS名は必然的に一意になりますし、かつオンプレDNSのフォワードが不要となります。
企業ネットワークのProxyやDNSが絡む問題の大半が解消されます。
AWS へのフィードバックポイント
AWSさんへ伝えたいポイントを整理すると以下です。
- Private EndpointのDNS 名をリージョン単位の固定値にしないでほしい
- Directoryごとの固有DNS名にするか、グローバルDNS名にしてほしい
- Proxyを回避するために特殊な設定が必要になるため改善してほしい
現状の仕様だと「複数アカウントのWorkSpacesを同リージョンでPrivate接続」できないことが、企業ネットワークでは大きな制約です。
特にマルチアカウント運用が前提の大規模企業にとって致命的だと思います。
WorkSpacesを本格的に企業向けに広げるには、この点の改善が不可欠だと思います。
暫定的な回避策
現状の仕様でも、ある程度実現できる構成があります。
ただし「暫定策」であり、根本的な解決にはなりません。
回避策 1. WorkSpacesをリージョンごとに分散させる
DNS名はリージョン単位で固定のため、
・アカウントA → ap-northeast-1
・アカウントB → ap-southeast-1
のようにリージョンを分ければPrivate接続を併用できます。
ただし、
・運用負荷の増大
・WorkSpacesのレイテンシ増大
という課題が発生します。
回避策 2. アカウント統合：WorkSpacesを単一アカウントに集約する
もっとも現実的なのは、
・WorkSpaces専用の共通アカウントを作る
・全ディレクトリ/WorkSpacesをここに集約する
という方法です。
ただし、
・ガバナンスがアカウント設計に依存
・部門別にアカウントを分けたい企業文化と相性が悪い
というデメリットがあります。
まとめ
WorkSpaces Private接続は有用な機能ですが、
DNS名がPrivate DNSでかつリージョン単位で固定されているため、企業のネットワーク構成に変更が必要となり、さらにマルチアカウント構成との相性が非常に悪いという問題があります。
企業ネットワークでの本格利用には、DNS周りの仕様改善が必須だと感じました。
AWSのアップデートに期待したいところです。