• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。
# AWS Systems Manager のマネージドノードのセットアップ
このセクションのタスクを完了して、AWS Systems Manager ツール用にロール、ユーザーアカウント、許可、初期リソースをセットアップおよび設定します。このセクションで説明するタスクは、通常、AWS アカウント およびシステム管理者によって実行されます。これらのステップが完了したら、組織内のユーザーは Systems Manager を使用して*マネージドノード*を設定、管理、アクセスします。マネージドノードは、[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境内の Systems Manager 用に設定されたあらゆるマシンです。
**注記**
Amazon EC2 インスタンスと独自のコンピューティングリソースの両方を[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境で使用する場合は、[Systems Manager を利用した EC2 インスタンスの管理](systems-manager-setting-up-ec2.md) のステップに従います。そのトピックは、EC2 インスタンスおよび非 EC2 マシン用の Systems Manager セットアップを完了するための最適な順序でステップを説明します。
他の AWS のサービス を既に使用している場合は、これらの手順の一部は完了しています。ただし、他の手順は Systems Manager に固有です。そのため、このセクション全体を確認の上、Systems Manager のすべてのツールを使用できる状態であることを確認します。
**Topics**
+ [Systems Manager を利用した EC2 インスタンスの管理](systems-manager-setting-up-ec2.md)
+ [Systems Manager を利用したハイブリッド環境およびマルチクラウド環境でのノードの管理](systems-manager-hybrid-multicloud.md)
+ [Systems Manager を利用したエッジデバイスの管理](systems-manager-setting-up-edge-devices.md)
+ [Systems Manager 用の AWS Organizations 委任された管理者の作成](setting_up_delegated_admin.md)
+ [AWS Systems Manager の一般的なセットアップ](#setting_up_prerequisites)
# Systems Manager を利用した EC2 インスタンスの管理
このセクションのタスクを完了して、AWS Systems Manager 用にロール、許可、初期リソースを設定します。このセクションで説明するタスクは、通常、AWS アカウント およびシステム管理者によって実行されます。これらのステップが完了すると、組織内のユーザーは Systems Manager を使用して、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを設定、管理、アクセスできます。
**注記**
Systems Manager を使用してオンプレミスマシンを管理および設定する場合は、「[Systems Manager を利用したハイブリッド環境およびマルチクラウド環境でのノードの管理](systems-manager-hybrid-multicloud.md)」のセットアップ手順に従います。Amazon EC2 インスタンスと非 EC2 インスタンスの両方を[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境で使用する場合は、まずこのステップに従います。このセクションでは、Systems Manager オペレーションで使用するロール、ユーザー、アクセス許可、初期リソースを推奨される順序で設定するための手順を説明します。
他の AWS のサービス を既に使用している場合は、これらの手順の一部は完了しています。ただし、他の手順は Systems Manager に固有です。そのため、このセクション全体を確認の上、Systems Manager のすべてのツールを使用できる状態であることを確認します。
**Topics**
+ [Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)
+ [Systems Manager のために VPC エンドポイントを使用して EC2 インスタンスのセキュリティを強化する](setup-create-vpc.md)
# Systems Manager に必要なインスタンスのアクセス許可を設定する
デフォルトでは、AWS Systems Manager にはインスタンスでアクションを実行する権限がありません。インスタンスのアクセス許可は、AWS Identity and Access Management (IAM) ロールを使用してアカウントレベルで付与するか、またはインスタンスプロファイルを使用してインスタンスレベルで付与することができます。可能であれば、デフォルトのホスト管理設定を使用してアカウントレベルでアクセスを付与することをお勧めします。
**注記**
このステップをスキップして、統合コンソールをセットアップするときに Systems Manager が自動的に必要なアクセス許可をインスタンスに適用するようにすることもできます。詳細については、「[AWS Systems Manager を設定する](systems-manager-setting-up-console.md)」を参照してください。
## EC2 インスタンスのアクセス許可の推奨設定
デフォルトのホスト管理設定では、Systems Manager が Amazon EC2 インスタンスを自動的に管理することができます。この設定をオンにすると、SSM Agent バージョン 3.2.582.0 以降がインストールされている AWS リージョン および AWS アカウント で、インスタンスメタデータサービスバージョン 2 (IMDSv2) を使用しているすべてのインスタンスが、自動的にマネージドインスタンスになります。デフォルトのホスト管理設定は、インスタンスメタデータサービスバージョン 1 をサポートしていません。IMDSv2 への移行の詳細については、「Amazon EC2 ユーザーガイド」の「[インスタンスメタデータサービスバージョン 2 の使用への移行](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html)」を参照してください。インスタンスにインストールされている SSM Agent のバージョンを確認する方法については、「[SSM Agent バージョン番号の確認](ssm-agent-get-version.md)」を参照してください。SSM Agent の更新方法については、「[SSM Agent の自動更新](ssm-agent-automatic-updates.md#ssm-agent-automatic-updates-console)」を参照してください。マネージドインスタンスには、次のような利点があります。
+ Session Manager を使用して安全にインスタンスに接続する。
+ Patch Manager を使用して自動パッチスキャンを実行する。
+ Systems Manager インベントリを使用して、インスタンスに関する詳細情報を表示する。
+ Fleet Manager を使用してインスタンスを追跡、管理する。
+ SSM Agent を自動的に最新の状態に保つ。
Fleet Manager、Inventory、Patch Manager、Session Manager は AWS Systems Manager のツールです。
デフォルトのホスト管理設定では、インスタンスプロファイルを使用せずにインスタンスを管理でき、Systems Manager にリージョンとアカウント内のすべてのインスタンスを管理するアクセス許可が付与されていることを確認できます。付与されたアクセス許可がユースケースに十分でない場合は、デフォルトのホスト管理設定で作成されたデフォルトの IAM ロールにポリシーを追加することもできます。また、デフォルトの IAM ロールで提供されるすべての機能の一部に対してのみアクセス許可が必要な場合は、独自のカスタムロールとポリシーを作成できます。デフォルトのホスト管理設定で選択した IAM ロールに加えられた変更は、リージョンとアカウントのすべてのマネージド Amazon EC2 インスタンスに適用されます。デフォルトのホスト管理設定で使用するポリシーの詳細については、「[AWS マネージドポリシー: AmazonSSMManagedEC2InstanceDefaultPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonSSMManagedEC2InstanceDefaultPolicy)」を参照してください。デフォルトのホスト管理設定の詳細については、「[Default Host Management Configuration を使用した EC2 インスタンスの自動管理](fleet-manager-default-host-management-configuration.md)」を参照してください。
**重要**
デフォルトのホスト管理設定を使用して登録されたインスタンスは、登録情報を `/lib/amazon/ssm` または `C:\ProgramData\Amazon` ディレクトリへローカルに保存します。これらのディレクトリやファイルを削除すると、インスタンスはデフォルトのホスト管理設定を使用して Systems Manager に接続するために必要な認証情報を取得できなくなります。このような場合は、インスタンスプロファイルを使用してインスタンスに必要なアクセス許可を付与するか、インスタンスを再作成する必要があります。
**注記**
この手順を実行できるのは、管理者のみです。ユーザー個人がデフォルトのホスト管理設定を設定または変更できるようにする場合は、最小特権アクセス許可を実装してください。デフォルトのホスト管理設定は、Amazon EC2 インスタンスを自動的に管理したい AWS リージョン でオンにする必要があります。
**デフォルトのホスト管理設定を有効にするには**
デフォルトのホスト管理設定は、Fleet Manager コンソールからオンにできます。AWS マネジメントコンソール または任意のコマンドラインツールを使用してこの手順を正常に完了するには、API オペレーション ([GetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetServiceSetting.html)、[ResetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ResetServiceSetting.html)、[UpdateServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateServiceSetting.html)) のアクセス許可が必要です。さらに、`AWSSystemsManagerDefaultEC2InstanceManagementRole` IAM ロールの `iam:PassRole` アクセス許可を付与する権限が必要です。以下は、ポリシーの例です。各*リソースプレースホルダーの例*をユーザー自身の情報に置き換えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting",
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com"
]
}
}
}
]
}
```
------
開始する前に、Amazon EC2 インスタンスにインスタンスプロファイルが添付されている場合は、`ssm:UpdateInstanceInformation` オペレーションを許可する権限をすべて削除してください。SSM Agent は、デフォルトのホスト管理設定のアクセス許可を使用する前に、インスタンスプロファイルのアクセス許可を使用しようとします。インスタンスプロファイルで `ssm:UpdateInstanceInformation` オペレーションを許可すると、インスタンスはデフォルトのホスト管理設定のアクセス許可を使用しません。
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[Fleet Manager]** を選択します。
1. **[アカウント管理]** ドロップダウンの一覧で **[デフォルトのホスト管理設定]** をクリックします。
1. **[デフォルトのホスト管理設定を有効にする]** をオンにします。
1. インスタンスの Systems Manager ツールを有効にするために使用する IAM ロールを選択します。デフォルトのホスト管理設定で提供されるデフォルトのロールを使用することをお勧めします。このロールには、Systems Manager を使用して Amazon EC2 インスタンスを管理するために必要となる最小限のアクセス許可のセットが含まれています。カスタムロールを使用する場合は、ロールの信頼ポリシーで Systems Manager を信頼できるエンティティとして許可する必要があります。
1. **[設定]** をクリックして、セットアップを完了します。
デフォルトのホスト管理設定をオンにした後、選択したロールの認証情報をインスタンスが使用できるようになるまでに 30 分かかる場合があります。デフォルトのホスト管理設定は、Amazon EC2 インスタンスを自動的に管理したい各リージョンで有効にする必要があります。
## EC2 インスタンスのアクセス許可の代替設定
AWS Identity and Access Management (IAM) インスタンスプロファイルを使用すると、アクセス許可を個々のインスタンスレベルで付与することができます。インスタンスプロファイルは、起動時に IAM ロール情報を Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに渡すコンテナです。Systems Manager のインスタンスプロファイルを作成するには、必要なアクセス許可を定義する 1 つ以上の IAM ポリシーを、新しいロールか、作成済みのロールにアタッチします。
**注記**
AWS Systems Manager のツールである Quick Setup を使用すると、AWS アカウントのあらゆるインスタンスでインスタンスプロファイルをすばやく設定できます。Quick Setup では、IAM サービスロール (またはロールの*継承*) を作成します。これにより、Systems Manager はユーザーに代わってインスタンスで安全にコマンドを実行できます。Quick Setup を使用すると、このステップ (ステップ 3) とステップ 4 をスキップできます。詳細については、「[AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)」を参照してください。
IAM インスタンスプロファイルの作成に関する次の詳細情報に注意してください。
+ Systems Manager の[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境で非 EC2 を設定する場合、インスタンスプロファイルを作成する必要はありません。代わりに、IAM サービス ロールを使用するようにサーバーと VM を設定します。詳細については、「[ハイブリッドおよびマルチクラウド環境で Systems Manager に必要な IAM サービスロールを作成する](hybrid-multicloud-service-role.md)」を参照してください。
+ IAM インスタンスプロファイルを変更した場合、インスタンスの認証情報が更新されるまでに時間がかかることがあります。更新されるまで、SSM Agent はリクエストを処理しません。更新プロセスを高速化するには、SSM Agent を再起動するか、インスタンスを再起動します。
インスタンスプロファイルに新しいロールを作成するか、既存のロールに必要なアクセス許可を追加するかに応じて、以下のいずれかの手順を実行します。
**Systems Manager マネージドインスタンスのインスタンスプロファイルを作成するには (コンソール)**
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. ナビゲーションペインで **ロール** を選択してから、**ロールを作成する** を選択します。
1. **[Trusted entity type]** (信頼できるエンティティタイプ) で、**[AWS のサービス]** を選択します。
1. **[Use case]** (ユースケース) で **[EC2]** を選択し、**[Next]** (次へ) を選択します。
1. **[アクセス許可を追加]** ページで、以下を実行します。
+ **[Search]** (検索) フィールドを使用して、**[AmazonSSMManagedInstanceCore]** ポリシーを検索します。次の図に示すように、名前の横にあるチェックボックスをオンにします。
![\[AmazonSSMManagedInstanceCore の行のチェックボックスがオンになっています。\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/setup-instance-profile-2.png)
他のポリシーを検索しても、コンソールでは選択内容が保持されます。
+ 以前の手順 [(オプション) S3 バケットへのアクセスのカスタムポリシーを作成する](#instance-profile-custom-s3-policy) でカスタムの S3 バケットポリシーを作成した場合は、それを検索してその名前の横にあるチェックボックスをオンにします。
+ Directory Service によって管理されている Active Directory にインスタンスを結合する場合は、**[AmazonSSMDirectoryServiceAccess]** を検索し、その名前の横にあるチェックボックスをオンにします。
+ EventBridge または CloudWatch Logs を使用して、インスタンスを管理またはモニタリングする場合は、**[CloudWatchAgentServerPolicy]** を検索し、その名前の横にあるチェックボックスをオンにします。
1. [**次へ**] を選択します。
1. **[Role name]** (ロール名) に、新しいインスタンスプロファイルの名前 (**SSMInstanceProfile** など) を入力します。
**注記**
ロール名を書き留めます。このロール名は、Systems Manager を使用して管理するインスタンスを新しく作成する際に選択します。
1. (オプション) **[Description]** (説明) にある、このインスタンスプロファイルの説明を更新します。
1. (オプション) **[Tags]** (タグ) で、1 つ以上のタグキーと値のペアを追加し、このロールのアクセスを整理、追跡、制御して、**[Create role]** (ロールの作成) を選択します。**ロール**ページが再度表示されます。
**Systems Manager のインスタンスプロファイルのアクセス許可を既存のロールに追加するには (コンソール)**
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. ナビゲーションペインで、[**ロール**] を選択して、Systems Manager オペレーションのためにインスタンスプロファイルに関連付ける既存のロールを選択します。
1. **[Permissions]** (アクセス許可) タブで、**[Add permissions, Attach policies]** (アクセス許可の追加、ポリシーのアタッチ) をクリックします。
1. **[Attach Policy ]** (ポリシーのアタッチ) ページで、次の操作を実行します。
+ **[Search]** (検索) フィールドを使用して、**[AmazonSSMManagedInstanceCore]** ポリシーを検索します。名前の横にあるチェックボックスを選択します。
+ カスタムの S3 バケットポリシーを作成した場合は、その名前の横にあるチェックボックスをオンにします。インスタンスプロファイルのカスタム S3 バケットポリシーについては、「[(オプション) S3 バケットへのアクセスのカスタムポリシーを作成する](#instance-profile-custom-s3-policy)」を参照してください。
+ Directory Service によって管理されている Active Directory にインスタンスを結合する場合は、**[AmazonSSMDirectoryServiceAccess]** を検索し、その名前の横にあるチェックボックスをオンにします。
+ EventBridge または CloudWatch Logs を使用して、インスタンスを管理またはモニタリングする場合は、**[CloudWatchAgentServerPolicy]** を検索し、その名前の横にあるチェックボックスをオンにします。
1. **ポリシーのアタッチ** を選択します。
信頼できるエンティティを含むように、またはさらにアクセスを制限するようにロールを更新する方法については、*IAM ユーザーガイド*の「[ロールの修正](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_modify.html)」を参照してください。
## (オプション) S3 バケットへのアクセスのカスタムポリシーを作成する
Amazon S3 アクセス用のカスタムポリシーは、VPC エンドポイントを使用している場合、または Systems Manager オペレーションに独自の S3 バケットを使用している場合にのみ作成する必要があります。このポリシーは、デフォルトのホスト管理設定で作成されたデフォルトの IAM ロール、または前の手順で作成したインスタンスプロファイルにアタッチできます。
以下のポリシーでアクセスを付与する AWS マネージドの S3 バケットの詳細については、「[SSM Agent と AWS マネージド S3 バケットとの通信](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions)」を参照してください。
1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソール を開きます。
1. ナビゲーションペインで **ポリシー**を選択してから **ポリシーの作成**を選択します。
1. **[JSON]** タブを選択し、デフォルトのテキストを次に置き換えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::aws-ssm-us-east-2/*",
"arn:aws:s3:::aws-windows-downloads-us-east-2/*",
"arn:aws:s3:::amazon-ssm-us-east-2/*",
"arn:aws:s3:::amazon-ssm-packages-us-east-2/*",
"arn:aws:s3:::us-east-2-birdwatcher-prod/*",
"arn:aws:s3:::aws-ssm-distributor-file-us-east-2/*",
"arn:aws:s3:::aws-ssm-document-attachments-us-east-2/*",
"arn:aws:s3:::patch-baseline-snapshot-us-east-2/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:GetEncryptionConfiguration"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*",
"arn:aws:s3:::amzn-s3-demo-bucket"
]
}
]
}
```
------
**注記**
最初の `Statement` エレメントは、VPC エンドポイントを使用する場合にのみ必要です。
2 番目の `Statement` エレメントは、Systems Manager オペレーションで使用するために作成した S3 バケットを使用する場合にのみ必要です。
`PutObjectAcl` アクセスコントロールリストは、他のアカウントで S3 バケットへのクロスアカウントアクセスをサポートする場合にのみ必要です。
S3 バケットが暗号化を使用するように設定されている場合、`GetEncryptionConfiguration` エレメントが必要です。
S3 バケットが暗号化を使用するように設定されている場合、S3 バケットのルート (例: `arn:aws:s3:::amzn-s3-demo-bucket`) が **[リソース]** セクションに表示されている必要があります。ユーザー、グループ、またはロールに、ルートバケットへのアクセスを設定する必要があります。
1. オペレーションで VPC エンドポイントを使用する場合は、以下の操作を行います。
最初の `Statement` エレメントで、*region* の各プレースホルダーを、このポリシーが使用される AWS リージョン の識別子に置き換えます。例えば、米国東部 (オハイオ) リージョンの場合は、`us-east-2` を使用します。サポートされている*リージョン*値のリストについては、「*Amazon Web Services 全般のリファレンス*」の「[Systems Manager サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)」にある**リージョン**列を参照してください。
**重要**
このポリシーの特定のリージョンの代わりにワイルドカード文字 (\$1) を使用しないことをお勧めします。たとえば、`arn:aws:s3:::aws-ssm-us-east-2/*` を使用して、`arn:aws:s3:::aws-ssm-*/*` は使用しないでください。ワイルドカードを使用すると、アクセスを付与する S3 バケットへのアクセス権が付与される場合があります。複数のリージョンでインスタンスプロファイルを使用する場合は、各リージョンの最初の `Statement` エレメントを繰り返すことをお勧めします。
-または-
オペレーションで VPC エンドポイントを使用しない場合は、最初の `Statement` エレメントは削除することができます。
1. Systems Manager オペレーションで独自の S3 バケットを使用する場合は、以下の操作を行います。
2 つめの `Statement` エレメントで、*amzn-s3-demo-bucket* をアカウント内の S3 バケットの名前に置き換えます。このバケットは、Systems Manager のオペレーションに使用します。バケットのオブジェクトにアクセス許可を付与します。この際、`"arn:aws:s3:::my-bucket-name/*"` をリソースとして使用します。バケット、またはバケットのオブジェクトに許可を付与する方法については、*Amazon Simple Storage Service ユーザーガイド*のトピック「[Amazon S3 アクション](https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html)」および AWS ブログ記事「[IAM ポリシーとバケットポリシーと ACL\$1」を参照してください。Oh, My\$1 (Controlling Access to S3 Resources)](https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/)。
**注記**
複数のバケットを使用する場合は、それぞれの ARN を入力します。バケットのアクセス許可については、次の例を参照してください。
```
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1/*",
"arn:aws:s3:::amzn-s3-demo-bucket2/*"
]
```
-または-
Systems Manager オペレーションで独自の S3 バケットを使用していない場合は、2 つめの `Statement` エレメントは削除できます。
1. **[Next: Tags]** (次へ: タグ) を選択します。
1. (オプション) **[Add tag]** (タグを追加) を選択してタグを追加し、ポリシーの優先タグを入力します。
1. **[次へ: レビュー]** を選択します。
1. **[Name]** (名前) に、このポリシーを識別するための名前 (**SSMInstanceProfileS3Policy** など) を入力します。
1. [**Create policy**] (ポリシーの作成) を選択します。
## マネージドインスタンスのポリシーに関するその他の考慮事項
このセクションでは、デフォルトのホスト管理設定で作成されたデフォルトの IAM ロール、または AWS Systems Manager のインスタンスプロファイルに追加できるポリシーについて説明します。インスタンスと Systems Manager API 間における通信の許可を付与する場合、システムのニーズとセキュリティ要件を反映したカスタムポリシーを作成することをお勧めします。オペレーションプランによっては、他の 1 つまたは複数のポリシーに設定されているアクセス許可が必要になる場合があります。
**ポリシー: `AmazonSSMDirectoryServiceAccess`**
Windows Server の Amazon EC2 インスタンスを Microsoft AD ディレクトリに結合する場合にのみ必要です。
AWS 管理ポリシーでは、マネージドインスタンスによるドメインの結合リクエストに対して、SSM Agent による AWS Directory Service へのアクセスをお客様の代わりに許可します。詳細については、 *AWS Directory Service 管理ガイド*の 「[Windows EC2 インスタンスにシームレスに参加する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/launching_instance.html)」を参照してください。
**ポリシー: `CloudWatchAgentServerPolicy`**
メトリクスを読み取り、インスタンスにデータのログを記録して Amazon CloudWatch に書き込むために、インスタンスに CloudWatch をインストールして実行する場合にのみ必要です。これらは、AWS リソースの問題や変更をモニタリング、分析、および迅速に対応するのに役立ちます。
このポリシーは、Amazon EventBridge や Amazon CloudWatch Logs などの機能を使用する場合にのみ、デフォルトのホスト管理設定やインスタンスプロファイルで作成されたデフォルトの IAM ロールで必要になります。(例えば、特定の CloudWatch Logs ログストリームへの書き込みアクセスを制限する、より制限の厳しいポリシーを作成することもできます)。
EventBridge および CloudWatch Logs 機能の使用はオプションです。ただし、使用することにした場合は、Systems Manager の設定プロセスの最初にそれらを設定することをお勧めします。詳細については、*[Amazon EventBridge ユーザーガイド](https://docs.aws.amazon.com/eventbridge/latest/userguide/)*および *[Amazon CloudWatch Logs ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)*を参照してください。
追加の Systems Manager ツールのアクセス許可を含む IAM ポリシーを作成するには、次のリソースを参照してください。
+ [IAM ポリシーを使用して Parameter Store パラメータへのアクセスを制限する](sysman-paramstore-access.md)
+ [オートメーションの設定](automation-setup.md)
+ [ステップ 2: Session Manager のインスタンスのアクセス権限の確認または追加](session-manager-getting-started-instance-profile.md)
## インスタンスに Systems Manager インスタンスプロファイルを添付する (コンソール)
次の手順は、Amazon EC2 コンソールを使用して、IAM インスタンスプロファイルを Amazon EC2 インスタンスにアタッチする方法を示します。
1. AWS マネジメントコンソール にサインインし、Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインで、[**Instances**] の下にある [**Instances**] を選択します。
1. リストから EC2 インスタンスに移動して選択します。
1. [**アクション**] メニューで、[**セキュリティ**]、[**IAM ロールの変更**] の順に選択します。
1. [**IAM ロール**] で、[EC2 インスタンスのアクセス許可の代替設定](#instance-profile-add-permissions) の手順に従って作成したインスタンスプロファイルを選択します。
1. **[Update **IAM role**]** (IAM ロールの更新) を選択します。
インスタンスへの IAM ロールのアタッチの詳細については、選択したオペレーティングシステムのタイプに応じて、次のいずれかを選択してください。
+ 「*Amazon EC2 ユーザーガイド*」の「[IAM ロールをインスタンスにアタッチする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)」
+ 「*Amazon EC2 ユーザーガイド*」の「[IAM ロールをインスタンスにアタッチする](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)」
「[Systems Manager のために VPC エンドポイントを使用して EC2 インスタンスのセキュリティを強化する](setup-create-vpc.md)」に進みます。
# Systems Manager のために VPC エンドポイントを使用して EC2 インスタンスのセキュリティを強化する
Amazon Virtual Private Cloud (Amazon VPC) でインターフェイス VPC エンドポイントを使用するように AWS Systems Manager を設定することで、マネージドノード ([ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境の非 EC2 マシンを含む) のセキュリティ体制を向上させることができます。インターフェイス VPC エンドポイント (インターフェイスエンドポイント) を使用すると、AWS PrivateLink によって提供されるサービスに接続できます。AWS PrivateLink は、プライベート IP アドレスを使用して Amazon Elastic Compute Cloud (Amazon EC2) および Systems Manager API にプライベートアクセスできるようにするテクノロジーです。
AWS PrivateLink は、マネージドインスタンス、Systems Manager、および Amazon EC2 間のすべてのネットワークトラフィックを Amazon ネットワークに制限します。つまり、マネージドインスタンスはインターネットにアクセスできません。また AWS PrivateLink を使用する場合、インターネットゲートウェイ、NAT デバイス、仮想プライベートゲートウェイは必要はありません。
AWS PrivateLink の設定は要件ではありませんが、推奨されます。AWS PrivateLink および VPC エンドポイントの詳細については、「[AWS PrivateLink と VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)」を参照してください。
**注記**
VPC エンドポイントを使用する代わりに、マネージドインスタンスでアウトバウンドのインターネットアクセスを許可します。この場合、マネージドインスタンスは、以下のエンドポイントへの HTTPS (ポート 443) アウトバウンドトラフィックも許可する必要があります。
`ssm.region.amazonaws.com`
`ssmmessages.region.amazonaws.com`
`ec2messages.region.amazonaws.com`
SSM Agent は、クラウド内の Systems Manager サービスへのすべての接続を開始します。このため、Systems Manager のインスタンスへのインバウンドトラフィックを許可するようにファイアウォールを設定する必要はありません。
これらのエンドポイントへの呼び出しの詳細については、「[リファレンス: ec2messages、ssmmessages およびその他の API オペレーション](systems-manager-setting-up-messageAPIs.md)」を参照してください。
IPv6 **のみがサポートされる環境で Systems Manager を使用している場合は、次のエンドポイントへのアウトバウンドトラフィックも許可する必要があります。
`ssm.region.api.aws`
`ssmmessages.region.api.aws`
`ec2messages.region.api.aws`
デュアルスタックサービスエンドポイントの詳細については、「AWS 一般的なリファレンスガイド」の「[Dual stack endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#dual-stack-endpoints)」を参照してください。
また、「[参照: パッチ適用オペレーション用の Amazon S3 バケット](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-operations-s3-buckets.html)」で説明されているように、パッチオペレーションバケットがノードから到達可能であることを確認する必要があります。
**Amazon VPC について**
Amazon Virtual Private Cloud (Amazon VPC) を使用すると、AWS クラウド 内の論理的に分離された独自の領域に仮想プライベートクラウド (VPC) と呼ばれる仮想ネットワークを定義できます。AWS のリソース (インスタンスなど) を VPC 内部で起動できます。VPC は、お客様自身のデータセンターで運用されている従来のネットワークによく似ていますが、 のスケーラブルなインフラストラクチャを使用できるというメリットがありますAWS お客様の VPC はお客様が設定できます。IP アドレスレンジの選択、サブネットの作成、ルートテーブル、ネットワークゲートウェイ、セキュリティの設定ができます。VPC のインスタンスをインターネットに接続できます。VPC を自社のデータセンターに接続し、AWS クラウド をデータセンターの拡張部分として使用できます。各サブネットでのリソースの保護には、セキュリティグループ、ネットワークアクセスコントロールリストなど、複数のセキュリティレイヤーを使用できます。詳細については、[Amazon VPC ユーザーガイド](https://docs.aws.amazon.com/vpc/latest/userguide/)を参照してください。
**Topics**
+ [VPC エンドポイントの制約と制限](#vpc-requirements-and-limitations)
+ [Systems Manager 用の VPC エンドポイントを作成する](#create-vpc-endpoints)
+ [インターフェイス VPC エンドポイントポリシーの作成](#create-vpc-interface-endpoint-policies)
## VPC エンドポイントの制約と制限
Systems Manager の VPC エンドポイントを設定する前に、以下の制約と制限に注意してください。
**VPC ピアリング接続**
VPC インターフェイスのエンドポイントには、*リージョン内*および*リージョン間* VPC ピア接続の両方を介してアクセスできます。VPC インターフェイスエンドポイントの VPC ピア接続リクエストの詳細については、*Amazon Virtual Private Cloud ユーザーガイド*の「[VPC ピア接続 (クォータ)](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-peering)」を参照してください。
VPC ゲートウェイエンドポイントの接続を、VPC の外に延長することはできません。VPC 内の VPC ピア接続の反対側のリソースは、ゲートウェイエンドポイントを使用してゲートウェイエンドポイントサービス内のリソースと通信することはできません。VPC ゲートウェイエンドポイントの VPC ピア接続リクエストの詳細については、*Amazon Virtual Private Cloud ユーザーガイド*の「[VPC エンドポイント (クォータ)](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-endpoints)」を参照してください。
**着信接続**
VPC エンドポイントにアタッチされたセキュリティグループでは、マネージドインスタンスのプライベートサブネットから、ポート 443 で着信接続を許可する必要があります。着信接続が許可されていない場合、マネージドインスタンスは SSM および EC2 エンドポイントに接続できません。
**DNS 解決**
カスタム DNS サーバーを使用する場合は、`amazonaws.com` ドメインへのすべてのクエリの条件付きフォワーダーを VPC の Amazon DNS サーバーに追加する必要があります。
**S3 バケット**
VPC エンドポイントポリシーは、少なくとも [SSM Agent と AWS マネージド S3 バケットとの通信](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) にリストされている Amazon S3 バケットへのアクセスを許可する必要があります。
**注記**
オンプレミスのファイアウォールを使用していて Patch Manager を使用する場合は、そのファイアウォールでパッチベースラインのエンドポイントへの適切なアクセスを許可する必要もあります。
**Amazon CloudWatch Logs**
インスタンスがインターネットにアクセスすることを許可しない場合、CloudWatch Logs にログを送信する機能を使用するには、CloudWatch Logs の VPC エンドポイントを作成します。CloudWatch Logs のエンドポイントの作成の詳細については、*Amazon CloudWatch Logs ユーザーガイド*の「[CloudWatch Logs 用の VPC エンドポイントの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html#create-VPC-endpoint-for-CloudWatchLogs)」を参照してください。
**ハイブリッドおよびマルチクラウド環境の DNS**
[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境で AWS PrivateLink エンドポイントと連携するように DNS を設定する方法については、「Amazon VPC ユーザーガイド」の「[インターフェイスエンドポイントのプライベート DNS](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-private-dns)」を参照してください。独自の DNS を使用する場合には、Route 53 リゾルバーを使用できます。詳細については、「*Amazon Route 53 デベロッパーガイド*」の「[VPC とネットワーク間の DNS クエリの解決](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html)」を参照してください。
## Systems Manager 用の VPC エンドポイントを作成する
以下の情報を使用して、AWS Systems Manager の VPC インターフェイスエンドポイントを作成します このトピックは、*Amazon VPC ユーザーガイド*の手順にリンクしています。
**注記**
*region* は、米国東部 (オハイオ) リージョンの `us-east-2` のように、AWS Systems Manager でサポートされている AWS リージョン の識別子を表します。サポートされている *region* 値の一覧については、「Amazon Web Services 全般のリファレンス」の「[Systems Manager サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)」にある **Region** 列を参照してください。
「[インターフェイスエンドポイントの作成](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint)」の手順に従って、以下のインターフェイスエンドポイントを作成します。
+ **`com.amazonaws.region.ssm`** — Systems Manager サービスのエンドポイント。
+ **`com.amazonaws.region.ec2messages`** — Systems Manager は、このエンドポイントを使用して SSM Agent から Systems Manager サービスへの呼び出しを行います。SSM Agent のバージョン 3.3.40.0 以降、Systems Manager は、使用可能な場合には `ec2messages:*` エンドポイント (Amazon Message Delivery Service) の代わりに `ssmmessages:*` エンドポイント (Amazon Message Gateway Service) を使用するようになりました。
+ **`com.amazonaws.region.ec2`** — Systems Manager を使用して VSS 対応のスナップショットを作成する場合は、EC2 サービスへのエンドポイントがあることを確認します。EC2 エンドポイントが定義されていない場合、アタッチした Amazon EBS ボリュームを列挙する呼び出しは失敗し、Systems Manager コマンドが失敗します。
+ **`com.amazonaws.region.s3`** – Systems Manager は、このエンドポイントを使用して SSM Agent を更新します。また、Systems Manager は、バケットに保存されているスクリプトや他のファイルを取得したり、出力ログをバケットにアップロードしたりすることをユーザーがオプションで選択した場合にも、このエンドポイントを使用します。インスタンスに関連付けられたセキュリティグループでアウトバウンドトラフィックが制限されている場合は、Amazon S3 のプレフィックス一覧へのトラフィックを可能にするルールを追加する必要があります。詳細については、*AWS PrivateLink ガイド*の「[セキュリティグループの変更](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-gateway.html#vpc-endpoints-security)」を参照してください。
+ **`com.amazonaws.region.ssmmessages`** – このエンドポイントは、Run Command のために、および Session Manager を使用してセキュアなデータチャネル経由でインスタンスに接続している場合に、SSM Agent が Systems Manager サービスと通信する上で必要です。詳細については、「[AWS Systems Manager Session Manager](session-manager.md)」および「[リファレンス: ec2messages、ssmmessages およびその他の API オペレーション](systems-manager-setting-up-messageAPIs.md)」を参照してください。
+ (オプション) **`com.amazonaws.region.kms`** – Session Manager または Parameter Store パラメータのために AWS Key Management Service (AWS KMS) 暗号化を使用する場合は、このエンドポイントを作成します。
+ (オプション) **`com.amazonaws.region.logs`** – Session Manager、Run Command、または SSM Agent ログのために Amazon CloudWatch Logs (CloudWatch Logs) を使用する場合は、このエンドポイントを作成します。
SSM Agent がアクセスできる必要がある AWS マネージド S3 バケットについては、「[SSM Agent と AWS マネージド S3 バケットとの通信](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions)」を参照してください。Systems Manager のオペレーションで仮想プライベートクラウド (VPC) エンドポイントを使用している場合は、Systems Manager の EC2 インスタンスプロファイル、または[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境の非 EC2 ノードのサービスロールで、明示的な許可を付与する必要があります。
## インターフェイス VPC エンドポイントポリシーの作成
AWS Systems Manager には VPC インターフェイスエンドポイントのポリシーを作成することができます。このポリシーでは、以下の内容を指定できます。
+ アクションを実行できるプリンシパル
+ 実行可能なアクション
+ 自身に対してアクションを実行できたリソース
詳細については、*Amazon VPC ユーザーガイド*の「[VPC エンドポイントによるサービスへのアクセスのコントロール](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)」を参照してください。
# Systems Manager を利用したハイブリッド環境およびマルチクラウド環境でのノードの管理
AWS Systems Manager を使用して、Amazon Elastic Compute Cloud (EC2) インスタンスと多数の非 EC2 マシンタイプの両方を管理できます。このセクションでは、[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境で Systems Manager を使用して非 EC2 マシンを管理するために、アカウントおよびシステム管理者が実行する設定タスクについて説明します。これらのステップが完了したら、AWS アカウント 管理者から許可が付与されたユーザーは、Systems Manager を使用して組織の非 EC2 サーバーを設定と管理できます。
Systems Manager で使用するように設定されたマシンはすべて、マネージドノードと呼ばれます。
**注記**
非 EC2 マシンと同じハイブリッドアクティベーション手順を使用して、エッジデバイスをマネージドノードとして登録できます。これらのエッジデバイスのタイプには、AWS IoT デバイスと AWS IoT デバイス以外のデバイスの両方が含まれます。これらのエッジデバイスのタイプを設定するには、このセクションで説明されている手順を実行します。
Systems Manager は AWS IoT Greengrass コアソフトウェアを使用するエッジデバイスもサポートします。AWS IoT Greengrass コアデバイスの設定プロセスおよび要件は、AWS IoT および AWS エッジデバイス以外のエッジデバイスのものとは異なります。Systems Manager で使用する AWS IoT Greengrass デバイスの登録については、「[Systems Manager を利用したエッジデバイスの管理](systems-manager-setting-up-edge-devices.md)」を参照してください。
非 EC2 macOS マシンは、Systems Manager のハイブリッドおよびマルチクラウド環境ではサポートされていません。
Systems Manager を使用して Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを管理する場合、または Amazon EC2 インスタンスと非 EC2 マシンの両方をハイブリッドおよびマルチクラウド環境で使用する場合は、最初に [Systems Manager を利用した EC2 インスタンスの管理](systems-manager-setting-up-ec2.md) の手順に従います。
Systems Manager 向けにハイブリッドおよびマルチクラウド環境を設定すると以下のことを行うことができます。
+ 同じツールやスクリプトを使用して 1 か所からハイブリッドおよびマルチクラウドのワークロードをリモートで管理できる一貫したセキュアな方法が作成されます。
+ AWS Identity and Access Management (IAM) を使ってマシンに実行できるアクションのアクセス制御を一元化します。
+ AWS CloudTrail に記録されている API のアクティビティを確認することで、マシンで実行されるオペレーションを一元的に監査できます。
CloudTrail を使用して Systems Manager のアクションをモニタリングする方法については、「[AWS CloudTrail による AWS Systems Manager API コールのログ記録](monitoring-cloudtrail-logs.md)」を参照してください。
+ モニタリングを一元化するには、サービス実行の成功に関する通知を送信するように Amazon EventBridge と Amazon Simple Notification Service (Amazon SNS) を設定します。
EventBridge を使用して Systems Manager イベントをモニタリングする方法については、「[Amazon EventBridge を使用して Systems Manager イベントをモニタリングする](monitoring-eventbridge-events.md)」を参照してください。
**マネージドノードについて**
このセクションで説明している Systems Manager 用の非 EC2 マシンの設定を完了したら、ハイブリッドアクティベーションマシンは AWS マネジメントコンソール にリストされてマネージドノードとして表示されます。コンソールでは、ハイブリッドアクティベーションマネージドノードの ID は、「mi-」のプレフィックスにより Amazon EC2 インスタンスと区別されます。Amazon EC2 インスタンス ID は、プレフィックス「i-」を使用します。
マネージドノードとは、Systems Manager 用に設定されたあらゆるマシンのことです。以前は、マネージドノードはすべてマネージドインスタンスと呼ばれていました。現在、インスタンスとは EC2 インスタンスのみを指します。[deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html) コマンドは、この用語変更の前に命名されました。
詳細については、「[マネージドノードの使用](fleet-manager-managed-nodes.md)」を参照してください。
**重要**
サポート終了 (EOL) に達した OS バージョンを使用しないことを強くお勧めします。AWS を始めとする OS ベンダーは、通常、EOL に達したバージョンのセキュリティパッチやその他の更新を提供しません。EOL システムを使用し続けると、セキュリティ修正を始めとするアップグレードを適用できないリスクとその他の運用上の問題が大幅に増加します。AWS は、EOL に達した OS バージョンで Systems Manager の機能テストを行いません。
**インスタンスの階層について**
Systems Manager はハイブリッドおよびマルチクラウド環境内の非 EC2 マネージドノード用にスタンダードインスタンス層とアドバンストインスタンス層を提供します。スタンダードインスタンス層により、AWS アカウント ごと、AWS リージョン ごとに最大 1,000 のハイブリッドアクティベーションマシンを登録できます。1 つのアカウントとリージョンに 1,000 を超える非 EC2 マシンを登録する必要がある場合は、アドバンストインスタンス層を使用します。アドバンストインスタンスは、AWS Systems Manager Session Manager を使用して非 EC2 マシンに接続することも可能にします。Session Manager はマネージドノードにインタラクティブシェルアクセスを実現します。
詳細については、「[インスタンス層の設定](fleet-manager-configure-instance-tiers.md)」を参照してください。
**Topics**
+ [ハイブリッドおよびマルチクラウド環境で Systems Manager に必要な IAM サービスロールを作成する](hybrid-multicloud-service-role.md)
+ [ハイブリッドアクティベーションを作成して、Systems Manager にノードを登録する](hybrid-activation-managed-nodes.md)
+ [ハイブリッド Linux ノードで SSM Agent をインストールする](hybrid-multicloud-ssm-agent-install-linux.md)
+ [ハイブリッド Windows Server ノードに SSM Agent をインストールする](hybrid-multicloud-ssm-agent-install-windows.md)
# ハイブリッドおよびマルチクラウド環境で Systems Manager に必要な IAM サービスロールを作成する
[ハイブリッドおよびマルチクラウド環境の非 EC2 (Amazon Elastic Compute Cloud](operating-systems-and-machine-types.md#supported-machine-types)) マシンでは、AWS Systems Manager サービスと通信するために AWS Identity and Access Management (IAM) サービスロールが必要です。ロールは、Systems Manager サービスに AWS Security Token Service (AWS STS) [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) の信頼を付与します。AWS アカウント ごとにハイブリッドおよびマルチクラウド環境用にサービスロールを一度のみ作成する必要があります。ただし、ハイブリッドおよびマルチクラウド環境のマシンに異なる許可が必要な場合、異なるハイブリッドアクティベーションに対して複数のサービスロールを作成することもできます。
以下の手順は、Systems Manager コンソールまたはお好みのコマンドラインツールを使用して、必要なサービスロールを作成する方法を説明します。
## AWS マネジメントコンソール を使用して Systems Manager ハイブリッドアクティベーション用の IAM サービスロールを作成する
ハイブリッドアクティベーションのサービスロールを作成するために、以下の手順にしたがいます。この手順では、Systems Manager の主要機能で `AmazonSSMManagedInstanceCore` ポリシーを使用します。ユースケースによっては、オンプレミスマシンが他の Systems Manager ツールまたは AWS のサービスにアクセスできるようにするため、サービスロールにポリシーを追加する必要がある場合があります。例えば、必要な AWS マネージド型 Amazon Simple Storage Service (Amazon S3) バケットにアクセスがなければ、Patch Manager パッチ運用オペレーションが失敗します。
**サービスロールを作成するには (コンソール)**
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. ナビゲーションペインで **ロール** を選択してから、**ロールを作成する** を選択します。
1. **[Select trusted entity]** (信頼できるエンティティを選択) で、次のように選択します。
1. **信頼できるエンティティタイプ** で、**AWS のサービス** を選択します。
1. **[その他の AWS のサービス のユースケース]** で、**[Systems Manager]** を選択します。
1. **[Systems Manager]** を選択します。
次の画像は、Systems Manager オプションの場所を示しています。
![\[Systems Manager は、ユースケースのオプションの 1 つです。\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/iam_use_cases_for_MWs.png)
1. [**次へ**] を選択します。
1. **[アクセス許可を追加]** ページで、以下を実行します。
+ **[Search]** (検索) フィールドを使用して、**[AmazonSSMManagedInstanceCore]** ポリシーを検索します。次の図に示すように、名前の横にあるチェックボックスをオンにします。
![\[AmazonSSMManagedInstanceCore の行のチェックボックスがオンになっています。\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/setup-instance-profile-2.png)
**注記**
他のポリシーを検索しても、コンソールでは選択内容が保持されます。
+ 手順 [(オプション) S3 バケットへのアクセスのカスタムポリシーを作成する](setup-instance-permissions.md#instance-profile-custom-s3-policy) でカスタムの S3 バケットポリシーを作成した場合は、それを検索してその名前の横にあるチェックボックスをオンにします。
+ Directory Service によって管理されている Active Directory に、EC2 以外のマシンを結合する場合は、**AmazonSSMDirectoryServiceAccess** を検索し、その名前の横にあるチェックボックスをオンにします。
+ EventBridge または CloudWatch Logs を使用して、マネージドノードを管理またはモニタリングする場合は、**[CloudWatchAgentServerPolicy]** を検索し、その名前の横にあるチェックボックスをオンにします。
1. [**次へ**] を選択します。
1. **[ロール名]** で、**SSMServerRole** などの新しい IAM サーバーロールの名前を入力します。
**注記**
ロール名を書き留めます。このロール名は、Systems Manager を使用して管理するマシンを新しく登録する際に選択します。
1. (オプション) **[Description]** (説明) で、この IAM サーバーロールの説明を更新します。
1. (オプション) **[Tags]** (タグ)で、タグとキーの値のペアを 1 つまたは複数追加して、このロールのアクセスを整理、追跡、または制御します。
1. **[Create role]** (ロールの作成) を選択します。**ロール**ページが再度表示されます。
## AWS CLI を使用して Systems Manager ハイブリッドアクティベーション用の IAM サービスロールを作成する
ハイブリッドアクティベーションのサービスロールを作成するために、以下の手順にしたがいます。この手順では、Systems Manager の主要機能で `AmazonSSMManagedInstanceCore` ポリシーを使用します。ユースケースによっては、[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境の EC2 以外のマシンのサービスロールにポリシーをさらに追加して、他のツールや AWS のサービスにアクセスできるようにする必要がある場合があります。
**S3 バケットのポリシーの要件**
次のいずれかのケースに当てはまる場合は、この手順を実行する前に Amazon Simple Storage Service (Amazon S3) バケット用のカスタム IAM アクセス許可ポリシーを作成する必要があります。
+ **ケース 1** — VPC エンドポイントを使用して、サポートされている AWS のサービス、および AWS PrivateLink を搭載した VPC エンドポイントサービスに VPC をプライベート接続している。
+ **ケース 2** — Run Command コマンドや Session Manager セッションの出力を S3 バケットに保存するなど、作成する Amazon S3 バケットを Systems Manager オペレーションの一環として使用する。先に進む前に、「[インスタンスプロファイル用のカスタム S3 バケットポリシーを作成する](setup-instance-permissions.md#instance-profile-custom-s3-policy)」の手順に従います。そのトピックの S3 バケットポリシーに関する情報は、サービスロールにも適用されます。
------
#### [ AWS CLI ]
**ハイブリッドおよびマルチクラウド環境に IAM サービスロールを作成するには (AWS CLI)**
1. まだ AWS Command Line Interface (AWS CLI) をインストールして設定していない場合は、インストールして設定します。
詳細については、「[AWS CLI の最新バージョンをインストールまたは更新します。](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。
1. ローカルマシンで以下の信頼ポリシーを使用して、`SSMService-Trust.json` のような名前でテキストファイルを作成します。ファイル保存時に、必ずファイル拡張子 (`.json`) を付けます。ハイブリッドアクティベーションを作成した際の ARN 内の AWS アカウント と AWS リージョン を必ず指定してください。アカウント ID とリージョンの *placeholder values* をユーザーの情報に置き換えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"",
"Effect":"Allow",
"Principal":{
"Service":"ssm.amazonaws.com"
},
"Action":"sts:AssumeRole",
"Condition":{
"StringEquals":{
"aws:SourceAccount":"123456789012"
},
"ArnEquals":{
"aws:SourceArn":"arn:aws:ssm:us-east-1:111122223333:*"
}
}
}
]
}
```
------
1. AWS CLI を開き、JSON ファイルを作成したディレクトリで [create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) コマンドを実行してサービスロールを作成します。この例では、`SSMServiceRole` という名前のロールが作成されます。別の名前を選択することもできます。
------
#### [ Linux & macOS ]
```
aws iam create-role \
--role-name SSMServiceRole \
--assume-role-policy-document file://SSMService-Trust.json
```
------
#### [ Windows ]
```
aws iam create-role ^
--role-name SSMServiceRole ^
--assume-role-policy-document file://SSMService-Trust.json
```
------
1. 以下のように [attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) を実行して、先ほど作成したサービスロールでセッショントークンを作成できるようにします。セッショントークンは、Systems Manager を使用してコマンドを実行するためのアクセス許可をマネージドノードに付与します。
**注記**
ハイブリッドおよびマルチクラウド環境のマネージドノードのサービスプロファイルに追加するポリシーは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのインスタンスプロファイルの作成に使用されるものと同じです。以下のコマンドで使用する AWS ポリシーの詳細については、「[Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)」を参照してください。
(必須) 次のコマンドを使用して、マネージドノードで AWS Systems Manager サービスの主要機能を使用できるようにします。
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
------
#### [ Windows ]
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
------
サービスロールのカスタム S3 バケットポリシーを作成した場合は、次のコマンドを実行して、ポリシーで指定したバケットに AWS Systems Manager Agent (SSM Agent) がアクセスできるようにします。*account-id* と *amzn-s3-demo-bucket* は、お使いの AWS アカウント ID とバケット名に置き換えてください。
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::account-id:policy/amzn-s3-demo-bucket
```
------
#### [ Server ]
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::account-id:policy/amzn-s3-demo-bucket
```
------
(オプション) 次のコマンドを実行して、マネージドノードによるドメインへの結合リクエストに対して、SSM Agent がユーザーの代わりに Directory Service にアクセスできるようにします。ノードを Microsoft AD ディレクトリに統合する場合のみ、サービスロールにこのポリシーが必要です。
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
```
------
#### [ Server ]
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
```
------
(オプション) 次のコマンドを実行して、CloudWatch エージェントがマネージドノードで実行できるようにします。このコマンドを使用すると、ノードの情報を読み込んで CloudWatch に書き込みを行うことができます。サービスプロファイルには、Amazon EventBridge や Amazon CloudWatch Logs などのサービスを利用する場合にのみ、このポリシーが必要です。
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
------
#### [ Tools for PowerShell ]
**ハイブリッドおよびマルチクラウド環境に IAM サービスロールを作成するには (AWS Tools for Windows PowerShell)**
1. AWS Tools for PowerShell (Tools for Windows PowerShell) をインストールして設定します (まだインストールしていない場合)。
詳細については、「[AWS Tools for PowerShell のインストール](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html)」を参照してください。
1. ローカルマシンで以下の信頼ポリシーを使用して、`SSMService-Trust.json` のような名前でテキストファイルを作成します。ファイル保存時に、必ずファイル拡張子 (`.json`) を付けます。ハイブリッドアクティベーションを作成した際の ARN 内の AWS アカウント と AWS リージョン を必ず指定してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:ssm:us-east-1:123456789012:*"
}
}
}
]
}
```
------
1. PowerShell を管理モードで開き、JSON ファイルを作成したディレクトリで以下のように [New-IAMRole](https://docs.aws.amazon.com//powershell/latest/reference/items/Register-IAMRolePolicy.html) を実行してサービスロールを作成します。この例では、`SSMServiceRole` という名前のロールが作成されます。別の名前を選択することもできます。
```
New-IAMRole `
-RoleName SSMServiceRole `
-AssumeRolePolicyDocument (Get-Content -raw SSMService-Trust.json)
```
1. 以下のように、[Register-IAMRolePolicy](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-IAMRolePolicy.html) を使用して、作成したサービスロールでセッショントークンを作成できます。セッショントークンは、Systems Manager を使用してコマンドを実行するためのアクセス許可をマネージドノードに付与します。
**注記**
ハイブリッドおよびマルチクラウド環境のマネージドノードのサービスプロファイルに追加するポリシーは、EC2 インスタンスのインスタンスプロファイルの作成に使用されるものと同じです。以下のコマンドで使用する AWS ポリシーの詳細については、「[Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)」を参照してください。
(必須) 次のコマンドを使用して、マネージドノードで AWS Systems Manager サービスの主要機能を使用できるようにします。
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
サービスロールのカスタム S3 バケットポリシーを作成した場合は、次のコマンドを実行し、ポリシーで指定したバケットに SSM Agent がアクセスできるようにします。*account-id* および *my-bucket-policy-name* を AWS アカウント ID およびバケット名に置き換えます。
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::account-id:policy/my-bucket-policy-name
```
(オプション) 次のコマンドを実行して、マネージドノードによるドメインへの結合リクエストに対して、SSM Agent がユーザーの代わりに Directory Service にアクセスできるようにします。ノードを Microsoft AD ディレクトリに統合する場合のみ、サーバーロールにこのポリシーが必要です。
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
```
(オプション) 次のコマンドを実行して、CloudWatch エージェントがマネージドノードで実行できるようにします。このコマンドを使用すると、ノードの情報を読み込んで CloudWatch に書き込みを行うことができます。サービスプロファイルには、Amazon EventBridge や Amazon CloudWatch Logs などのサービスを利用する場合にのみ、このポリシーが必要です。
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
------
「[ハイブリッドアクティベーションを作成して、Systems Manager にノードを登録する](hybrid-activation-managed-nodes.md)」に進みます。
# ハイブリッドアクティベーションを作成して、Systems Manager にノードを登録する
Amazon Elastic Compute Cloud (EC2) インスタンス以外のマシンを[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境のマネージドノードとしてセットアップするには、ハイブリッドアクティベーションを作成して適用します。アクティベーションが正常に完了すると、コンソールページの上部にアクティベーションコードとアクティベーション ID が直ちに表示されます。ハイブリッドおよびマルチクラウド環境で非 EC2 マシンに AWS Systems Manager SSM Agent をインストールする際に、このコードと ID の組み合わせを指定します。このコードと ID を使用することで、マネージドノードから Systems Manager サービスに安全にアクセスできます。
**重要**
アクティベーションの作成方法に応じて、Systems Manager はすぐにアクティベーションコードと ID をコンソールまたはコマンドウィンドウに返します。この情報をコピーして、安全な場所に保管します。コンソールから離れたり、コマンドウィンドウを閉じたりすると、この情報は失われる可能性があります。紛失した場合は、新しいアクティベーションを作成する必要があります。
**アクティベーションの有効期限について**
*アクティベーションの有効期限*は、オンプレミスのマシンを Systems Manager で登録できる時間帯です。アクティベーションの有効期限が切れても、Systems Manager に前もって登録したサーバーまたは VM に影響はありません。アクティベーションが期限切れになると、その特定のアクティベーションを使用して、複数のサーバーまたは VM を Systems Manager に登録することはできません。新しいものを作成する必要があるだけです。
前もって登録したすべてのオンプレミスサーバーおよび VM は、明示的に登録を解除するまで、Systems Manager のマネージドノードとして登録されたままになります。EC2 以外のマネージドノードの登録は以下の方法で解除できます。
+ Systems Manager コンソールの Fleet Manager で**マネージドノード**タブを使用する
+ AWS CLI コマンド [https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html) を実行する
+ API アクション [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html) を使用する
詳細については、以下の各トピックを参照してください。
+ [マネージドノードの登録解除と再登録 (Linux)](hybrid-multicloud-ssm-agent-install-linux.md#systems-manager-install-managed-linux-deregister-reregister)
+ [マネージドノードの登録解除と再登録 (Windows Server)](hybrid-multicloud-ssm-agent-install-windows.md#systems-manager-install-managed-win-deregister-reregister)
**マネージドノードについて**
マネージドノードは AWS Systems Manager 用に設定されたすべてのマシンを指します。AWS Systems Manager は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、エッジデバイス、オンプレミスサーバー、または VM (他のクラウド環境にある VM を含む) をサポートしています。以前は、マネージドノードはすべてマネージドインスタンスと呼ばれていました。現在、インスタンスとは EC2 インスタンスのみを指します。[deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html) コマンドは、この用語変更の前に命名されました。
**アクティベーションタグについて**
AWS Command Line Interface (AWS CLI) または AWS Tools for Windows PowerShell を使用してアクティベーションを作成する場合は、タグを指定できます。タグは、リソースに割り当てるオプションのメタデータです。タグを使用すると、目的、所有者、環境などのさまざまな方法でリソースを分類できます。ここでは、米国東部 (オハイオ) のローカル Linux マシンで実行する、オプションのタグを含む AWS CLI サンプルコマンドを示します。
```
aws ssm create-activation \
--default-instance-name MyWebServers \
--description "Activation for Finance department webservers" \
--iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances \
--registration-limit 10 \
--region us-east-2 \
--tags "Key=Department,Value=Finance"
```
アクティベーションの作成時にタグを指定すると、それらのタグはアクティブ化する際に自動的にマネージドノードに割り当てられます。
既存のアクティベーションにタグを追加したり、既存のアクティベーションからタグを削除したりすることはできません。アクティベーションを使用してオンプレミスサーバーと VM に自動的にタグを割り当てない場合は、後でタグを追加できます。具体的には、オンプレミスサーバーと VM が初めて Systems Manager に接続した後にタグを付けることができます。接続すると、マネージドノード ID が割り当てられ、先頭に「mi-」が付いた ID で Systems Manager コンソールに表示されます。
**注記**
Systems Manager コンソールを使用してアクティベーションを作成した場合、アクティベーションにタグを割り当てることはできません。AWS CLI または Tools for Windows PowerShell のいずれかを使用してアクティベーションを作成する必要があります。
Systems Manager を使用してオンプレミスサーバーや仮想マシン (VM) を管理する必要がなくなった場合は、登録解除できます。詳細については、「[ハイブリッドおよびマルチクラウド環境でのマネージドノードの登録解除](fleet-manager-deregister-hybrid-nodes.md)」を参照してください。
**Topics**
+ [AWS マネジメントコンソール を使用して、Systems Manager でマネージドノードを登録するためのアクティベーションを作成します。](#create-managed-node-activation-console)
+ [コマンドラインを使用して、Systems Manager でマネージドノードを登録するためのアクティベーションを作成する](#create-managed-node-activation-command-line)
## AWS マネジメントコンソール を使用して、Systems Manager でマネージドノードを登録するためのアクティベーションを作成します。
**マネージドノードのアクティベーションを作成するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで [**ハイブリッドアクティベーション**] を選択します。
1. [**Create activation**] を選択します。
-または-
現在の AWS リージョン で **[Hybrid Activations]** (ハイブリッドアクティベーション) に初めてアクセスしている場合は、**[Create an Activation]** (アクティベーションの作成) を選択します。
1. (オプション) **[Activation description]** (アクティベーションの説明) フィールドに、このアクティベーションの説明を入力します。多数のサーバーや VM を有効化する場合は、説明を入力することをお勧めします。
1. **[Instance limit]** (インスタンス制限) で、このアクティベーションの一環として AWS に登録するノードの合計数を指定します。デフォルト値は 1 インスタンスです。
1. **[IAM role name]** (IAM ロール) で、サーバーや VM とクラウド内の AWS Systems Manager との通信を可能にするサービスロールオプションを選択します。
+ **オプション 1**: AWS が提供するロールと管理ポリシーを使用するには、**[Use the default role created by the system]** (システムによって作成されたデフォルトのロールを使用する) を選択します。
+ **オプション 2**: 前に作成したオプションのカスタムロールを使用するには、**[Select an existing custom IAM role that has the required permissions]** (必要な許可を持つ既存のカスタム IAM ロールを選択する) を選択します。このロールには、`"Service": "ssm.amazonaws.com"` を指定する信頼関係ポリシーが必要です。IAM ロールが信頼関係ポリシーでこの原則を指定しない場合、次のエラーが発生します。
```
An error occurred (ValidationException) when calling the CreateActivation
operation: Not existing role: arn:aws:iam:::role/SSMRole
```
このロールの作成に関する詳細については、「[ハイブリッドおよびマルチクラウド環境で Systems Manager に必要な IAM サービスロールを作成する](hybrid-multicloud-service-role.md)」を参照してください。
1. **[Activation expiry date]** (アクティベーションの有効期限日) で、アクティベーションの有効期限日を指定します。有効期限は将来の日付で、30 日以内でなければなりません。デフォルト値は 24 時間です。
**注記**
有効期限日後にマネージドノードを追加で登録するには、新しいアクティベーションを作成する必要があります。有効期限日は、登録済みで実行中のインスタンスには影響しません。
1. (オプション) **[Default instance name]** (デフォルトのインスタンス名) フィールドで、このアクティベーションに関連付けられているすべてのマネージドノードに表示する識別名の値を指定します。
1. [**Create activation**] を選択します。Systems Manager は、すぐにアクティベーションコードと ID をコンソールに返します。
## コマンドラインを使用して、Systems Manager でマネージドノードを登録するためのアクティベーションを作成する
次の手順では、AWS Command Line Interface (AWS CLI) (Linux または Windows Server の場合) または AWS Tools for PowerShell を使用して、マネージドノードのアクティベーションを作成する方法について説明します。
**アクティベーションを作成するには**
1. まだ AWS CLI または AWS Tools for PowerShell をインストールして設定していない場合は、インストールして設定します。
詳細については、「[AWS CLI の最新バージョンをインストールまたは更新します。](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」および「[AWS Tools for PowerShell のインストール](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html)」を参照してください。
1. アクティベーションを作成するには、次のコマンドを実行します。
**注記**
次のコマンドで、*[Region]* (リージョン) をユーザー自身の情報に置き換えます。サポートされている *region* 値の一覧については、「Amazon Web Services 全般のリファレンス」の「[Systems Manager サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)」にある **Region** 列を参照してください。
*iam-role* パラメータに指定するロールには、`"Service": "ssm.amazonaws.com"` を指定する信頼関係ポリシーが必要です。AWS Identity and Access Management (IAM) ロールが信頼関係ポリシーでこの原則を指定しない場合、次のエラーが発生します。
```
An error occurred (ValidationException) when calling the CreateActivation
operation: Not existing role: arn:aws:iam:::role/SSMRole
```
このロールの作成に関する詳細については、「[ハイブリッドおよびマルチクラウド環境で Systems Manager に必要な IAM サービスロールを作成する](hybrid-multicloud-service-role.md)」を参照してください。
`--expiration-date` の場合、アクティベーションコードの有効期限が切れるときの日付を、`"2021-07-07T00:00:00"` などのタイムスタンプ形式で指定します。日付は 30 日を上限に事前に指定できます。有効期限を指定しない場合、アクティベーションコードは 24 時間で有効期限が切れます。
------
#### [ Linux & macOS ]
```
aws ssm create-activation \
--default-instance-name name \
--iam-role iam-service-role-name \
--registration-limit number-of-managed-instances \
--region region \
--expiration-date "timestamp" \\
--tags "Key=key-name-1,Value=key-value-1" "Key=key-name-2,Value=key-value-2"
```
------
#### [ Server ]
```
aws ssm create-activation ^
--default-instance-name name ^
--iam-role iam-service-role-name ^
--registration-limit number-of-managed-instances ^
--region region ^
--expiration-date "timestamp" ^
--tags "Key=key-name-1,Value=key-value-1" "Key=key-name-2,Value=key-value-2"
```
------
#### [ PowerShell ]
```
New-SSMActivation -DefaultInstanceName name `
-IamRole iam-service-role-name `
-RegistrationLimit number-of-managed-instances `
–Region region `
-ExpirationDate "timestamp" `
-Tag @{"Key"="key-name-1";"Value"="key-value-1"},@{"Key"="key-name-2";"Value"="key-value-2"}
```
------
以下はその例です。
------
#### [ Linux & macOS ]
```
aws ssm create-activation \
--default-instance-name MyWebServers \
--iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances \
--registration-limit 10 \
--region us-east-2 \
--expiration-date "2021-07-07T00:00:00" \
--tags "Key=Environment,Value=Production" "Key=Department,Value=Finance"
```
------
#### [ Server ]
```
aws ssm create-activation ^
--default-instance-name MyWebServers ^
--iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances ^
--registration-limit 10 ^
--region us-east-2 ^
--expiration-date "2021-07-07T00:00:00" ^
--tags "Key=Environment,Value=Production" "Key=Department,Value=Finance"
```
------
#### [ PowerShell ]
```
New-SSMActivation -DefaultInstanceName MyWebServers `
-IamRole service-role/AmazonEC2RunCommandRoleForManagedInstances `
-RegistrationLimit 10 `
–Region us-east-2 `
-ExpirationDate "2021-07-07T00:00:00" `
-Tag @{"Key"="Environment";"Value"="Production"},@{"Key"="Department";"Value"="Finance"}
```
------
アクティベーションが正常に完了するとすぐに、システムからアクティベーションコードとアクティベーション ID が返ります。
# ハイブリッド Linux ノードで SSM Agent をインストールする
このトピックでは、[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境で非 EC2 (Amazon Elastic Compute Cloud) Linux マシンに AWS Systems Manager SSM Agent をインストールする方法について説明します。Linux の EC2 インスタンスへの SSM Agent のインストールの詳細については、「[Linux 用 EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](manually-install-ssm-agent-linux.md)」を参照してください。
開始する前に、「[ハイブリッドアクティベーションを作成して、Systems Manager にノードを登録する](hybrid-activation-managed-nodes.md)」の説明に従って、ハイブリッドアクティベーションプロセス中に生成されたアクティベーションコードとアクティベーション ID を見つけます。このコードと ID を次の手順で指定します。
**ハイブリッドおよびマルチクラウド環境の非 EC2 マシンに SSM Agent をインストールするには**
1. ハイブリッドおよびマルチクラウド環境のサーバーまたは VM にログオンします。
1. HTTP または HTTPS プロキシを使用する場合は、現在のシェルセッションで `http_proxy` または `https_proxy` の環境変数を設定する必要があります。プロキシを使用していない場合は、この手順を省略できます。
HTTP プロキシサーバーの場合は、コマンドラインで次のコマンドを入力します。
```
export http_proxy=http://hostname:port
export https_proxy=http://hostname:port
```
HTTPS プロキシサーバの場合は、コマンドラインで次のコマンドを入力します。
```
export http_proxy=http://hostname:port
export https_proxy=https://hostname:port
```
1. SSH に以下のコマンドブロックをコピーアンドペーストします。プレースホルダー値を、ハイブリッドアクティベーションプロセス中に生成されたアクティベーションコードとアクティベーション ID、および SSM Agent のダウンロード元の AWS リージョン の識別子に置き換えて、`Enter` を押します。
**重要**
次の重要な詳細に留意してください。
EC2 以外のインストールに `ssm-setup-cli` を使用すると、Systems Manager のインストールと設定のセキュリティを最大化できます。
root ユーザーの場合は `sudo` が必要ありません。
ハイブリッドアクティベーションを作成したのと同じ AWS リージョン から `ssm-setup-cli` をダウンロードします。
`ssm-setup-cli` で、エージェントのダウンロード元を判断する `manifest-url` オプションがサポートされました。ご自身の組織で必要とされている場合を除き、このオプションには値を指定しないでください。
インスタンスを登録するときは、`ssm-setup-cli` 用として指定されたダウンロードリンクのみを使用します。`ssm-setup-cli` を今後の使用のために個別に保管しないでください。
[ここ](https://github.com/aws/amazon-ssm-agent/blob/mainline/Tools/src/setupcli_data_integrity_linux.sh)に記載されているスクリプトを使用して、`ssm-setup-cli` の署名を検証できます。
*region* は、米国東部 (オハイオ) リージョンの `us-east-2` のように、AWS Systems Manager でサポートされている AWS リージョン の識別子を表します。サポートされている*リージョン*値のリストについては、「*Amazon Web Services 全般のリファレンス*」の「[Systems Manager サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)」にある**リージョン**列を参照してください。
さらに、`ssm-setup-cli` には次のオプションが含まれます。
+ `version` – 有効な値は `latest` および `stable` です。
+ `downgrade` - SSM Agent を以前のバージョンにダウングレードすることを許可します。エージェントの以前のバージョンをインストールするため `true` を指定します。
+ `skip-signature-validation` - エージェントをダウンロードおよびインストールする間の署名検証をスキップします。
## Amazon Linux 2、RHEL 7.x、および Oracle Linux
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/linux_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
## RHEL 8.x
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/linux_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
## Debian Server
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
## Ubuntu Server
+ **.deb パッケージを使用**
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
+ **スナップパッケージを使用**
ダウンロードの URL を指定する必要はありません。`snap` コマンドでは、エージェントが [Snap アプリストア](https://snapcraft.io/amazon-ssm-agent) [https://snapcraft.io](https://snapcraft.io) から自動的にダウンロードされます。
Ubuntu Server 20.04、18.04 および 16.04 LTS の場合、SSM Agent インストーラファイル (エージェントバイナリや設定ファイルなど) は `/snap/amazon-ssm-agent/current/` ディレクトリに保存されます。このディレクトリで設定ファイルに変更を加えた場合、これらのファイルを `/snap` ディレクトリから `/etc/amazon/ssm/` ディレクトリにコピーする必要があります。ログファイルおよびライブラリファイルは変更されていません (`/var/lib/amazon/ssm`、`/var/log/amazon/ssm`)。
```
sudo snap install amazon-ssm-agent --classic
sudo systemctl stop snap.amazon-ssm-agent.amazon-ssm-agent.service
sudo /snap/amazon-ssm-agent/current/amazon-ssm-agent -register -code "activation-code" -id "activation-id" -region "region"
sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service
```
**重要**
Snap ストアの*候補*チャンネルには、安定したチャンネルではなく、SSM Agent の最新バージョンが含まれています。候補チャンネルの SSM Agent バージョン情報を追跡する場合は、Ubuntu Server 18.04 および 16.04 LTS 64 ビットマネージドノードで次のコマンドを実行します。
```
sudo snap switch --channel=candidate amazon-ssm-agent
```
このコマンドでは、ハイブリッドおよびマルチクラウド環境のハイブリッドアクティベーションマシンに SSM Agent をダウンロードしてインストールします。コマンドは、SSM Agent を停止してから、マシンを Systems Manager サービスに登録します。これで、マシンはマネージドノードになりました。Systems Manager 用に設定されている Amazon EC2 インスタンスも、マネージドノードです。ただし、Systems Manager コンソールでは、ハイブリッドアクティベーションノードは、プレフィックス「mi-」が付いている Amazon EC2 インスタンスとは区別されます。
「[ハイブリッド Windows Server ノードに SSM Agent をインストールする](hybrid-multicloud-ssm-agent-install-windows.md)」に進んでください。
## プライベートキーの自動ローテーションを設定する
セキュリティポスチャを強化するには、ハイブリッドおよびマルチクラウド環境のプライベートキーを自動的にローテーションするように AWS Systems Manager エージェント (SSM Agent) を設定できます。SSM Agent バージョン 3.0.1031.0 以降を使用すると、この機能にアクセスできます。次の手順に従ってこの機能を有効にします。
**ハイブリッドおよびマルチクラウド環境のプライベートキーをローテーションするように SSM Agent を設定するには**
1. Linux マシンでは `/etc/amazon/ssm/`、Windows マシンでは `C:\Program Files\Amazon\SSM` に移動します。
1. `amazon-ssm-agent.json.template` の内容を `amazon-ssm-agent.json` という名前の新ファイルにコピーします。`amazon-ssm-agent.json.template` と同じディレクトリに `amazon-ssm-agent.json` を保存します。
1. `Profile`、`KeyAutoRotateDays` を探す プライベートキーの自動ローテーション間隔の日数を入力します。
1. SSM Agent を再起動します。
設定を変更するたびに、SSM Agent を再起動します。
同じ手順を使用して、SSM Agent の他の機能をカスタマイズできます。使用可能な設定プロパティとそのデフォルト値の最新リストについては、「[Config Property Definitions](https://github.com/aws/amazon-ssm-agent#config-property-definitions) (設定プロパティの定義)」を参照してください。
## マネージドノードの登録解除と再登録 (Linux)
ハイブリッドアクティベーションマネージドノードの登録を解除するには、AWS CLI または Tools for Windows PowerShell のいずれかから [DeregisterManagedInstance](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html) API オペレーションを呼び出します。以下に CLI コマンドの例を示します。
`aws ssm deregister-managed-instance --instance-id "mi-1234567890"`
エージェントの残りの登録情報を削除するには、`amazon-ssm-agent.json` ファイル内の `IdentityConsumptionOrder` キーを削除します。インストールのタイプに応じて、次のいずれかのコマンドを実行します。
Snap パッケージを使用して SSM Agent がインストールされた Ubuntu Server ノードの場合:
```
sudo /snap/amazon-ssm-agent/current/amazon-ssm-agent -register -clear
```
それ以外の Linux インストールの場合:
```
amazon-ssm-agent -register -clear
```
**注記**
指定のアクティベーションコードと ID のインスタンス制限に達していない限り、同じアクティベーションコードと ID を使用してオンプレミスサーバー、エッジデバイス、または VM を再登録できます。AWS CLI を使用して [describe-activations](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-activations.html) API を呼び出すことで、アクティベーションコードと ID のインスタンス制限を確認できます。このコマンドを実行した後、`RegistrationCount` の値が `RegistrationLimit` を超えていないことを確認します。もし超えている場合は、別のアクティベーションコードと ID を使用する必要があります。
**非 EC2 Linux マシンでマネージノードを再登録するには**
1. マシンへ接続します。
1. 以下のコマンドを実行してください。必ずプレースホルダー値の代わりに、マネージドノードのアクティベーションの作成時に生成されたアクティベーションコードとアクティベーション ID、および SSM Agent のダウンロード元のリージョンの識別子を入力します。
```
echo "yes" | sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region
```
## 非 EC2 Linux マシンでの SSM Agent のインストールに関するトラブルシューティング
次の情報は、[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境でハイブリッドアクティベーション Linux マシンに SSM Agent をインストールする際の問題のトラブルシューティングに役立ちます。
### DeliveryTimedOut エラーの発生
**問題**: ある AWS アカウント のマシンを別の AWS アカウント のマネージドノードとして設定している際に、ターゲットマシンに SSM Agent をインストールするコマンドを実行した後に `DeliveryTimedOut` が表示されます。
**解決方法**: `DeliveryTimedOut` がこのシナリオで予想される応答コードです。ターゲットノードに SSM Agent をインストールするコマンドによって、ソースノードのノード ID が変更されます。ノード ID が変更されたため、ソースノードは、実行中にコマンドが失敗したこと、完了したこと、またはタイムアウトしたことをターゲットノードに返信できません。
### ノードの関連付けをロードできない
**問題**: インストールコマンドを実行した後、SSM Agent エラーログに次のエラーが表示されます。
`Unable to load instance associations, unable to retrieve associations unable to retrieve associations error occurred in RequestManagedInstanceRoleToken: MachineFingerprintDoesNotMatch: Fingerprint doesn't match`
このエラーは、再起動後にマシン ID が持続しない場合に表示されます。
**解決方法**: この問題を解決するには、次のコマンドを実行します。このコマンドは、再起動後もマシン ID を強制的に保持します。
```
umount /etc/machine-id
systemd-machine-id-setup
```
# ハイブリッド Windows Server ノードに SSM Agent をインストールする
このトピックでは、[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境の Windows Server マシンに AWS Systems Manager SSM Agent をインストールする方法について説明します。Windows Server の EC2 インスタンス SSM Agent へのインストールの詳細については、「[Windows Server 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](manually-install-ssm-agent-windows.md)」を参照してください。
開始する前に、「[ハイブリッドアクティベーションを作成して、Systems Manager にノードを登録する](hybrid-activation-managed-nodes.md)」の説明に従って、ハイブリッドアクティベーションプロセス中に生成されたアクティベーションコードとアクティベーション ID を見つけます。このコードと ID を次の手順で指定します。
**ハイブリッドおよびマルチクラウド環境の非 EC2 Windows Server マシンに SSM Agent をインストールするには**
1. ハイブリッドおよびマルチクラウド環境のサーバーまたは VM にログオンします。
1. HTTP または HTTPS プロキシを使用する場合は、現在のシェルセッションで `http_proxy` または `https_proxy` の環境変数を設定する必要があります。プロキシを使用していない場合は、この手順を省略できます。
HTTP プロキシサーバーの場合は、次の変数を設定します。
```
http_proxy=http://hostname:port
https_proxy=http://hostname:port
```
HTTPS プロキシサーバーの場合は、次の変数を設定します。
```
http_proxy=http://hostname:port
https_proxy=https://hostname:port
```
PowerShell の場合は、WinINet プロキシ設定を構成します。
```
[System.Net.WebRequest]::DefaultWebProxy
$proxyServer = "http://hostname:port"
$proxyBypass = "169.254.169.254"
$WebProxy = New-Object System.Net.WebProxy($proxyServer,$true,$proxyBypass)
[System.Net.WebRequest]::DefaultWebProxy = $WebProxy
```
**注記**
PowerShell オペレーションには WinINet プロキシ設定が必要です。詳細については、「[SSM Agent プロキシ設定とSystems Manager サービス](configure-proxy-ssm-agent-windows.md#ssm-agent-proxy-services)」を参照してください。
1. 昇格された (管理者) モードで Windows PowerShell を開きます。
1. Windows PowerShell に以下のコマンドブロックを貼り付けます。各*リソースプレースホルダーの例*をユーザー自身の情報に置き換えます。例えば、ハイブリッドのアクティベーションの作成時に生成されたアクティベーションコードとアクティベーション ID、および SSM Agent のダウンロード元の AWS リージョン の識別子です。
**重要**
次の重要な詳細に留意してください。
EC2 以外のインストールに `ssm-setup-cli` を使用すると、Systems Manager のインストールと設定のセキュリティを最大化できます。
`ssm-setup-cli` で、エージェントのダウンロード元を判断する `manifest-url` オプションがサポートされました。ご自身の組織で必要とされている場合を除き、このオプションには値を指定しないでください。
[ここ](https://github.com/aws/amazon-ssm-agent/blob/mainline/Tools/src/setupcli_data_integrity_windows.ps1)に記載されているスクリプトを使用して、`ssm-setup-cli` の署名を検証できます。
インスタンスを登録するときは、`ssm-setup-cli` 用として指定されたダウンロードリンクのみを使用します。`ssm-setup-cli` を今後の使用のために個別に保管しないでください。
*region* は、米国東部 (オハイオ) リージョンの `us-east-2` のように、AWS Systems Manager でサポートされている AWS リージョン の識別子を表します。サポートされている*リージョン*値のリストについては、「*Amazon Web Services 全般のリファレンス*」の「[Systems Manager サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)」にある**リージョン**列を参照してください。
さらに、`ssm-setup-cli` には次のオプションが含まれます。
+ `version` – 有効な値は `latest` および `stable` です。
+ `downgrade` - エージェントを以前のバージョンに戻します。
+ `skip-signature-validation` - エージェントをダウンロードおよびインストールする間の署名検証をスキップします。
------
#### [ 64-bit ]
```
[System.Net.ServicePointManager]::SecurityProtocol = 'TLS12'
$code = "activation-code"
$id = "activation-id"
$region = "us-east-1"
$dir = $env:TEMP + "\ssm"
New-Item -ItemType directory -Path $dir -Force
cd $dir
(New-Object System.Net.WebClient).DownloadFile("https://amazon-ssm-$region.s3.$region.amazonaws.com/latest/windows_amd64/ssm-setup-cli.exe", $dir + "\ssm-setup-cli.exe")
./ssm-setup-cli.exe -register -activation-code="$code" -activation-id="$id" -region="$region"
Get-Content ($env:ProgramData + "\Amazon\SSM\InstanceData\registration")
Get-Service -Name "AmazonSSMAgent"
```
------
1. `Enter` キーを押します。
**注記**
コマンドが失敗した場合は、AWS Tools for PowerShell の最新バージョンを実行していることを確認します。
コマンドが以下の操作を行います。
+ SSM Agent をマシンにダウンロードしてインストールします。
+ マシンを Systems Manager サービスに登録します。
+ リクエストに対して次のようなレスポンスを返します。
```
Directory: C:\Users\ADMINI~1\AppData\Local\Temp\2
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 07/07/2018 8:07 PM ssm
{"ManagedInstanceID":"mi-008d36be46EXAMPLE","Region":"us-east-2"}
Status : Running
Name : AmazonSSMAgent
DisplayName : Amazon SSM Agent
```
これで、マシンはマネージドノードになりました。これらのマネージドノードは、「mi-」というプレフィックスで識別されます。Fleet Manager の [**マネージドノード**] ページにマネージドノードを表示するには、AWS CLI コマンド [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-information.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-information.html)、または API コマンド [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceInformation.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceInformation.html) を使用します。
## プライベートキーの自動ローテーションを設定する
セキュリティポスチャを強化するには、AWS Systems Manager エージェント (SSM Agent) を設定して、ハイブリッドまたはマルチクラウド環境用のプライベートキーを自動的にローテーションさせます。SSM Agent バージョン 3.0.1031.0 以降を使用すると、この機能にアクセスできます。次の手順に従ってこの機能を有効にします。
**ハイブリッドおよびマルチクラウド環境のプライベートキーをローテーションするように SSM Agent を設定するには**
1. Linux マシンでは `/etc/amazon/ssm/`、Windows Server マシンでは `C:\Program Files\Amazon\SSM` に移動します。
1. `amazon-ssm-agent.json.template` の内容を `amazon-ssm-agent.json` という名前の新ファイルにコピーします。`amazon-ssm-agent.json.template` と同じディレクトリに `amazon-ssm-agent.json` を保存します。
1. `Profile`、`KeyAutoRotateDays` を探す プライベートキーの自動ローテーション間隔の日数を入力します。
1. SSM Agent を再起動します。
設定を変更するたびに、SSM Agent を再起動します。
同じ手順を使用して、SSM Agent の他の機能をカスタマイズできます。使用可能な設定プロパティとそのデフォルト値の最新リストについては、「[Config Property Definitions](https://github.com/aws/amazon-ssm-agent#config-property-definitions) (設定プロパティの定義)」を参照してください。
## マネージドノードの登録解除と再登録 (Windows Server)
マネージドノードの登録を解除するには、AWS CLI または Tools for Windows PowerShell のいずれかから [DeregisterManagedInstance](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html) API オペレーションを呼び出します。以下に CLI コマンドの例を示します。
`aws ssm deregister-managed-instance --instance-id "mi-1234567890"`
エージェントの残りの登録情報を削除するには、`amazon-ssm-agent.json` ファイル内の `IdentityConsumptionOrder` キーを削除します。次に、以下のコマンドを実行します。
`amazon-ssm-agent -register -clear`
**注記**
指定のアクティベーションコードと ID のインスタンス制限に達していない限り、同じアクティベーションコードと ID を使用してオンプレミスサーバー、エッジデバイス、または VM を再登録できます。AWS CLI を使用して [describe-activations](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-activations.html) API を呼び出すことで、アクティベーションコードと ID のインスタンス制限を確認できます。このコマンドを実行した後、`RegistrationCount` の値が `RegistrationLimit` を超えていないことを確認します。もし超えている場合は、別のアクティベーションコードと ID を使用する必要があります。
**Windows Server ハイブリッドマシンでマネージドノードを再登録するには**
1. マシンへ接続します。
1. 以下のコマンドを実行してください。必ずプレースホルダー値の代わりに、ハイブリッドのアクティベーションの作成時に生成されたアクティベーションコードとアクティベーション ID、および SSM Agent のダウンロード元のリージョンの識別子を入力します。
```
$dir = $env:TEMP + "\ssm"
cd $dir
Start-Process ./ssm-setup-cli.exe -ArgumentList @(
"-register",
"-activation-code=$code",
"-activation-id=$id",
"-region=$region"
) -Wait -NoNewWindow
```
# Systems Manager を利用したエッジデバイスの管理
このセクションでは、アカウント管理者とシステム管理者が AWS IoT Greengrass コアデバイスの設定と管理を有効にするために実行する設定タスクについて説明します。これらのタスクを完了すると、AWS アカウント 管理者によって権限が付与されたユーザーは AWS Systems Manager を使って組織の AWS IoT Greengrass コアデバイスを設定と管理することができます。
**注記**
AWS IoT Greengrass 用の SSM Agent は macOS と Windows 10 にサポートされていません。Systems Manager のツールを使用して、これらのオペレーティングシステムを使用するエッジデバイスの管理と設定を行うことはできません。
Systems Manager は、AWS IoT Greengrass コアデバイスとして設定されていないエッジデバイスもサポートしています。Systems Manager を使用して AWS IoT コアデバイスおよび非 AWS エッジデバイスを管理する場合、ハイブリッドアクティベーションを使用して設定する必要があります。詳細については、「[Systems Manager を利用したハイブリッド環境およびマルチクラウド環境でのノードの管理](systems-manager-hybrid-multicloud.md)」を参照してください。
Session Manager と Microsoft アプリケーションパッチをエッジデバイスと使用する場合、アドバンストインスタンス層を有効にする必要があります。詳細については、「[アドバンストインスタンス層を有効にするには](fleet-manager-enable-advanced-instances-tier.md)」を参照してください。
**[開始する前に]**
エッジデバイスが以下の要件を満たしていることを確認します。
+ エッジデバイスを AWS IoT Greengrass コアデバイスとして設定する場合、要件を満たしている必要があります。詳細については、*AWS IoT Greengrass Version 2 デベロッパーガイド*の「[AWS IoT Greengrass コアデバイスの設定](https://docs.aws.amazon.com/greengrass/v2/developerguide/setting-up.html)」を参照してください。
+ エッジデバイスは AWS Systems Manager エージェント (SSM Agent) と互換性がなければなりません。詳細については、「[System Manager でサポートされているオペレーティングシステム](operating-systems-and-machine-types.md#prereqs-operating-systems)」を参照してください。
+ エッジデバイスはクラウド内の Systems Manager サービスと通信できる必要があります。Systems Manager は切断されたエッジデバイスをサポートしていません。
**エッジデバイスのセットアップについて**
Systems Manager 用に AWS IoT Greengrass デバイスの設定には以下のプロセスが含まれます。
**注記**
エッジデバイスからの SSM Agent のアンインストールの詳細については、*AWS IoT Greengrass Version 2 デベロッパーガイド*の「[Uninstall the AWS Systems Manager Agent](https://docs.aws.amazon.com/greengrass/v2/developerguide/uninstall-systems-manager-agent.html)」を参照してください。
## エッジデバイス用の IAM サービスロールを作成
AWS IoT Greengrass コアデバイスは AWS Systems Manager と通信するため、AWS Identity and Access Management (IAM) サービスロールが必要となります。ロールは、Systems Manager サービスに AWS Security Token Service (AWS STS) [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) の信頼を付与します。サービスロールの作成は AWS アカウント ごとに一度のみ行う必要があります。AWS IoT Greengrass デバイスに SSM Agent のコンポーネントを設定と展開する際、このロールは `RegistrationRole` のパラメータに指定します。[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境用に非 EC2 ノードをセットアップするときにこのロールを既に作成している場合は、この手順をスキップできます。
**注記**
エッジデバイスで Systems Manager を社内または組織内で使用するユーザーは、Systems Manager API を呼び出すために IAM で許可を付与する必要があります。
**S3 バケットのポリシーの要件**
次のいずれかのケースに当てはまる場合は、この手順を実行する前に Amazon Simple Storage Service (Amazon S3) バケット用のカスタム IAM アクセス許可ポリシーを作成する必要があります。
+ **ケース 1**: VPC エンドポイントを使用して、サポートされている AWS のサービス、および AWS PrivateLink を搭載した VPC エンドポイントサービスに VPC をプライベート接続しています。
+ **ケース 2**: Systems Manager オペレーションの一環として作成した S3 バケットを使用します (例: Run Command コマンドまたは、Session Manager セッションの出力を S3 バケットに保存)。先に進む前に、「[インスタンスプロファイル用のカスタム S3 バケットポリシーを作成する](setup-instance-permissions.md#instance-profile-custom-s3-policy)」の手順に従います。そのトピックの S3 バケットポリシーに関する情報は、サービスロールにも適用されます。
**注記**
デバイスがファイアウォールで保護され、かつ Patch Manager を使用する場合、ファイアウォールはパッチベースラインのエンドポイント `arn:aws:s3:::patch-baseline-snapshot-region/*` へアクセスを許可する必要があります。
*region* は、米国東部 (オハイオ) リージョンの `us-east-2` のように、AWS Systems Manager でサポートされている AWS リージョン の識別子を表します。サポートされている*リージョン*値のリストについては、「*Amazon Web Services 全般のリファレンス*」の「[Systems Manager サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)」にある**リージョン**列を参照してください。
------
#### [ AWS CLI ]
**AWS IoT Greengrass 環境用 (AWS CLI) に IAM サービスロールを作成する方法**
1. まだ AWS Command Line Interface (AWS CLI) をインストールして設定していない場合は、インストールして設定します。
詳細については、「[AWS CLI の最新バージョンをインストールまたは更新します。](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。
1. ローカルマシンで以下の信頼ポリシーを使用して、`SSMService-Trust.json` のような名前でテキストファイルを作成します。ファイル保存時に、必ずファイル拡張子 (`.json`) を付けます。
**注記**
名前をメモします。SSM Agent を AWS IoT Greengrass コアデバイスに展開する際にそれを指定します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
}
```
------
1. AWS CLI を開き、JSON ファイルを作成したディレクトリで [create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) コマンドを実行してサービスロールを作成します。各*リソースプレースホルダーの例*をユーザー自身の情報に置き換えます。
**Linux と macOS**
```
aws iam create-role \
--role-name SSMServiceRole \
--assume-role-policy-document file://SSMService-Trust.json
```
**Windows**
```
aws iam create-role ^
--role-name SSMServiceRole ^
--assume-role-policy-document file://SSMService-Trust.json
```
1. 以下のように [attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) を実行して、先ほど作成したサービスロールでセッショントークンを作成できるようにします。セッショントークンは、Systems Manager を使用してコマンドを実行するため、エッジデバイスに許可を付与します。
**注記**
エッジデバイスに対してサービスプロファイル用に追加するポリシーは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのインスタンスプロファイルの作成に使用されるものと同じポリシーです。次のコマンドで使用する IAM ポリシーの詳細については、「[Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)」を参照してください。
(必須) 以下のコマンドを実行して、エッジデバイスが AWS Systems Manager サービスの主要機能を使用できるようにします。
**Linux と macOS**
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
**Windows**
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
サービスロールのカスタム S3 バケットポリシーを作成した場合は、次のコマンドを実行して、ポリシーで指定したバケットに AWS Systems Manager Agent (SSM Agent) がアクセスできるようにします。*account\$1ID* と *my\$1bucket\$1policy\$1name* をユーザーの AWS アカウント ID とバケット名に置き換えます。
**Linux と macOS**
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::account_ID:policy/my_bucket_policy_name
```
**Windows**
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::account_id:policy/my_bucket_policy_name
```
(選択可) 以下のコマンドを実行して、エッジデバイスからドメインの統合するリクエストのため、ユーザーに代わって SSM Agent が Directory Service にアクセスできるようにします。エッジデバイスを Microsoft AD ディレクトリに統合する場合のみ、サービスロールはこのポリシーが必要です。
**Linux と macOS**
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
```
**Windows**
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
```
(選択可) 以下のコマンドを実行して、CloudWatch エージェントがエッジデバイスの実行できるようにします。このコマンドはデバイスの情報を読み込んでCloudWatch に書き込むことを可能にします。サービスロールは、Amazon EventBridge や Amazon CloudWatch Logs などのサービスを利用する場合にのみ、このポリシーが必要です。
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
------
#### [ Tools for PowerShell ]
**AWS IoT Greengrass 環境用 (AWS Tools for Windows PowerShell) に IAM サービスロールを作成する方法**
1. AWS Tools for PowerShell (Tools for Windows PowerShell) をインストールして設定します (まだインストールしていない場合)。
詳細については、「[AWS Tools for PowerShell のインストール](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html)」を参照してください。
1. ローカルマシンで以下の信頼ポリシーを使用して、`SSMService-Trust.json` のような名前でテキストファイルを作成します。ファイル保存時に、必ずファイル拡張子 (`.json`) を付けます。
**注記**
名前をメモします。SSM Agent を AWS IoT Greengrass コアデバイスに展開する際にそれを指定します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
}
```
------
1. PowerShell を管理モードで開き、JSON ファイルを作成したディレクトリで以下のように [New-IAMRole](https://docs.aws.amazon.com//powershell/latest/reference/items/Register-IAMRolePolicy.html) を実行してサービスロールを作成します。
```
New-IAMRole `
-RoleName SSMServiceRole `
-AssumeRolePolicyDocument (Get-Content -raw SSMService-Trust.json)
```
1. 以下のように、[Register-IAMRolePolicy](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-IAMRolePolicy.html) を使用して、作成したサービスロールでセッショントークンを作成できます。セッショントークンは、Systems Manager を使用してコマンドを実行するため、エッジデバイスに許可を付与します。
**注記**
AWS IoT Greengrass 環境内でエッジデバイスに対してサービスロール用に追加するポリシーは、EC2 インスタンスのインスタンスプロファイルの作成に使用されるものと同じポリシーです。以下のコマンドで使用する AWS ポリシーの詳細については、「[Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)」を参照してください。
(必須) 以下のコマンドを実行して、エッジデバイスが AWS Systems Manager サービスの主要機能を使用できるようにします。
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
サービスロールのカスタム S3 バケットポリシーを作成した場合は、次のコマンドを実行し、ポリシーで指定したバケットに SSM Agent がアクセスできるようにします。*account\$1ID* と *my\$1bucket\$1policy\$1name* をユーザーの AWS アカウント ID とバケット名に置き換えます。
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::account_ID:policy/my_bucket_policy_name
```
(選択可) 以下のコマンドを実行して、エッジデバイスからドメインの統合するリクエストのため、ユーザーに代わって SSM Agent が Directory Service にアクセスできるようにします。エッジデバイスを Microsoft AD ディレクトリに統合する場合のみ、サービスロールはこのポリシーが必要です。
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
```
(選択可) 以下のコマンドを実行して、CloudWatch エージェントがエッジデバイスの実行できるようにします。このコマンドはデバイスの情報を読み込んでCloudWatch に書き込むことを可能にします。サービスロールは、Amazon EventBridge や Amazon CloudWatch Logs などのサービスを利用する場合にのみ、このポリシーが必要です。
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
------
## AWS IoT Greengrass のためにエッジデバイスを設定する
エッジデバイスを AWS IoT Greengrass コアデバイスとしてセットアップします。セットアッププロセスは、サポートされたオペレーティングシステムとシステム要件の確認、並びにデバイス上に AWS IoT Greengrass コアソフトウェアのインストールと設定が含まれます。詳細については、AWS IoT Greengrass Version 2 デベロッパーガイドの「[AWS IoT Greengrass コアデバイスの設定](https://docs.aws.amazon.com/greengrass/v2/developerguide/setting-up.html)」を参照してください。
## AWS IoT Greengrass トークン交換ロールを更新して SSM Agent をエッジデバイスにインストールします。
Systems Manager 用に AWS IoT Greengrass コアデバイスのセットアップと設定における最終ステップでは、AWS IoT Greengrass AWS Identity and Access Management (IAM) デバイスサービスロール (*トークン交換ロール*とも呼ばれる) を更新して、AWS Systems Manager エージェント (SSM Agent) を AWS IoT Greengrass デバイスにデプロイする必要があります。これらのプロセスの詳細については、AWS IoT Greengrass Version 2 デベロッパーガイドの「[AWS Systems Manager エージェントのインストール](https://docs.aws.amazon.com/greengrass/v2/developerguide/install-systems-manager-agent.html)」を参照してください。
デバイスに SSM Agent を展開したら、AWS IoT Greengrass はデバイスを自動的に Systems Manager に登録します。追加登録は必要ありません。Systems Manager のツールを使って、AWS IoT Greengrass デバイスへのアクセスやその管理、設定を行うことができます。
**注記**
エッジデバイスはクラウド内の Systems Manager サービスと通信できる必要があります。Systems Manager は切断されたエッジデバイスをサポートしていません。
# Systems Manager 用の AWS Organizations 委任された管理者の作成
**Change Manager の可用性の変更**
AWS Systems ManagerChange Manager は、2025 年 11 月 7 日以降、新規のお客様の受付を終了します。Change Manager を使用する場合は、その日付の前にサインアップしてください。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、「[AWS Systems Manager Change Manager の可用性の変更](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager-availability-change.html)」を参照してください。
AWS Organizations で組織をセットアップする際には、すべての AWS のサービス に対してすべての管理タスクを実行する管理アカウントを割り当てます。管理アカウントユーザーは、Systems Manager が Change Manager、Explorer、および OpsCenter の管理タスクを実行するための委任管理者アカウントのみを割り当てることができます。AWS Organizations は、組織を作成し、これらの AWS アカウント を一元管理するために割り当てるために使用できるアカウント管理サービスです。AWS Organizations の詳細については、「AWS Organizations ユーザーガイド」の「[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)」を参照してください。
AWS Systems Manager のツールである Change Manager、Explorer、および OpsCenter を AWS Organizations と連携させて、組織のすべてのメンバーアカウントでタスクを実行できます。Systems Manager のすべてのツールに対して、委任管理者を 1 人だけ割り当てることができます。委任管理者アカウントは、割当先の組織のメンバーである必要があります。
**Topics**
+ [Change Manager での委任された管理者の使用](#setting_up_delegated_administrator_change_manager)
+ [Explorer での委任された管理者の使用](#setting_up_delegated_administrator_explorer)
+ [OpsCenter での委任された管理者の使用](#setting_up_delegated_administrator_opscenter)
+ [Quick Setup での委任された管理者の使用](#setting_up_delegated_administrator_quick_setup)
## Change Manager での委任された管理者の使用
Change Manager は、アプリケーションの設定やインフラストラクチャに対する運用上の変更を要求、承認、実装、レポート作成するためのエンタープライズ変更管理フレームワークです。
組織全体で Change Manager を使用する場合は、委任管理者アカウントを割り当てて、すべてのメンバーアカウントの変更テンプレート、承認、およびレポートを管理します。Quick Setup の使用により、組織での使用向けに Change Manager をセットアップして委任された管理者アカウントを選することができます。Change Manager を単一の AWS アカウント のみで使用する場合、委任管理者アカウントは必要ありません。
デフォルトでは、Change Manager には委任管理者アカウントのすべての変更関連タスクが表示されます。組織の Change Manager をセットアップする時に委任管理者を設定する手順については、「[組織の Change Manager の設定 (管理アカウント)](change-manager-organization-setup.md)」を参照してください。
**重要**
組織全体で Change Manager を使用する場合は、常に委任管理者アカウントから変更を行うことをお勧めします。組織内の他のアカウントから変更を行うことはできますが、それらの変更は、委任管理者アカウントで報告されず、表示することもできません。
## Explorer での委任された管理者の使用
Explorer はカスタマイズ可能なオペレーションダッシュボードであり、AWS リージョン 全体の AWS アカウント のオペレーションデータ (OpsData) の集約ビューをレポートします。
Systems Manager の委任管理者アカウントを設定して、AWS Organizations とのリソースデータ同期を使用して、複数のリージョンとアカウントから Explorer データを集約できます。委任管理者は、AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、または AWS Tools for Windows PowerShell を使用し Explorer データを検索、フィルタリング、および集約できます。
Explorer 用に委任管理者アカウントを使用する場合、各 AWS アカウント へマルチアカウントおよびリージョンのリソースデータの同期を作成または削除できる管理者の数を制限します。
Explorer を使用することにより、組織内のすべての AWS アカウント 間でオペレーションデータを同期できます。Explorer から委任管理者を割り当てる方法については、「[Explorer のための委任された管理者の設定](Explorer-setup-delegated-administrator.md)」を参照してください。
## OpsCenter での委任された管理者の使用
OpsCenter は、オペレーションエンジニアや IT プロフェッショナルは AWS リソースに関連する運用上の作業項目 (OpsItems) の表示、調査、解決を一元管理できます。OpsCenter を使用して複数のアカウント間で OpsItems を一元管理する場合は、AWS Organizations で組織をセットアップする必要があります。
OpsCenter の Quick Setup を使用すると、委任された管理者アカウントを割り当て、OpsItems を一元管理するように OpsCenter を設定できます。詳細については、「[(オプション) Quick Setup を使用して、複数のアカウント間で OpsItems を管理するように OpsCenter を設定](OpsCenter-quick-setup-cross-account.md)」を参照してください。
## Quick Setup での委任された管理者の使用
Quick Setup は Systems Manager のツールであり、推奨されるベストプラクティスに従って、よく使用する AWS サービスと機能をすばやく設定できます。Quick Setup 用に委任管理者アカウントを設定することで、AWS Organizations を使用してアカウントとリージョン全体にわたって設定をデプロイおよび管理できます。Quick Setup の委任管理者は、組織の設定マネージャーリソースを作成、更新、表示、および削除できます。Systems Manager は、統合コンソールエクスペリエンスのセットアッププロセスの一環として Quick Setup の委任管理者を登録します。詳細については、「[組織用の Systems Manager 統合コンソールのセットアップ](systems-manager-setting-up-organizations.md)」を参照してください。
## AWS Systems Manager の一般的なセットアップ
まだ作成していない場合は、AWS アカウント にサインアップして管理者ユーザーを作成します。
### AWS アカウントへのサインアップ
AWS アカウント がない場合は、以下のステップを実行して作成します。
**AWS アカウント にサインアップするには**
1. [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup) を開きます。
1. オンラインの手順に従います。
サインアップ手順の一環として、電話またはテキストメッセージを受け取り、電話キーパッドで検証コードを入力します。
AWS アカウントにサインアップすると、*AWS アカウントのルートユーザー*が作成されます。ルートユーザーには、アカウントのすべての AWS のサービス とリソースへのアクセス権があります。セキュリティのベストプラクティスとして、ユーザーに管理アクセスを割り当て、ルートユーザーのみを使用して[ルートユーザーアクセスが必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)を実行してください。
サインアップ処理が完了すると、AWS からユーザーに確認メールが送信されます。[https://aws.amazon.com/](https://aws.amazon.com/) の **[マイアカウント]** をクリックして、いつでもアカウントの現在のアクティビティを表示し、アカウントを管理することができます。
### 管理アクセスを持つユーザーを作成する
AWS アカウントにサインアップしたら、AWS アカウントのルートユーザーをセキュリティで保護し、AWS IAM アイデンティティセンター を有効にして、管理ユーザーを作成します。これにより、日常的なタスクにルートユーザーを使用しないようにします。
**AWS アカウントのルートユーザー をセキュリティで保護する**
1. **[ルートユーザー]** を選択し、AWS アカウント のメールアドレスを入力して、アカウント所有者として [AWS マネジメントコンソール](https://console.aws.amazon.com/) にサインインします。次のページでパスワードを入力します。
ルートユーザーを使用してサインインする方法については、「*AWS サインイン ユーザーガイド*」の「[ルートユーザーとしてサインインする](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial)」を参照してください。
1. ルートユーザーの多要素認証 (MFA) を有効にします。
手順については、「*IAM ユーザーガイド*」の「[AWS アカウント ルートユーザーの仮想 MFA デバイスを有効にする (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html)」を参照してください。
**管理アクセスを持つユーザーを作成する**
1. IAM アイデンティティセンターを有効にします。
手順については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[AWS IAM アイデンティティセンター の有効化](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html)」を参照してください。
1. IAM アイデンティティセンターで、ユーザーに管理アクセスを付与します。
IAM アイデンティティセンターディレクトリ をアイデンティティソースとして使用するチュートリアルについては、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[デフォルトの IAM アイデンティティセンターディレクトリ を使用してユーザーアクセスを設定する](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html)」を参照してください。
**管理アクセス権を持つユーザーとしてサインインする**
+ IAM アイデンティティセンターのユーザーとしてサインインするには、IAM アイデンティティセンターのユーザーの作成時に E メールアドレスに送信されたサインイン URL を使用します。
IAM アイデンティティセンターユーザーを使用してサインインする方法については、「*AWS サインイン ユーザーガイド*」の「[AWS アクセスポータルにサインインする](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html)」を参照してください。
**追加のユーザーにアクセス権を割り当てる**
1. IAM アイデンティティセンターで、最小特権のアクセス許可を適用するというベストプラクティスに従ったアクセス許可セットを作成します。
手順については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[アクセス許可セットを作成する](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html)」を参照してください。
1. グループにユーザーを割り当て、そのグループにシングルサインオンアクセス権を割り当てます。
手順については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[グループを追加する](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html)」を参照してください。