ご機嫌いかがでしょうか、豊崎です。

現在開催されている、AWS Summit 2018 TokyoのAmazon WorkSpaces Deep Dive アーキテクチャ設計と展開のベストプラクティスを拝聴いたしましたので、レポートしたいと思います。

概要

Amazon WorkSpaces はマネージド型の DaaS(Desktop as a Service) ですが、大規模環境などで最適に利用するためには適切なアーキテクチャ設計のノウハウが必要となります。このセッションでは、既存のネットワークに安全に 接続する方法、Active Directory を使用して WorkSpaces を管理し、ユーザーを認証する方法、およびアクセスできるデバイスを指定する方法など設計及び展開のベストプラクティスについてご説明します。

スピーカー

渡邉 源太：アマゾン ウェブ サービス ジャパン株式会社 ソリューション営業本部 ソリューションアーキテクト

レポート

前提条件

• 以下を有していること
  • AWSのサービス概要
  • Windowsシステム管理
  • 一般的なスクリプトおよびプログラミングの理解

AWSのデスクトップとアプリケーションサービス

• WorkSpaces
  • マネージド型クラウドデスクトップ
  • セキュア
  • 従量課金
  • シンプルなデプロイと管理
  • スケール＋パフォーマンス
• AppStream2.0
  • Webブラウザにデスクトップアプリケーションをセキュアにストリーミング
  • デクストップアプリケーションストリーミングサービス
  • インフラの管理不要
  • 従量課金
  • アプリケーションとデータのセキュリティ
  • グローバルにスケール可能

想定するシナリオ

• 既存のAWSのお客様
• オンプレミスとクラウドのアプリによるハイブリッドアーキテクト
• 既存のADを使用した認証
• AWS Direct Connectを利用してオンプレミスとAWS間を接続している
• 2000+ユーザ
• ハイパフォーマンスおよびGPUワークロードを行うのはユーザの10%以下
• 既存のアーキテクト例
  • オンプレミス（1.0.0.0/8）とVPC（２つ：10.10.0.0/16内で適宜切り出した）がDXで接続されている

設計のポイント

AWSアカウントとVPC設計のポイント

• AWSアカウント
  • エンドユーザ環境用に専用のAWSアカウントを使用する
  • Amazon Workspaces/AppStream2.0
  • IAMを使用してAWSアカウントへのアクセスを管理
  • リソースへの一貫したタグ付けルール
  • payerアカウントへのログの集約
• VPCの設計
  • IPアドレスの無駄遣いを避ける
  • VPCの最大サイズは/16（65000アドレス程度)
  • WorkSpacesは最小２つのサブネットが必要
  • サブネットごとに５つのIPアドレスを消費するので注意
  • リージョン内で特定の２つのAZのみで利用可能
  • 設計例
    • 最小で２つのサブネット
    • 今後の成長を想定してIP枯渇を避ける
      • イニシ ャルで2000台のWorkSpacesと成長の余地
    • お客様がAWSで利用するために
    • 10.10.０.0/16を割り当てている
      • 共有サービス用の別VPCを用意
      • ネットワークインターフェース
        • それぞれのWorkSpacesのインスタンスは２つのネットワークインターフェースを持つ
          • ETH0：サービスようインターフェース
          • ETH1：お客様が利用するインターフェース

ディレクトリ統合

• WorkSpaces
  • 全てのWorkSpacesはADドメインに参加
  • ユーザがWorkSpacesに接続するためにAWS Directory Serviceが必要
• AppStream2.0
  • フリートはドメイン参加またはスタンドアロン
  • AD参加のフリートはアイデンティティプロバイダとSAMLにより統合
• ポイント
  • WorkSpacesとAppStream2.0はディレクトリ統合の考え方が違う
• ディレクトリ設計のポイント
  • ディレクトリ：AWS Directory Service
  • ディレクトリは２つのサブネットに展開
  • VPC内に複数のディレクトリを展開可能
  • ディレクトリ単位でRegistration codeを持つ

シナリオ１

AD ConnectorからオンプレミスAD DSへプロキシ認証

• オンプレミスとはDirect Connect/VPNで接続

シナリオ２

AD on EC2をAWS（Shared Services用のVPC）に拡張、AD Connectorによる認証

• シナリオ１からなぜ？ADをVPCへ？
  • オンプレミスとはDirect Connect/VPNに障害があっても、AWS内で業務を継続可能
  • オンプレミス側のADと連携

シナリオ３

• AWS MicrosoftADとオンプレミスAD DSとの双方向の推移的信頼関係
• AWS_WorkSpaces<-TrustFilter->ReadUsers
• ADへの接続
• ドメインコントローラと疎通を行うために、以下のポートの開放が必要

  • 信頼関係を作成する場合

  • Directory Service Port testアプリケーションで簡単に確認可能

ネットワーク構成 オンプレミスからの接続

• Auth/Session Gateway
• Stream GatewayはAWSが管理するVPC内にある
• PCoIP GatewayのグローバルIPレンジ
  • US East (N. Virginia): 52.23.61.0 - 52.23.62.255
  • US West (Oregon): 54.244.46.0 - 54.244.47.255
  • EU (Ireland): 52.19.124.0 - 52.19.125.255
  • Asia Pacific (Singapore): 52.76.127.0 - 52.76.127.255
  • Asia Pacific (Sydney): 54.153.254.0 - 54.153.254.255
  • Asia Pacific (Tokyo): 54.250.251.0 - 54.250.251.255
• 認証オプション
  • ユーザ名・パスワード
  • RADIUS認証による多要素認証MFA
    • FreeRADIUS＋GoogleAuthenticator
      • メリット：認証基盤、トラフィックをAWS内に閉じることが可能
      • デメリット：自身で管理や可溶性の担保が必要
    • クラウドベースのRADIUS
      • メリット：ベンダーが提供する可用性を考慮した構成
      • デメリット：別途課金が必要
  • デバイス認証によるアクセス制御
    • ルートCAをWorkSpacesへ割り当て
    • PCにクライアント証明書、ルート証明書をインストール
  • IPアドレスベースのアクセス認証
    • PublicDirectConnect接続を利用したIPアドレス制限

アプリ配信

• AppStream2.0によるアプリ配信
  • ユーザ/アプリケーションに合わせたインスタンスのパフォーマンス
  • 処理負荷が高いものはグラフィックインスタンスで吸収
    • WorkSpaces側にグラフィックの処理能力がなくても利用可能
• ネットワーク接続とユーザ認証

WorkSpacesにおけるIT管理

• 新規WorkSpacesの作成：AWSマネジメントコンソールから追加可能
• WorkSpacesカスタムバンドル
  • １）WorkSpacesを起動しカスタマイズ（アプリケーションのインストールなど）
  • ２）WorkSpacesからイメージを作成
  • ３）イメージからカスタムバンドルを作成することが可能
• アップデートの管理
  • WorkSpacesのアップデートは保守管理時間（AlwaysOnでは毎週日曜日0:00−4:00）に自動的にインストールされる
  • デフォルトではWindowsupdateが有効で毎週日曜の午前２時に更新がインストール
    • ただし推奨は以下
      • WSUSまたはSSMなどによるWindowsUpdateを管理
      • SSMで利用する場合はpowershellでSSMエージェントをインストールする必要がある
• グループポリシーによる制御かグループポリシー管理テンプレートをインストールすることによりポリシー設定を変更可能
  • WorkSpaces固有のポリシー
    • ローカルプリンターのサポート
    • クリップボードのリダイレクト
    • などなど
• ITの自動化の必要性
  • WorkSpacesによるITオペレーションの自動化
  • 従業員のオンボーディング
  • 故障したハードウェアの修理
  • ハードの再利用
  • WorkSpacesのAPI
    • AWSCLIや各種SDKから利用可能
  • 自動化されたセルフサービスのためのハイレベルワークフロー
    • 例：ユーザ＞申請＞承認プロセス＞承認をする・しない＞StepFunctions＞WS作成
• ウィルス検知によるネットワークの自動化
  • ウィルスバスタココーポレートエディションXGがウィルス感染を検知
  • CloudWatchに通知、Lambdaファンクションがセキュリティグループの隔離を実行
  • デモ
    • 既存のWorkSpaces
      • この時点ではタグがない
      • インターネットの利用が可能
      • ユーザのブラウジングが原因でマルウェアが組み込まれる
      • ウィルスバスターが検知する
      • CloudWatchにアラートと通知
      • 検疫というタグがつく
      • SecurityGroupのOutBoundの許可を剥奪

まとめ

• 大規模展開には最適なアーキテクチャ設計が重要
• 管理と自動化のシナリオを検討することでITオペレーションをより効率化することが可能

感想

WorkSpacesとAppStream2.0の組み合わせでWorkSpacesで利用するアプリケーションの負荷をAppStream2.0側にオフロードすることが可能でWorkSpaces側のスペック選定が容易になります。また、作り込みが必要ではあるものの、ユーザが自身で申請を行うフローをwebインターフェースと共に提供することで管理者側の負担を大きく減らせる可能性があります。