以前、WorkSpacesはリージョンごとの固定DNSしか持たないという制約がある、という記事を書きました。
この仕様はいろいろな制約につながるため、同記事でも以下2点を改善してほしい点としてあげました。
- DNS名にディレクトリ固有の識別子を入れてほしい
- Private DNS ではなく、ELB と同様に「グローバルアクセス可能な DNS 名」にしてほしい
先日、WorkSpacesが個別のグローバルDNS名を持つようになったと発表がありました。
「各インターフェイス VPC エンドポイントは、すべてのエンドポイントで共有されていた以前の汎用 DNS 名に加えて、AWS で管理されるグローバルに一意の DNS 名を受け取るようになります。」
とあります。これは私の記事で記載した改善してほしい点を取り込んだ機能改善のようです。
どのように変わったか早速検証したいと思います。
検証用の環境
検証用にこのような環境を作りました。(サブネット等の記載は省略しています)
VPC三つ、踏み台EC2(WorkSpaces Client)用、Endpoint用、WorkSpaces用
踏み台EC2用VPCとEndpoint用VPCはVPC Peeringで繋ぎます。
これは、「Endpointに到達はできるが、EndpointのPrivate DNSは解決できない」という環境を作るためです。
検証結果
まずは踏み台EC2にRDPし、共有のPrivate DNS名が解決できないこととEndpointのPublic DNS名(vpce~~~)が解決できることを確認します。
この状態でWorkSpaces WebAccessを使ってWorkSpacesにアクセスします。
WebAccessを使用するのは開発者ツールでWorkSpacesに対するリクエストを確認するためです。
点線部分にある通り、privatelink.prod.eu-west-1.highlander.a2z.comにアクセスしてからvpce~~~にアクセスしています。
https://docs.aws.amazon.com/workspaces/latest/adminguide/creating-streaming-vpc-endpoints.html
には
と、まずはPublic、解決できなければPrivateとありますが、どうも順番は逆のように見えます。
この動きだとPrivate DNS名が解決できる環境ではPrivate DNS名でアクセスに行くのでは？と思います。
まとめ
WorkSpacesの機能改善により、各VPCエンドポイントがグローバルに一意のDNS名を持つようになりました。
本記事では「Endpointには到達できるが共有Private DNS名は解決できない」環境を用意し、この個別DNS名を使った接続が実際に成立することを確認できました。以前の記事で提起した2つの改善要望が、まさに取り込まれた形です。
一方で、ドキュメント上は「まずPublicのDNS名、解決できなければPrivate」という順序で説明されているのに対し、実際の挙動では先にPrivateLinkのグローバルDNS名へアクセスしているように見えました。この点は、Private DNSが解決できる環境では挙動が変わる可能性があり、引き続き検証したいポイントです。
いずれにせよ、共有DNSに起因していた制約が緩和されたことで、WorkSpacesへのPrivate接続の利用がより柔軟になったと言えそうです。