AWSへの接続
「接続とリソースの作成と管理」では接続を作成するためのウィザードについて説明しています。 以下の情報は、AWSクラウド環境に固有の詳細について説明しています。
注：
AWSへの接続を作成する前に、まずAWSアカウントをリソースの場所として設定する必要があります。 「AWSクラウド環境」を参照してください。
接続の作成
Studioから接続を作成する場合：
- APIキーと秘密キーの値を指定する必要があります。 AWSでこれらの値を含んでいるキーファイルをエクスポートしてから、値をインポートすることができます。 また、リージョン、アベイラビリティゾーン、仮想プライベートクラウド名、サブネットアドレス、ドメイン名、セキュリティグループ名、および資格情報も必要になります。
- AWSコンソールから取得するルートAWSアカウント用の資格情報ファイルでは、標準的なAWSユーザーのものとは異なる形式が使用されています。 したがって、Citrix Virtual Apps and Desktops™管理では、このファイルを使用してAPIキーと秘密キーのフィールドに入力することはできません。 AWS Identity Access Management（IAM）形式の資格情報ファイルを使用してください。
注：
接続を作成した後、APIキーと秘密キーを更新しようとすると失敗することがあります。 この問題を解決するには、プロキシサーバーまたはファイアウォールの制限を確認し、次のアドレスに接続できることを確認してください：
https://*.amazonaws.com。
ホスト接続のデフォルト値
AWSクラウド環境のホスト接続を作成すると、次のデフォルト値が表示されます：
| オプション | 絶対 | パーセンテージ |
|---|---|---|
| 同時操作（すべての種類） | 125 | 100 |
| 1分あたりの最大新規操作 | 125 |
MCSは、デフォルトで最大100の同時プロビジョニング操作をサポートします。
クロスアカウントプロビジョニング
Delivery ControllerをプライマリAWSアカウント（共有サービスアカウントまたはサイトコンポーネントアカウント）にIAMロールを使用して配置しようとしているユースケースがあります。別のセカンダリAWSアカウント（ワークロードアカウント）にクロスアカウントアクセス（クロスアカウントIAMロール）とMCSでプロビジョニングされたマシンカタログがあり、個別のアカウントでの追加のDelivery Controllerの必要性を排除します。 このようなシナリオをサポートするために、この機能は、IAMロールを使用したVPCピアリングとクロスアカウントアクセスを活用し、複数のAWSアカウントを管理する企業がさまざまなAWSアカウント間でプロビジョニングできるようにします。
VPCピアリングを使用すると、Delivery Controllerと、異なるリージョンやアカウントにプロビジョニングされた仮想マシンが相互に通信できるようになります。
IAMロールを使用したクロスアカウントアクセスを使用すると、プライマリアカウント（Delivery Controllerアカウント）がIAMロールを引き受け、セカンダリアカウント（マシンカタログVM）のAWSリソースにアクセスできるようになります。
Delivery Controllerがセカンダリアカウントのリソースにアクセスできるようにするには、セカンダリアカウントからIAMロールを引き受けた後、ホスト接続を作成します。
前提条件
クロスアカウントプロビジョニング用のホスト接続を作成する前に、以下を設定します：
- VPCピアリングを設定し、両方のリージョンまたはアカウントでセキュリティグループを構成します。 「VPCピアリングを設定する」を参照してください
- IAMロールを使用してクロスアカウントアクセスを委任します。 （以下のトピックへのリンク）を参照してください。
VPCピアリングを設定する
VPC Aがプライマリアカウント（アカウントA）にあり、Delivery ControllerとActive Directoryがあると仮定します。 VPC Bは、仮想マシンをプロビジョニングするセカンダリアカウント（アカウントB）にあります。
アカウントAとアカウントBの間にVPCピアリング接続を設定するには、次の手順を実行します：
-
VPCピアリング接続を作成します。 次を参照してください：
- VPC Aに移動し、パブリックサブネットに関連付けられているルートテーブルに移動します。
- ［ルートの編集］>［ルートの追加］をクリックします。 VPC BのCIDRブロックを［Destination］列に追加し、作成したVPCピアリングを［Target］列に追加します。
- 手順2と3を繰り返しますが、VPC AとVPC Bのプライベートサブネットを使用します（VPC AのCIDRブロックを追加します）。 「VPCピアリング接続のルートテーブルを更新する」を参照してください。
- VPC Aに関連付けられているプライベートセキュリティグループに移動します。
- ［Actions］を選択し、次に［Edit inbound rules］を選択します。
-
［規則の追加］を選択します。 タイプには、［All Traffic］を選択し、［Source］列に以下を追加します：
- 異なるリージョンの場合は、VPC BのCIDRブロック。
- 異なるアカウントで同じリージョンの場合は、VPC BのアカウントIDとプライベートセキュリティグループIDをスラッシュで区切って追加します（例：123456789012/sg-1a2b3c4d）
- 手順5から7を繰り返しますが、VPC Bのプライベートセキュリティグループを使用します（ただし、VPC AのCIDRブロックを追加するか、同じリージョンで異なるアカウントのVPC AのアカウントIDとプライベートセキュリティグループIDを追加します）。 「セキュリティグループの更新とピアセキュリティグループの参照」を参照してください。
注：
VPCピアリング接続の作成には料金はかかりません。 ただし、アベイラビリティーゾーン内のVPCピアリングは無料ですが、複数のアベイラビリティーゾーンおよびリージョンにまたがるVPCピアリング接続を介したデータ転送が発生する場合は料金が発生します。 「VPCピアリング接続の料金」を参照してください。
IAMロールを使用してアカウント間のアクセスを委任する
アカウント間でVPCピアリングを設定した後、IAMロールを使用してクロスアカウントアクセスを委任します。
IAMロールを使用したクロスアカウントアクセスでは、プライマリアカウント（Delivery Controller™アカウント）がIAMロールを引き受け、セカンダリアカウント（マシンカタログ仮想マシン）のAWSリソースにアクセスできるようにします。
クロスアカウントリソースにアクセスするには、次の手順を実行します：
注意事項：
VPC Aがプライマリアカウント（アカウントA）にあり、Delivery ControllerとActive Directoryがあると仮定します。 VPC Bは、VMをプロビジョニングするセカンダリアカウント（アカウントB）にあります
- 上記の手順に従って、アカウント間でVPCピアリングを設定します。
- 最小限のCitrix IAM権限を持つアカウントBにIAMロールとポリシーを作成します。 「IAMチュートリアル：AWSアカウント間のIAMロールを使用したアクセスの委任」を参照してください。 このロールのarnが「arn:aws:iam::5678:role/citrix-role」であるとします。
- ロール「arn:aws:iam::5678:role/citrix-role」に信頼ポリシーを追加し、「IAMでのクロスアカウントのリソースへのアクセス」に従って、アカウントAのロール「arn:aws:iam::1234:role/primary-account-citrix-role」によるアクセスを許可します。
- アカウントAに、上記の名前「primary-account-citrix role」でIAMロールとポリシーを作成します。このロールとポリシーには、IAMロールを引き受け、アカウントB（arn:aws:iam::5678:role/citrix-role）からIAMロールを渡す機能があります。
- アカウントAのすべてのDelivery Controllerにロール「arn:aws:iam::1234:role/primary-account-citrix-role」を割り当てます。
Delivery Controllerは、アカウントB（「arn:aws:iam::5678:role/citrix-role」）からロールを引き受けることができるようになりました。
クロスアカウントプロビジョニング用のホスト接続を作成する
仮想マシンをプロビジョニングするセカンダリアカウント（アカウントB）にホスト接続を作成します。 これにより、アカウントAのDelivery Controllerは、アカウントBのロールを引き受けた後、アカウントBのリソースにアクセスできるようになります。
PowerShellコマンドを使用してホスト接続を作成し、次の2つのカスタムプロパティを追加します：
-
CrossAccountRoleArn：CrossAccountRoleArnプロパティを指定しない場合は、通常のホスト接続が作成されます。 この場合、MaximumAssumeRoleDurationInSecondsは指定されていても無視されます。 -
MaximumAssumeRoleDurationInSeconds：DurationInSecondsは900秒から3600秒の範囲でなければなりません。 デフォルト値は900秒です。 3600を超える値を指定した場合、DurationInSecondsは3600に設定されます。
例：
$connectionName = "cross-account-conn"
$cloudRegion = "us-east-1"
$apiKey = "role_based_auth"
$secretKey = "role_based_auth"
$zoneUid = "xxxxxx"
$secureKey = (ConvertTo-SecureString -String $secretKey -AsPlainText -Force)
$connectionPath = "XDHyp:\Connections\" + $connectionName
$customProperties = '<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Property xsi:type="StringProperty" Name="CrossAccountRoleArn" Value="arn:aws:iam::5678:role/citrix-role" /><Property xsi:type="StringProperty" Name="MaximumAssumeRoleDurationInSeconds" Value="3600" />
"</CustomProperties>'
$connection = New-Item -Path $connectionPath -ConnectionType "AWS" -HypervisorAddress "https://ec2.$($cloudRegion).amazonaws.com" -Persist -Scope @() -UserName $apiKey -SecurePassword $secureKey -ZoneUid $zoneUid -CustomProperties $customProperties
New-BrokerHypervisorConnection -HypHypervisorConnectionUid $connection.HypervisorConnectionUid
<!--NeedCopy-->
ホスト接続が作成されたら、StudioまたはPowerShellを使用してホスティングユニットを作成します。 ただし、VPCとネットワークを選択してください。
サービスエンドポイントURL
標準ゾーンのサービスエンドポイントURL
MCSを使用すると、APIキーとAPIシークレットで新しいAWS接続が追加されます。 この情報と認証済みアカウントで、MCSはAWS DescribeRegions EC2 API呼び出しを使用して、サポートされているゾーンのクエリをAWSに対して実行します。 このクエリは、一般的なEC2サービスエンドポイントURLのhttps://ec2.amazonaws.com/を使用して行われます。 MCSを使用して、サポートされているゾーンの一覧から、接続するゾーンを選択します。 そのゾーンで優先されるAWSサービスエンドポイントURLが自動的に選択されます。 ただし、サービスエンドポイントURLを作成した後は、URLを設定または変更することはできなくなります。
IAM権限の定義
このセクションの情報を使用して、AWS上のCitrix Virtual Apps and DesktopsのIAMアクセス許可を定義します。 AmazonのIAMサービスでは、複数のユーザーを持つアカウントが許可されており、さらにグループに編成することができます。 これらのユーザーは、アカウントに関連付けられた操作の実行を制御できるさまざまな権限を持つことができます。 IAMアクセス権限について詳しくは、「IAM JSONポリシーのリファレンス」を参照してください。
IAMアクセス権限ポリシーを新しいユーザーグループに適用するには、次を実行します：
- AWS管理コンソールにログインし、ドロップダウンリストから ［IAM service］ を選択します。
- ［Create a New Group of Users］ を選択します。
- 新しいユーザーグループの名前を入力し、［Continue］ を選択します。
- ［Permissions］ ページで ［Custom Policy］ を選択します。 ［Select］ を選択します。
- ［Permissions policy］ の名前を入力します。
- ［Policy Document］ セクションで、関連する権限の情報を入力します。
ポリシー情報の入力後、［Continue］ を選択してユーザーのグループを完了します。 グループ内のユーザーには、Citrix Virtual Apps and Desktopsに必要なアクションのみを実行するためのアクセス許可が付与されます。
重要:
前述の例で提供されているポリシーテキストを使用して、Citrix Virtual Apps and Desktopsが特定のリソースに限定せずにAWSアカウント内でアクションを実行するために使用するアクションを一覧表示します。 Citrixでは、この例はテスト目的で使用することをお勧めします。 実稼働環境では、リソースにさらに制限を加えることを選択できます。
IAMアクセス許可の設定
AWSマネジメントコンソールの ［IAM］ セクションで、アクセス許可を設定します：
- ［Summary］ パネルで ［Permissions］ タブを選択します。
- ［Add permissions］ を選択します。
［Add Permissions to］ 画面でアクセス許可を付与します：
以下は［JSON］ タブの例です：
ヒント:
JSONの例には、環境に対するすべての権限が含まれているとは限らないことに注意してください。 詳しくは、「AWSでCitrix Virtual Apps and Desktopsを実行するIDアクセス管理の権限を定義する方法」を参照してください。
必要なAWS権限
このセクションでは、AWS権限の完全なリストが示されています。
注：
iam:PassRole権限は、role_based_authでのみ必要です。
ホスト接続の作成
AWSからの情報を使用して、新しいホスト接続が追加されます。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeAvailabilityZones",,
"ec2:DescribeSubnets",
"ec2:DescribeVpcs"
"ec2:DescribeRegions",
],
"Effect": "Allow",
"Resource": "*"
}
]
}
<!--NeedCopy-->
VMの電源管理
VMの電源がオンまたはオフになっています。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeInstances",
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:RebootInstances"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
<!--NeedCopy-->
VMの作成、更新、または削除
マシンカタログは、AWSインスタンスとしてプロビジョニングされたVMで、作成、更新、または削除されます。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:AttachVolume",
"ec2:AssociateIamInstanceProfile",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateImage",
"ec2:CreateLaunchTemplate",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:DeleteVolume",
"ec2:DescribeAccountAttributes",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeIamInstanceProfileAssociations",
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:DescribeInstanceTypes",
"ec2:DescribeLaunchTemplates",
"ec2:DescribeLaunchTemplateVersions",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeRegions",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSnapshots",
"ec2:DescribeSubnets",
"ec2:DescribeTags",
"ec2:DescribeSpotInstanceRequests",
"ec2:DescribeInstanceCreditSpecifications",
"ec2:DescribeInstanceAttribute",
"ec2:GetLaunchTemplateData",
"ec2:DescribeVolumes",
"ec2:DescribeVpcs",
"ec2:DetachVolume",
"ec2:DisassociateIamInstanceProfile",
"ec2:RunInstances",
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:TerminateInstances"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"ec2:CreateSecurityGroup",
"ec2:DeleteSecurityGroup",
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"ebs:StartSnapshot",
"ebs:GetSnapshotBlock",
"ebs:PutSnapshotBlock",
"ebs:CompleteSnapshot",
"ebs:ListSnapshotBlocks",
"ebs:ListChangedBlocks",
"ec2:CreateSnapshot"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
<!--NeedCopy-->
注：
セキュリティグループに関連するEC2セクションは、カタログの作成中に準備VM用に分離セキュリティグループを作成する必要がある場合にのみ必要です。 これが行われると、これらの権限は必要ありません。
ディスクの直接アップロードとダウンロード
ディスクの直接アップロードは、マシンカタログプロビジョニングのボリュームワーカー要件をなくし、代わりにAWSが提供するパブリックAPIを使用します。 この機能により、追加のストレージアカウントに関連するコストと、ボリュームワーカーの操作を維持する複雑さが軽減されます。
注：
ボリュームワーカーのサポートは削除されました。 マシンカタログのプロビジョニングには、ディスクの直接アップロードおよびダウンロードの権限が必要です。
次の権限をポリシーに追加する必要があります：
ebs:StartSnapshotebs:GetSnapshotBlockebs:PutSnapshotBlockebs:CompleteSnapshotebs:ListSnapshotBlocksebs:ListChangedBlocksec2:CreateSnapshotec2:DeleteSnapshotec2:DescribeLaunchTemplates
重要:
- ボリュームワーカーAMIやボリュームワーカーVMなどのボリュームワーカー操作を行わなくても、既存のマシンカタログにVMを追加できます。
- 以前にボリュームワーカーを使用していた既存のカタログを削除すると、ボリュームワーカーに関連するアーティファクトを含むすべてのアーティファクトが削除されます。
作成されたボリュームのEBS暗号化
AMIが暗号化されている場合、またはEBSがすべての新しいボリュームを暗号化するように構成されている場合、EBSは新しく作成されたボリュームを自動で暗号化できます。 ただし、この機能を実装するには、次の権限がIAMポリシーに含まれている必要があります。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:Decrypt",
"kms:DescribeKey",
"kms:GenerateDataKeyWithoutPlainText",
"kms:ReEncryptTo",
"kms:ReEncryptFrom"
],
"Resource": "*"
}
]
}
<!--NeedCopy-->
注：
ResourceとConditionのブロックを含めることにより、ユーザーの裁量で権限を特定のキーに制限できます。 たとえば、Conditionを使用したKMS権限：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:Decrypt",
"kms:DescribeKey",
"kms:GenerateDataKeyWithoutPlainText",
"kms:ReEncryptTo",
"kms:ReEncryptFrom"
],
"Resource": [
"arn:aws:kms:us-east-2:123456789012:key/abcd1234-a123-456d-a12b-a123b4cd56ef"
],
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": true
}
}
}
]
}
<!--NeedCopy-->
以下のキーポリシーステートメントは、アカウントがIAMポリシーを使用してKMSキーの全操作（kms:*）の権限を委任できるようにするために必要なKMSキーのデフォルトのキーポリシー全体です。
{
"Sid": "Enable IAM policies",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:",
"Resource": ""
}
<!--NeedCopy-->
詳しくは、AWS Key Management Service公式ドキュメントを参照してください。
IAM役割ベースの認証
以下の権限が、役割ベースの認証をサポートするために追加されています。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/*"
}
]
}
<!--NeedCopy-->
最低限のIAM権限ポリシー
以下のJSONは、現在サポートされているすべての機能に使用できます。 このポリシーを使用して、ホスト接続の作成、VMの作成、更新、削除、および電源管理を行うことができます。 IAM権限の定義セクションで説明されているように、ポリシーをユーザーに適用できます。または、role_based_authセキュリティキーと秘密キーを使用して、役割ベースの認証を使用することもできます。
重要:
role_based_authを使用するには、まずサイトのすべてのDelivery Controllerで必要なIAM役割を構成します。 Web Studioを使用して、ホスティング接続を追加し、認証キーとシークレットのrole_based_authを指定します。 これらの設定のホスティング接続は、役割ベースの認証を使用します。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:AttachVolume",
"ec2:AssociateIamInstanceProfile",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateImage",
"ec2:CreateLaunchTemplate",
"ec2:CreateNetworkInterface",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:DeleteLaunchTemplate",
"ec2:DeleteNetworkInterface",
"ec2:DeleteSecurityGroup",
"ec2:DeleteSnapshot",
"ec2:DeleteTags",
"ec2:DeleteVolume",
"ec2:DeregisterImage",
"ec2:DescribeAccountAttributes",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeIamInstanceProfileAssociations",
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:DescribeInstanceTypes",
"ec2:DescribeLaunchTemplates",
"ec2:DescribeLaunchTemplateVersions",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeRegions",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSnapshots",
"ec2:DescribeSubnets",
"ec2:DescribeTags",
"ec2:DescribeSpotInstanceRequests",
"ec2:DescribeInstanceCreditSpecifications",
"ec2:DescribeInstanceAttribute",
"ec2:GetLaunchTemplateData",
"ec2:DescribeVolumes",
"ec2:DescribeVpcs",
"ec2:DetachVolume",
"ec2:DisassociateIamInstanceProfile",
"ec2:RebootInstances",
"ec2:RunInstances",
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:TerminateInstances"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"ec2:CreateSecurityGroup",
"ec2:DeleteSecurityGroup",
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"ebs:StartSnapshot",
"ebs:GetSnapshotBlock",
"ebs:PutSnapshotBlock",
"ebs:CompleteSnapshot",
"ebs:ListSnapshotBlocks",
"ebs:ListChangedBlocks",
"ec2:CreateSnapshot"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:Decrypt",
"kms:DescribeKey",
"kms:GenerateDataKeyWithoutPlainText",
"kms:GenerateDataKey",
"kms:ReEncryptTo",
"kms:ReEncryptFrom"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/*"
}
]
}
<!--NeedCopy-->
注：
- SecurityGroupsに関連するEC2セクションは、カタログの作成中に準備VM用に分離セキュリティグループを作成する必要がある場合にのみ必要です。 これが行われると、これらの権限は必要ありません。
- EBSボリューム暗号化を使用している場合は、KMSセクションのみが必要です。
- iam:PassRole権限セクションは、role_based_authでのみ必要です。
- 要件と環境に基づいて、フルアクセス権限の代わりに、特定のリソースレベルのアクセス権限を追加できます。 詳しくは、AWSドキュメントの「Demystifying EC2 Resource-Level Permissions」と「AWSリソースのアクセス管理」を参照してください。
ホスト接続の権限を検証する
MCSマシンカタログの作成と管理に関連するタスクを実行するために、ホスト接続の権限を検証できます。 この実装により、VMの作成、削除、更新、VMの電源管理、EBS暗号化などのさまざまなシナリオに必要な不足している権限を事前に見つけることができ、重要なタイミングでブロックされることを回避できます。
PowerShellコマンドTest-HypHypervisorConnectionを使用して、ホスト接続の権限を検証できます。 コマンドの結果は一覧としてキャプチャされ、一覧内の各項目は3つのセクションに分割されます。
- カテゴリ：ユーザーがMCSマシンカタログを作成および管理するために実行できるアクションまたはタスク。
- 修正アクション：ユーザーの不足している権限による不一致を解決するために管理者が実行する必要がある手順。
- 不足している権限：カテゴリに不足している権限の一覧。
権限を検証するには、次の手順を実行します：
- AWSへのホスト接続を作成します。
- Delivery ControllerホストからPowerShellウィンドウを開きます。
-
asnp citrix*を実行し、Citrix固有のPowerShellモジュールをロードします。 -
必要な権限があるかどうか確認するために権限を検索するには、次のコマンドを実行します。
Test-HypHypervisorConnection -LiteralPath "XDHyp:\Connections\AWSCon" <!--NeedCopy--> -
権限を検索するために必要な不足している権限を追加した後、次のコマンドを実行して、次のカテゴリの権限があるかどうかを確認します：
- 作成 更新 削除
- 電源管理
- EBS暗号化
Test-HypHypervisorConnection -LiteralPath "XDHyp:\Connections\AWSCon" [-SecurePassword -Password] "password" -UserName "" -CustomProperties "" <!--NeedCopy-->
権限の追加について詳しくは、「IAMアクセス許可の設定」を参照してください。
次の手順
- 初期展開プロセスを行っている場合は、「マシンカタログの作成」を参照してください
- AWS固有の情報については、「AWSカタログの作成」を参照してください。