• 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-RunPatchBaseline` AWS Systems Manager は、AWS Systems Manager のツールである Patch Manager 用の Systems Manager ドキュメント (SSM ドキュメント) である `AWS-RunPatchBaseline` をサポートしています。この SSM ドキュメントでは、セキュリティ関連および他のタイプの更新の両方について、マネージドノードにパッチ適用オペレーションを実行します。パッチグループが指定されていない場合、ドキュメントを実行すると、オペレーティングシステムタイプの「デフォルト」として指定されているパッチベースラインが使用されます。それ以外の場合は、パッチグループに関連付けられているパッチベースラインが使用されます。パッチグループの詳細については、「[パッチグループ](patch-manager-patch-groups.md)」を参照してください。 ドキュメント `AWS-RunPatchBaseline` を使用して、オペレーティングシステムとアプリケーションの両方にパッチを適用することができます。(Windows Server では、アプリケーションのサポートは、Microsoft がリリースしたアプリケーションの更新に制限されています)。 このドキュメントでは、Linux macOS、および Windows Server マネージドノードをサポートしています。ドキュメントは、プラットフォーム別に適切なアクションを実行します。 **注記** Patch Manager は、レガシー SSM ドキュメント `AWS-ApplyPatchBaseline` もサポートしています。ただし、このドキュメントが対応するのは Windows マネージドノードのみです。Linux、macOS、および Windows Server マネージドノードでのパッチ適用をサポートしているため、代わりに `AWS-RunPatchBaseline` を使用することをお勧めします。 `AWS-RunPatchBaseline`ドキュメントを使用するには、バージョン 2.0.834.0 以降の SSM Agent が必要です。 ------ #### [ Windows サーバー ] Windows Server マネージドノードの場合、`AWS-RunPatchBaseline` ドキュメントは、PowerShell モジュールをダウンロードして呼び出します。これに伴って、マネージドノードに適用するパッチベースラインのスナップショットがダウンロードされます。このパッチベースラインスナップショットには、Windows Server Update Services (WSUS) サーバーに対してパッチベースラインを照会することによってコンパイルされる承認済みパッチのリストが含まれています。このリストは、Windows Update API に渡され、ここで承認済みパッチのダウンロードとインストールが適切に制御されます。 ------ #### [ Linux ] Linux マネージドノードの場合、`AWS-RunPatchBaseline` ドキュメントは、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` が必要です。 ------ #### [ macOS ] macOS マネージドノードの場合、`AWS-RunPatchBaseline` ドキュメントは、Python モジュールを呼び出します。これに伴って、マネージドノードに適用するパッチベースラインのスナップショットがダウンロードされます。次に、Python サブプロセスがノードで AWS Command Line Interface (AWS CLI) を呼び出し、指定されたパッケージマネージャーのインストールおよび更新情報を取得し、各更新パッケージに適切なパッケージマネージャーを実行します。 ------ 各スナップショットは、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-RunPatchBaseline` ドキュメントで `RebootOption` パラメータが `NoReboot` に設定されている場合、Patch Manager の実行後、マネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。 パッチコンプライアンスデータの表示方法については、「[パッチコンプライアンスについて](compliance-about.md#compliance-monitor-patch)」を参照してください。 ## `AWS-RunPatchBaseline` 個のパラメータ `AWS-RunPatchBaseline` では 6 つのパラメータがサポートされています。`Operation` パラメータは必須です。`InstallOverrideList`、`BaselineOverride`、`RebootOption` の各パラメータはオプションです。`Snapshot-ID` は技術的にはオプションですが、メンテナンスウィンドウを使用せずに `AWS-RunPatchBaseline` を実行する場合はカスタム値を指定することをお勧めします。このドキュメントをメンテナンスウィンドウオペレーションの一部として実行する場合は、Patch Manager がカスタム値を自動的に提供します。 **Topics** + [パラメータ名: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation) + [パラメータ名: `AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id) + [パラメータ名: `Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id) + [パラメータ名: `InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist) + [パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption) + [パラメータ名: `BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride) + [パラメータ名: `StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds) ### パラメータ名: `Operation` **使用**: 必須。 **オプション**: `Scan` \$1 `Install`。 Scan `Scan` オプションを選択すると、`AWS-RunPatchBaseline` はマネージドノードのパッチコンプライアンス状態を確認し、この情報を Patch Manager に返します。`Scan` では、更新のインストールや、マネージドノードの再起動を求めません。その代わりに、このオペレーションでは、承認されたノードに適用可能なアップデートがどこに欠けているかを特定します。 インストール `Install` オプションを選択すると、`AWS-RunPatchBaseline` はマネージドノードに見つからない承認済み更新と適用可能な更新のインストールを試行します。`Install` オペレーションの一部として生成されるパッチコンプライアンス情報には、見つからない更新は示されませんが、更新のインストールが何らかの原因で失敗した場合は「失敗」状態になっている更新がレポートされることがあります。更新がマネージドノードにインストールされるたびに、ノードが再起動され、更新がインストール済みで有効になっていることが確認されます。(例外: `RebootOption` パラメータが `AWS-RunPatchBaseline` ドキュメントの `NoReboot` で設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「[パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)」を参照してください。) Patch Manager がマネージドノードを更新する*前*に、ベースラインルールで指定されているパッチがインストールされている場合、システムが予期したとおりに再起動しないことがあります。この可能性があるのは、パッチがユーザーによって手動でインストールされたか、Ubuntu Server の `unattended-upgrades` パッケージなどの別のプログラムによって自動的にインストールされた場合です。 ### パラメータ名: `AssociationId` **使用**: オプション。 `AssociationId` は、AWS Systems Manager のツールである State Manager の、既存の関連付けの ID です。これは、指定した関連付けにコンプライアンスデータを追加するために Patch Manager で使用します。この関連付けは、[Quick Setup のパッチポリシーでセットアップ](quick-setup-patch-manager.md)されたパッチ適用オペレーションに関連しています。 **注記** `AWS-RunPatchBaseline` では、パッチポリシーベースラインのオーバーライドとともに `AssociationId` 値を指定すると、パッチ適用は `PatchPolicy` オペレーションとして実行され、`AWS:ComplianceItem` で報告される `ExecutionType` 値も `PatchPolicy` です。`AssociationId` 値が指定されていない場合、パッチ適用は `Command` オペレーションとして実行され、送信される `AWS:ComplianceItem` の `ExecutionType` 値のレポートも `Command` です。 使用する関連付けがまだない場合は、[https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) コマンドを実行して関連付けを作成できます。 ### パラメータ名: `Snapshot ID` **使用**: オプション。 `Snapshot ID` は、Patch Manager が使用する一意の ID (GUID) です。この ID により、1 回のオペレーションでパッチを適用するマネージドノードのすべてに同じ承認済みパッチのセットが適用されます。このパラメータは省略可能ですが、次の表に示すようにメンテナンスウィンドウで `AWS-RunPatchBaseline` を実行しているかどうかに応じて、推奨されるベストプラクティスが異なります。 **`AWS-RunPatchBaseline` のベストプラクティス** | モード | ベストプラクティス | 詳細 | | --- | --- | --- | | メンテナンスウィンドウ内で AWS-RunPatchBaseline を実行する | スナップショット ID は指定しないでください。Patch Manager によって指定されます。 | メンテナンスウィンドウを使用して `AWS-RunPatchBaseline` を実行する場合は、独自に生成したスナップショット ID を提供すべきではありません。このシナリオでは、メンテナンスウィンドウの実行 ID に基づく GUID 値が Systems Manager から提供されます。これにより、そのメンテナンスウィンドウでは、`AWS-RunPatchBaseline` のすべての呼び出しで正しい ID が使用されます。 このシナリオで値を指定しないと、パッチベースラインのスナップショットは 3 日以内に有効期限が切れる場合があります。スナップショットの有効期限が切れると、同じ ID を指定しても、別のスナップショットが生成されます。 | | メンテナンスウィンドウ外で AWS-RunPatchBaseline を実行する | スナップショット ID のカスタム GUID 値を生成および指定します。¹ | メンテナンスウィンドウを使用しないで `AWS-RunPatchBaseline` を実行する場合は、パッチベースラインごとに一意のスナップショット ID を生成し指定することをお勧めします (特に、同一のオペレーションで `AWS-RunPatchBaseline` ドキュメントを複数のマネージドノードで実行する場合)。このシナリオで ID を指定しないと、コマンドの送信先のマネージドノードごとに異なるスナップショット ID が Systems Manager で生成されます。これにより、マネージドノード間で異なるパッチセットが指定される場合があります。 例えば、AWS Systems Manager のツールである Run Command を使用して `AWS-RunPatchBaseline` ドキュメントを直接実行し、50 個のマネージドノードのグループをターゲットにしているとします。カスタムスナップショット ID を指定すると、1 つのベースラインスナップショットが作成され、これがすべてのノードの評価とパッチ適用に使用されるため、すべてのノードの状態が一致します。 | | ¹Snapshot ID パラメータの値を生成するには、GUID を生成できる任意のツールを使用できます。たとえば、PowerShell では、`New-Guid` cmdlet を使用して `12345699-9405-4f69-bc5e-9315aEXAMPLE` という形式の GUID を生成できます。 | ### パラメータ名: `InstallOverrideList` **使用**: オプション。 `InstallOverrideList` を使用すると、インストールするパッチのリストに対する https URL または Amazon S3 パス形式の URL を指定できます。このパッチインストールリストは、YAML 形式で管理され、デフォルトのパッチベースラインで指定されたパッチを上書きします。これにより、どのマネージドノードにどのパッチがインストールされているかを、より詳細にコントロールできます。 **重要** `InstallOverrideList` ファイル名には、バックティック (`)、一重引用符 (')、二重引用符 (")、およびドル記号 (\$1) を含めることはできません。 `InstallOverrideList` パラメータを使用する場合のパッチ適用オペレーションの動作は、Linux および macOS マネージドノードと、Windows Server マネージドノードで異なります。Linux および macOS では、パッチがパッチベースラインルールと一致するかどうかにかかわらず、Patch Manager は、ノードで有効になっているリポジトリに存在する `InstallOverrideList` パッチリストに含まれるパッチを適用しようとします。一方、Windows Server ノードでは、`InstallOverrideList` パッチリスト内のパッチは、パッチベースラインルールとも一致する場合にのみ適用されます。 コンプライアンスレポートは、パッチの `InstallOverrideList` リストで指定するものではなく、パッチのベースラインで指定されているものに従ってパッチの状態が反映されることに注意してください。つまり、スキャンオペレーションは `InstallOverrideList` パラメータを無視します。これは、コンプライアンスレポートが、特定のパッチ適用オペレーションで承認されたものではなく、ポリシーに従ってパッチ状態を一貫して反映することを保証するためです。 **注記** IPv6 のみを使用するノードにパッチを適用する場合は、指定された URL がノードから到達可能であることを確認してください。SSM Agent config オプション `UseDualStackEndpoint` が `true` に設定されている場合、S3 の URL を指定するとデュアルスタック S3 クライアントが使用されます。デュアルスタックを使用するためのエージェントの設定の詳細については、「[チュートリアル: IPv6 のみの環境でサーバーにパッチを適用する](patch-manager-server-patching-iPv6-tutorial.md)」を参照してください。 単一のパッチベースラインを使用しながら、`InstallOverrideList` パラメータを使用して、異なるメンテナンスウィンドウスケジュールで異なるタイプのパッチをターゲットグループに適用する方法の詳細については、「[`AWS-RunPatchBaseline` または `AWS-RunPatchBaselineAssociation` で InstallOverrideList パラメータを使用するサンプルシナリオ](patch-manager-override-lists.md)」を参照してください。 **有効な URL 形式** **注記** ファイルが公開されているバケットに格納されている場合は、「https」URL 形式または Amazon S3 パススタイルの URL を指定できます。ファイルがプライベートバケットに格納されている場合は、Amazon S3 パススタイルの URL を指定する必要があります。 + **https URL 形式**: ``` https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml ``` + **Amazon S3 パス形式の URL** : ``` s3://amzn-s3-demo-bucket/my-windows-override-list.yaml ``` **有効な YAML コンテンツ形式** リストにパッチを指定するために使用する書式は、マネージドノードのオペレーティングシステムによって異なります。ただし、一般的な形式は次のとおりです。 ``` patches: - id: '{patch-d}' title: '{patch-title}' {additional-fields}:{values} ``` YAML ファイルにフィールドを追加することはできますが、パッチオペレーション中は無視されます。 さらに、S3 バケットのリストを追加または更新する前に、YAML ファイルのフォーマットが有効であることを確認することをお勧めします。YAML 形式の詳細については、[yaml.org](http://www.yaml.org) を参照してください。検証ツールのオプションについては、ウェブで「yaml 形式の検証」を検索します。 ------ #### [ Linux ] **id** **id** フィールドは必須です。これにより、パッケージ名とアーキテクチャを使用してパッチを指定します。例: `'dhclient.x86_64'`。ID にワイルドカードを使用すると、複数のパッケージを指定できます。例: `'dhcp*'` および `'dhcp*1.*'`。 **タイトル** **title** フィールドはオプションですが、Linux システムでは追加のフィルタリング機能を提供します。**title** を使用する場合は、次のいずれかの形式でパッケージのバージョン情報を含める必要があります。 YUM/SUSE Linux Enterprise Server (SLES): ``` {name}.{architecture}:{epoch}:{version}-{release} ``` APT ``` {name}.{architecture}:{version} ``` Linux のパッチタイトルでは、任意の位置に 1 つ以上のワイルドカードを使用して一致するパッケージの数を拡張することができます。例: `'*32:9.8.2-0.*.rc1.57.amzn1'`。 例: + apt パッケージのバージョン 1.2.25 が現在マネージドノードにインストールされていますが、バージョン 1.2.27 が利用できるようになりました。 + apt.amd64 バージョン 1.2.27 をパッチリストに追加します。これは apt utils.amd64 バージョン 1.2.27 に依存しますが、apt-utils.amd64 バージョン 1.2.25 がリストで指定されています。 この場合、apt バージョン 1.2.27 のインストールはブロックされ、「Failed-NonCompliant」として報告されます。 ------ #### [ Windows サーバー ] **id** **id** フィールドは必須です。Microsoft Knowledge Base ID (KB2736693 など) および Microsoft Security Bulletin ID (MS17-023 など) を使用してパッチを指定する場合に使用します。 Windows 用のパッチリストで提供する他のフィールドはオプションであり、情報提供のみを目的としています。特定のパッチに関する詳細情報を提供するために、**title**、**classification**、**severity** などの追加フィールドを使用することができます。 ------ #### [ macOS ] **id** **id** フィールドは必須です。**id** フィールドの値は、`{package-name}.{package-version}` 形式または \$1package\$1name\$1 形式のいずれかを使用して指定することができます。 ------ **サンプルパッチリスト** + **Amazon Linux 2** ``` patches: - id: 'kernel.x86_64' - id: 'bind*.x86_64' title: '39.11.4-26.P2.amzn2.5.2' id: 'glibc*' - id: 'dhclient*' title: '*4.2.5-58.amzn2' - id: 'dhcp*' title: '*4.2.5-77.amzn2' ``` + **Debian Server** ``` patches: - id: 'apparmor.amd64' title: '2.10.95-0ubuntu2.9' - id: 'cryptsetup.amd64' title: '*2:1.6.6-5ubuntu2.1' - id: 'cryptsetup-bin.*' title: '*2:1.6.6-5ubuntu2.1' - id: 'apt.amd64' title: '*1.2.27' - id: 'apt-utils.amd64' title: '*1.2.25' ``` + **macOS** ``` patches: - id: 'XProtectPlistConfigData' - id: 'MRTConfigData.1.61' - id: 'Command Line Tools for Xcode.11.5' - id: 'Gatekeeper Configuration Data' ``` + **Oracle Linux** ``` patches: - id: 'audit-libs.x86_64' title: '*2.8.5-4.el7' - id: 'curl.x86_64' title: '*.el7' - id: 'grub2.x86_64' title: 'grub2.x86_64:1:2.02-0.81.0.1.el7' - id: 'grub2.x86_64' title: 'grub2.x86_64:1:*-0.81.0.1.el7' ``` + **Red Hat Enterprise Linux (RHEL)** ``` patches: - id: 'NetworkManager.x86_64' title: '*1:1.10.2-14.el7_5' - id: 'NetworkManager-*.x86_64' title: '*1:1.10.2-14.el7_5' - id: 'audit.x86_64' title: '*0:2.8.1-3.el7' - id: 'dhclient.x86_64' title: '*.el7_5.1' - id: 'dhcp*.x86_64' title: '*12:5.2.5-68.el7' ``` + **SUSE Linux Enterprise Server (SLES)** ``` patches: - id: 'amazon-ssm-agent.x86_64' - id: 'binutils' title: '*0:2.26.1-9.12.1' - id: 'glibc*.x86_64' title: '*2.19*' - id: 'dhcp*' title: '0:4.3.3-9.1' - id: 'lib*' ``` + **Ubuntu Server ** ``` patches: - id: 'apparmor.amd64' title: '2.10.95-0ubuntu2.9' - id: 'cryptsetup.amd64' title: '*2:1.6.6-5ubuntu2.1' - id: 'cryptsetup-bin.*' title: '*2:1.6.6-5ubuntu2.1' - id: 'apt.amd64' title: '*1.2.27' - id: 'apt-utils.amd64' title: '*1.2.25' ``` + **Windows** ``` patches: - id: 'KB4284819' title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)' - id: 'KB4284833' - id: 'KB4284835' title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)' - id: 'KB4284880' - id: 'KB4338814' ``` ### パラメータ名: `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` に更新されます。 `NoReboot` オプションは、オペレーティングシステムレベルの再起動のみを防ぎます。サービスレベルの再起動は、パッチ適用プロセスの一環として引き続き発生する可能性があります。例えば、Docker が更新されると、`NoReboot` が有効にされていても Amazon Elastic Container Service などの依存サービスが自動的に再起動される場合があります。中断してはならない重要なサービスがある場合は、一時的にインスタンスをサービスから削除したり、メンテナンス期間中にパッチ適用をスケジュールしたりするなどの追加の対策を検討してください。 **パッチのインストール追跡ファイル**: パッチ (特にシステムの最後の再起動以降にインストールされたパッチ) のインストールを追跡するために、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` ### パラメータ名: `BaselineOverride` **使用**: オプション。 `BaselineOverride` パラメータを使用して、実行時にパッチ定義設定を定義できます。このベースラインオーバーライドは、S3 バケット内の JSON オブジェクトとして維持されます。これにより、パッチ適用操作で、デフォルトのパッチベースラインのルールを適用する代わりに、ホストオペレーティングシステムに一致する指定されたベースラインが使用されるようにします。 **重要** `BaselineOverride` ファイル名には、バックティック (`)、一重引用符 (')、二重引用符 (")、およびドル記号 (\$1) を含めることはできません。 `BaselineOverride` パラメータの使用方法の詳細については、「[BaselineOverride パラメータの使用](patch-manager-baselineoverride-parameter.md)」を参照してください。 ### パラメータ名: `StepTimeoutSeconds` **使用**: 必須。 コマンドが失敗したとみなされるまでの経過時間 (秒、1～36,000 秒 (10 時間))。