「AWS Black Belt Online Seminar Amazon WorkSpaces」の自分向けメモ
Amazon WorkSpaces語感はなんとなく分かるけど......レベルの人向け
デスクトップ仮想化（VDI）の背景
- セキュリティ向上が目的で注目されるようになった
- データをローカルに持ち出せない
- 安価
- 最近はリモートワークとしてさらに注目されている（働き方改革）
オンプレのVDIの課題
- 高額な初期投資
- 利用までに時間がかかる
- 定期的な大規模システム更改
- 利用者増減対応が困難
- サイジングが重要だが困難
- 業務内容を踏まえたサイジングが困難
概要
- オンプレの課題の解決を図った
- クラウド上のデスクトップ環境（いつでも・どこでも）
- 初期投資不要
- サイジング、増減が容易
- デプロイ、管理がシンプル
- グローバル展開しやすい
- AWSサービスとの連携が容易
- WorkSpacesの監視をCloudWatchで行う
- 価格要素
- スペック・タイプ
- 利用時間（MonthlyかHourly）
- 月80h以下ならHourlyがお得
- ユースケース
- モバイルワーク
- 短期PRJ
- トレーニング
- 派遣社員
- コンプライアンスの準拠
- 機能
- シミュレーション、3Dエンジニアリングも耐えうるスペック
- Amazon Linux 2がベース
- ブラウザ、Libre Office、AWS SDKが標準搭載
- セルフサービス管理機能
- 管理者の負担軽減
- Windowsを利用することも可能（Bring Your Online Licence（BYOL））
- ライセンスをAWSに持ち込み、利用することが可能
- 200台の利用から
- BYOLが自動化され、2ヶ月かかっていた移行プロセスを大幅改善
利用方法
セットアップ
- ディレクトリ作成
- ディレクトリにユーザー追加
- ユーザーにバンドル割り当て
- WorkSpacesの設定
- 自動停止
- 暗号化
- 起動
WorkSpacesクライアント
- ネットワーク接続性の確認
- ユーザー名とパスワードでデスクトップ画面が立ち上がる
- ブラウザでのアクセスも可能
アーキテクチャ
ログインフロー
- インターネット経由で接続リクエストが認証ゲートに送られる
- AWS内で、ディレクトリサービスにリクエストが飛ぶ
- ディレクトリサービスはドメインコントロール経由でオンプレにDirect Connectでリクエストを投げる
- 認証情報を入力し、ストリーミングゲートウェイにリクエストを投げる
- 認証が通ると、Direct Connect経由でDIVがユーザーに見える
- ストリーミングとそれ以外の通信でネットワークが分かれている
VPC
- AWS管理VPCとユーザー用VPCがある
ストリーミングプロトコル
- PCoIPプロトコルを使用
- 通信の暗号化
冗長構成
- 認証Gateway、Streaming Gatewayは冗長化済みで考慮不要
- Directory Service
- 異なるAZに展開されている
- WorkSpaces
- いずれかのサブネットにデプロイされ、全体的には均等分散される
- Dドライブは12時間ごとにバックアップをとっている
- Cドライブは起動時の状態に戻る
ディレクトリサービス
- AWS Directory Serviceを利用したデスクトップ認証
- AD Connectorを利用した既存ドメイン連携
トラフィックフローとネットワーク接続
デスクトップストリーミング
- 認証はインターネット経由
- WorkSpacesからオンプレは専用線
- 認証も専用線にすることが可能
WorkSpacesからインターネット接続
- WorkSpacesにEIPを付与（セキュリティ設定は必要）
- NAT Gatewayを利用
- オンプレ経由で利用（壁、proxyは既存のオンプレを使う）
セキュリティとアクセス制御
- ユーザー認証
- ADドメイン認証
- MFA
- RADIUSとの連携
- IP制限
- IPアクセスコントロールグループ
- セキュリティグループ
- ディレクトリ用
- WorkSpaces用
- デバイス制御
- クライアント証明書
- デバイスタイプによってアクセス可否設定
- WorkSpacesのグループポリシー
- デスクトップやOS上での挙動を制御
- ローカルプリンターのサポート
- クリップボードのリダイレクト
- セッションレジュームのタイムアウト
- ストリーミングの暗号強度
- 一般的なWindowsのグループポリシーも利用可能
- デスクトップやOS上での挙動を制御
デザインパターン
ユースケース、要件の収集
- WorkSpacesの数、予想される増加の程度からサブネットのサイズを決定
- ユーザーのタイプからペルソナを定義
- 業務種類
- 気密性
- 認証
- セルフサーボス
- 端末種類
- アクセス制限
- 接続するActive Directoryドメインの数
- 単一ドメイン、複数ドメイン
- 既存ドメインの設定ポリシー
AWSアカウントの構造
- 用途に応じてAWSアカウントを分割、課金はPayerアカウントに集約
- WorkSpaces用の独立したアカウント
- ログや認証は共有サービスに集約
- 全アカウントで一貫したタグ付け
VPC、サブネットの設計
- WorkSpaces専用VPC作成と複数サブネット
- 将来の拡張性を考慮したサブネット作成によるIP枯渇を避ける
まとめ
- フルマネージドなDIVサービス
- セキュアなデスクトップ環境
- 初期投資不要、すぐ始められる
- AWS連携可能
- 適切なアーキテクチャ設計が重要