• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。
# パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaselineWithHooks`
AWS Systems Manager は、AWS Systems Manager のツールである Patch Manager 用の Systems Manager ドキュメント (SSM ドキュメント) である `AWS-RunPatchBaselineWithHooks` をサポートしています。この SSM ドキュメントでは、セキュリティ関連および他のタイプの更新の両方について、マネージドノードにパッチ適用オペレーションを実行します。
`AWS-RunPatchBaselineWithHooks` は、次の点で `AWS-RunPatchBaseline` とは異なります。
+ **ラッパードキュメント** – `AWS-RunPatchBaselineWithHooks` は、`AWS-RunPatchBaseline` のラッパーであり、そのオペレーションの一部で `AWS-RunPatchBaseline` に依存しています。
+ **`Install` オペレーション** – `AWS-RunPatchBaselineWithHooks` では、マネージドノードのパッチ適用中に指定されたポイントで実行されるライフサイクルフックがサポートされます。パッチのインストールにはマネージドノードの再起動が必要になる場合があるため、パッチ適用オペレーションは 2 つのイベントに分割され、合計 3 つのフックでカスタム機能をサポートします。最初のフックは `Install with NoReboot` オペレーションの前です。2 番目のフックは `Install with NoReboot` オペレーションの後です。3 番目のフックは、マネージドノードの再起動後に使用できます。
+ **カスタムパッチリストはサポートしません** – `AWS-RunPatchBaselineWithHooks` では、`InstallOverrideList` パラメータはサポートされません。
+ **SSM Agent サポート** – `AWS-RunPatchBaselineWithHooks` では、パッチを適用するために SSM Agent 3.0.502 以降をマネージドノードにインストールする必要があります。
パッチグループが指定されていない場合、ドキュメントを実行すると、オペレーティングシステムタイプの「デフォルト」として現在指定されているパッチベースラインが使用されます。それ以外の場合は、パッチグループに関連付けられているパッチベースラインが使用されます。パッチグループの詳細については、「[パッチグループ](patch-manager-patch-groups.md)」を参照してください。
ドキュメント `AWS-RunPatchBaselineWithHooks` を使用して、オペレーティングシステムとアプリケーションの両方にパッチを適用することができます。(Windows Server では、アプリケーションのサポートは、Microsoft がリリースしたアプリケーションの更新に制限されています)。
このドキュメントでは、Linux および Windows Server マネージドノードをサポートしています。ドキュメントは、プラットフォーム別に適切なアクションを実行します。
**注記**
`AWS-RunPatchBaselineWithHooks` は macOS ではサポートされていません。
------
#### [ Linux ]
Linux マネージドノードの場合、`AWS-RunPatchBaselineWithHooks` ドキュメントは、Python モジュールを呼び出します。これに伴って、マネージドノードに適用するパッチベースラインのスナップショットがダウンロードされます。このパッチベースラインのスナップショットは、定義済みルールと、承認済みパッチおよび拒否済みパッチのリストを使用し、ノードタイプ別に適切なパッケージマネージャーを設定します。
+ Amazon Linux 2、Oracle Linux、および RHEL 7 マネージドノードでは、YUM が使用されています。YUM のオペレーションでは、Patch Manager には、`Python 2.6` またはそれ以降のサポートされているバージョン (2.6～3.12) が必要です。Amazon Linux 2023 では DNF が使用されています。DNF のオペレーションでは、Patch Manager には、サポートされているバージョン (2.6～3.12) の `Python 2` または `Python 3` が必要です。
+ RHEL 8 マネージドノードでは DNF が使用されます。DNF のオペレーションでは、Patch Manager には、サポートされているバージョン (2.6～3.12) の `Python 2` または `Python 3` が必要です。(どちらのバージョンも RHEL 8 にはデフォルトでインストールされていません。どちらか一方を手動でインストールする必要があります。)
+ Debian Server インスタンスと Ubuntu Server インスタンスでは、APT を使用します。APT のオペレーションでは、Patch Manager には、サポートされているバージョン (3.0～3.12) の `Python 3` が必要です。
------
#### [ Windows サーバー ]
Windows Server マネージドノードの場合、`AWS-RunPatchBaselineWithHooks` ドキュメントは、PowerShell モジュールをダウンロードして呼び出します。これに伴って、マネージドノードに適用するパッチベースラインのスナップショットがダウンロードされます。このパッチベースラインスナップショットには、Windows Server Update Services (WSUS) サーバーに対してパッチベースラインを照会することによってコンパイルされる承認済みパッチのリストが含まれています。このリストは、Windows Update API に渡され、ここで承認済みパッチのダウンロードとインストールが適切に制御されます。
------
各スナップショットは、AWS アカウント 、パッチグループ、オペレーティングシステム、スナップショット ID に固有のものです。スナップショットは、署名付きの Amazon Simple Storage Service (Amazon S3) URL を介して配信されます。この URL は、スナップショットが作成されてから 24 時間後に期限切れになります。ただし、URL の有効期限が切れた後に、同じスナップショットコンテンツを他のマネージドノードに適用する場合は、スナップショットを作成してから 3 日以内であれば新しい署名付き Amazon S3 URL を生成できます。これを行うには、[https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html) コマンドを使用します。
すべての承認済みで適用可能な更新プログラムがインストールされ、必要に応じて再起動されると、パッチのコンプライアンス情報がマネージドノードで生成されて Patch Manager にレポートされます。
`AWS-RunPatchBaselineWithHooks` ドキュメントで `RebootOption` パラメータが `NoReboot` に設定されている場合、Patch Manager の実行後、マネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。
**重要**
`NoReboot` オプションはオペレーティングシステムの再起動を防止しますが、特定のパッケージの更新時に発生する可能性のあるサービスレベルの再起動は防止しません。例えば、Docker などのパッケージを更新すると、`NoReboot` が指定されていても依存サービス (コンテナオーケストレーションサービスなど) の自動再起動がトリガーされる場合があります。
パッチコンプライアンスデータの表示方法については、「[パッチコンプライアンスについて](compliance-about.md#compliance-monitor-patch)」を参照してください。
## `AWS-RunPatchBaselineWithHooks` オペレーションステップ
`AWS-RunPatchBaselineWithHooks` が実行されると、次の手順が実行されます。
1. **スキャン** - `Scan` を使用した `AWS-RunPatchBaseline` オペレーションがマネージドノードで実行され、コンプライアンスレポートが生成され、アップロードされます。
1. **ローカルパッチ状態の確認** - スクリプトを実行して、選択したオペレーションとステップ 1 の `Scan` 結果に基づいて実行されるステップを決定します。
1. 選択したオペレーションが `Scan` の場合、そのオペレーションは完了としてマークされます。オペレーションは終了します。
1. 選択したオペレーションが `Install` の場合、Patch Manager はステップ 1 の `Scan` 結果を評価し、次に実行するオペレーションを決定します。
1. パッチの欠落が検出されず、保留中の再起動が必要ない場合は、オペレーションは最後のステップ (ステップ 8) に直接進みます。これには、指定したフックが含まれます。その間のステップはすべてスキップされます。
1. パッチの欠落が検出されないが、保留中の再起動が必要で、選択した再起動オプションが `NoReboot` である場合、オペレーションは最後のステップ (ステップ 8) に直接進みます。これには、指定したフックが含まれます。その間のステップはすべてスキップされます。
1. それ以外の場合、オペレーションは次のステップに進みます。
1. **パッチ適用前のフックオペレーション** - 最初のライフサイクルフック用に指定した SSM ドキュメント (`PreInstallHookDocName`) は、マネージドノードで実行されます。
1. **再起動せずにインストール** - `Install` を使用して `NoReboot` の再起動オプションを含む `AWS-RunPatchBaseline` オペレーションがマネージドノードで実行され、コンプライアンスレポートが生成され、アップロードされます。
1. **インストール後のフックオペレーション** - 2 番目のライフサイクルフック用に指定した SSM ドキュメント (`PostInstallHookDocName`) は、マネージドノードで実行されます。
1. **パッチ適用前のフックオペレーション** - 最初のライフサイクルフック用に指定した SSM ドキュメントは、インスタンスで実行されます。
1. 選択した再起動オプションが `NoReboot` の場合、オペレーションは最後のステップ (ステップ 8) に直接進みます。これには、指定したフックが含まれます。その間のステップはすべてスキップされます。
1. 選択した再起動オプションが `RebootIfNeeded` の場合、Patch Manager はステップ4で収集されたインベントリから保留中の再起動が必要かどうかをチェックします。つまり、次のいずれかの場合に操作をステップ 7 に進み、マネージド ノードが再起動されます。
1. Patch Manager は、1 つ以上のパッチをインストールしました。(Patch Manager は、パッチに再起動が必要かどうかを評価しません。パッチに再起動が必要ない場合でも、システムは再起動されます。)
1. Patch Manager は、インストールの実行中、`INSTALLED_PENDING_REBOOT` の状態によってパッチをひとつ以上検出します。`INSTALLED_PENDING_REBOOT` ステータスは、前回インストールオペレーションを実行したときにオプション `NoReboot` が選択されたことを意味する場合や、マネージドノードが最後に再起動されたとき以降にパッチが Patch Manager 以外でインストールされたことを意味する場合があります。
これらの条件を満たすパッチが見つからない場合は、マネージド ノードのパッチ適用操作が完了し、操作は最終ステップ (ステップ 8) に直接進みます。これには、提供されたフックが含まれます。その間のステップはすべてスキップされます。
1. **再起動とレポート** - 再起動オプションが `RebootIfNeeded` であるインストールオペレーションは、`AWS-RunPatchBaseline` を使用してマネージドノードで実行され、コンプライアンスレポートが生成され、アップロードされます。
1. **再起動後のフックオペレーション** - 3 番目のライフサイクルフック用に指定した SSM ドキュメント (`OnExitHookDocName`) は、マネージドノードで実行されます。
`Scan` オペレーションの場合、ステップ 1 が失敗すると、ドキュメントの実行プロセスは停止し、ステップは失敗として報告されますが、後続のステップは成功として報告されます。
`Install` オペレーションの場合、オペレーション中にいずれかの `aws:runDocument` ステップが失敗すると、そのようなステップは失敗として報告され、オペレーションは直接最終ステップ (ステップ 8) に進みます。これには、指定したフックが含まれます。その間のステップはすべてスキップされます。このステップは失敗として報告され、最後のステップはそのオペレーション結果のステータスを報告し、その間にあるすべてのステップは成功として報告されます。
## `AWS-RunPatchBaselineWithHooks` 個のパラメータ
`AWS-RunPatchBaselineWithHooks` では 6 つのパラメータがサポートされています。
`Operation` パラメータは必須です。
`RebootOption`、`PreInstallHookDocName`、`PostInstallHookDocName` および `OnExitHookDocName` パラメータはオプションです。
`Snapshot-ID` は技術的にはオプションですが、`AWS-RunPatchBaselineWithHooks` をメンテナンスウィンドウ以外で実行する場合は、カスタム値を指定することをお勧めします。ドキュメントがメンテナンスウィンドウオペレーションの一部として実行されるときに、Patch Manager に値を自動的に指定させましょう。
**Topics**
+ [パラメータ名: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [パラメータ名: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [パラメータ名: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [パラメータ名: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [パラメータ名: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)
### パラメータ名: `Operation`
**使用**: 必須。
**オプション**: `Scan` \$1 `Install`。
Scan
`Scan` オプションを選択すると、システムは `AWS-RunPatchBaseline` ドキュメントを使用してマネージドノードのパッチコンプライアンスの状態を判断し、その情報を Patch Manager にレポートします。`Scan` では、更新のインストールやマネージドノードの再起動は行われません。その代わりに、このオペレーションでは、承認されたノードに適用可能なアップデートがどこに欠けているかを特定します。
インストール
`Install` オプションを選択すると、`AWS-RunPatchBaselineWithHooks` はマネージドノードに見つからない承認済み更新と適用可能な更新のインストールを試行します。`Install` オペレーションの一部として生成されるパッチコンプライアンス情報には、見つからない更新は示されませんが、更新のインストールが何らかの原因で失敗した場合は「失敗」状態になっている更新がレポートされることがあります。更新がマネージドノードにインストールされるたびに、ノードが再起動され、更新がインストール済みで有効になっていることが確認されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaselineWithHooks` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)」を参照してください。)
Patch Manager がマネージドノードを更新する*前*に、ベースラインルールで指定されているパッチがインストールされている場合、システムが予期したとおりに再起動しないことがあります。この可能性があるのは、パッチがユーザーによって手動でインストールされたか、Ubuntu Server の `unattended-upgrades` パッケージなどの別のプログラムによって自動的にインストールされた場合です。
### パラメータ名: `Snapshot ID`
**使用**: オプション。
`Snapshot ID` は、Patch Manager が使用する一意の ID (GUID) です。この ID により、1 回のオペレーションでパッチを適用するマネージドノードのすべてに同じ承認済みパッチのセットが適用されます。このパラメータは省略可能ですが、次の表に示すようにメンテナンスウィンドウで `AWS-RunPatchBaselineWithHooks` を実行しているかどうかに応じて、推奨されるベストプラクティスが異なります。
**`AWS-RunPatchBaselineWithHooks` のベストプラクティス**
| モード | ベストプラクティス | 詳細 |
| --- | --- | --- |
| メンテナンスウィンドウ内で AWS-RunPatchBaselineWithHooks を実行する | スナップショット ID は指定しないでください。Patch Manager によって指定されます。 | メンテナンスウィンドウを使用して `AWS-RunPatchBaselineWithHooks` を実行する場合は、独自に生成したスナップショット ID を提供すべきではありません。このシナリオでは、メンテナンスウィンドウの実行 ID に基づく GUID 値が Systems Manager から提供されます。これにより、そのメンテナンスウィンドウでは、`AWS-RunPatchBaselineWithHooks` のすべての呼び出しで正しい ID が使用されます。 このシナリオで値を指定しないと、パッチベースラインのスナップショットは 3 日以内に有効期限が切れる場合があります。スナップショットの有効期限が切れると、同じ ID を指定しても、別のスナップショットが生成されます。 |
| メンテナンスウィンドウ外で AWS-RunPatchBaselineWithHooks を実行する | スナップショット ID のカスタム GUID 値を生成および指定します。¹ | メンテナンスウィンドウを使用しないで `AWS-RunPatchBaselineWithHooks` を実行する場合は、パッチベースラインごとに一意のスナップショット ID を生成し指定することをお勧めします (特に、同一のオペレーションで `AWS-RunPatchBaselineWithHooks` ドキュメントを複数のマネージドノードで実行する場合)。このシナリオで ID を指定しないと、コマンドの送信先のマネージドノードごとに異なるスナップショット ID が Systems Manager で生成されます。これにより、ノード間で異なるパッチセットが指定される場合があります。 例えば、AWS Systems Manager のツールである Run Command を使用して `AWS-RunPatchBaselineWithHooks` ドキュメントを直接実行し、50 個のマネージドノードのグループをターゲットにしているとします。カスタムスナップショット ID を指定すると、1 つのベースラインスナップショットが作成され、これがすべてのマネージドノードの評価とパッチ適用に使用されるため、すべてのノードの状態が一致します。 |
| ¹Snapshot ID パラメータの値を生成するには、GUID を生成できる任意のツールを使用できます。たとえば、PowerShell では、`New-Guid` cmdlet を使用して `12345699-9405-4f69-bc5e-9315aEXAMPLE` という形式の GUID を生成できます。 |
### パラメータ名: `RebootOption`
**使用**: オプション。
**オプション**: `RebootIfNeeded` \$1 `NoReboot`
**デフォルト**: `RebootIfNeeded`
**警告**
デフォルトのオプションは `RebootIfNeeded` です。ユースケースに適したオプションを必ず選択してください。例えば、設定プロセスを完了するためにマネージドノードをすぐに再起動する必要がある場合は、`RebootIfNeeded` を選択します。または、スケジュールされた再起動時間までマネージドノードの可用性を維持する必要がある場合は、`NoReboot` を選択します。
**重要**
Amazon EMR (以前は Amazon Elastic MapReduce と呼ばれていました) のクラスターインスタンスへのパッチ適用には、Patch Manager を使用しないことをお勧めします。特に、`RebootOption` パラメータの `RebootIfNeeded` オプションは選択しないでください。(このオプションは、`AWS-RunPatchBaseline`、`AWS-RunPatchBaselineAssociation`、および `AWS-RunPatchBaselineWithHooks` のパッチ適用用の SSM コマンドドキュメントに記載されています。)
Patch Manager を使用してパッチを適用する基本コマンドは、`yum` と `dnf` コマンドを使用します。そのため、パッケージのインストール方法が原因となり、オペレーションの互換性が失われます。Amazon EMR クラスターのソフトウェアを更新するための推奨方法については、「Amazon EMR 管理ガイド」の「[Amazon EMR のデフォルト AMI の使用](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html)」を参照してください。
RebootIfNeeded
`RebootIfNeeded` オプションを選択すると、次のいずれかの場合にマネージドノードが再起動されます。
+ Patch Manager が 1 つ以上のパッチをインストールしている場合。
Patch Manager は、パッチによる再起動が*必要*かどうか評価しない場合。パッチで再起動が必要ない場合でも、システムは再起動されます。
+ Patch Manager は、`Install` オペレーションの実行中、ステータスが `INSTALLED_PENDING_REBOOT` のパッチをひとつ以上検出します。
`INSTALLED_PENDING_REBOOT` ステータスは、前回 `Install` オペレーションを実行したときにオプション `NoReboot` が選択されたことを意味する場合や、マネージドノードが最後に再起動されたとき以降にパッチが Patch Manager 以外でインストールされたことを意味する場合があります。
上記 2 つの場合にマネージドノードを再起動すると、更新されたパッケージがメモリからフラッシュされ、パッチ適用と再起動の動作があらゆるオペレーティングシステムで一貫して維持されます。
NoReboot
`NoReboot` オプションを選択すると、Patch Manager が `Install` オペレーション中にパッチをインストールした場合でも、マネージドノードは再起動されません。このオプションは、パッチ適用後にマネージドノードを再起動する必要がないことがわかっている場合や、パッチ適用操作の再起動によって中断されないアプリケーションまたはプロセスがノードで実行されている場合に便利です。また、メンテナンスウィンドウを使用するなど、マネージドノードの再起動のタイミングをより詳細に制御する場合にも役立ちます。
パッチがインストールされている場合に `NoReboot` オプションを選択すると、ステータス `InstalledPendingReboot` がパッチに割り当てられます。ただし、マネージドノード自体は、`Non-Compliant` と表示されています。再起動が発生し、`Scan` オペレーションが実行されると、ノードのステータスは `Compliant` に更新されます。
**パッチのインストール追跡ファイル**: パッチ (特にシステムの最後の再起動以降にインストールされたパッチ) のインストールを追跡するために、Systems Manager は、マネージドノードのファイルを管理します。
**重要**
追跡ファイルを削除または変更しないでください。このファイルを削除または破損すると、マネージドノードのパッチコンプライアンスレポートが不正確になります。ファイルを削除または破損した場合は、ノードを再起動し、パッチのスキャンオペレーションを実行してファイルを復元します。
この追跡ファイルは、マネージドノードの以下の場所に保存されます。
+ Linux オペレーティングシステム:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server オペレーティングシステム:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### パラメータ名: `PreInstallHookDocName`
**使用**: オプション。
**デフォルト**: `AWS-Noop`。
`PreInstallHookDocName` パラメータに指定する値は、選択した SSM ドキュメントの名前または Amazon リソースネーム (ARN) です。AWS マネージドドキュメントの名前や、作成したか共有されたカスタム SSM ドキュメントの名前または ARN を指定できます。(別の AWS アカウント から共有されている SSM ドキュメントの場合は、`arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument` などの完全なリソース ARN を指定する必要があります)。
指定した SSM ドキュメントは、`Install` オペレーションの前に実行され、マネージドノードでパッチ適用が実行される前にアプリケーションのヘルスチェックを行うシェルスクリプトなど、SSM Agent がサポートするアクションを実行します。(アクションの一覧については、「[コマンドドキュメントプラグインリファレンス](documents-command-ssm-plugin-reference.md)」を参照してください)。デフォルトの SSM ドキュメント名は `AWS-Noop` で、マネージドノードに対するオペレーションは実行されません。
カスタム SSM ドキュメントの作成方法については、「[SSM ドキュメントコンテンツを作成する](documents-creating-content.md)」を参照してください。
### パラメータ名: `PostInstallHookDocName`
**使用**: オプション。
**デフォルト**: `AWS-Noop`。
`PostInstallHookDocName` パラメータに指定する値は、選択した SSM ドキュメントの名前または Amazon リソースネーム (ARN) です。AWS マネージドドキュメントの名前や、作成したか共有されたカスタム SSM ドキュメントの名前または ARN を指定できます。(別の AWS アカウント から共有されている SSM ドキュメントの場合は、`arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument` などの完全なリソース ARN を指定する必要があります)。
指定した SSM ドキュメントは、`Install with NoReboot` オペレーション後に実行され、再起動前にサードパーティ製の更新プログラムをインストールするためのシェルスクリプトなど、SSM Agent がサポートするアクションを実行します。(アクションの一覧については、「[コマンドドキュメントプラグインリファレンス](documents-command-ssm-plugin-reference.md)」を参照してください)。デフォルトの SSM ドキュメント名は `AWS-Noop` で、マネージドノードに対するオペレーションは実行されません。
カスタム SSM ドキュメントの作成方法については、「[SSM ドキュメントコンテンツを作成する](documents-creating-content.md)」を参照してください。
### パラメータ名: `OnExitHookDocName`
**使用**: オプション。
**デフォルト**: `AWS-Noop`。
`OnExitHookDocName` パラメータに指定する値は、選択した SSM ドキュメントの名前または Amazon リソースネーム (ARN) です。AWS マネージドドキュメントの名前や、作成したか共有されたカスタム SSM ドキュメントの名前または ARN を指定できます。(別の AWS アカウント から共有されている SSM ドキュメントの場合は、`arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument` などの完全なリソース ARN を指定する必要があります)。
指定した SSM ドキュメントは、マネージドノードの再起動オペレーションの後に実行され、パッチ適用オペレーションの完了後にノードの状態を確認するシェルスクリプトなど、SSM Agent がサポートするアクションを実行します。(アクションの一覧については、「[コマンドドキュメントプラグインリファレンス](documents-command-ssm-plugin-reference.md)」を参照してください)。デフォルトの SSM ドキュメント名は `AWS-Noop` で、マネージドノードに対するオペレーションは実行されません。
カスタム SSM ドキュメントの作成方法については、「[SSM ドキュメントコンテンツを作成する](documents-creating-content.md)」を参照してください。