CodeNote.net

サイト内検索

Amazon WorkSpaces Personal を Simple AD で小規模に使う — 構成と費用と拡張パス

#aws#workspaces#active-directory#security#infrastructure
重岡 正 · Wed, July 15, 2026

ブラウザと電子証明書を使う業務専用の Windows 端末が必要になり、Amazon WorkSpaces Personal を東京リージョンに Simple AD で立ち上げた。当初の利用者は少人数（数名程度）で、特定業務にしか使わない端末なので、時間従量の AutoStop で 1 日数時間だけ動かせば十分という前提だった。

構築の途中で AWS 公式ドキュメントを何度も往復することになった。Simple AD が 2026-07-30 以降は新規顧客向けの提供を停止していること、WorkSpaces に併用する Simple AD は無料になる条件があること、AutoStop の課金がどこで発生するか、より高度な認証・管理統制が必要になったときに Simple AD からどう移せるか、といった点はいずれも一次情報を読み込まないと判断できない。この記事では、少人数向けの最小構成を軸に、東京リージョンの実費用と Simple AD の制約、そして AWS Managed Microsoft AD や AD Connector を選ぶときの判断軸を整理する。公式情報の確認日はすべて 2026-07-15 とする。

なぜ業務専用 Windows 環境が必要だったか

理由は 1 つで、普段使いのメイン端末が macOS だったからである。今回対象になった業務は Windows でしか動かない要件があり、macOS からは物理的にも運用上も無理があった。

追加で Windows マシンを 1 台調達して机の上に置く運用も検討したが、使わない時間帯にも電源が入りっぱなしになる、遠隔地から使えない、故障時の代替を都度確保する必要がある、といった副作用がある。手元の macOS からブラウザ 1 枚で立ち上げられて、使わない時間は自動で止まる Windows デスクトップが欲しかった。それがクラウドの DaaS を選んだ理由である。

Amazon WorkSpaces を選んだ理由

WorkSpaces のほかに Amazon AppStream 2.0 や、EC2 に Windows Server を立てて RDP する方式も検討したが、次の理由で WorkSpaces に絞った。

  • 個人に永続的に紐付く Windows デスクトップとして扱いたい（AppStream 2.0 はアプリケーションストリーミングが主眼で、常設の個人デスクトップは WorkSpaces のほうが素直）
  • 停止・起動、ユーザー割り当て、ディレクトリ連携が管理コンソールから完結する
  • 東京リージョンで日本語 Windows Server ベースのバンドルがライセンス込みで提供されている（WorkSpaces のバンドル一覧）
  • 利用時間だけ課金する AutoStop モードがあり、少人数の業務専用用途と相性が良い

Windows 10/11 のクライアント OS を使いたい場合は BYOL（Bring Your Own License）が前提になるが、Windows Server ベースの日本語デスクトップであれば追加ライセンスなしのバンドルとして選択できる。今回は BYOL を用意する手間を避けて Windows Server 2025 ベースを選んだ。

最初に迷ったディレクトリ選び

WorkSpaces Personal は、ディレクトリ（認証・ユーザー管理の基盤）とセットで作る必要がある。管理者ガイドの Manage directories に列挙されている選択肢は次のとおりだった。

  • Simple AD
  • AWS Managed Microsoft AD
  • AD Connector（既存 Active Directory へのプロキシ）
  • Microsoft Entra ID（Windows 10/11 BYOL 限定、IAM Identity Center 経由）
  • Custom directory

このうち、少人数・業務専用・既存 AD なし・BYOL なしという条件では、実質 Simple AD と AWS Managed Microsoft AD の 2 択になる。ここで一次情報にあたって初めて把握したのが、Simple AD の提供方針の変更である。

2026-06-30 発表、2026-07-30 効力発生の Simple AD 提供方針変更

AWS は 2026-06-30 に AWS Service Availability Updates を公表し、Simple AD を含む複数サービスがメンテナンスモードへ移行することをアナウンスした。効力発生日は 2026-07-30 で、この日以降は新規顧客が Simple AD を利用開始できない。既存顧客への影響はなく、AWS の運用・サポートも継続される。

Directory Service ドキュメント側にも Simple AD availability changes というページが用意され、次のように明記されている。

Only new customer onboarding to Simple AD is not permitted. Existing Simple AD customers retain full functionality. Your directories, users, computers, and integrated workloads are not affected, and you can continue to create new Simple AD directories.

つまり整理すると次のようになる。

  • 2026-07-30 以降に初めて Simple AD を触る新規顧客は使えない
  • 既存顧客は影響を受けず、既存アカウントで新たに Simple AD ディレクトリを作ることもできる
  • AWS の推奨移行先は AWS Managed Microsoft AD または AD Connector

「Simple AD は新規作成できない」と単純化して書かれている記事もあるが、条件を省略すると事実と食い違う。判断の基準は「アカウントが既存 Simple AD 顧客に該当するかどうか」で、これは AWS アカウント単位で決まる。WorkSpaces Personal の Create a Simple AD directory for WorkSpaces Personal チュートリアルにも同じ制約が明記されており、Quick Setup を新規顧客向けの例外扱いとする記述は公式ドキュメントでは確認できなかった。

今回のケースでは、当該 AWS アカウントが既存 Simple AD 顧客に該当していたため、Simple AD を選択する余地があった。もし新規アカウントであれば Simple AD の選択肢は最初からなく、AWS Managed Microsoft AD もしくは AD Connector を採用することになる。

今回採用した Simple AD 最小構成

実際に構築した構成は次のとおり。実体験のパラメータをそのまま並べる。

  • リージョン: 東京 (ap-northeast-1)
  • サービス: Amazon WorkSpaces Personal
  • OS: Windows Server 2025 ベースの日本語 Windows デスクトップ
  • バンドル: Performance（2 vCPU、8 GiB メモリ）
  • ルートボリューム: 80 GB、ユーザーボリューム: 100 GB
  • 実行モード: AutoStop（停止までの時間 60 分）
  • プロトコル: DCV
  • ディレクトリ: Simple AD（Small）
  • VPC: 専用 VPC
  • サブネット: 異なる AZ に 2 つ
  • インターネット接続: Internet Gateway 経由
  • 利用者: 少人数（数名程度）
  • 用途: ブラウザと電子証明書を使う業務専用端末

Simple AD は 2 台のドメインコントローラーを異なる AZ に自動で配置するため、サブネットも異なる AZ に 2 つ用意する必要がある。DCV は WorkSpaces の ストリーミングプロトコル のうち、Amazon DCV ベースの新しいほうで、Web Access や各種クライアントから使える。AutoStop は最短停止時間が 60 分で、指定時間ぶんの切断が続くと自動的にワークスペースが停止し、時間従量課金が止まる仕組みになっている。

ネットワーク構成

VPC・サブネット・Internet Gateway 自体には課金が発生しない。今回はプライベートサブネットを立ててから NAT Gateway を経由させる構成にはせず、WorkSpaces のサブネットから Internet Gateway に直接抜ける経路にした。WorkSpaces 自体は原則としてパブリック IP を持たず、リージョナルなエンドポイント経由でクライアントと通信するため、NAT Gateway の常時課金（東京で $0.062/hr、月換算 $45.26、加えて $0.062/GB のデータ処理料）を避けられる。

構成を Mermaid で描くと次のようになる。

flowchart LR
  User[Windows/Mac<br/>WorkSpaces Client] -->|DCV/HTTPS| Endpoint[WorkSpaces<br/>リージョナルエンドポイント]
  Endpoint --> WS
  subgraph VPC[専用 VPC ap-northeast-1]
    subgraph AZ1[AZ-a]
      Subnet1[サブネット 1]
      SimpleAD1[Simple AD DC1]
      WS[WorkSpaces Personal<br/>Windows Server 2025<br/>2 vCPU / 8 GiB]
    end
    subgraph AZ2[AZ-c]
      Subnet2[サブネット 2]
      SimpleAD2[Simple AD DC2]
    end
    IGW[Internet Gateway]
  end
  WS -->|Web/証明書| IGW --> Internet[インターネット/業務サイト]

インターネット側からクライアントが WorkSpaces に接続する経路は、Internet Gateway ではなく AWS 側が管理するリージョナルなエンドポイントで、管理者ガイドのポート要件 に記載されているとおり、クライアント → WorkSpaces 方向の受信ポートを VPC 側で開ける必要はない。

実際に発生する費用

料金は東京リージョン、2026-07-15 時点の WorkSpaces 料金ページ と Directory Service 料金ページ で確認した値をベースに算出する。USD から JPY への換算は $1 = 150 円の概算で、記事公開時点の為替とは異なる。

Performance バンドルの単価

  • AutoStop: $19/月 の固定料金 + $0.61/hr の時間従量
  • AlwaysOn: $65/月 の固定料金（時間従量なし）

Simple AD 併用時の月額（Simple AD は WorkSpaces 併用中は無料）

ユーザー数AutoStop 20hAutoStop 80hAutoStop 160hAlwaysOn
3 名$93.6
（約 14,000 円）		$203.4
（約 30,500 円）		$349.8
（約 52,500 円）		$195
（約 29,300 円）
5 名$156
（約 23,400 円）		$339
（約 50,900 円）		$583
（約 87,500 円）		$325
（約 48,800 円）
10 名$312
（約 46,800 円）		$678
（約 101,700 円）		$1,166
（約 174,900 円）		$650
（約 97,500 円）

Simple AD は WorkSpaces と併用している間は無料になる（Directory Service other directories pricing）。「WorkSpaces を 30 日連続で使わないと自動的に deregister され、Directory Service の通常料金が発生する」という条件は WorkSpaces 側の Create a Simple AD directory for WorkSpaces Personal に明記されている。今回のように業務専用で毎月何らかの利用があるうちは Simple AD 側の課金はゼロで通る。

AWS Managed Microsoft AD Standard 追加時の月額（ディレクトリ +$53.3/月）

ユーザー数AutoStop 20hAutoStop 80hAutoStop 160hAlwaysOn
3 名$146.9
（約 22,000 円）		$256.7
（約 38,500 円）		$403.1
（約 60,500 円）		$248.3
（約 37,200 円）
5 名$209.3
（約 31,400 円）		$392.3
（約 58,800 円）		$636.3
（約 95,400 円）		$378.3
（約 56,700 円）
10 名$365.3
（約 54,800 円）		$731.3
（約 109,700 円）		$1,219.3
（約 182,900 円）		$703.3
（約 105,500 円）

AWS Managed Microsoft AD Standard の東京単価は $0.073/hr で、730h 換算で約 $53.3/月。WorkSpaces 併用による無料条件は Simple AD と AD Connector 向けの記述で、AWS Managed Microsoft AD には適用されない（時間従量で常時課金）。

AD Connector Large 追加時の月額（ディレクトリ +$175.2/月、別途 VPN/DX）

ユーザー数AutoStop 20hAutoStop 80hAutoStop 160hAlwaysOn
3 名$268.8 + VPN/DX
（約 40,300 円〜）		$378.6 + VPN/DX
（約 56,800 円〜）		$525 + VPN/DX
（約 78,800 円〜）		$370.2 + VPN/DX
（約 55,500 円〜）
5 名$331.2 + VPN/DX
（約 49,700 円〜）		$514.2 + VPN/DX
（約 77,100 円〜）		$758.2 + VPN/DX
（約 113,700 円〜）		$500.2 + VPN/DX
（約 75,000 円〜）
10 名$487.2 + VPN/DX
（約 73,100 円〜）		$853.2 + VPN/DX
（約 128,000 円〜）		$1,341.2 + VPN/DX
（約 201,200 円〜）		$825.2 + VPN/DX
（約 123,800 円〜）

AD Connector Large の東京単価は $0.24/hr で、730h 換算で約 $175.2/月。AD Connector 自体は WorkSpaces 併用中の無料条件が Directory Service 料金ページに明記されているが、実運用では別途 Site-to-Site VPN もしくは Direct Connect のコストと、オンプレミス側 AD の運用コストが乗る。

ネットワーク関連の代表額（別枠、参考値）

項目単価月額目安（730h 換算）備考
Public IPv4（EIP・自動割当共通）$0.005/hr$3.65/IP
（約 550 円）		WorkSpaces 自体はパブリック IP を持たないが、NAT 用途などで必要な場合
NAT Gateway$0.062/hr + $0.062/GB$45.26 固定
（約 6,800 円）+ 通信量		プライベートサブネットからインターネットへ出す構成のときのみ発生
Internet Gateway 本体無料-通信量に応じたデータ転送料は別途
データ転送アウト（東京発）Tier 別 USD/GB料金ページ要確認100 GB/月まで無料枠が全リージョン共通で提供

費用に含めていない項目

追加ストレージ（Root 80 GB / User 100 GB を超えた分）の USD/GB-月単価、東京発データ転送アウトの Tier 別 USD/GB、AWS Private CA（証明書ベース認証で必要）、CloudTrail データイベント、CloudWatch Logs 保存量、VPN や Direct Connect、RADIUS サーバ、運用担当者の工数は、いずれも本記事の表には入れていない。特に追加ストレージと東京発データ転送は、公式一次情報から本記事執筆時点で単価を確認できなかったため、AWS Pricing Calculator で個別に見積もることを推奨する。

料金と為替は変動するため、公開直前の最終確認は AWS の公式料金ページで行う前提でお願いしたい。

Simple AD でできること・困ること

Simple AD は Samba 4 ベースの、AD 互換のディレクトリサービスである。Directory Service ドキュメントの Simple AD 概要 に、機能と制限が明確に列挙されている。

Simple AD でできることは次のとおり。

  • Windows / Linux インスタンスのドメイン参加
  • 基本的なユーザー・グループ・OU の作成と管理
  • 基本的なパスワードポリシー
  • Kerberos ベースの SSO
  • 自動デイリースナップショットと手動スナップショット
  • 2 台のドメインコントローラーを異なる AZ に自動配置する冗長性

Simple AD で公式に非対応と明記されているのは次のとおり。

  • 多要素認証（MFA）
  • 他ドメインとの信頼関係
  • スキーマ拡張
  • AD Administrative Center、PowerShell モジュール、AD ごみ箱、gMSA
  • IAM Identity Center との連携
  • Amazon FSx、Amazon RDS for SQL Server / Oracle、Amazon Chime、WorkSpaces Applications

とくに MFA が非対応であることと、信頼関係・スキーマ拡張が使えないことは、後で組織的な運用に切り替えるときの制約として大きい。RADIUS ベースの MFA は WorkSpaces のドキュメント上、AD Connector と AWS Managed Microsoft AD で有効化する機能として案内されている（Enable multi-factor authentication for Amazon WorkSpaces）。

WorkSpaces 向けのグループポリシー（クリップボード、USB、印刷、ドライブリダイレクトなどの制御）に関しては、Manage your Windows WorkSpaces with Group Policy の記述が実質的に AD Connector または AWS Managed Microsoft AD を前提としている。Simple AD 自身は「グループポリシーを作成・適用できる」とうたっているが、WorkSpaces 用の ADMX テンプレートを Simple AD で完全にサポートするという明示的な記述は公式ドキュメントで確認できなかった。少人数・業務専用の範囲であれば深刻な問題にはならないことが多いが、組織的にリダイレクション制御を厳密にかけたいときは、この差が効いてくる。

「よりセキュア」を要件ごとに考える

「Simple AD 以外を選べば自動的に安全になる」という言い方は正確ではない。Simple AD で十分実施できるセキュリティ対策と、Simple AD だけでは実現が難しい対策を、観点ごとに分解する。

観点Simple AD で可能Simple AD では難しい／不可
パスワードポリシー基本ポリシーきめ細かいポリシー（Fine-Grained Password Policy）
MFAディレクトリ側 MFA は不可（SAML 経路で IdP MFA を併用する場合のみ実質可能）RADIUS ベースの MFA
ユーザー入退場管理AD ユーザーの作成・削除IAM Identity Center や既存 HR システムとの連携
管理者権限の分離Domain Admins など基本的な分離詳細な RBAC・特権管理
グループポリシー一部の基本 GPOWorkSpaces ADMX の完全サポートは公式明示なし
端末制御（USB・クリップボード・印刷など）GPO 経由の一部制御高度なリダイレクション制御は AWS Managed Microsoft AD / AD Connector 推奨
ネットワーク分離VPC・セキュリティグループ・IP Access Control Group-
インターネット出口制御NAT・ファイアウォール・プロキシで実施可-
CloudTrail / CloudWatch○-
ディレクトリ監査ログ限定的（Samba ベース）AWS Managed Microsoft AD の詳細イベントログ
ディレクトリのバックアップ自動デイリースナップショット + 手動スナップショット-
WorkSpace のバックアップ12h ごとのスナップショット 1 世代のみ任意時点への PITR、外部への世代バックアップは別途仕組みが必要
冗長性異なる AZ に 2 DC を自動配置-
証明書ベース認証（CBA）不可（SAML 2.0 + AWS Private CA 前提）AWS Managed Microsoft AD で可
IAM Identity Center 連携不可AWS Managed Microsoft AD で可

ネットワーク分離・出口制御・CloudTrail による監査・スナップショットによる冗長性といった「AWS 側の共通機能で提供される部分」は Simple AD でも同等に使える。逆に MFA・詳細な監査ログ・信頼関係・スキーマ拡張・CBA・IAM Identity Center 連携といった「ディレクトリ自体の機能に依存する部分」は Simple AD の枠を超えるとほぼ間違いなく Simple AD 以外を選ぶことになる。

IP Access Control Group は WorkSpaces の IP access control groups で提供される機能で、クライアントの WorkSpaces ストリーミング接続の送信元 CIDR を制限できる。ディレクトリに関連付ける形で有効化するため、Simple AD 環境でも使える。

Simple AD 以外の構成案

Simple AD で足りなくなったときの現実的な代替案を 3 パターン整理する。

AWS Managed Microsoft AD で管理統制を強化する

AWS Managed Microsoft AD は AWS 上で本物の Microsoft Active Directory を提供するサービスで、Simple AD と違って Samba 実装ではなく Windows Server の AD が動く。GPO、信頼関係、スキーマ拡張、Kerberos、LDAPS、そして CBA まで一通り使える。

Simple AD と比較して強化されるのは以下。

  • ディレクトリ側 MFA（RADIUS）
  • Fine-Grained Password Policy
  • 他ドメインとの信頼関係（既存オンプレ AD と信頼関係を張って利用者を共有できる）
  • スキーマ拡張とサードパーティツール互換性
  • 詳細な監査イベントログを CloudWatch Logs へ転送
  • Standard で 30,000 オブジェクト、Enterprise で 500,000 オブジェクトまで対応
  • Multi-Region 構成による広域冗長化
  • 証明書ベース認証（AWS Private CA と組み合わせて）
  • IAM Identity Center 連携

デメリットは費用と運用負荷である。東京では Standard で $0.073/hr の常時課金（月換算 $53.3）、Enterprise で $0.2225/hr（月換算 $162.4）。WorkSpaces 併用による無料条件は適用されない。障害対応時にはネイティブ AD としてのトラブルシューティング知識が必要になる。少人数の業務専用用途で、これらの追加機能を実際に使わないなら、月額 $53.3 の追加投資は正当化しにくい。

AD Connector で既存の組織認証基盤へ統合する

すでに社内で Active Directory を運用している組織であれば、AD Connector を使ってオンプレの AD をそのまま WorkSpaces の認証基盤にできる。AD Connector は AWS 側にディレクトリのレプリカを持たず、AWS からオンプレ AD へのプロキシとして振る舞う。

強化されるのは以下。

  • ユーザーのライフサイクル管理を既存 AD にそのまま任せられる（入社・異動・退職の運用が一元化）
  • パスワードポリシー、アカウントロックアウト、ログオン制限などが既存 AD の設定をそのまま反映
  • 既存の RADIUS 基盤があれば MFA も既存基盤を利用
  • GPO は既存 AD 側でそのまま管理

デメリットは、AD Connector Large が $0.24/hr の常時課金（月換算 $175.2）と Simple AD より高いこと、AWS からオンプレ AD への到達性を Site-to-Site VPN もしくは Direct Connect で確保する必要があること、そして AD Connector 自身にはスナップショット機能がないこと（ディレクトリの復旧は既存 AD 側の責務）である。「新規で AD を用意する必要はないが、既存 AD への接続経路と運用体制は必要」というのが選択条件になる。

非永続で共有利用するなら WorkSpaces Pools

用途によっては、個人に永続的にデスクトップを紐付ける WorkSpaces Personal ではなく、WorkSpaces Pools が向く場合がある。Pools は非永続のデスクトップをプールから割り当てる方式で、Personal とは別の課金体系（セッション時間ベース）で提供される。

Pools は Personal と異なり、認証に SAML 2.0 が必須で、IAM SAML federation ロール + relay state URL を使う実装になる。Active Directory 参加は必須ではなく、AD を紐付けた場合のみスマートカード・CBA・ドメイン参加が有効化される。今回のような「特定業務用の常設デスクトップ」という要件には合わないが、コールセンターや期間限定のトレーニング用途のように「同じ環境を都度クリーンに再現したい」ケースでは選択肢に入る。

AWS Managed Microsoft AD は小規模用途には重いのか

少人数・業務専用の範囲で AWS Managed Microsoft AD を選ぶかどうかは、費用よりも「今後 12〜24 か月で、認証・管理統制の要件が変わる見込みがあるか」で判断するのが実務的である。

Simple AD を選んでおいて後で AWS Managed Microsoft AD に切り替える場合、Migrate WorkSpaces が対象とする移行はバンドル間の移行に限定されており、既存 WorkSpace を別ディレクトリ配下に付け替える公式手順は本記事執筆時点で確認できなかった。事実上、新ディレクトリで WorkSpace を再作成し、ユーザーデータを移設し直す再構築が前提になる。少人数のうちに切り替えるならこの再構築の影響は小さく済むが、ユーザーが増えてから移すと影響範囲が広がる。

判断の目安は次のとおり。

  • 少人数のままで、当面 MFA・GPO による端末制御・信頼関係を要求されない見込み → Simple AD で開始しても十分
  • 半年以内に MFA、詳細な GPO、IAM Identity Center 連携、CBA のいずれかが要件に入りそう → 最初から AWS Managed Microsoft AD Standard
  • 既存オンプレ AD がある → AD Connector（Simple AD を経由しない）

既存認証基盤へ統合する場合の選択肢

「既存の組織認証基盤へ統合する」と一口に言っても、統合される対象は複数あり、それぞれで選ぶ構成が違う。区別しておくと迷いにくい。

  • WorkSpaces クライアントへの sign-in（＝どうやってセッションを起動するか）: SAML 2.0 対応の IdP と連携すればここは IdP の MFA・条件付きアクセスに寄せられる。ただし WorkSpaces Personal の SAML 2.0 authentication は「Simple AD / AD Connector / AWS Managed Microsoft AD のいずれかを背後に持つこと」を必須要件として明記しており、SAML だけで AD レスにはできない
  • Windows デスクトップへのログオン: SAML でセッションを起動しても、Windows OS 側のログオンには AD 資格情報が必要（CBA を使う場合のみ証明書に置き換えられる）
  • ユーザーのライフサイクル管理: AD Connector を使えば既存 AD 側に一任、AWS Managed Microsoft AD を使うと AWS 側で改めて運用が必要
  • MFA: Simple AD 単体では不可。AD Connector と AWS Managed Microsoft AD で RADIUS MFA が使える。SAML 経路にすれば IdP 側の MFA を活用できる
  • Windows 端末へのポリシー適用: GPO が使えるのは AD Connector と AWS Managed Microsoft AD。CBA を使いたい場合の証明書発行と信頼関係の設計は SAML と AWS Private CA を組み合わせる

Microsoft Entra ID ネイティブ結合は WorkSpaces の中でも特殊で、Access with Microsoft Entra ID に「Windows 10 or 11 BYOL WorkSpaces のみ」「Microsoft Intune へ Autopilot 経由で enrollment」「Directory は IAM Identity Center を identity broker として使う」と明記されている。Windows Server ベースのバンドルでは選択できない。逆に、Windows 10/11 BYOL のライセンスと Intune 環境をすでに持っているなら、AD を新設せずに Entra ID に寄せる構成が最短になる。

外部 IdP（SAML 2.0 対応の各種製品）の設定手順や料金比較は本記事の範囲外だが、AWS 公式ドキュメントには IdP 例として ADFS、Azure AD、Duo、Okta、PingFederate、PingOne が挙げられている。特定製品の設定に踏み込むのではなく、「SAML 2.0 対応の IdP と連携できる構成がある」という原則だけ押さえておくと、要件が固まった段階で選定に入りやすい。

バックアップと復旧

WorkSpaces のバックアップ・復旧は、想像する「任意の時点に戻せる世代バックアップ」とは異なるので、期待値を合わせておく必要がある。

  • 自動スナップショットは 12 時間ごとに取得される。管理者ガイドの Restore a WorkSpace には「the date and time of the snapshots used for the operation are shown」と書かれており、コンソール・API で提示されるのは常に直近スナップショットの 1 世代のみで、任意の過去時点を指定して戻すことはできない
  • Rebuild a WorkSpace はルートボリュームをバンドルの最新イメージから再作成し、ユーザーボリュームは最新スナップショットから再作成する。プライマリ ENI も再作成されるためプライベート IP が変わる
  • Restore はルートとユーザーの両ボリュームを同一時点のスナップショットに戻す
  • WorkSpace の Delete a WorkSpace は完全な削除で、「the WorkSpace user’s data does not persist and is destroyed」と明記されている。terminate 前のデータ退避は自分で行う必要がある

ディレクトリ側のスナップショットは、Simple AD と AWS Managed Microsoft AD で違いがある。

  • Simple AD: 自動デイリースナップショット + 手動スナップショット
  • AWS Managed Microsoft AD: 自動デイリースナップショット + 手動スナップショット
  • AD Connector: スナップショット機能なし（既存 AD 側の責務）

電子証明書と秘密鍵の復旧については注意が必要である。Rebuild ではルートボリューム（C:）がバンドルイメージで再作成されるため、C: の LocalMachine 証明書ストアや端末固有情報は失われる。ユーザー証明書ストアはユーザープロファイル配下（D: にマップされる場合が多い）にあるため、理論上はユーザーボリュームスナップショットに含まれるが、「証明書が Rebuild 後に確実に復元される」と保証する記述は WorkSpaces 公式ドキュメントで確認できなかった。DPAPI で保護された秘密鍵はマシン・SID に紐付くため、一般論としては別マシンでは復号できない可能性が高い。電子証明書を扱う業務では、秘密鍵の再発行手順を運用として持っておくのが安全である。

セキュリティ設定と日常運用

Simple AD 環境でも実施できる基本的なセキュリティ・運用の要点をまとめておく。

  • ローカル管理者権限を常時付与しない。ソフトウェアインストール時のみ管理者パスワードを取り出す運用にする
  • 業務専用 WorkSpace と、通常業務端末を明確に分離する（ブラウザ拡張・ログイン状態・履歴を混在させない）
  • Windows Update と主要ブラウザの更新は自動化に任せつつ、月次で状態を目視確認する
  • ウイルス対策および EDR は組織標準のものを WorkSpace にも導入する（バンドルによってはプリインストールされないため、明示的な導入が必要）
  • クリップボード・ドライブ・USB・印刷・ファイル転送の制御を GPO で必要最小限に絞る
  • IP Access Control Group で、WorkSpaces クライアント接続元 IP を制限する
  • CloudTrail で WorkSpaces と Directory Service の API 操作を全リージョンで記録する
  • CloudWatch メトリクスで ConnectionAttempt / ConnectionSuccess / ConnectionFailure / SessionLaunchTime / UserConnected などの接続イベントを監視する
  • インターネットへの出口通信は必要最小限のドメインに絞る（NAT ゲートウェイ配下でネットワーク ACL やファイアウォールを併用）
  • 電子証明書の秘密鍵は WorkSpace 内でのみ扱う。エクスポート不可設定にする、または OS のキーストアから取り出せない形にする
  • WorkSpace を terminate する前に必ずユーザーデータを退避する。退避先はクラウドストレージ（Amazon S3、OneDrive、Google Drive など組織で許容されているもの）
  • 退職者・異動者はディレクトリ側で速やかに無効化し、WorkSpace の割り当てを外す
  • 障害時の代替端末と復旧手順を最低限ドキュメント化しておく（Rebuild でどこまで戻るか、ユーザーデータの退避先はどこか、証明書は再発行が必要か）

CloudTrail、CloudWatch メトリクス、IP Access Control Group はディレクトリの種類に依存せず利用できる。組織的な監査要件が入ったときに、ディレクトリを差し替えなくても対応できる余地がある部分といえる。

将来の拡張・移行方針

Simple AD で始めた構成を、後で AWS Managed Microsoft AD もしくは AD Connector に移す場合、前述のとおり事実上の再構築が前提になる。段階的な移行を想定した際の実務的な流れは次のとおり。

  1. 新しいディレクトリ（AWS Managed Microsoft AD もしくは AD Connector）を別 VPC あるいは同じ VPC に作成する
  2. 新ディレクトリで新規 WorkSpace を作成し、動作確認する
  3. 既存ユーザーのデータをクラウドストレージ経由で新 WorkSpace に移す
  4. 電子証明書は新 WorkSpace 上で新規発行する（秘密鍵の可搬性は仕様として期待しない）
  5. 旧 WorkSpace を terminate する前に、必ずデータの退避が完了していることを確認する
  6. 旧 Simple AD を deregister する

「Simple AD で始めて、あとで移せばよい」という気軽さは、少人数のうちだけ通用する。10 名を超えたあたりから、証明書の再発行、ブラウザ設定の引き直し、業務システム側の登録変更などの副次的な作業量が線形に増える。半年〜 1 年のスパンで規模拡大が見えているなら、最初から AWS Managed Microsoft AD もしくは AD Connector を選ぶほうが総コストは安いことが多い。

規模・要件別の推奨構成

最後に、規模と要件から構成を逆引きできる一覧を置いておく。

  • 少人数・業務専用・既存 AD なし・BYOL なし・MFA 不要・既存 AWS アカウントが Simple AD 対象 → Simple AD + WorkSpaces Personal（AutoStop）
  • 少人数だが、新規 AWS アカウントで Simple AD が使えない → AWS Managed Microsoft AD Standard + WorkSpaces Personal（AutoStop）
  • 少人数〜中規模・MFA / GPO / IAM Identity Center 連携 / CBA のいずれかが要件 → AWS Managed Microsoft AD Standard + WorkSpaces Personal
  • 既存オンプレ AD がある → AD Connector + WorkSpaces Personal + Site-to-Site VPN もしくは Direct Connect
  • Windows 10/11 BYOL と Intune がすでにある → Microsoft Entra ID ネイティブ結合 + WorkSpaces Personal
  • 非永続で共有利用したい、コールセンターや期間限定用途 → WorkSpaces Pools + SAML 2.0
  • 大規模かつグローバル → AWS Managed Microsoft AD Enterprise + Multi-Region

以上、Simple AD の新規受付停止後を踏まえて WorkSpaces Personal の最小構成と拡張パスを整理した、現場からお送りしました。

参考情報