• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.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
```