製品ドキュメント
Citrix DaaS™
PDFを表示

Amazon WorkSpaces Core マネージドインスタンスで準備済みイメージを使用してカタログを作成する

September 3, 2026
寄稿者: 
C C

準備済みイメージを作成し、その準備済みイメージを使用して、次の方法でMCSマシンカタログを作成します。

  • スタジオ
  • PowerShell

主な手順

  1. イメージ定義と初期イメージバージョンを作成します。
  2. 初期イメージバージョンからイメージバージョンを作成します。
  3. イメージバージョンを準備済みイメージとして使用してカタログを作成します。

Studioを使用してイメージ定義と初期イメージバージョンを作成する

イメージ定義と初期イメージバージョンを作成するには、次の手順を実行します。

  1. Studioで、イメージノードに移動し、イメージ定義の作成をクリックします。はじめにページで次へをクリックします。
  2. イメージ定義ページで、イメージ定義のOSの種類とセッションの種類を指定します。

  3. イメージページで、リソース（設定された接続に適用可能なリソースのみが一覧表示されます）、イメージバージョンを作成するためのテンプレートとして使用するマスターイメージ、およびハードウェアプロパティをキャプチャするためのマシンプロファイルを選択します。VMインスタンスまたは起動テンプレートバージョンからハードウェアプロパティをキャプチャするためのマシンプロファイルを選択します。

    注：

    • イメージを選択する前に、マスターイメージにVDA 2311以降がインストールされており、MCSIOドライバーがVDAにインストールされていることを確認してください。
    • Instance Metadata Service (IMDS) V2のみがサポートされており、IMDS V1はサポートされていません。詳細については、「How Instance Metadata Service Version 2 works」を参照してください。
  4. 「マシン仕様」ページで、マシンサイズを選択します。「イメージ」ページで選択したマシンプロファイルのマシンサイズがデフォルトで選択されています。
  5. 「NIC」ページで、準備イメージのNICを選択または追加します。各NICについて、関連するVPCサブネットを選択します。
  6. 「バージョン説明」ページで、作成された初期イメージバージョンの説明を入力します。
  7. 「概要」ページで、イメージ定義と作成された初期イメージバージョンの詳細を確認します。イメージ定義の名前と説明を入力します。「完了」をクリックします。

Studioを使用してイメージバージョンを作成する

イメージバージョンを使用すると、特定のイメージに対するさまざまなイテレーションや更新を管理できます。この機能により、さまざまな目的のためにイメージの複数のバージョンを維持できます。

初期イメージバージョンからイメージバージョンを作成するには、次の手順を実行します。

注:

すべてのイメージバージョンのホスティングユニットは同じである必要があります。

  1. 「イメージ」ノードに移動し、イメージバージョンまたはイメージ定義を選択して、「イメージバージョンの作成」をクリックします。
  2. 「イメージ定義」ページで、ホスティングユニットを変更し、そのイメージバージョンのマスターイメージとマシンプロファイルを再選択できます。
  3. イメージバージョンの構成を初期構成イメージバージョンと異なるものにする場合は、「イメージバージョンの作成」ダイアログの「マシン仕様」ページと「NIC」ページで設定を構成します。
  4. イメージバージョンの説明を追加します。「完了」をクリックします。

注:

何らかの理由でイメージバージョンの作成に失敗した場合、下部にあるトラブルシューティングタブに再試行オプションが表示されます。

PowerShell を使用して準備済みイメージバージョン仕様を作成する

準備済みイメージバージョン仕様を作成するための詳細な PowerShell コマンドは次のとおりです。

  1. Test-ProvImageDefinitionNameAvailable command を使用して、利用可能なイメージ定義名を確認します。例:

    Test-ProvImageDefinitionNameAvailable -ImageDefinitionName <string[]>
<!--NeedCopy-->

  2. New-ProvImageDefinition コマンドを使用してイメージ定義を作成します。例:

    New-ProvImageDefinition -ImageDefinitionName image1 -OsType Windows -VdaSessionSupport MultiSession
<!--NeedCopy-->

  3. Add-ProvImageDefinitionConnection コマンドを使用して、指定されたホスティング接続にイメージ定義の新しい構成を作成します。

    Add-ProvImageDefinitionConnection -ImageDefinitionName image1 -HypervisorConnectionName test-conn
<!--NeedCopy-->

  4. New-ProvImageVersion コマンドを使用してイメージバージョンを作成します。例:

    New-ProvImageVersion -ImageDefinitionName image1 -Description "version 1"
<!--NeedCopy-->

  5. Add-ProvImageVersionSpec コマンドを使用して、マスターイメージバージョン仕様をイメージバージョンに追加します。例:

    Add-ProvImageVersionSpec -ImageDefinitionName  image1  -ImageVersionNumber  1 -HostingUnitName wsc -MasterImagePath "XDHyp:\HostingUnits\wsc\win10-2411-ami (ami-00123456789abcdef).template”"
<!--NeedCopy-->

    注:

    ホスティングユニットのイメージバージョンには、マスターイメージバージョン仕様を1つだけ追加できます。

  6. New-ProvImageVersionSpec コマンドを使用して、マスターイメージバージョン仕様から準備済みイメージバージョン仕様を作成します。SourceImageVersionSpecUid パラメーターは Add-ProvImageVersionSpec コマンドから派生します。例:

    New-ProvImageVersionSpec
-SourceImageVersionSpecUid  00000000-0000-0000-0000-00000000000
-MachineProfile 'XDHyp:\HostingUnits\wsc\w2022-2411 (lt-00123456789abcdef).launchtemplate\lt-00123456789abcdef (1).launchtemplateversion' -RunAsynchronously
<!--NeedCopy-->

イメージ定義、イメージバージョン、および準備済みイメージバージョン仕様を作成するための PowerShell コマンドの完全なセットの例:

New-ProvImageDefinition -ImageDefinitionName image1 -OsType Windows -VdaSessionSupport MultiSession


Add-ProvImageDefinitionConnection -ImageDefinitionName image1 -HypervisorConnectionName wsc -CustomProperties $CustomProperties

$imageVersion = New-ProvImageVersion -ImageDefinitionName image1 -Description "version 1"

$SourceImageVersionSpec = Add-ProvImageVersionSpec -ImageVersionUid $imageVersion.ImageVersionUid `
    -HostingUnitUid $hostingunit.HostingUnitUid `
    -MasterImagePath "XDHyp:\HostingUnits\wsc\win10-2411-ami (ami-00123456789abcdef).template”

New-ProvImageVersionSpec -MachineProfile 'XDHyp:\HostingUnits\wsc\w2022-2411 (lt-00123456789abcdef).launchtemplate\lt-00123456789abcdef (1).launchtemplateversion' -SourceImageVersionSpecUid $SourceImageVersionSpec.ImageVersionSpecUid
Add-ProvImageVersionSpecHostingUnit -ImageVersionSpecUid 00000000-0000-0000-0000-00000000000-HostingUnitName wsc
$PreparedImageVersionSpec = Get-ProvImageVersionSpec -ImageVersionUid $imageVersion.ImageVersionUid | Where SourceImageVersionSpecUid-eq $SourceImageVersionSpec.ImageVersionSpecUid
<!--NeedCopy-->

注:

  • イメージ定義内のすべてのイメージバージョン仕様は、同じホスティングユニットに属している必要があります。
  • イメージバージョンには、マスターイメージバージョン仕様を1つ、準備済みイメージバージョン仕様を1つだけ含めることができます。
  • すべてのイメージバージョン仕様には、マシンプロファイルが必要です。

準備済みイメージをアベイラビリティゾーンとリージョン間で共有する

Amazon WorkSpaces Core Managed Instancesの場合、単一の準備済みイメージを、同じAWSリージョン内または異なるリージョン内の異なるホスティングユニットに紐付けられた、異なるアベイラビリティゾーン間で共有できるようになりました。これにより、1つの準備済みイメージを使用して、さまざまなアベイラビリティゾーンとリージョンでMCSマシンカタログを作成および更新できます。異なるリージョンの異なるAZ間で共有する場合、準備済みイメージバージョンは元のリージョンから宛先リージョンにコピーされます。

単一の準備済みイメージを維持し、それを使用して、異なるホスティングユニットに紐付けられた複数のアベイラビリティゾーンとリージョン間でマシンカタログを作成および更新できます。これにより、イメージ管理のオーバーヘッドが大幅に削減され、展開全体の一貫性が確保され、プロビジョニングプロセスが合理化されます。また、既存のマシンカタログを、異なるアベイラビリティゾーンまたはリージョンからの準備済みイメージでシームレスに更新することもできます。

ユースケース

  • 集中型イメージ管理: 1つのアベイラビリティゾーン（例: us-east-1a）で準備済みイメージを作成します。その後、このイメージを同じus-east-1 AWSリージョン内のus-east-1bのような他のアベイラビリティゾーン、または異なるus-west-1 region内のus-west-1aに共有できます。これにより、単一のイメージで複数のホスティングユニットに対応でき、メンテナンスが簡素化されます。
  • 効率的なカタログ作成と更新: AZ 1で作成された準備済みイメージ（例: us-east-1a）を使用して、AZ 1に新しいカタログを作成できます。このイメージをAZ 2（例: us-east-1b）に共有した後、AZ 2の共有イメージを使用して、AZ 2でカタログを作成および更新できます。
  • ホスティングユニット間およびホスティング接続の展開: 環境に同じまたは異なるAWSリージョンに複数のホスティングユニットがある場合、これらのホスティングユニット間で準備済みイメージを効率的に共有できます。

制限事項

  • 同じAWSアカウント内での共有: 現在の実装では、異なるAWSアカウント間で共有することはできません。

重要な考慮事項

  • 削除順序: 元の準備済みイメージバージョン仕様を削除するには、まずその共有イメージバージョン仕様をすべて削除する必要があります。または、元の仕様と共有仕様を同時に削除する必要があります。
  • イメージバージョンの依存関係: イメージバージョンを削除する場合、まずその特定のイメージバージョンに依存する共有構成をすべて削除する必要があります。元の（共有されていない）イメージから作成したカタログはそのまま残すことができます。
  • カタログのバックポート可能性: この機能が導入される前に展開した既存のマシンカタログを更新できます。カタログを最初に展開した場所とは異なるアベイラビリティゾーンまたはリージョンで作成した準備済みイメージを使用します。
  • 完全削除: 準備済みイメージを削除すると、共有または最初に作成したどのアベイラビリティゾーンでも使用できなくなります。さらに、準備済みイメージバージョンに紐付けられたすべてのカタログが最初に削除されるまで、準備済みイメージバージョンを削除することはできません。

前提条件

この機能を構成または使用する前に、以下の条件を満たしていることを確認してください。

  • お使いの環境は、Amazon WorkSpaces Core Managed Instances環境である必要があります。
  • 同じAWSアカウントで、複数のホスティングユニット（それぞれ異なるアベイラビリティゾーンに紐付け可能）とホスト接続（それぞれ異なるリージョンに紐付け可能）を構成する必要があります。

Studio UIを使用した構成

Studio UIを使用して、異なるホスティングユニットに紐付けられたアベイラビリティゾーン間で準備済みイメージを共有できます。

準備済みイメージを共有するには

  1. Studioのイメージノードに移動し、他のアベイラビリティゾーンと共有したい準備済みイメージバージョンを選択します。
  2. 上部のナビゲーションバーでイメージ共有の管理を選択し、選択したイメージバージョンのイメージ共有を管理します。
  3. イメージ共有の管理ページで、イメージバージョンを共有したいリソースを1つ以上選択します。リソースは、元のイメージバージョンとは異なるアベイラビリティゾーンに存在できます。
  4. 保存をクリックして、他のアベイラビリティゾーンのリソースでイメージバージョンを共有します。イメージバージョンは、選択した異なるリソース間で共有されるように更新されます。完了したら、イメージバージョンが共有されているアベイラビリティゾーンでカタログを作成するために、そのイメージバージョンを使用します。

準備済みイメージの共有を削除するには

  1. Studioのイメージノードで、共有から削除したい準備済みイメージバージョンを選択します。
  2. 上部のナビゲーションバーでイメージ共有の管理を選択し、選択したイメージバージョンのイメージ共有を管理します。

  3. イメージバージョンの共有を停止したい1つ以上のリソース（アベイラビリティゾーン）のチェックボックスをオフにします。

    注記:

    リソースには、共有イメージバージョンに関連付けられ、そこから作成されたカタログが存在しないようにする必要があります。削除する共有イメージバージョンから作成されたカタログは、まず削除する必要があります。

  4. 保存をクリックして、クリアされたアベイラビリティゾーン全体でのリソースの共有を削除します。イメージバージョンが更新され、それらのアベイラビリティゾーンでは共有されなくなります。

PowerShell を使用して構成する

または、PowerShell コマンドを使用して、異なるホスティングユニットに紐付けられたアベイラビリティゾーン間で準備済みイメージを共有できます。

準備済みイメージを共有するには

  1. 共有したい準備済みイメージの ImageVersionSpecUid を確認します。これは、PowerShell で Get-ProvImageVersionSpec または同様の Get- コマンドを使用して取得できます。
  2. 準備済みイメージを利用可能にしたいアベイラビリティゾーン（同じリージョンでも異なるリージョンでも可）の HostingUnitName を特定します。これは、その特定の AZ 用に構成したホスティングユニットの名前です。

  3. Add-ProvImageVersionSpecHostingUnit コマンドを実行します: 次の PowerShell コマンドを使用します。<ImageVersionSpecUid> をイメージの Uid に、<targetHostingUnitName> をイメージバージョン仕様を共有したいターゲットアベイラビリティゾーンのホスティングユニット名に置き換えます。

    Add-ProvImageVersionSpecHostingUnit -ImageVersionSpecUid <ImageVersionSpecUid> -HostingUnitName <targetHostingUnitName>
<!--NeedCopy-->
  4. 正常に実行されると、Studio UI でイメージのステータスが表示され、指定されたホスティングユニットと共有されたことが示されます。

準備済みイメージの共有を削除するには

  1. 共有を削除したい準備済みイメージの ImageVersionSpecUid を確認します。
  2. 共有イメージを削除したいアベイラビリティゾーンの HostingUnitName を特定します。

  3. Remove-ProvImageVersionSpecHostingUnit コマンドを実行します: 次の PowerShell コマンドを使用します。<ImageVersionSpecUid> をイメージの Uid に、<targetHostingUnitName> をイメージバージョン仕様の共有を削除したいターゲットアベイラビリティゾーンのホスティングユニット名に置き換えます。

    Remove-ProvImageVersionSpecHostingUnit -ImageVersionSpecUid <ImageVersionSpecUid> -HostingUnitName <targetHostingUnitName>
<!--NeedCopy-->

イメージ準備中のネットワーク設定

イメージの準備中に、元のVMに基づいて準備用仮想マシン (VM) が作成されます。この準備用VMはネットワークから切断されます。準備用VMからネットワークを切断するために、すべてのインバウンドおよびアウトバウンドトラフィックを拒否するネットワークセキュリティグループが作成されます。このネットワークセキュリティグループは永続化され、再利用されます。ネットワークセキュリティグループの名前はCitrix.XenDesktop.IsolationGroup-GUIDで、GUIDはランダムに生成されます。

マシンプロファイルベースのマシンカタログ

マシンプロファイルを使用して、EC2インスタンス (VM) または起動テンプレートバージョンからハードウェアプロパティをキャプチャし、プロビジョニングされたマシンに適用できます。キャプチャされるプロパティには、たとえば、テナンシータイプ、インスタンスタイプ、セキュリティグループ、ネットワークマッピング、EBSボリュームプロパティ、EBS最適化、CPUオプション、ハイバネーション機能、およびその他のサポートされているAWS構成が含まれます。

AWS EC2インスタンス (VM) またはAWS起動テンプレートバージョンをマシンプロファイルの入力として使用できます。

注：

  • EBSボリュームプロパティは、マシンプロファイルからのみ派生します。
  • Instance Metadata Service (IMDS) V2のみがサポートされており、IMDS V1はサポートされていません。詳細については、「How Instance Metadata Service Version 2 works」を参照してください。

AWSテナンシー

AWSは、共有テナンシー（デフォルトタイプ）と専用テナンシーの2つのテナンシーオプションを提供します。共有テナンシーとは、異なる顧客の複数のAmazon WorkSpaces Coreインスタンスが同じ物理ハードウェア上に存在する可能性があることを意味します。専用テナンシーとは、展開した他のインスタンスと同じハードウェア上でのみAmazon WorkSpaces Coreインスタンスが実行されることを意味します。

注：

専用インスタンスのみがサポートされています（専用ホストは現在サポートされていません）。他の顧客は同じハードウェアを使用しません。

テナンシータイプはマシンプロファイルからキャプチャされます

MCSを使用してAWSでマシンをプロビジョニングするカタログを作成すると、テナンシータイプはマシンプロファイルからキャプチャされます。

  • 共有ハードウェア: この設定は、ほとんどの展開に適しています。複数の顧客が互いにやり取りすることはありませんが、ハードウェアを共有します。共有ハードウェアを使用することは、Amazon EC2インスタンスを実行するための最も安価なオプションです。
  • 専用インスタンス: この設定は、特定のセキュリティまたはコンプライアンス要件を持つ展開により適しています。専用インスタンスを使用すると、他のAWS顧客とは別のホストを持つという利点を享受できますが、ホスト全体に対して料金を支払う必要はありません。ホストの容量について心配する必要はありませんが、インスタンスに対してはより高い料金が課金されます。さらに、専用インスタンスはBring Your Own License (BYOL) の限定的なサポートを提供します。

柔軟な課金

Amazon WorkSpaces Core マネージドインスタンスは、次の2つの課金モードをサポートしています。

課金モード 説明
月額 固定の月額定額課金。永続デスクトップや予測可能なワークロードに最適です。
時間単位 従量課金。課金モードが明示的に指定されていない場合、これはAWSのデフォルト設定です。

これらのオプションにより、ワークロードの永続性と使用パターンに基づいてコンピューティングコストを柔軟に管理できます。

この機能を使用するには、Amazon WorkSpaces 課金サービスを使用する必要があります。デフォルトでは、MCSはこのサービスを使用してインスタンスをプロビジョニングおよび管理するため、永続的なワークロードに対してより競争力のある定額料金の恩恵を受けることができます。

前提条件と考慮事項

  • AWSアカウントの設定: AWSアカウントは、WorkSpaces課金サービスを使用するように設定されている必要があります。AWSアカウントはデフォルトで切り替えられますが、一部のお客様は、WorkSpaces Core マネージドインスタンスを使用するために、AWSにレガシーEC2課金サービスを継続して使用するよう要求する場合があります。

    注:

    アカウントがレガシーEC2課金サービスを使用している場合、月額課金オプションは利用できません。

  • ホスト接続: 柔軟な課金は、Amazon WorkSpaces Coreホスト接続にのみ適用されます。標準のAWS EC2ホスト接続ではサポートされていません。
  • スポットインスタンス: スポットインスタンスは WorkSpaces 課金サービスではサポートされていません。
  • 混合課金: AWSアカウントは、コアマネージドインスタンスに対してWorkSpaces課金またはEC2課金のいずれかを使用する必要があります。単一のアカウント内で両方を混在させることはサポートされていません。
  • 互換性: 特定のインスタンスタイプ、プラットフォームタイプ（OS）、およびテナンシータイプのみが、特定の課金モードと互換性があります。MCSは、選択内容（サービスオファリング、マシンプロファイル、準備済みイメージ）が選択した課金モードと一致することを確認するために、事前チェックを実行します。

[特定の課金モードでマシンカタログを作成する]を参照してください(#create-a-machine-catalog-with-a-specific-billing-mode)。

カタログを作成する

Amazon WorkSpaces Coreマネージドインスタンスのカタログを作成するには、準備済みイメージとマシンプロファイルが必要です。マシンプロファイルの入力として、AWS VMインスタンスまたはAWS起動テンプレートバージョンを使用できます。

注:

現在、永続VMと非永続VMの両方のカタログ（CleanOnBootプロパティがTrueまたはFalseであるもの）の作成がサポートされています。

Amazon WorkSpaces Coreマネージドインスタンスのカタログを作成する前に、以下を作成しておく必要があります。

  1. Amazon WorkSpaces Coreマネージドインスタンスへの接続。[Amazon WorkSpaces Coreマネージドインスタンスへの接続]を参照してください(/ja-jp/citrix-daas/install-configure/connections/connection-amazon-wsc.html)
  2. 準備済みイメージ。

カタログは以下を使用して作成できます。

Studioを使用してカタログを作成する

「イメージ」ノードからマシンカタログを作成する

「イメージ」ノードのカタログの作成オプションを使用して、イメージバージョンでカタログを作成します。

または、「マシンカタログ」ノードでカタログを作成するときにバージョンを選択し、カタログ作成ワークフローで準備されたイメージオプションにリンクすることもできます。「マシンカタログ」ノードからマシンカタログを作成する(#create-a-machine-catalog-from-the-machine-catalogs-node)を参照してください。

「イメージ」ノードからMCSマシンカタログを作成するには、次の手順を実行します。

  1. イメージバージョンを選択し、カタログの作成をクリックします。「はじめに」ページで次へをクリックします。
  2. 「マシン管理」ページと「イメージ」ページでは、選択したイメージバージョンに基づいて設定が事前に選択されています。「イメージ」ページで、選択した準備済みイメージのメモを入力します。
  3. 次のページで設定を完了します。
  4. 「概要」ページで、マシンカタログの詳細を確認します。マシンカタログの名前と説明を入力します。完了をクリックします。
  5. 作成されたマシンカタログを表示するには、「マシンカタログ」ノードに移動します。

「マシンカタログ」ノードからマシンカタログを作成する

「マシンカタログ」ノードからMCSマシンカタログを作成するには、次の手順を実行します。

  1. 左側のナビゲーションペインでマシンカタログをクリックします。
  2. マシンカタログの作成をクリックします。「マシンカタログのセットアップ」ページが表示されます。
  3. 「マシンタイプ」ページで、カタログのマシンタイプ（例: マルチセッションOS）を選択します。

  4. 「マシン管理」ページで、次の設定を選択します。

    1. 「電源管理されているマシン（仮想マシンやブレードPCなど）」を選択します。
    2. 「Citrixプロビジョニングテクノロジー」を選択します。次に、「Citrix Machine Creation Services™」を選択します。
    3. 「リソース」フィールドで、ホスト接続の作成時に構成したリソース（アベイラビリティゾーンまたはローカルゾーン）を選択し、「次へ」をクリックします。
  5. 「デスクトップエクスペリエンス」ページで、ユーザーがログオンしたときに使用するランダムまたは静的デスクトップのいずれかを選択します。静的デスクトップを選択した場合は、ユーザーがローカルディスクで行った変更を保存するかどうか（永続的または非永続的）をさらに指定します。

  6. 「イメージ」ページで、「イメージの選択」をクリックして、マシンカタログ用の準備済みイメージを選択します。作成した準備済みバージョンを選択します。イメージのバージョン名をクリックします。選択したイメージバージョンの詳細を表示するには、下線が引かれているバージョン番号をクリックします。「完了」をクリックします。

    準備済みイメージに関連付けられたマシンプロファイルが表示され、そのハードウェアプロパティ（インスタンスタイプ、テナンシータイプ、ネットワークマッピング、セキュリティグループ、ボリュームプロパティなど）がカタログ内のマシンを作成するために使用されます。マシンプロファイルのソースを別のVMまたは起動テンプレートバージョンに変更するには、編集ボタンをクリックします。

  7. 「仮想マシン」ページで：

    1. カタログのVM数を入力します。
    2. マシンプロファイルに基づいて、デフォルトのマシン仕様が表示されます。変更するには、編集アイコンを選択し、マシン仕様を選択します。
  8. 「NIC」ページで、VMのNIC（またはENI）を選択します。

  9. 「マシンID」ページで、カタログ内のマシンのマシンIDタイプを構成します。

    1. ドメイン参加済みマシン（オンプレミスActive DirectoryまたはMicrosoft Entraハイブリッド参加） を構成するには、ドメインを選択し、このマシンカタログで作成するVM用の新しいADアカウントを作成します。プロビジョニングされたVMは、選択したドメインに参加します。ドメイン非参加マシン をプロビジョニングするには、ドメイン非参加オプションを選択します。
    2. VM用に作成する新しいアカウントのアカウント命名スキームを指定します。
  10. 「ドメイン資格情報」ページで、「資格情報の入力」をクリックして、選択したドメインの資格情報を入力します。プロンプトが表示されたら、管理者レベルのユーザー名とパスワードを入力します。以前に当社の製品ドキュメントに従ってドメイン資格情報を保存している場合は、サービスアカウントを使用することもできます。
  11. 「概要」ページが表示されるまで残りのページをクリックします。マシンカタログの名前を入力し、「完了」を選択してマシンカタログを作成します。

AWSローカルゾーンでのマシンカタログ作成に関する制限事項

  • 特定のローカルゾーンは特定のハードウェア構成のみをサポートします（例：パースのローカルゾーンはGP3ボリュームをサポートせず、GP2のみをサポートします）。
  • すべてのローカルゾーンでgp2のみが普遍的にサポートされており、すべてのローカルゾーンがgp3をサポートしているわけではないため、IDディスクの作成はデフォルトでgp2ボリュームタイプを使用します。
  • 目的のローカルゾーンでサポートされているハードウェア仕様を持つマシンプロファイルを選択する必要があります。
  • 準備済みイメージAMIスナップショットとIDディスクスナップショットは、デフォルトでローカルゾーンではなくリージョンに配置されます（ローカルゾーンでのEBSスナップショットサポートの可視性に関するAWSの制限のため）。
  • 完全なEC2およびEBSサービスをサポートするローカルゾーンのみがサポート対象ゾーンです。

PowerShellを使用してカタログを作成する

準備済みイメージバージョン仕様とマシンプロファイルを使用してカタログを作成する

  • New-ProvSchemeコマンドを使用して、準備済みイメージバージョン仕様からMCS非永続マシンカタログを作成します。例：

     New-ProvScheme -ProvisioningSchemeName <string> -ImageVersionSpecUid <Guid> -HostingUnitUid <Guid> -IdentityPoolUid <Guid> [-CleanOnBoot $true] [-MachineProfile <string>] [-ProvisioningSchemeType “MCS”]
 <!--NeedCopy-->

  • New-ProvSchemeコマンドを使用して、準備済みイメージバージョン仕様からMCS永続マシンカタログを作成します。例：

     New-ProvScheme -ProvisioningSchemeName <string> -ImageVersionSpecUid <Guid> -HostingUnitUid <Guid> -IdentityPoolUid <Guid> [-CleanOnBoot $false] [-MachineProfile <string>] [-ProvisioningSchemeType “MCS”]
 <!--NeedCopy-->

カタログを作成するためのPowershellコマンドの完全なセットの例：

$Catalog = New-BrokerCatalog  -AllocationType "Random"  -IsRemotePC $False  -MinimumFunctionalLevel "L7_20" -Name "wsccatalog" -PersistUserChanges "Discard" -ProvisioningType "MCS" -Scope @() -SessionSupport "MultiSession"

$IdentityPool = New-AcctIdentityPool  -AllowUnicode  -Domain "domainname" -IdentityPoolName "wsccatalog" -IdentityType "ActiveDirectory"  -NamingScheme "aws##" -NamingSchemeType "Numeric" -Scope @()

$PreparedImageVersionSpec = Get-ProvImageVersionSpec -ImageDefinitionName image1 -ImageVersionNumber 1 -Filter "PreparationType -eq 'Mcs'"

$Task = New-ProvScheme -ProvisioningSchemeName wsccatalog -ImageVersionSpecUid $PreparedImageVersionSpec.ImageVersionSpecUid -HostingUnitName wsc -IdentityPoolName wsccatalog -CleanOnBoot -Scope @() -SecurityGroup @() -MachineProfile 'XdHyp:\HostingUnits\cvad-test-scalestress\us-east-1a.availabilityzone\machine-profile-instance i (i-0xxxxxxxx).vm' -RunAsynchronously

Get-ProvTask -TaskId $Task.TaskId
$ProvScheme = Get-ProvScheme -ProvisioningSchemeName wsccatalog

Set-BrokerCatalog -Name $Catalog.Name -ProvisioningSchemeId $ProvScheme.ProvisioningSchemeUid
<!--NeedCopy-->

マシンプロファイルを更新する

マシンプロファイルで最初にプロビジョニングされたカタログのマシンプロファイルを更新するには、次の手順を実行します。MCSマシンカタログを編集する際に、マシンプロファイルソースのテナンシータイプとハイバネーション機能を変更することもできます。

  1. Set-ProvSchemeコマンドを実行します。例：

    Set-ProvScheme `
-ProvisioningSchemeUid "<ID" `
-MachineProfile "XDHyp:\HostingUnits\abc\us-east-1a.availabilityzone\citrix-cvad-machineprofile-instance (i-0xxxxxxxx).vm"
<!--NeedCopy-->

特定の課金モードでマシンカタログを作成する

現在、PowerShell を使用してマシンカタログを作成する際にのみ、課金モードを指定できます。

PowerShell を介して課金モードを指定するには、New-ProvScheme コマンドで CustomProperties パラメーターを使用します。

$custprop = "BillingMode,Monthly"

New-ProvScheme -ProvisioningSchemeName "MyCatalog" `
-ImageVersionSpecUid $ImageVersionSpecUid `
-HostingUnitName "wsc-unit" `
-IdentityPoolName "MyIdentityPool" `
-MachineProfile "XdHyp:\HostingUnits\wsc-unit\machine-profile lt-123.launchtemplate\lt-123 (1).launchtemplateversion" `
-CustomProperties $custprop `
-CleanOnBoot
<!--NeedCopy-->

注:

BillingMode プロパティが省略されている場合、カタログはデフォルトで Hourly になります。

既存のカタログの課金モードを変更する

既存のカタログを Monthly から Hourly に、またはその逆に変換できます。この変更は、カタログ内の新規および既存の VM の両方に適用できます。

更新に関する重要な考慮事項

  • サービスウィンドウ: 既存の VM は、課金変更を適用するためにサービスウィンドウまたは電源サイクルを経る必要があります。
  • 検証: MCS は、変更を適用する前に、既存のインスタンスタイプとプラットフォームが新しい課金モードと互換性があることを検証します。

PowerShell を使用した更新

  • カタログに追加された新しい VM の課金モードのみを更新するには、プロビジョニングスキームの課金モードカスタムプロパティを更新します。

     $custprop = "BillingMode,Hourly"

 Set-ProvScheme -ProvisioningSchemeName "MyCatalog" -CustomProperties $custprop
 <!--NeedCopy-->

  • カタログ内の新規および既存の VM の課金モードを更新するには、更新されたカスタムプロパティを持つ新しいプロビジョニングスキームバージョンを作成し、その新しいバージョンをすべての VM に適用します。

     $custprop = "BillingMode,Hourly"

 New-ProvSchemeVersion -ProvisioningSchemeName "MyCatalog" -CustomProperties $custprop

 New-ProvSchemeHardwareUpdate -ProvisioningSchemeVersion 2 `
 -StartsNow -AllVMs `
 -MaxDurationInMinutes 100 `
 -ProvisioningSchemeName "MyCatalog"
 <!--NeedCopy-->

課金情報の監視

カタログおよび個々の仮想マシンの課金モードを確認できます。

アカウントの課金資格を確認するには、次の PowerShell コマンドを実行します。

  • CustomPropertiesの一部としてBillingModeを返します

     Get-ProvScheme –ProvisioningSchemeName “"MyCatalog" "  | Select  ProvisioningSchemeName,  CustomProperties
 <!--NeedCopy-->

  • VMInfoの一部としてBillingModeを返します

     Get-ProvVMDetails –ProvisioningSchemeName “"MyCatalog" "  | Select-Object  -ExpandProperty VMInfo
 <!--NeedCopy-->

トラブルシューティングと検証

MCSには、互換性のない構成を防ぐための事前チェックが含まれています。カタログの作成または編集中に、次のエラーが発生する可能性があります。

  • NoInstanceConfigFoundForBillingMode: 選択したサービスオファリング（インスタンスタイプ）、テナンシー、およびプラットフォームタイプが、選択された課金モードでサポートされていない場合に発生します。

  • Spot Instance Not Supported: WorkSpacesホスト接続でスポットインスタンスを使用しようとすると、検証に失敗します。
  • EC2 billing restriction: AWSアカウントが従来のEC2課金モデルを使用している場合、月額課金モードを設定しようとすると検証エラーが発生します。

PowerShellを使用して起動テンプレートバージョンでカタログを作成する

起動テンプレートバージョンをマシンプロファイルの入力として使用して、MCSマシンカタログを作成できます。また、マシンプロファイルカタログの入力をVMから起動テンプレートバージョンへ、または起動テンプレートバージョンからVMへ更新することもできます。

AWS EC2コンソールでは、起動テンプレートのインスタンス構成情報をバージョン番号とともに提供できます。マシンカタログの作成または更新時に、起動テンプレートバージョンをマシンプロファイルの入力として指定すると、その起動テンプレートバージョンのプロパティがプロビジョニングされたVDA VMにコピーされます。

以下のプロパティは、マシンプロファイルの入力として、またはNew-ProvSchemeまたはSet-ProvSchemeコマンドのパラメーターとして明示的に提供できます。New-ProvSchemeまたはSet-ProvSchemeコマンドで提供された場合、これらのプロパティのマシンプロファイル値よりも優先されます。

  • サービスオファリング
  • ネットワーク

注:

サービスオファリングがマシンプロファイルの起動テンプレートで提供されていない場合、またはNew-ProvSchemeコマンドのパラメーターとして提供されていない場合、適切なエラーが発生します。

マシンプロファイル入力として起動テンプレートバージョンを使用してカタログを作成するには：

  1. PowerShell ウィンドウを開きます。
  2. Citrix 固有の PowerShell モジュールをロードするには、asnp citrix* を実行します。

  3. 起動テンプレートの起動テンプレートバージョンの一覧を取得します。例：

    XDHyp:\HostingUnits\test\test-mp-sard (lt-01xxxxx).launchtemplate> ls | Select FullPath
<!--NeedCopy-->

  4. 作成されていない場合は、ID プールを作成します。例：

    New-AcctIdentityPool `
-IdentityPoolName "abc11" `
-NamingScheme "abc1-##" `
-NamingSchemeType Numeric `
-Domain "citrix-xxxxxx.local" `
-ZoneUid "xxxxxxxx" `
<!--NeedCopy-->

  5. マシンプロファイル入力として起動テンプレートバージョンを使用してプロビジョニングスキームを作成します。例：

    New-ProvScheme `
-ProvisioningSchemeName "MPLT1" `
-HostingUnitUid "c7f71f6a-3f45-4xxx-xxxx-xxxxxxxxxx" `
-IdentityPoolUid "bf3a6ba2-1f80-4xxx-xxxx-xxxxxxxxx" `
-ImageVersionSpecUid ‘24dfb047-e867-527g-896c-25664xxxxx1t’ `
-CleanOnBoot `
-MachineProfile "XDHyp:\HostingUnits\xxxx-ue1a\machineprofiletest (lt-01xxxxx).launchtemplate\lt-01xxxxx (1).launchtemplateversion"
<!--NeedCopy-->

  6. プロビジョニングスキームをブローカーカタログとして登録します。例：

    New-BrokerCatalog -Name "MPLT1" `
-AllocationType Random `
-Description "Machine profile catalog" `
-ProvisioningSchemeId fe7df345-244e-4xxxx-xxxxxxxxx `
-ProvisioningType Mcs `
-SessionSupport MultiSession `
-PersistUserChanges Discard
<!--NeedCopy-->
  7. カタログの作成を完了します。

マシンプロファイルソースを更新する

マシンプロファイルカタログの入力を、VM から起動テンプレートバージョンへ、または起動テンプレートバージョンから VM へ更新することもできます。例：

  • マシンプロファイルカタログの入力を VM から起動テンプレートバージョンに更新するには：

     Set-ProvScheme -ProvisioningSchemeName "CloudServiceOfferingTest" `
 -MachineProfile "XDHyp:\HostingUnits\xxxx-ue1a\machineprofiletest (lt-0bxxxxxxxxxxxx).launchtemplate\lt-0bxxxxxxxxxxxx (1).launchtemplateversion"
 <!--NeedCopy-->

  • マシンプロファイルカタログの入力を起動テンプレートバージョンから VM に更新するには：

     Set-ProvScheme -ProvisioningSchemeName "CloudServiceOfferingTest" `
 -MachineProfile "XDHyp:\HostingUnits\sard-ue1a\us-east-1a.availabilityzone\apollo-non-persistent-vda-win2022-2 (i-08xxxxxxxxx).vm"
 <!--NeedCopy-->

MCSIO が有効なカタログ

MCS ストレージ最適化 (MCSIO) は、2層メカニズムを通じてディスク書き込み操作をキャッシュすることで、仮想マシンの I/O パフォーマンスを向上させます。

  • メモリ内、または
  • 専用の高速ディスク上（メモリがいっぱいになるとディスクにオーバーフローします）。

Amazon WorkSpaces Core マネージドインスタンスの場合、MCSIO を有効にすると、標準の OS ディスクと ID ディスクに加えて、プロビジョニングされた各 VM にライトバックキャッシュ (WBC) ディスクが接続されます。

MCSIO を有効にして構成するには、以下を使用します。

  • スタジオ
  • PowerShell

Studio を使用して MCSIO を有効にする

前提条件

Studio で MCSIO を構成する前に、以下を確認してください。

  • マスターイメージ (AMI) に MCSIO ドライバーがインストールされていること。VDA をインストールまたはアップグレードするときに、MCSIO ドライバーをインストールするオプションを選択します。デフォルトでは、ドライバーはインストールされません。
  • MCSIO ドライバーを含むマスターイメージから、準備されたイメージバージョンが作成されていること。
  • マシンカタログが非永続 (CleanOnBoot) デスクトップエクスペリエンスを使用していること。MCSIO は非永続 VDI カタログに適用されます。

Studio を使用して MCSIO が有効なマシンカタログを作成する

カタログの作成 で説明されているように、以前のカタログ作成手順（マシンタイプ、マシン管理、デスクトップエクスペリエンス、イメージ、仮想マシン、NIC、マシンID、ドメイン資格情報）を完了します。ディスク設定ページに到達したら、以下を実行します。

  1. ディスク設定ページで、最適な I/O パフォーマンスのためにライトバックキャッシュを有効にして構成するチェックボックスをオンにします。

  2. ライトバックキャッシュディスクの設定を構成します。

    • ディスクキャッシュサイズ (GB): キャッシュに使用するディスクのサイズをギガバイト単位で入力します。値は1 GB以上で、OSディスクサイズを超えてはなりません。
    • ディスクドライブ文字: システムにドライブ文字を自動的に割り当てさせるには「自動割り当て」を選択するか、ドライブ文字を手動で指定します。
    • キャッシュに割り当てられるメモリ (MB): キャッシュに割り当てるメモリ量をメガバイト単位で入力します。値はゼロより大きく、マシンの総メモリ量より小さくなければなりません。

    注：

    ライトバックキャッシュを使用するには、マスターイメージにMCSIOドライバーがインストールされている必要があります。

  3. ライトバックキャッシュディスクのストレージタイプを選択で、EBS SSDボリュームタイプを選択します。

    ストレージタイプ：

    • 汎用SSD (gp2)
    • 汎用SSD (gp3)
    • プロビジョンドIOPS SSD (io1)
    • プロビジョンドIOPS SSD (io2)

    注：

    ライトバックキャッシュはEBS SSDボリュームタイプのみをサポートします。HDDボリュームタイプおよびローカルインスタンスストレージ（エフェメラルストレージ）はサポートされていません。

  4. ライトバックキャッシュディスクの永続性タイプを選択で、次のいずれかを選択します。

    • 非永続ライトバックキャッシュディスクを使用: キャッシュディスクはマシンの電源がオンになると作成され、電源がオフになると削除されます。これがデフォルトです。
    • 「永続的なライトバックキャッシュディスクを使用する」：キャッシュディスクは電源サイクルをまたいで保持されます。

  5. 「システムディスク」で、オプションで「電源サイクル中にシステムディスクを保持する」を選択して、マシンの電源がオフになったときにOSディスクを保持します。有効にすると、マシンは起動ごとにテンプレートからルートディスクを再作成するのをスキップし、起動時間を短縮します。

    「注：」:

    起動パフォーマンスを最適化するには、「永続的なライトバックキャッシュディスクを使用する」と「電源サイクル中にシステムディスクを保持する」の両方を有効にします。両方のオプションを有効にすると、マシンは起動時に新しいキャッシュディスクとOSディスクを初期化するのではなく、既存のものを再利用します。

  6. 残りのウィザードページに進むには、「次へ」をクリックします。

  7. 「概要」ページで、完了する前にMCSIO関連の設定を確認します。概要には、次のライトバックキャッシュフィールドが表示されます。

    • 一時ディスクキャッシュを有効にする
    • メモリキャッシュサイズ (MB)
    • ディスクキャッシュサイズ (GB)
    • ライトバックキャッシュディスクで永続化
    • ライトバックキャッシュディスクの種類
    • ライトバックキャッシュディスクのドライブ文字
    • システムディスクを保持する
  8. マシンカタログの名前とオプションの説明を入力し、「完了」をクリックします。

Studio を使用して既存のカタログの MCSIO 設定を更新する

既存のカタログのライトバックキャッシュ設定は、マシンカタログの編集から更新できます。

注:

ディスク設定ページで行った変更は、後でカタログに追加する新しいマシンにのみ適用されます。既存のマシンは変更されません。

  1. マシンカタログから、更新するカタログを選択し、マシンカタログの編集をクリックします。

  2. ディスク設定ページに移動します。次のいずれかの設定を更新します。

    • ディスクキャッシュサイズ (GB): ライトバックキャッシュディスクのサイズを変更します。
    • キャッシュに割り当てられたメモリ (MB): キャッシュに割り当てられたメモリを変更します。
    • ストレージタイプ: ライトバックキャッシュディスクのEBSボリュームタイプを変更します。
    • 永続性タイプ: 永続ライトバックキャッシュディスクと非永続ライトバックキャッシュディスクを切り替えます。
    • 電源サイクル中にシステムディスクを保持: OSディスクの保持を有効または無効にします。
  3. 閉じずに保存するには適用をクリックし、保存して閉じるには保存をクリックします。

MCSIOが有効なマシンのEBSディスクレイアウト

MCSIOが有効な場合、プロビジョニングされた各Amazon WorkSpaces Core VMには3つのEBSボリュームが接続されます。ディスクレイアウトは、AWS Management ConsoleのEC2インスタンス詳細のElastic Block Storeセクションで確認できます。

ディスク デバイスインデックス 説明
OSディスク /dev/sda1 準備されたイメージからクローンされたルートボリューム。「電源サイクル中にシステムディスクを保持する」が有効になっている場合、マシンの電源がオフになってもこのディスクは保持されます。
IDディスク エックスブイディーエフ プロビジョニングされたVMのマシンID情報を保存します。常に保持されます。
ライトバックキャッシュディスク エックスブイディーシー MCSIO書き込み操作用の高速キャッシュディスク。「永続的なライトバックキャッシュディスクを使用する」が選択されている場合にのみ、電源サイクルを超えて保持されます。

ライトバックキャッシュとOSディスクの動作リファレンス

次の表は、選択された永続性設定に基づいてライトバックキャッシュとOSディスクがどのように動作するかをまとめたものです。

WBC永続性 OSディスク保持 電源オフ時 起動パフォーマンス VMの電源オフ時のストレージコスト
非永続 (デフォルト) 無効 (デフォルト) WBCディスクとOSディスクの両方が削除されます。次回の電源投入時に新しいディスクが作成されます。 標準 OSディスクまたはWBCディスクのコストはかかりません。
非永続 (デフォルト) 有効 WBCディスクは削除されます。OSディスクは保持されます。 高速 — OSディスクの初期化をスキップします OSディスクのコストはかかりますが、WBCディスクのコストはかかりません。
永続 無効 (デフォルト) WBCディスクは保持されます。OSディスクは削除され、次回の電源投入時にテンプレートから再作成されます。 より高速 — WBCの初期化をスキップ WBCディスクのコストはかかるが、OSディスクのコストはかからない。
永続的 有効 WBCディスクとOSディスクの両方が保持されます。 最速 — ディスクの初期化は不要 OSディスクとWBCディスクのコストがかかります。

注：

非永続カタログでOSディスクの保持を有効にすると、再起動時にOSディスクがリセットされません。これにより、起動時間は速くなりますが、OSディスクのストレージコストが発生します。ただし、すべての書き込みは、ライトバックメモリキャッシュまたはライトバックキャッシュディスクにのみ行われます。OSディスクの保持を有効にしても、ユーザーの変更はOSディスクに蓄積されません。環境要件に基づいて評価してください。

PowerShellを使用してMCSIOを有効にする

PowerShellを使用してMCSIOが有効なカタログを作成する

New-ProvScheme PowerShellコマンドに追加される4つのパラメーターは次のとおりです。

  • UseWriteBackCache: 指定されたプロビジョニングスキームのキャッシュ（ライトバックキャッシュ）をオンにします
  • WriteBackCacheDiskSize: キャッシュに使用される一時ディスクのサイズをGB単位で指定します
  • WriteBackCacheMemorySize: キャッシュに使用するメモリ量をMB単位で指定します。これはオプションのパラメーターです。

注：

  • WriteBackCacheDiskSize の値は、少なくとも 1 GB のキャッシュディスクストレージが必要なため、ゼロより大きくする必要があります。キャッシュディスクのサイズは、OS ディスクのサイズより大きくしてはいけません。
  • WriteBackCacheMemorySize の値は、ゼロ以外で、マシンカタログのメモリサイズよりも小さくする必要があります。

MCSIO に影響するカスタムプロパティは次のとおりです。

  • WBCDiskStorageType: Amazon WorkSpaces Core Managed Instances の一時ディスクに使用されるボリュームタイプを定義します。このパラメーターは、volume-type[:iops][:throughput] の形式で文字列引数を取ります。ボリュームタイプは次のとおりです。

    • gp2: このボリュームタイプには iops および throughput パラメーターを使用しないでください
    • gp3: このボリュームタイプには iops および throughput パラメーターを使用してください
    • io1: このボリュームタイプには iops パラメーターのみを使用してください
    • io2: このボリュームタイプには iops パラメーターのみを使用してください

    デフォルトのボリュームタイプは gp2 です。

  • PersistWBC: Amazon WorkSpaces Core Managed Instances の電源がオフになったときに、キャッシュディスクを保持するか破棄するかを制御します。true に設定すると、キャッシュディスクは保持されます。false (デフォルト) に設定すると、キャッシュディスクは AMI インスタンスの電源がオンになっている間のみ作成および保持されます。
  • PersistOSDisk: Amazon WorkSpaces Core Managed Instances の電源がオフになったときに、OS ディスクを保持するか破棄するかを制御します。true に設定すると、OS ディスクは保持されます。false (デフォルト) に設定すると、OS ディスクは AMI インスタンスの電源がオンになっている間のみ作成および保持されます。

MCSIO が有効な非永続カタログを作成するには、PowerShell ウィンドウで次の手順を実行します。

  1. PowerShell ウィンドウを開きます。
  2. Citrix 固有の PowerShell モジュールをロードするには、asnp citrix* を実行します。
  3. ブローカーカタログとIDプールを作成します。

  4. プロビジョニングスキームを作成します。例:

    $HostingUnitUid = '0xxxx1d9-bbfc-xxxf-bxxb-exxxxxe008b2'
$MasterImageVM = 'XDHyp:\HostingUnits\ctx-test\aws-apollo-non-persistent-multi-mcsio-vda-win2022 (ami-0bf1810488acbxxxb).template'
$NetworkMap = @{ 'NetworkPath' = 'XDHyp:\HostingUnits\ctx-test\us-east-1a.availabilityzone\10.0.128.0`/17 (vpc-0fa6e41d72507fxxx).network' }
$SecurityGroup = $( 'XDHyp:\HostingUnits\ctx-test\us-east-1a.availabilityzone\private.securitygroup' )
$ServiceOffering = 'XDHyp:\HostingUnits\ctx-test\T3 Medium Instance.serviceoffering'
$CustomProperties = 'WBCDiskStorageType,gp3:6000:250;PersistWBC,false'

$provScheme = New-ProvScheme -ProvisioningSchemeName $CatalogName -HostingUnitUid $HostingUnitUid `
-IdentityPoolUid $acctPool.IdentityPoolUid -CleanOnBoot `
- MasterImageVM $MasterImageVM `
-NetworkMap $NetworkMap `
-ServiceOffering $ServiceOffering `
-SecurityGroup $SecurityGroup `
-CustomProperties $CustomProperties `
-UseWriteBackCache -WriteBackCacheDiskSize 16 -WriteBackCacheMemorySize 256
<!--NeedCopy-->
  5. カタログにVMを追加します。

MCSIOで起動パフォーマンスを向上させる

MCSIOを有効にし、PersistWBCとPersistOSDiskのカスタムプロパティをtrueとして設定すると、VMの起動パフォーマンスを向上させることができます。このような設定により、VMは新しいキャッシュディスクを初期化したり、テンプレートからルートディスクを再作成したりする必要がないため、より高速に起動できます。

OSディスクとIDディスクを暗号化する

AWS KMSキー（カスタマー管理キーとAWS管理キー）を使用してVMのカタログを作成でき、これらはOSディスクとIDディスクの暗号化に使用できます。

  • AWS管理キーは毎年自動的にローテーションされます。
  • カスタマー管理キーは自動ローテーションがオプションであり、手動で管理できます。

KMSキーの詳細については、以下のAWSドキュメントを参照してください。

OSディスクとIDディスクの暗号化には、次のいずれかを構成します。

  • 暗号化された準備済みイメージを使用します (たとえば、KMSキーで暗号化されたEBSルートボリュームを含むインスタンスまたはスナップショットから作成されたAMI)
  • 暗号化されたEBSルートボリュームを含むマシンプロファイルソース (VMまたは起動テンプレート) を使用します。

制限事項

次の制限事項を考慮してください。

  • MCS は現在、準備済みイメージ AMI 上のディスクを 1 つのみサポートしています。

  • 既存の暗号化されていない EBS ボリュームまたはスナップショットを直接暗号化したり、既存の暗号化されたボリュームの KMS キーを変更したりすることはできません。これを行うには、次の手順を実行する必要があります。

    1. そのボリュームの新しいスナップショットを作成します。
    2. そのスナップショットから新しいボリュームを作成します。
    3. 新しいボリュームを暗号化します。

次の AWS ドキュメントを参照してください。

ディスク暗号化を使用してカタログを作成する

ディスク暗号化を使用して MCS マシンカタログを作成するには、次の方法があります。

  • 準備済みイメージ（暗号化されたディスクを持つマスターイメージからのイメージ管理を使用して作成）
  • マシンプロファイル

マシンプロファイル入力を使用する際の考慮事項は次のとおりです。

  • マシンプロファイル入力のKMSキーは、準備済みイメージのKMSキーよりも優先されます。
  • マシンプロファイルの入力が提供されない場合、準備済みイメージAMIのKMSキーがカタログVMのディスクの暗号化に使用されます。
  • マシンプロファイルにブロックデバイスマッピングが存在する場合、準備済みイメージテンプレート（AMI）とマシンプロファイルに存在するブロックデバイスは一致している必要があります。たとえば、AMIに/dev/sda1で定義されたデバイスがある場合、マシンプロファイルにも/dev/sda1で定義されたデバイスが必要です。
  • マシンプロファイルソースにキーがなく、準備済みイメージが暗号化されていない場合、カタログVMのディスクは暗号化されません。
  • 準備済みイメージが暗号化されている場合、マシンプロファイルソースVMまたは起動テンプレートには、有効な入力と見なされるために暗号化されたルートボリュームが必要です。

既存のカタログを変更する

Set-ProvScheme PowerShellコマンドを使用して、既存のカタログを次のように変更できます。

  • 新しいKMSキーを含むボリュームを持つマシンプロファイル入力。
  • イメージ管理を使用して、暗号化されたAMIを持つマスターイメージから作成された準備済みイメージ。

重要な考慮事項：

  • カタログに追加された新しいVMのボリュームは、新しいKMSキーで暗号化されます。
  • 既存のマシンプロファイルがある場合に暗号化設定を更新するには、新しいマシンプロファイルでSet-ProvSchemeを実行します。
  • 既存のカタログを、暗号化されたボリュームから暗号化されていないボリュームに変更することはできません。 暗号化された準備済みイメージAMIから暗号化されていない準備済みイメージAMIへのイメージ更新はできません。

VMインスタンスでNitroTPMとUEFIセキュアブートを有効にする

カタログを作成する際、NitroTPMおよび/またはUEFIセキュアブートが有効な準備済みイメージ（AMI）を選択できるようになりました。これにより、カタログ内のプロビジョニングされたVMもNitroTPMおよび/またはUEFIセキュアブートが有効になります。この実装により、VMのセキュリティと信頼性が確保されます。NitroTPMとUEFIセキュアブートの詳細については、Amazonドキュメントを参照してください。

制限事項

  • 現在、中国を除くすべてのAWSリージョン（AWS GovCloud (US) リージョンを含む）で、NitroTPMとセキュアブートの両方を使用できます。
  • 既存のカタログでNitroTPMとUEFIセキュアブートを有効にすることはできません。NitroTPMとUEFIセキュアブートが有効なカタログが必要な場合は、新しいカタログを作成してください。

主な手順

  1. AWS環境をセットアップします。
  2. AWSへの接続を作成します。
  3. NitroTPMおよび/またはUEFIセキュアブートが有効なマスターイメージ (AMI) を作成します(#create-an-ami-that-supports-nitrotpm-and-uefi-secure-boot)。
  4. マスターイメージから準備済みイメージを作成します。詳細については、「Amazon WorkSpaces Coreマネージドインスタンス用の準備済みイメージを作成する」(/ja-jp/citrix-daas/install-configure/create-prepared-image-amazon-wsc.html)を参照してください。
  5. Citrix Studioのカタログ作成メニューでNitroTPMとUEFIセキュアブートが有効な準備済みイメージを選択するか、PowerShellコマンドを使用してプロビジョニングスキームを作成する際に、マシンカタログを作成します。

作成されたカタログに追加されたVMには、NitoTPMとUEFIセキュアブートが有効になっています。

NitroTPMとUEFIセキュアブートをサポートするAMIを作成する

  1. NitroTPMおよび/またはUEFIセキュアブートが有効なVMからAMIを作成できます。

    1. AWS Marketplaceイメージを使用してインスタンスを作成します。例: TPM-Windows_Server-2022-English-Full-Base on the aws-marketplaceを検索します。
    2. シングルセッションまたはマルチセッションVDAをダウンロードします。
    3. そのVMからAMIを作成します。

  2. register-imageコマンドを使用します:

    --boot-mode (string)
--tpm-support (string)
<!--NeedCopy-->

    詳細については、register-imageを参照してください。

以下のAWSドキュメントを参照してください:

Delivery controller™ホストからPowerShellウィンドウを開き、特定の項目を確認できます:

  • サービスオファリングがNitroTPMまたはUEFIセキュアブートをサポートしているか

     (Get-Item -Path “XDHyp:\HostingUnits\aws\T3 Medium Instance.serviceoffering”).AdditionalData.BootMode
 (Get-Item -Path “XDHyp:\HostingUnits\aws\T3 Medium Instance.serviceoffering”).AdditionalData.NitroTpmSupportVersions
 <!--NeedCopy-->

  • テンプレートがNitroTPMまたはUEFIセキュアブートをサポートしているか

     (Get-HypInventoryItem -LiteralPath “XDHyp:\HostingUnits\aws” -ResourceType “template -Id “ID”).AdditionalData.BootMode

 (Get-HypInventoryItem -LiteralPath “XDHyp:\HostingUnits\aws” -ResourceType “template -Id “ID”).AdditionalData.TpmSupport
 <!--NeedCopy-->

既存のカタログのサービスオファリングを更新する

Set-ProvSchemeを使用して、既存のカタログのサービスオファリングを変更できます。この変更は、新しく追加されたVMに適用されます。ただし、以下のシナリオではエラーが発生します:

AMIのブートモード AMIはNitro TPMをサポートしていますか？ サービスオファリングはNitroTPMとUEFIセキュアブートをサポートしていますか？
UEFI いいえ いいえ
レガシーBIOS はい いいえ
UEFI はい いいえ
UEFI優先 はい いいえ

VM上のタグをコピーする

マシンプロファイルで指定されたNICとディスク（IDディスク、ライトバックキャッシュディスク、OSディスク）のタグを、MCSマシンカタログで新しく作成されたVMにコピーできます。これらのタグは、マシンプロファイルソース（AWS VMインスタンスまたはAWS起動テンプレートバージョン）のいずれかで指定できます。この機能は、永続および非永続マシンカタログとVMに適用されます。

注：

  • AWS EC2コンソールでは、起動テンプレートバージョンのリソースタグの下にネットワークインターフェイスのタグ付けの値が表示されません。ただし、PowerShellコマンドaws ec2 describe-launch-template-versions --launch-template-id lt-0bb652503d45dcbcd --versions 12を実行してタグの仕様を確認できます。
  • マシンプロファイルソース（VMまたは起動テンプレートバージョン）に2つのネットワークインターフェイス（eni-1とeni-2）があり、eni-1にタグt1、eni-2にタグt2がある場合、VMは両方のネットワークインターフェイスのタグを取得します。

PowerShell を使用して VM インスタンスをフィルタリングする

マシンプロファイル VM として使用する AWS VM インスタンスは、マシンカタログが正しく作成され機能するために互換性がある必要があります。マシンプロファイルの入力 VM として使用できる AWS VM インスタンスを一覧表示するには、Get-HypInventoryItem コマンドを使用できます。このコマンドは、ホスティングユニットで利用可能な VM のインベントリをページングおよびフィルタリングできます。

ページネーション:

Get-HypInventoryItem は、2 つのページネーションモードをサポートしています。

  • ページングモードでは、-MaxRecords および -Skip パラメーターを使用してアイテムのセットを返します。
    • -MaxRecords: デフォルトは 1 です。これは、返すアイテムの数を制御します。
    • -Skip: デフォルトは 0 です。これは、ハイパーバイザー内のリストの絶対的な先頭 (または絶対的な末尾) からスキップするアイテムの数を制御します。
  • スクロールモードでは、-MaxRecords、-ForwardDirection、および -ContinuationToken パラメーターを使用してレコードのスクロールを許可します。
    • -ForwardDirection: デフォルトは True です。これは -MaxRecords とともに使用され、一致するレコードの次のセットまたは前のセットのいずれかを返します。
    • -ContinuationToken: これは、ContinuationToken で指定されたアイテムの直後 (または ForwardDirection が false の場合は直前) のアイテムを返しますが、そのアイテム自体は含みません。

ページネーションの例:

  • 最も名前の小さいマシンテンプレートの単一レコードを返します。AdditionalData フィールドには TotalItemsCount と TotalFilteredItemsCount があります。

     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template
 <!--NeedCopy-->

  • 最も名前の小さいマシンテンプレートのレコードを 10 件返します。

     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -MaxRecords 10 | select Name
 <!--NeedCopy-->

  • 最も名前の大きいレコードで終わるレコードの配列を返します。

     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -ForwardDirection $False -MaxRecords 10 | select Name
 <!--NeedCopy-->

  • 指定された ContinuationToken に関連付けられたマシンテンプレートから始まるレコードの配列を返します。

     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -ContinuationToken "ami-07xxxxxxxxxx" -MaxRecords 10
 <!--NeedCopy-->

フィルタリング:

フィルタリングには、以下の追加のオプションパラメーターがサポートされています。これらのパラメーターは、ページネーションオプションと組み合わせることができます。

  • -ContainsName "my_name": 指定された文字列がAMI名の一部と一致する場合、そのAMIはGet結果に含まれます。例：

     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -MaxRecords 100 -ContainName ‘apollo’ | select Name
 <!--NeedCopy-->

  • -Tags '{ "Key0": "Value0", "Key1": "Value1", "Key2": "Value2" }': AMIにこれらのタグの少なくとも1つがある場合、そのAMIはGet結果に含まれます。例：

     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -MaxRecords 100 -Tags '{"opex owner": "Not tagged"}' | select Name
 <!--NeedCopy-->

    注：

    2つのタグ値がサポートされています。タグなしタグ値は、タグのリストに指定されたタグがない項目と一致します。すべての値タグ値は、タグの値に関係なくタグを持つ項目と一致します。それ以外の場合、一致は、項目がタグを持ち、その値がフィルターで指定されたものと等しい場合にのみ発生します。

  • -Id "ami-0a2d913927e0352f3": AMIが指定されたIDと一致する場合、そのAMIはGet結果に含まれます。例：

     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -Id ami-xxxxxxxxxxxxx
 <!--NeedCopy-->

AdditionalDataパラメーターでのフィルタリング:

AdditionalDataフィルターパラメーターは、テンプレートまたはVMを、その機能、サービス提供、またはAdditionalDataにある任意のプロパティに基づいてリストします。例：

(Get-HypInventoryItem -ResourceType "launchtemplateversion" -LiteralPath "XDHyp:\HostingUnits\aws" -MaxRecords 200).AdditionalData
<!--NeedCopy-->

互換性のないVMを示すために、-Warnパラメーターを追加することもできます。VMには、Warningという名前のAdditionalDataフィールドが含まれます。例：

(Get-HypInventoryItem -ResourceType "launchtemplateversion" -LiteralPath "XDHyp:\HostingUnits\aws" -MaxRecords 200 -Template "ami-015xxxxxxxxx" -Warn $true).AdditionalData
<!--NeedCopy-->

次のステップ

詳細情報

Amazon WorkSpaces Core マネージドインスタンスで準備済みイメージを使用してカタログを作成する
September 3, 2026
寄稿者: 
C C
September 3, 2026
寄稿者: 
C C

この記事の概要

サイトに関するフィードバック | Your privacy choices footer linkプライバシーに関する選択肢 | プライバシーと法令 | Cookieの設定 | 同意設定 | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.