株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

Amazon WorkSpaces検証 Part1:AWSベースの仮想デスクトップ基盤を探る

皆様、こんにちは。

ネットワールド SEの目木です。

今回はAWS初学者である私がAWSのVDIソリューションであるAmazon Workspacesの検証を行うことになりましたので、そのもようをお届けしたいと思います。

ちなみに、筆者自身はCitrix製品を担当するエンジニアでしてAWSについては全くの初心者になります。ところどころ大雑把に進めてしまう箇所も出てくるかとは思いますが、
その点についてはどうかご容赦ください。

一方で、VDIシステムの導入経験については豊富にございますので、VDIエンジニアの視点から気になるところを深堀りして調査し、皆様にお伝えできればと思いますので、よろしくお願いいたします。

今回は第1回ということで、まずは以下の内容について調べていきたいと思います。

  • 製品概要 -Amazon Workspaceとは?-
  • 事前準備 -ユーザ管理環境の整備-
  • 価格体系 -コスト管理のために-

製品概要 -Amazon Workspacesとは?-

"あらゆるワークロードに対応する、安全で信頼性の高いフルマネージド型仮想デスクトップ"というのがAWSのサイトに書かれた紹介文ですが、実際にドキュメントを見てみると認証用のポータルサイト、画面転送用のゲートウェイ、ユーザが利用するWorkspace(VDI)からなるサービス、というのが実態のようです。

パッと見で理解するには以下のサイトに掲載されている構成図をおススメします。

参考:Amazon Workspace Architecture

https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html

ここで書かれている接続フローとしては、

  1. Auth/Session Gatewayにアクセスしてユーザ認証を行う
  2. ユーザ認証の結果をもとに割り当てられているWorkspaceの起動が開始される
  3. Streaming Gatewayへリダイレクトされる
  4. Streaming Gatewayを介してWorkspaceとセッションを形成し、ログインする

となっています。

念のため、各コンポーネントの役割についても簡単に整理しておきましょう。

【AWS管理】

  • Auth / Session Gateway
    ユーザ認証用途のゲートウェイ
    ユーザ認証を仲介し、認証を通過したユーザのStreaming Gatewayへのリダイレクトを行う
  • Streaming Gateway
    ユーザ端末からWorkspaceへの通信を通すゲートウェイ
  • AWS Managed Microsoft AD / Simple AD / AD Connect
    Amazon Workspacesの利用ユーザ情報を管理するためのディレクトリサービス
    ユーザ管理のオンプレADを利用する場合は、AD Connectが認証を仲介する

【ユーザ管理】

  • Workspace展開先となる環境(VPC、サブネット、NSGなど)
    Workspace自体はユーザ管理の環境に展開されるため、その基盤となるネットワークおよびセキュリティグループが必要となる
  • Workspace
    ユーザが利用するAmazon Workspacesにて管理されるVM
    ユーザとVMは1:1の関係で展開される
  • EC2 – Microsoft AD
    ユーザ管理のAD ※マネージドディレクトリサービスを利用する場合は不要

基本的にはAmazon Workspaces管理下の環境として構成することになりますが、展開先のインフラ環境とユーザ管理のADサーバについては事前に準備が必要となります。(マネージドADも利用可)

次回以降でAmazon Workspacesを構築していきますので、今回はユーザ管理の基盤部分について構成しておきます。

事前準備 -ユーザ管理環境の整備-

環境としては最低限で構わないため、簡易フローから構成してみました。

VPCの構成フロー
  • VPC
  • サブネット(AZ 2か所、パブリックサブネットあり)
  • ルートテーブル(パブリック向け共通、プライベート向け個別で作成)
  • ゲートウェイ(NAT、インターネット)←外部アクセス用として構成しています
  • エンドポイント(S3)←特に使わないかもしれません

Workspaceの管理用にドメインサーバが必要となりますが、今回はEC2インスタンスでADサーバを用意してそちらと連携することにしました。

この時点で出来上がったのが以下のような環境です。

今後はこちらの環境にAmazon Workspacesを展開していきます。

 

価格体系 -コスト管理のために-

最後にAmazon Workspacesの価格体系について調べておきましょう。

Amazon Workspacesの課金の種類については、月額課金となるインフラおよびストレージの利用料金と、従量課金/月額課金から選択可能なWorkspaceの利用料金という2つに分けて理解する必要があります。
このインフラ部分の例としては、Auth/Session Gateway、Streaming Gateway(画面転送)の利用料が含まれます。そのため、クラウドVDIの利用において頭を悩ませるネットワークトラフィックに対する課金については比較的予想しやすいものとなります。

以下は価格表からの抜粋ですが、割り当てるCPU、メモリリソースが大きいほど、またストレージ容量が大きいほど金額も高くなります。このあたりはEC2と同じような感覚ですが、Workspaceの利用に関する従量課金についてはEC2の場合と比較して高めの設定となっておりますので、一般的な業務時間内で定常的に利用(1日8時間)する場合は月額課金が推奨と考えてよさそうです。

インスタンス
サイズ

ディスク
サイズ

価格

備考

Performance:
2vCPU,
8GB RAM

10GB

従量課金
 Workspace課金:0.58 USD/時間
 インフラ+ストレージ料金:10.00 USD/月

※EC2との料金比較
m5.large (2vCPU, 8GB RAM) = 0.216 USD/時間

月額課金
 57 USD/月

※従量課金との比較
月あたり82時間以上利用している場合は、月額課金の方が安い(3-4時間/1日利用×20日)

50GB

従量課金
 Workspace課金:0.58 USD/時間
 インフラ+ストレージ料金:14.00 USD/月

 

月額課金
 60 USD/月

 

Power:
4vCPU,
16GB RAM

10GB

従量課金
 Workspace課金:0.87 USD/時間
 インフラ+ストレージ料金:10.00 USD/月

※EC2との料金比較
m5.xlarge (4vCPU, 16GB RAM) = 0.432 USD/時間

月額課金
 106 USD/月

※従量課金との比較
月あたり110時間以上利用している場合は、月額課金の方が安い(4-5時間/1日利用×20日)

50GB

従量課金
 Workspace課金:0.87 USD/時間
 インフラ+ストレージ料金:14.00 USD/月

 

月額課金
 109 USD/月

 

なお、Amazon Workspacesの課金では初月の課金は月の残日数をもとに算出されますが、月の途中でマシンを削除したとしてもその月は最後まで利用したものとして料金が発生します。
そのため、テスト用途にて削除、展開を繰り返した場合はその回数分だけ課金計算が発生しますし、それが月の前半であればあるほど月額部分のコストが嵩みます。

インフラ、ストレージの利用料金が月額課金固定と設定されていることもあり、この点は避けることができない要素ですので注意が必要となります。

 

今回のまとめ

今回はAmazon Workspaces とは何なのかを知るために、ソリューションとしての概要を追ってみました。おおまかには以下のようなイメージになります。

  • AWSが提供するフルマネージド型VDI
  • VDIおよびセッションブローカーを提供しつつユーザ環境への接続も可能
  • 1台から構成可能で課金額は台数、起動時間、マシンスペックに依存

構造としてはマネージドサービスが中心にあるだけでそこまで複雑なものではなさそうです。課金体系もシンプルですし、AWS上に設置したVDIをどこからでも利用できるようにする簡易的なソリューションのように見受けられます。

あとは実際に検証しつつどんな機能が実装されているのか、次回以降のパートで深堀りしていきたいと思いますので、Part2にもご期待ください。