• 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-RunPatchBaselineAssociation`
`AWS-RunPatchBaseline` ドキュメントと同様に、`AWS-RunPatchBaselineAssociation` では、セキュリティ関連および他のタイプの更新の両方について、インスタンスにパッチ適用オペレーションを実行します。また、ドキュメント `AWS-RunPatchBaselineAssociation` を使用して、オペレーティングシステムとアプリケーションの両方にパッチを適用することもできます。(Windows Server では、アプリケーションのサポートは、Microsoft がリリースしたアプリケーションの更新に制限されています)。
このドキュメントでは、Linux、macOS、および Windows Server 用の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスがサポートされています。[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境内の非 EC2 ノードは、サポートされていません。このドキュメントでは、各プラットフォームに対して適切なアクションを実行し、Linux インスタンスおよび macOS インスタンスでは Python モジュールを、Windows インスタンスでは PowerShell モジュールを呼び出します。
ただし、`AWS-RunPatchBaselineAssociation` は、次の点で `AWS-RunPatchBaseline` とは異なります。
+ `AWS-RunPatchBaselineAssociation` は、主に AWS Systems Manager のツールである [Quick Setup](systems-manager-quick-setup.md) を使用して作成された State Manager 関連付けでの使用を目的としています。具体的には、Quick Setup ホスト管理設定タイプを使用する場合、**[Scan instances for missing patches daily]** (不足しているパッチがないか毎日インスタンスをスキャンする) オプションを選択すると、システムはオペレーションに `AWS-RunPatchBaselineAssociation` を使用します。
ただし、ほとんどの場合、独自のパッチ適用オペレーションを設定する場合は、`AWS-RunPatchBaselineAssociation` の代わりに、[`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) または [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) を選択する必要があります。
+ `AWS-RunPatchBaselineAssociation` ドキュメントを使用すると、ドキュメントの `BaselineTags` パラメータフィールドでタグのキーペアを指定できます。AWS アカウント内のカスタムパッチベースラインがこれらのタグを共有している場合、AWS Systems Manager のツールである Patch Manager は、ターゲットインスタンスでの実行時に、オペレーティングシステムタイプに対して現在指定されている「デフォルト」パッチベースラインではなく、そのタグ付きベースラインを使用します。
**注記**
Quick Setup を使用してセットアップした以外のパッチオペレーションで `AWS-RunPatchBaselineAssociation` を使用することを選択し、そのオプションの `BaselineTags` パラメータを使用する場合は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの[インスタンスプロファイル](setup-instance-permissions.md)に対する追加のアクセス許可を指定する必要があります。詳細については、「[パラメータ名: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)」を参照してください。
次の形式はどちらも `BaselineTags` パラメータに対して有効です。
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**重要**
タグキーと値には、バックティック (`)、一重引用符 (')、二重引用符 (")、およびドル記号 (\$1) を含めることはできません。
+ `AWS-RunPatchBaselineAssociation` の実行時に収集されるパッチコンプライアンスデータは、`PutComplianceItems` によって使用される `PutInventory` コマンドではなく、 `AWS-RunPatchBaseline` API コマンドを使用して記録されます。この違いは、特定の*関連付け*ごとに保存およびレポートされるパッチコンプライアンス情報であることを意味します。この関連付けの外部で生成されたパッチコンプライアンスデータは上書きされません。
+ `AWS-RunPatchBaselineAssociation` の実行後にレポートされるパッチコンプライアンス情報は、インスタンスが準拠しているかどうかを示します。次の AWS Command Line Interface ( AWS CLI )コマンドの出力で示されているように、パッチレベルの詳細は含まれません。コマンドはコンプライアンスタイプとして `Association` でフィルタリングされます。
```
aws ssm list-compliance-items \
--resource-ids "i-02573cafcfEXAMPLE" \
--resource-types "ManagedInstance" \
--filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
--region us-east-2
```
システムが以下のような情報をレスポンスします。
```
{
"ComplianceItems": [
{
"Status": "NON_COMPLIANT",
"Severity": "UNSPECIFIED",
"Title": "MyPatchAssociation",
"ResourceType": "ManagedInstance",
"ResourceId": "i-02573cafcfEXAMPLE",
"ComplianceType": "Association",
"Details": {
"DocumentName": "AWS-RunPatchBaselineAssociation",
"PatchBaselineId": "pb-0c10e65780EXAMPLE",
"DocumentVersion": "1"
},
"ExecutionSummary": {
"ExecutionTime": 1590698771.0
},
"Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE"
}
]
}
```
`AWS-RunPatchBaselineAssociation` ドキュメントのパラメータとしてタグのキーペア値が指定されている場合、Patch Manager は、オペレーティングシステムのタイプと一致し、同じタグのキーペアでタグ付けされているカスタムパッチベースラインを検索します。この検索は、現在指定されているデフォルトのパッチベースライン、またはパッチグループに割り当てられたベースラインに制限されません。指定されたタグを持つベースラインが見つからない場合は、Patch Managerはパッチグループを検索します (`AWS-RunPatchBaselineAssociation` を実行するコマンドで指定されている場合)。一致するパッチグループがない場合、Patch Managerはオペレーティングシステムのアカウントにデフォルトに設定されているパッチベースラインを使用します。
`AWS-RunPatchBaselineAssociation` ドキュメントで指定されているタグを持つパッチベースラインが複数見つかった場合、Patch Managerは、オペレーションを続行するために、そのキーと値のペアでタグ付けできるパッチベースラインは 1 つだけであることを示すエラーメッセージを返します。
**注記**
Linux ノードでは、各ノードタイプに適切なパッケージマネージャーを使用してパッケージをインストールします。
Amazon Linux 2、Oracle Linux、および RHEL インスタンスでは、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` が必要です
Debian Server インスタンスと Ubuntu Server インスタンスでは、APT を使用します。APT のオペレーションでは、Patch Manager には、サポートされているバージョン (3.0～3.12) の `Python 3` が必要です。
スキャンが完了した後、またはすべての承認済み更新と該当する更新がインストールされた後、必要に応じて再起動されると、パッチコンプライアンス情報がインスタンスで生成されてパッチコンプライアンスサービスにレポートされます。
**注記**
`AWS-RunPatchBaselineAssociation` ドキュメントで `RebootOption` パラメータが `NoReboot` に設定されている場合、Patch Managerの実行後、インスタンスは再起動されません。詳細については、「[パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)」を参照してください。
パッチコンプライアンスデータの表示方法については、「[パッチコンプライアンスについて](compliance-about.md#compliance-monitor-patch)」を参照してください。
## `AWS-RunPatchBaselineAssociation` 個のパラメータ
`AWS-RunPatchBaselineAssociation` は 5 つのパラメータをサポートしています。`Operation` および `AssociationId` パラメータが必要です。`InstallOverrideList`、`RebootOption` および `BaselineTags` パラメータはオプションです。
**Topics**
+ [パラメータ名: `Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [パラメータ名: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [パラメータ名: `AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [パラメータ名: `InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)
### パラメータ名: `Operation`
**使用**: 必須。
**オプション**: `Scan` \$1 `Install`。
Scan
`Scan` オプションを選択すると、`AWS-RunPatchBaselineAssociation` はインスタンスのパッチコンプライアンス状態を確認し、この情報を Patch Manager に返します。`Scan` では、更新のインストールや、インスタンスの再起動を求めません。代わりに、承認済み更新でインスタンスに適用可能なものが見つからない個所を示します。
インストール
`Install` オプションを選択すると、`AWS-RunPatchBaselineAssociation` はインスタンスに見つからない承認済み更新と適用可能な更新のインストールを試行します。`Install` オペレーションの一部として生成されるパッチコンプライアンス情報には、見つからない更新は示されませんが、更新のインストールが何らかの原因で失敗した場合は「失敗」状態になっている更新がレポートされることがあります。更新がインスタンスにインストールされるたびに、インスタンスが再起動され、更新がインストール済みで有効になっていることが確認されます。（例外: `RebootOption` パラメータが `AWS-RunPatchBaselineAssociation` ドキュメントの `NoReboot` で設定されている場合、Patch Manager の実行後にインスタンスは再起動されません。詳細については、「[パラメータ名: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)」を参照してください。）
Patch Managerがインスタンスを更新する*前*に、ベースラインルールで指定されているパッチがインストールされている場合、システムが予期したとおりに再起動しないことがあります。この可能性があるのは、パッチがユーザーによって手動でインストールされたか、Ubuntu Server の `unattended-upgrades` パッケージなどの別のプログラムによって自動的にインストールされた場合です。
### パラメータ名: `BaselineTags`
**使用**: オプション。
`BaselineTags` は、一意のタグのキーと値のペアで、選択して個々のカスタムパッチベースラインに割り当てます。このパラメータには、1 つ以上の値を指定できます。次の形式はどちらも有効です。
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**重要**
タグキーと値には、バックティック (`)、一重引用符 (')、二重引用符 (")、およびドル記号 (\$1) を含めることはできません。
Patch Manager は、`BaselineTags` の値を使用して、1 回のオペレーションでパッチを適用するインスタンスのすべてに同じ承認済みパッチのセットが適用されるようにします。 パッチ適用オペレーションが実行すると、Patch Manager は、オペレーティングシステムのタイプのパッチベースラインが `BaselineTags` で指定したものと同じキーと値のペアでタグ付けされているか確認します。一致するものがある場合は、このカスタムパッチベースラインが使用されます。一致するものがない場合、パッチ適用オペレーションに指定されたパッチグループに従って、パッチベースラインが識別されます。存在しない場合は、そのオペレーティングシステムの AWS マネージド定義済みパッチベースラインが使用されます。
**追加のアクセス許可要件**
Quick Setup を使用してセットアップした以外のパッチオペレーションで `AWS-RunPatchBaselineAssociation` を使用し、オプションの `BaselineTags` パラメータを使用する場合は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの[インスタンスプロファイル](setup-instance-permissions.md)に対する以下のアクセス許可を追加する必要があります。
**注記**
Quick Setup と `AWS-RunPatchBaselineAssociation` は、オンプレミスのサーバーと仮想マシン (VM) をサポートしていません。
```
{
"Effect": "Allow",
"Action": [
"ssm:DescribePatchBaselines",
"tag:GetResources"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetPatchBaseline",
"ssm:DescribeEffectivePatchesForPatchBaseline"
],
"Resource": "patch-baseline-arn"
}
```
*patch-baseline-arn* を、アクセス許可を付与するパッチベースラインの Amazon リソースネーム (ARN) に、`arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE` 形式で置き換えます。
### パラメータ名: `AssociationId`
**使用**: 必須。
`AssociationId` は、AWS Systems Manager のツールである State Manager の、既存の関連付けの ID です。これは、指定した関連付けにコンプライアンスデータを追加するために Patch Manager で使用します。この関連付けは、[Quick Setup で作成されたホスト管理設定](quick-setup-host-management.md)で有効になっているパッチ `Scan` オペレーションに関連しています。パッチ適用の結果をインベントリコンプライアンスデータではなく関連付けコンプライアンスデータとして送信することで、インスタンスの既存のインベントリコンプライアンス情報は、パッチ適用オペレーションの後やその他の関連付け ID に対して上書きされません。使用する関連付けがまだない場合は、[https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) コマンドを実行して関連付けを作成できます。例えば、次のようになります。
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-RunPatchBaselineAssociation" \
--association-name "MyPatchHostConfigAssociation" \
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" \
--parameters "Operation=Scan" \
--schedule-expression "cron(0 */30 * * * ? *)" \
--sync-compliance "MANUAL" \
--region us-east-2
```
------
#### [ Windows サーバー ]
```
aws ssm create-association ^
--name "AWS-RunPatchBaselineAssociation" ^
--association-name "MyPatchHostConfigAssociation" ^
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" ^
--parameters "Operation=Scan" ^
--schedule-expression "cron(0 */30 * * * ? *)" ^
--sync-compliance "MANUAL" ^
--region us-east-2
```
------
### パラメータ名: `InstallOverrideList`
**使用**: オプション。
`InstallOverrideList` を使用して、インストールするパッチのリストに対する https URL または Amazon Simple Storage Service (Amazon S3) パス形式の URL を指定します。このパッチインストールリストは、YAML 形式で管理され、デフォルトのパッチベースラインで指定されたパッチを上書きします。これにより、どのインスタンスにどのパッチがインストールされているかを、より詳細にコントロールできます。
**重要**
`InstallOverrideList` ファイル名には、バックティック (`)、一重引用符 (')、二重引用符 (")、およびドル記号 (\$1) を含めることはできません。
`InstallOverrideList` パラメータを使用する場合のパッチ適用オペレーションの動作は、Linux および macOS マネージドノードと、Windows Server マネージドノードで異なります。Linux および macOS では、パッチがパッチベースラインルールと一致するかどうかにかかわらず、Patch Manager は、ノードで有効になっているリポジトリに存在する `InstallOverrideList` パッチリストに含まれるパッチを適用しようとします。一方、Windows Server ノードでは、`InstallOverrideList` パッチリスト内のパッチは、パッチベースラインルールとも一致する場合にのみ適用されます。
コンプライアンスレポートは、パッチの `InstallOverrideList` リストで指定するものではなく、パッチのベースラインで指定されているものに従ってパッチの状態が反映されることに注意してください。つまり、スキャンオペレーションは `InstallOverrideList` パラメータを無視します。これは、コンプライアンスレポートが、特定のパッチ適用オペレーションで承認されたものではなく、ポリシーに従ってパッチ状態を一貫して反映することを保証するためです。
**有効な URL 形式**
**注記**
ファイルが公開されているバケットに格納されている場合は、「https」URL 形式または Amazon S3 パススタイルの URL を指定できます。ファイルがプライベートバケットに格納されている場合は、Amazon S3 パススタイルの URL を指定する必要があります。
+ **https URL 形式の例**:
```
https://s3.amazonaws.com/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 形式の検証」を検索します。
+ Microsoft Windows
**id**
**id** フィールドは必須です。Microsoft Knowledge Base ID (KB2736693 など) および Microsoft Security Bulletin ID (MS17-023 など) を使用してパッチを指定する場合に使用します。
Windows 用のパッチリストで提供する他のフィールドはオプションであり、情報提供のみを目的としています。特定のパッチに関する詳細情報を提供するために、**title**、**classification**、**severity** などの追加フィールドを使用することができます。
+ Linux
**id**
**id** フィールドは必須です。これにより、パッケージ名とアーキテクチャを使用してパッチを指定します。例: `'dhclient.x86_64'`。ID にワイルドカードを使用すると、複数のパッケージを指定できます。例: `'dhcp*'` および `'dhcp*1.*'`。
**title**
**title** フィールドはオプションですが、Linux システムでは追加のフィルタリング機能を提供します。**title** を使用する場合は、次のいずれかの形式でパッケージのバージョン情報を含める必要があります。
YUM/Red Hat Enterprise Linux (RHEL):
```
{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」として報告されます。
**その他のフィールド**
Linux 用のパッチリストで提供する他のフィールドはオプションであり、情報提供のみを目的としています。特定のパッチに関する詳細情報を提供するために、**classification**、**severity** などの追加フィールドを使用することができます。
**サンプルパッチリスト**
+ **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'
```
+ **APT**
```
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'
```
+ **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'
```
+ **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` を選択します。
**重要**
`NoReboot` オプションは、オペレーティングシステムレベルの再起動のみを防ぎます。サービスレベルの再起動は、パッチ適用プロセスの一環として引き続き発生する可能性があります。例えば、Docker が更新されると、`NoReboot` が有効にされていても Amazon Elastic Container Service などの依存サービスが自動的に再起動される場合があります。中断してはならない重要なサービスがある場合は、一時的にインスタンスをサービスから削除したり、メンテナンス期間中にパッチ適用をスケジュールしたりするなどの追加の対策を検討してください。
**重要**
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` オペレーション中にパッチをインストールした場合でも、インスタンスは再起動されません。このオプションは、パッチ適用後にインスタンスを再起動する必要がないことがわかっている場合や、パッチ適用操作の再起動によって中断されないアプリケーションまたはプロセスがインスタンスで実行されている場合に便利です。また、メンテナンスウィンドウを使用するなど、インスタンスの再起動のタイミングをより詳細に制御する場合にも役立ちます。
**パッチのインストール追跡ファイル**: パッチ (特にシステムの最後の再起動以降にインストールされたパッチ) のインストールを追跡するために、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`