LoginSignup
3
1

More than 1 year has passed since last update.

@hidekko(hideaki koga)

Amazon WorkSpaces と Azure Virtual Desktop 比較 ～Amazon WorkSpaces事前準備編～

Last updated at Posted at 2022-12-14

今更ですが、Amazon WorkSpaces(以下、WorkSpaces)とAzure Virtual Desktop(以下、AVD)の比較をしてみたので記事にしました。
まずは事前準備編です。

前提条件

エンタープライズのユーザを想定するとMicrosoftのActive Directoryを利用していることが多いので、WorkSpacesやAVDの利用ユーザは既存のActive Directoryで制御することとします。
ですのでWorkSpacesやAVDのユーザ認証は既存のActive Directoryとの連携を想定します。
またアクセス元IPアドレス制限を行う運用も無くは無いと思いますが、インターネット経由で直接アクセスした方がネットワークのレイテンシーの影響やフラグメンテーションが起こりにくいため、セキュリティは多要素認証を前提とします。
まとめると

  1. 既存のActive Directoryでユーザ管理
  2. セキュリティは多要素認証

となります。
この前提条件でWorkSpacesとAVDを比較します。

既存のActive DirectoryとAWS Directory Serviceを連携する

厳密に前提条件の作業から記載するとVPN張るところからなんですが、そこは今回は割愛します。
また別で記事を書きます。

AWS Directory Serviceですが、Simple ADとAD Connecor、Managed ADと3種類ありますが、AVDがAzure AD Connect構成と比較しますので、AWSもAD Connecorを使います。
AD Connectorの構成図を書くとこうなります。
image.png
VPN GatewayはオンプレミスのDomain ControllerとAD Connectorを通信させる必要があるため必須、NAT GatewayとInternet Gatewayは今回の構成では必須ではないですが、MFA実装時に必要になるので記載しました。

AD Connectorはどういうものなのか？

私の触ってみた感覚だとPaaSっぽくみせたIaaSです。
AD Connectorの前提条件にある通り、サブネットは2つ、かつ異なるアベイラビリティゾーンで構成する必要があります。
ですので構成図もPrivate subnetを01と02の2つ作成しました。
恐らく内部では2つのPrivate subnetにそれぞれIaaSがあります。
分かりやすく構成図にすると
image.png
こういうことだと思います。
サブネットを2つ、かつ異なるアベイラビリティゾーンが必須条件なので暗黙的に冗長構成を行いつつ、IaaSはユーザへのログインはさせずAWSコンソールからパラメータを与えるだけの構成にして「フルマネージド」と謳っているんだと思います。
あくまで私見ですので間違っていたらごめんなさい。
AD Connectorを構成するにあたり、「なぜサブネットが2ついるのか？」という疑問が頭をよぎったので、自分なりに納得のいく回答を導き出しました。

AD Connector構築の事前準備

はい。
事前準備の事前準備、になっちゃうのですが、必要なので記載します。

グループの作成

まずDomain Controllerにログインして、[Active Directory ユーザーとコンピューター]を開いて、[Users]をクリックし、画面上にある人が並んでて光ってるみたいなアイコン、[現在のコンテナーに新しいグループを作成]をクリックします。
image.png
以下のような画面が出てくるので、[グループ名]を入力します。
今回は[aws-ad-connector-group01]とします。
そして大事なパラメータ―なのですが、[グループのスコープ]を[グローバル]を選択し、[グループの種類]を[セキュリティ]を選択して[OK]をクリックします。
image.png
[ドメインルート]、今回の場合は[sh-style.info]を右クリックして[制御の委任]をクリックします。
image.png
[オブジェクト制御のウィザード]が起動するので、[次へ]をクリックします。
image.png
[ユーザーまたはグループ]の画面で[追加]をクリックします。
image.png
[選択するオブジェクト名を入力してください]の画面で先ほど作成したグループ名を入力し、[名前の確認]をクリックします。
image.png
[名前の確認]で問題なくグループ名が指定できれば、入力したグループ名にアンダーバーが引かれますので[OK]をクリックします。
image.png
グループが正しく指定できたので[次へ]をクリックします。
image.png
[オブジェクト制御の委任ウィザード]画面で[委任するカスタムタスクを作成する]を選択し、[次へ]をクリックします。
image.png
[フォルダー内の次のオブジェクトのみ]を選択し、まず[コンピューター オブジェクト]を選択し、下の方にある[ユーザー オブジェクト]も選択します。
image.png
[ユーザ オブジェクト]を選択したら、[選択されたオブジェクトをこのフォルダーに作成する]と[選択されたオブジェクトをこのフォルダーから削除する]も選択し、[次へ]をクリックします。
image.png
[アクセス許可]の画面で[全般]と[プロパティ固有]を選択し、[アクセス許可]の項目内の[読み取り]と[書き込み]を選択します。
[書き込み]を選択すると[すべてのプロパティの書き込み]も選択されますので[次へ]をクリックします。
image.png
確認画面が出てくるので[完了]をクリックします。
image.png
ここまででグループの作成は完了です。

ユーザーの作成

続いてここで作成したグループに追加するユーザを作成します。
グループ作成の時と同じく[Users]を選択し、今度はグループ作成の隣にある[現在のコンテナーに新しいユーザを作成]をクリックします。
image.png
[新しいオブジェクト - ユーザー]画面が出てくるので、[姓][名][ユーザーログオン名]の3つを入力します。
[ユーザーログオン名(Windows 2000 より以前)]は[ユーザーログオン名]を入力すると自動で入力されますので[次へ]をクリックします。
Windows 2000以前だと、ユーザ名の長さが足りずに最後の2桁が無くなっちゃってますね・・・
image.png
パスワードの入力ですが、めちゃくちゃ強力なパスワードに設定してください、というAWSさんからのお達しなので、超強力なパスワードを入力し、[パスワードを無期限にする]を選択し、[次へ]をクリックします。
image.png
確認画面が出てきますので、[完了]をクリックします。
image.png

ユーザをグループに追加

次に作成したユーザを作成したグループに追加します。
作成したユーザを右クリックして[プロパティ]をクリックします。
image.png
[所属するグループ]のタブをクリックします。
image.png
[追加]をクリックします。
image.png
[グループの選択]画面が出てきますので、先ほど作成したグループ名を入力し、[名前の確認]をクリックします。
image.png
[名前の確認]で問題なくグループ名が指定できれば、入力したグループ名にアンダーバーが引かれますので[OK]をクリックします。
image.png
[所属するグループ]に指定したグループ名が追加されていれば[適用]をクリックし[OK]をクリックします。
image.png

以上で事前準備の事前準備は完了です。
AWSさんはやっぱり手順が複雑ですね・・・
ちなみにネタばれですがAzureだとAzure AD ConnectがAD Connectorを競合サービスになり、前述の通りAVDではAzure AD Connectを利用するのですが、ここまで複雑ではないです。
もう事前準備の事前準備でおなかいっぱいです。

AD Connector構築

はい。
では早速でもないですがAD Connectorの構築を行います。
AWSコンソールにログインして出てくる以下の検索ボックスに[WorkSpaces]と入力しましょう。
image.png
以下のような画面が出てきますので赤枠内の[高速セットアップ]をクリックしましょう。
image.png
まぁ今回はAD Connectorの構成なんで、ここで無くても、検索ボックスに[Directory Service]を入力してもOKなんですけどね。
元々WorkSpacesの構築から行ったので、この順序になってしまいました。
そして次もですが、いきなりWorkSpacesの構築画面に入っちゃうんですが、一回[ディレクトリ]をクリックします。
image.png
ちょっとAWSさんはオレンジがイメージカラーなんで赤枠は分かりづらいかもしれませんが、赤枠で続けます。
以下の画面で[ディレクトリの作成]をクリックします。
image.png

ディレクトリタイプの選択

はい来ました！ディレクトリタイプの選択画面です。
ここで[AD Connector]をクリックして[次へ]をクリックします。
image.png

AD Connectorの情報を入力

今回は検証用ですので[スモール]を選択して[次へ]をクリックします。
スモールが100ユーザくらいまでだったか、それ以上がラージだったかと思います。
image.png

VPCとサブネットを選択

次に構成図にあるAD Connector必須条件のサブネット2つを選択します。
image.png
今回は以下のようなVPC、サブネット構成にしました。
image.png
サブネット名と構成図はある程度一致しているので、以下のような選択結果にし[次へ]をクリックします。
image.png

ADに接続

はい。
検証用ですが結構ガチのドメインを構成しましたので、その構成をつらつらと記載していきます。
上から順に行きましょう。
[組織名]ですが、私は生意気にも屋号を持っているので、屋号を[組織名]としました。
[ディレクトリのDNS名]は画像内の説明の通り、完全修飾ドメイン名、つまりFQDNですね。
例えばhogehoge.localがローカルドメインであれば、ここにhogehoge.localと入力します。
[ディレクトリのNetBIOS名]に関してはオプションなのでスキップしてもいいですが、ここに記載の通りの設定になります。
先のhogehoge.localがローカルドメインの場合、hogehogeになります。
[DNS IP アドレス]ですが、2つ前の項目[ディレクトリのDNS名]の名前解決ができるDNSサーバのIPアドレスを指定します。
Active Directoryはデフォルトの設定だとDNSサーバも兼用していますが、別建てでDNSサーバがあるのであればそれを指定しましょう。
[サービスアカウントのユーザ名]ですが、[AD Connector構築の事前準備]の項目(事前準備の事前準備)で作成したユーザ名を入力します。
[サービスアカウントのパスワード]と[パスワードを確認]は[サービスカウントのユーザ名]で指定するユーザのパスワードを入力します。
最後に[次へ]をクリックします。
image.png
確認画面が出てきますので内容を確認し、
image.png
[ディレクトリの作成]をクリックします。
image.png
作成自体はここまでで完了なのですが、オンプレミスのDomain Controller接続までの状態遷移を見ていきましょう。

AD Connector完成までの状態遷移

作成直後は[組織名]は空白で[登録済み]の項目が[False]、[ステータス]も[リクエスト済み]です。
この[登録済み]はWorkSpacesに登録されているかどうか、というFalseかTrue、[ステータス]はAD Connectorの構築状態を表しています。
image.png
しばらくするとなぜか組織名がディレクトリIDと同じになるのですが、
image.png
[組織名]が入力通りになると[ステータス]も[作成中]になります。
image.png
私の環境だと7分くらい待っておくと、勝手に[ステータス]が[アクティブ]になりました。
image.png

AD Connectorをサブネットに登録する

ディレクトリを選択し、[アクション]をクリックし[登録]をクリックします。
image.png
ディレクトリをどのサブネットに、どういうディレクトリとして登録するのか入力を求められるので、構成図のPrivate Subnet01とPrivate subnet02を選択します。
[セルフサービス許可を有効化]と[Amazon WorkDocs]にチェックを入れ、[登録]をクリックします。
image.png
画面が遷移し、[登録済み]が[登録中]になります。
image.png
こちらは1分以内に[True]になります。
image.png

WorkSpacesの事前準備は以上です。

いや、AWSさんは相変わらず事前準備が多いっすね。
大変です。

今日はここまで。

3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
1