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

最終公開日 : Oct 24, 2026
準備済みイメージを作成し、その準備済みイメージを使用して、以下で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. 「Machine Specification」ページで、マシンサイズを選択します。マシンプロファイル(「Image」ページで選択)のマシンサイズがデフォルトで選択されています。
  5. 「NICs」ページで、準備イメージ用のNICを選択または追加します。各NICについて、関連するVPCサブネットを選択します。
  6. 「Version Description」ページで、作成された初期イメージバージョンの説明を入力します。
  7. 「Summary」ページで、イメージ定義と作成された初期イメージバージョンの詳細を確認します。イメージ定義の名前と説明を入力します。「Finish」をクリックします。

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

イメージバージョンを使用すると、特定のイメージに対するさまざまなイテレーションや更新を管理できます。この機能により、さまざまな目的のためにイメージの複数のバージョンを維持できます。
初期イメージバージョンからイメージバージョンを作成するには、次の手順を実行します。
注:
すべてのイメージバージョンのホスティングユニットは同じである必要があります。
  1. 「Images」ノードに移動し、イメージバージョンまたはイメージ定義を選択して、「Create Image Version」をクリックします。
  2. 「Image definition」ページで、ホスティングユニットを変更し、そのイメージバージョンのマスターイメージとマシンプロファイルを再選択できます。
  3. イメージバージョンの構成を初期構成イメージバージョンと異なるものにする場合は、「Create Image Version」ダイアログの「Machine Specification」ページと「NICs」ページで設定を構成します。
  4. イメージバージョンの説明を追加します。「Finish」をクリックします。
注:
何らかの理由でイメージバージョンの作成に失敗した場合、下部にあるトラブルシューティングタブに再試行オプションが表示されます。

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

準備済みイメージバージョン仕様を作成するための詳細な PowerShell コマンドは次のとおりです。
  1. Test-ProvImageDefinitionNameAvailable command を使用して、利用可能なイメージ定義名を確認します。例:
    Test-ProvImageDefinitionNameAvailable -ImageDefinitionName <string[]>
  2. New-ProvImageDefinition コマンドを使用してイメージ定義を作成します。例:
    New-ProvImageDefinition -ImageDefinitionName image1 -OsType Windows -VdaSessionSupport MultiSession
  3. Add-ProvImageDefinitionConnection コマンドを使用して、指定されたホスティング接続でイメージ定義の新しい構成を作成します。
    Add-ProvImageDefinitionConnection -ImageDefinitionName image1 -HypervisorConnectionName test-conn
  4. New-ProvImageVersion コマンドを使用してイメージバージョンを作成します。例:
    New-ProvImageVersion -ImageDefinitionName image1 -Description "version 1"
  5. Add-ProvImageVersionSpec コマンドを使用して、マスターイメージバージョン仕様をイメージバージョンに追加します。例:
    Add-ProvImageVersionSpec -ImageDefinitionName  image1  -ImageVersionNumber  1 -HostingUnitName wsc -MasterImagePath "XDHyp:\HostingUnits\wsc\win10-2411-ami (ami-00123456789abcdef).template”"
    注:
    ホスティングユニットのイメージバージョンには、マスターイメージバージョン仕様を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
イメージ定義、イメージバージョン、および準備済みイメージバージョン仕様を作成するための 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
注:
  • イメージ定義内のすべてのイメージバージョン仕様は、同じホスティングユニットに属している必要があります。
  • イメージバージョンには、マスターイメージバージョン仕様を1つ、準備済みイメージバージョン仕様を1つだけ含めることができます。
  • すべてのイメージバージョン仕様には、マシンプロファイルが必要です。

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

Amazon WorkSpaces Core マネージドインスタンスの場合、単一の準備済みイメージを、同じ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 を特定します。これは、その特定のアベイラビリティゾーン用に構成したホスティングユニットの名前です。
  3. 「Add-ProvImageVersionSpecHostingUnit コマンドを実行します:」次の PowerShell コマンドを使用します。<ImageVersionSpecUid> をイメージの Uid に、<targetHostingUnitName> を、イメージバージョン仕様を共有するターゲットアベイラビリティゾーンのホスティングユニット名に置き換えます。
    Add-ProvImageVersionSpecHostingUnit -ImageVersionSpecUid <ImageVersionSpecUid> -HostingUnitName <targetHostingUnitName>
  4. 正常に実行されると、Studio UI でイメージのステータスを確認でき、指定されたホスティングユニットと共有されたことが示されます。

準備されたイメージの共有を削除するには

  1. 共有を削除したい準備されたイメージの ImageVersionSpecUid を持っていることを確認します。
  2. 共有イメージを削除したいアベイラビリティゾーンの HostingUnitName を特定します。
  3. 「Remove-ProvImageVersionSpecHostingUnit コマンドを実行します:」次の PowerShell コマンドを使用します。<ImageVersionSpecUid> をイメージの Uid に、<targetHostingUnitName> を、イメージバージョン仕様の共有を削除するターゲットアベイラビリティゾーンのホスティングユニット名に置き換えます。
    Remove-ProvImageVersionSpecHostingUnit -ImageVersionSpecUid <ImageVersionSpecUid> -HostingUnitName <targetHostingUnitName>

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

イメージ準備中に、元の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 マネージドインスタンスを使用するために、レガシーEC2請求サービスに残るようAWSに要求する場合があります。
    注:
    アカウントがレガシーEC2請求サービスを使用している場合、月額請求オプションは利用できません。
  • ホスト接続: 柔軟な請求は、Amazon WorkSpaces Core ホスト接続にのみ適用されます。標準のAWS EC2ホスト接続ではサポートされていません。
  • スポットインスタンス: スポットインスタンスは、WorkSpaces課金サービスではサポートされていません。
  • 混合課金: AWSアカウントは、コアマネージドインスタンスに対してWorkSpaces課金またはEC2課金のいずれかを使用する必要があります。単一のアカウント内で両方を混在させることはサポートされていません。
  • 互換性: 特定のインスタンスタイプ、プラットフォームタイプ(OS)、およびテナンシータイプのみが、特定の課金モードと互換性があります。MCSは、選択内容(Service Offering、Machine Profile、およびPrepared Image)が選択された課金モードと一致することを確認するために、事前チェックを実行します。
「特定の課金モードでマシンカタログを作成する」を参照してください(#create-a-machine-catalog-with-a-specific-billing-mode)。

カタログを作成する

Amazon WorkSpaces Core Managed Instancesのカタログを作成するには、準備されたイメージとマシンプロファイルが必要です。マシンプロファイルの入力として、AWS VMインスタンスまたはAWS起動テンプレートバージョンを使用できます。
注:
現在、永続VMと非永続VMの両方のカタログの作成(CleanOnBootプロパティがTrueまたはFalseの場合)がサポートされています。
Amazon WorkSpaces Core Managed Instancesのカタログを作成する前に、以下を作成しておく必要があります。
  1. Amazon WorkSpaces Core Managed Instancesへの接続。「Amazon WorkSpaces Core Managed Instancesへの接続」を参照してください(/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”]
  • New-ProvSchemeコマンドを使用して、準備済みイメージバージョン仕様からMCS永続マシンカタログを作成します。例:
    New-ProvScheme -ProvisioningSchemeName <string> -ImageVersionSpecUid <Guid> -HostingUnitUid <Guid> -IdentityPoolUid <Guid> [-CleanOnBoot $false] [-MachineProfile <string>] [-ProvisioningSchemeType “MCS”]
カタログを作成するための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

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

マシンプロファイルで最初にプロビジョニングされたカタログのマシンプロファイルを更新するには、次の手順を実行します。MCSマシンカタログを編集する際に、マシンプロファイルソースのテナンシータイプとハイバネーション機能を変更することもできます。
  1. Set-ProvSchemeコマンドを実行します。例:
    Set-ProvScheme `
    -ProvisioningSchemeUid "<ID" `
    -MachineProfile "XDHyp:\HostingUnits\abc\us-east-1a.availabilityzone\citrix-cvad-machineprofile-instance (i-0xxxxxxxx).vm"

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

現在、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
注:
BillingMode プロパティが省略されている場合、カタログはデフォルトで Hourly になります。

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

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

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

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

PowerShell を使用した更新

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

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

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

    New-ProvSchemeHardwareUpdate -ProvisioningSchemeVersion 2 `
    -StartsNow -AllVMs `
    -MaxDurationInMinutes 100 `
    -ProvisioningSchemeName "MyCatalog"

課金情報の監視

カタログおよび個々の仮想マシンの課金モードを確認できます。
アカウントの課金資格を確認するには、次の PowerShell コマンドを実行します。
  • CustomPropertiesの一部としてBillingModeを返します
    Get-ProvScheme –ProvisioningSchemeName “"MyCatalog" "  | Select  ProvisioningSchemeName,  CustomProperties
  • VMInfoの一部としてBillingModeを返します
    Get-ProvVMDetails –ProvisioningSchemeName “"MyCatalog" "  | Select-Object  -ExpandProperty VMInfo

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

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
  4. 作成されていない場合は、IDプールを作成します。例:
    New-AcctIdentityPool `
    -IdentityPoolName "abc11" `
    -NamingScheme "abc1-##" `
    -NamingSchemeType Numeric `
    -Domain "citrix-xxxxxx.local" `
    -ZoneUid "xxxxxxxx" `
  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"
  6. プロビジョニングスキームをブローカーカタログとして登録します。例:
    New-BrokerCatalog -Name "MPLT1" `
    -AllocationType Random `
    -Description "Machine profile catalog" `
    -ProvisioningSchemeId fe7df345-244e-4xxxx-xxxxxxxxx `
    -ProvisioningType Mcs `
    -SessionSupport MultiSession `
    -PersistUserChanges Discard
  7. カタログの作成を完了します。

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

マシンプロファイルカタログの入力を、VMから起動テンプレートバージョンへ、または起動テンプレートバージョンからVMへ更新することもできます。例:
  • マシンプロファイルカタログの入力をVMから起動テンプレートバージョンに更新するには:
    Set-ProvScheme -ProvisioningSchemeName "CloudServiceOfferingTest" `
    -MachineProfile "XDHyp:\HostingUnits\xxxx-ue1a\machineprofiletest (lt-0bxxxxxxxxxxxx).launchtemplate\lt-0bxxxxxxxxxxxx (1).launchtemplateversion"
  • マシンプロファイルカタログの入力を起動テンプレートバージョンからVMに更新するには:
    Set-ProvScheme -ProvisioningSchemeName "CloudServiceOfferingTest" `
    -MachineProfile "XDHyp:\HostingUnits\sard-ue1a\us-east-1a.availabilityzone\apollo-non-persistent-vda-win2022-2 (i-08xxxxxxxxx).vm"

MCSIOが有効なカタログ

MCSストレージ最適化 (MCSIO) は、2層メカニズムを通じてディスク書き込み操作をキャッシュすることにより、仮想マシンのI/Oパフォーマンスを向上させます。
  • メモリ内、または
  • 専用の高速ディスク上(メモリがいっぱいになるとディスクにオーバーフローします)。
Amazon WorkSpaces Core マネージドインスタンスの場合、MCSIO を有効にすると、標準の OS ディスクと ID ディスクに加えて、プロビジョニングされた各 VM にライトバックキャッシュ (WBC) ディスクがアタッチされます。
MCSIO を有効にして構成するには、以下を使用します。
  • スタジオ
  • PowerShell

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

前提条件

Studio で MCSIO を構成する前に、以下を確認してください。
  • MCSIO ドライバーがマスターイメージ (AMI) にインストールされていること。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およびスループットパラメーターを使用しないでください
    • gp3: このボリュームタイプにはiopsおよびスループットパラメーターを使用してください
    • 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. asnp citrix* を実行して、Citrix固有のPowerShellモジュールをロードします。
  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
  5. カタログにVMを追加します。

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

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

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

OSディスクとIDディスクを暗号化するために使用できるAWS KMSキー(カスタマー管理キーとAWS管理キー)を使用して、VMのカタログを作成できます。
  • 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 Managed Instances 用の準備済みイメージを作成する」を参照してください(/ja-jp/citrix-daas/install-configure/create-prepared-image-amazon-wsc.html)。
  5. Citrix Studioのカタログ作成メニューでNitroTPMとUEFIセキュアブートが有効な準備済みイメージを選択するか、PowerShellコマンドを使用してプロビジョニングスキームを作成する際に、マシンカタログを作成します。
作成されたカタログに追加されたVMは、NitroTPMと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)
    詳細については、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
  • テンプレートが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

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

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: これは、直後(または ForwardDirection が false の場合は直前)のアイテムを返しますが、ContinuationToken で指定されたアイテムは含まれません。
ページネーションの例:
  • 最も名前の小さいマシンテンプレートの単一レコードを返します。AdditionalData フィールドには TotalItemsCount と TotalFilteredItemsCount があります。
    Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template
  • 最も名前の小さいマシンテンプレートのレコードを10件返します。
    Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -MaxRecords 10 | select Name
  • 最も名前の大きいレコードで終わるレコードの配列を返します。
    Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -ForwardDirection $False -MaxRecords 10 | select Name
  • 指定された ContinuationToken に関連付けられたマシンテンプレートから始まるレコードの配列を返します。
    Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -ContinuationToken "ami-07xxxxxxxxxx" -MaxRecords 10
フィルタリング:
フィルタリングには、以下の追加のオプションパラメータがサポートされています。これらのパラメータは、ページネーションオプションと組み合わせることができます。
  • -ContainsName "my_name": 指定された文字列がAMI名の一部と一致する場合、そのAMIはGet結果に含まれます。例:
    Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -MaxRecords 100 -ContainName ‘apollo’ | select Name
  • -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
    注:
    2つのタグ値がサポートされています。タグなしタグ値は、タグのリストに指定されたタグがない項目と一致します。すべての値タグ値は、タグの値に関係なくタグを持つ項目と一致します。それ以外の場合、一致は、項目がタグを持ち、その値がフィルターで指定されたものと等しい場合にのみ発生します。
  • -Id "ami-0a2d913927e0352f3": AMIが指定されたIDと一致する場合、そのAMIはGet結果に含まれます。例:
    Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -Id ami-xxxxxxxxxxxxx
AdditionalData パラメータでのフィルタリング:
AdditionalDataフィルターパラメータは、テンプレートまたはVMを、その機能、サービス提供、またはAdditionalDataにある任意のプロパティに基づいてリストします。例:
(Get-HypInventoryItem -ResourceType "launchtemplateversion" -LiteralPath "XDHyp:\HostingUnits\aws" -MaxRecords 200).AdditionalData
互換性のないVMを示す-Warnパラメータを追加することもできます。VMには、Warningという名前のAdditionalDataフィールドが含まれます。例:
(Get-HypInventoryItem -ResourceType "launchtemplateversion" -LiteralPath "XDHyp:\HostingUnits\aws" -MaxRecords 200 -Template "ami-015xxxxxxxxx" -Warn $true).AdditionalData

次のステップ

詳細情報

  • イメージ管理
  • Amazon WorkSpaces Core の GitHub PowerShell の例については、citrix-mcs-sdk-samples-Amazon WorkSpaces Coreを参照してください。