• 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 Patch Manager のチュートリアル
このセクションのチュートリアルでは、AWS Systems Manager のツールである Patch Manager をいくつかのパッチ適用シナリオで使用する方法を示します。
**Topics**
+ [チュートリアル: IPv6 のみの環境でサーバーにパッチを適用する](patch-manager-server-patching-iPv6-tutorial.md)
+ [チュートリアル: コンソールを使用して Windows サービスパックをインストールするためのパッチベースラインを作成する](patch-manager-windows-service-pack-patch-baseline-tutorial.md)
+ [チュートリアル: アプリケーションの依存関係の更新、マネージドノードへのパッチ適用、およびアプリケーション固有のヘルスチェックの実行](aws-runpatchbaselinewithhooks-tutorial.md)
+ [チュートリアル: AWS CLI を使用してサーバー環境にパッチを適用する](patch-manager-patch-servers-using-the-aws-cli.md)
# チュートリアル: IPv6 のみの環境でサーバーにパッチを適用する
Patch Manager は、IPv6 のみの環境でのノードのパッチ適用をサポートします。SSM Agent 設定を更新することで、IPv6 サービスエンドポイントのみを呼び出すようにパッチ適用オペレーションを設定できます。
**IPv6 のみの環境でサーバーにパッチを適用するには**
1. SSM Agent のバージョン 3.3270.0 以降がマネージドノードにインストールされていることを確認します。
1. マネージドノードで、SSM Agent 設定ファイルに移動します。`amazon-ssm-agent.json` ファイルは次のディレクトリにあります。
+ Linux: `/etc/amazon/ssm/`
+ macOS: `/opt/aws/ssm/`
+ Windows Server: `C:\Program Files\Amazon\SSM`
`amazon-ssm-agent.json` がまだ存在しない場合は、同じディレクトリの `amazon-ssm-agent.json.template` の内容を `amazon-ssm-agent.json` にコピーします。
1. 次のエントリを更新して正しいリージョンを設定し、`UseDualStackEndpoint` を `true` に設定します。
```
{
--------
"Agent": {
"Region": "region",
"UseDualStackEndpoint": true
},
--------
}
```
1. オペレーティングシステムに適したコマンドを使用して SSM Agent サービスを再起動します。
+ Linux: `sudo systemctl restart amazon-ssm-agent`
+ Snap を使用する Ubuntu Server: `sudo snap restart amazon-ssm-agent`
+ macOS: `sudo launchctl stop com.amazon.aws.ssm` の前の `sudo launchctl start com.amazon.aws.ssm`
+ Windows Server: `Stop-Service AmazonSSMAgent` の前の `Start-Service AmazonSSMAgent`
オペレーティングシステムごとのコマンドの完全なリストについては、「[SSM Agent ステータスの確認とエージェントの起動](ssm-agent-status-and-restart.md)」を参照してください。
1. パッチ適用オペレーションを実行して、IPv6 のみの環境でパッチ適用オペレーションが正常に完了することを確認します。パッチを適用するノードがパッチソースに接続されていることを確認します。パッチ適用の実行からの Run Command 出力をチェックして、アクセスできないリポジトリに関する警告を確認できます。IPv6 のみの環境で実行されているノードにパッチを適用する場合は、ノードがパッチソースに接続されていることを確認します。パッチ適用の実行からの Run Command 出力をチェックして、アクセスできないリポジトリに関する警告を確認できます。DNF ベースのオペレーティングシステムでは、 `/etc/dnf/dnf.conf` で `skip_if_unavailable` オプションが `True` に設定されている場合、使用できないリポジトリをパッチ適用中にスキップするように設定できます。DNF ベースのオペレーティングシステムには、Amazon Linux 2023、Red Hat Enterprise Linux 8 以降のバージョン、Oracle Linux 8 以降のバージョン、Rocky Linux、AlmaLinux、および CentOS 8 以降のバージョンが含まれます。Amazon Linux 2023 では、`skip_if_unavailable` オプションはデフォルトで `True` に設定されています。
**注記**
Install Override List または Baseline Override 機能を使用する場合は、指定された URL がノードから到達可能であることを確認してください。SSM Agent config オプション `UseDualStackEndpoint` が `true` に設定されている場合、S3 の URL を指定するとデュアルスタック S3 クライアントが使用されます。
# チュートリアル: コンソールを使用して Windows サービスパックをインストールするためのパッチベースラインを作成する
カスタムパッチベースラインを作成するときに、サポートされているパッチのすべて、一部、または 1 つのタイプのみをインストールするように指定できます。
Windows のパッチベースラインでは、パッチ適用の更新をサービスパックのみに制限するために、唯一の [**分類**] オプションとして `ServicePacks` を選択できます。サービスパックは、更新プログラムが Windows Update または Windows Server Update サービス (WSUS) で利用可能であれば、AWS Systems Manager のツールである Patch Manager によって自動的にインストールできます。
パッチベースラインを構成して、すべての Windows バージョンのサービスパックをインストールするか、Windows 7 や Windows Server 2016 などの特定のバージョンのサービスパックだけをインストールするかを制御できます。
Windows マネージドノードにすべてのサービスパックをインストールするためにのみ使用されるカスタム パッチベースラインを作成するには、以下の手順を使用します。
**Windows サービスパックをインストールするためのパッチベースラインを作成するには (コンソール)**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[Patch Manager]** を選択します。
1. **[パッチベースライン]** タブを選択し、**[パッチベースラインの作成]** を選択します。
1. [**Name (名前)**] フィールドに、新しいパッチベースラインの名前 (例: `MyWindowsServicePackPatchBaseline`) を入力します。
1. (オプション) [**Description (説明)**] に、パッチベースラインの説明を入力します。
1. [**Operating system (オペレーティングシステム)**] で、`Windows` を選択します。
1. 作成してすぐに、このパッチベースラインを Windows のデフォルトとして使用する場合は、[**Set this patch baseline as the default patch baseline for Windows Server instances (このパッチベースラインを Windows Server インスタンスのデフォルトのパッチベースラインにする)**] を選択します。
**注記**
このオプションは、2022 年 12 月 22 日の[パッチポリシー](patch-manager-policies.md)リリース前に初めて Patch Manager にアクセスした場合にのみ使用できます。
既存のパッチベースラインのデフォルト設定の詳細については、「[既存のパッチベースラインをデフォルトとして設定する](patch-manager-default-patch-baseline.md)」を参照してください。
1. [**Approval rules for operating systems (オペレーティングシステムの承認ルール)**] セクションで、フィールドを使用して 1 つ以上の自動承認ルールを作成します。
+ **[製品]**: 承認ルールが適用されるオペレーティングシステムのバージョン (`WindowsServer2012` など)。1 つ、複数、またはサポートされているすべてのバージョンの Windows を選択できます。デフォルトの選択は `All` です。
+ **分類**: `ServicePacks` を選択します。
+ [**Severity (重要度)**]: ルールが適用されるパッチの重要度の値。ルールによってすべてのサービスパックが含まれるようにするには、`All` を選択します。
+ [**Auto-approval (自動承認)**]: 自動承認のためにパッチを選択する方法。
+ **[Approve patches after a specified number of days]** (指定した日数後にパッチを承認): パッチがリリースまたは更新されてから、自動的に承認されるまで Patch Manager が待機する日数。ゼロ (0) から 360 の任意の整数を入力できます。ほとんどのシナリオでは、待機日数を 100 日以内にすることをお勧めします。
+ **[Approve patches released up to a specific date]** (特定の日付までにリリースされたパッチを承認): Patch Manager がその日付以前にリリースまたは最後に更新されたすべてのパッチを自動的に適用するパッチのリリース日。例えば、2023 年 7 月 7 日を指定した場合、リリース日または最後の更新日が 2023 年 7 月 8 日以降であるパッチは、自動的にインストールされません。
+ (オプション) [**Compliance reporting (コンプライアンスレポート)**]: ベースラインで承認されたサービスパックに割り当てる重要度 (`High` など)。
**注記**
コンプライアンスレポートレベルを指定し、承認されたサービスパックのパッチ状態が `Missing` として報告された場合、パッチベースラインで報告されるコンプライアンス全体の重要度は、指定した重要度レベルになります。
1. (オプション) [**Manage tags (タグの管理)**] で、1 つ以上のタグキーの名前と値のペアをパッチベースラインに適用します。
タグは、リソースに割り当てるオプションのメタデータです。タグを使用すると、目的、所有者、環境などのさまざまな方法でリソースを分類できます。サービスパックの更新専用のこのパッチベースラインでは、次のようなキーと値のペアを指定できます。
+ `Key=OS,Value=Windows`
+ `Key=Classification,Value=ServicePacks`
1. [**Create patch baseline**] を選択します。
# チュートリアル: アプリケーションの依存関係の更新、マネージドノードへのパッチ適用、およびアプリケーション固有のヘルスチェックの実行
多くの場合、マネージドノードは、最新のソフトウェア更新プログラムでパッチを適用した後に再起動する必要があります。ただし、安全対策を講じずに本番環境でノードを再起動すると、アラームの発動、不正なメトリクス データの記録、データ同期の中断など、いくつかの問題が発生する可能性があります。
このチュートリアルでは、AWS Systems Manager ドキュメント (SSM ドキュメント) `AWS-RunPatchBaselineWithHooks` を使用して、このような問題を回避する方法を学習します。これにより、複雑なマルチステップのパッチオペレーションを実現し、以下のことを達成できます。
1. アプリケーションへの新しい接続を防止
1. オペレーティングシステムの更新のインストール
1. アプリケーションのパッケージの依存関係の更新
1. システムの再起動
1. アプリケーション固有のヘルスチェックの実行
この例では、インフラストラクチャを次のようにセットアップしました。
+ 対象の仮想マシンは、マネージドノードとして Systems Manager に登録されます。
+ `Iptables` はローカルファイアウォールとして使用されます。
+ マネージドノードでホストされているアプリケーションは、ポート 443 で実行されています。
+ マネージドノードでホストされるアプリケーションは `nodeJS` アプリケーションです。
+ マネージドノードでホストされるアプリケーションは、pm2 プロセスマネージャーによって管理されます。
+ アプリケーションには、指定したヘルスチェックエンドポイントが既に存在します。
+ アプリケーションのヘルスチェックエンドポイントは、エンドユーザー認証を必要としません。エンドポイントにより、可用性を確立する際に組織の要件を満たすヘルスチェックを行うことが可能になります。(実際の環境では、`nodeJS` アプリケーションが実行中であり、リクエストをリッスンできることを確認するだけで十分な場合があります。また、キャッシュレイヤーまたはデータベースレイヤーへの接続が既に確立されていることを確認する必要があります)。
このチュートリアルの例は、デモンストレーションのみを目的としており、本番環境にそのまま実装することを意図していません。また、Systems Manager のツールである Patch Manager のライフサイクルフック機能は、`AWS-RunPatchBaselineWithHooks` ドキュメントとともに他の多数のシナリオをサポートできることに注意してください。次にいくつかの例を示します。
+ マネージドノードの再起動後にパッチを適用して再起動する前に、メトリクスレポート エージェントを停止します。
+ パッチを適用する前に、CRM または PCS クラスターからマネージドノードをデタッチし、ノードの再起動後に再アタッチします。
+ オペレーティングシステム (OS) の更新が適用された後、マネージドノードが再起動する前に、Windows Server マシン上のサードパーティーソフトウェア (Java、Tomcat、Adobe アプリケーションなど) を更新します。
**アプリケーションの依存関係を更新し、マネージドノードにパッチを適用し、アプリケーション固有のヘルスチェックを実行するには**
1. preinstallation スクリプトの SSM ドキュメントを次の内容で作成し、`NodeJSAppPrePatch` と名前を付けます。*your\$1application* をアプリケーションの名前に置き換えます。
このスクリプトは、新しい受信リクエストを直ちにブロックし、既にアクティブなリクエストが完了するまで 5 秒間待ってからパッチ適用操作を開始します。`sleep` オプションでは、受信リクエストが完了するのに通常かかる秒数よりも長い秒数を指定します。
```
# exit on error
set -e
# set up rule to block incoming traffic
iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1
# wait for current connections to end. Set timeout appropriate to your application's latency
sleep 5
# Stop your application
pm2 stop your_application
```
SSM ドキュメントの作成の詳細については、「[SSM ドキュメントコンテンツを作成する](documents-creating-content.md)」を参照してください。
1. postinstall スクリプト用に次の内容を含む別の SSM ドキュメントを作成し、アプリケーションの依存関係を更新し、`NodeJSAppPostPatch` と名前を付けます。*/your/application/path* をお使いのアプリケーションへのパスに置き換えます。
```
cd /your/application/path
npm update
# you can use npm-check-updates if you want to upgrade major versions
```
1. アプリケーションをバックアップし、ヘルスチェックを実行するには、`onExit` スクリプト用に次の内容を含む別の SSM ドキュメントを作成します。この SSM ドキュメント `NodeJSAppOnExitPatch` の名前を付けます。*your\$1application* をアプリケーションの名前に置き換えます。
```
# exit on error
set -e
# restart nodeJs application
pm2 start your_application
# sleep while your application starts and to allow for a crash
sleep 10
# check with pm2 to see if your application is running
pm2 pid your_application
# re-enable incoming connections
iptables -D INPUT -j DROP -p tcp --syn --destination-port
# perform health check
/usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1
```
1. AWS Systems Manager のツールである State Manager で関連付けを作成し、以下の手順を実行してオペレーションを発行します。
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、[**State Manager**] を選択し、[**Create association (関連付けの作成)**] を選択します。
1. [**Name (名前)**] に、関連付けの目的を特定するのに役立つ名前を指定します。
1. [**Document (ドキュメント)**] リストで、[`AWS-RunPatchBaselineWithHooks`] を選択します。
1. [**Operation (オペレーション)**] で、[**Install (インストール)**] を選択します。
1. (オプション) [**Snapshot Id**] では、GUID を指定します。これは、オペレーションの高速化と一貫性の確保のために生成します。この GUID は `00000000-0000-0000-0000-111122223333` と同じくらいシンプルです。
1. [**Pre Install Hook Doc Name (インストール前のフックドキュメント名)**] に、「`NodeJSAppPrePatch`」と入力します。
1. [**Post Install Hook Doc Name (インストール後のフックドキュメント名)**] に、「`NodeJSAppPostPatch`」と入力します。
1. [**On ExitHook Doc Name (ExitHook ドキュメント名)**] に、「`NodeJSAppOnExitPatch`」と入力します。
1. **[Targets]** (ターゲット) では、タグの指定、ノードの手動選択、リソースグループの選択、またはすべてのマネージドノードの選択により、マネージドノードを特定します。
1. [**Specify schedule (スケジュールの指定)**] では、関連付けを実行する頻度を指定します。マネージドノードのパッチ適用では、週に 1 回が一般的な頻度です。
1. **[Rate control]** (レート制御) セクションで、複数のマネージドノードでの関連付けの実行方法を制御するオプションを選択します。一度に更新されるのは一部のマネージドノードであることを確認します。そうしないと、フリートのすべてまたはほとんどを同時にオフラインにすることになってしまいます。レート制御については、「[State Manager 関連付けのターゲットとレート制御について](systems-manager-state-manager-targets-and-rate-controls.md)」を参照してください。
1. (オプション) [**出力オプション**] で、コマンド出力をファイルに保存するには、[**S3 への出力の書き込みを有効にします**] ボックスをオンにします。ボックスにバケット名とプレフィックス (フォルダ) 名を入力してください。
**注記**
S3 バケットにデータを書き込む機能を許可する S3 アクセス許可は、このタスクを実行する IAM ユーザーのものではなく、マネージドノードに割り当てられたインスタンスプロファイルのものです。詳細については、「[Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)」または「[ハイブリッド環境に IAM サービスロールを作成する](hybrid-multicloud-service-role.md)」を参照してください。さらに、指定された S3 バケットが別の AWS アカウント にある場合は、マネージドノードに関連付けられたインスタンスプロファイルまたは IAM サービスロールに、そのバケットへの書き込みに必要なアクセス許可があることを確認してください。
1. **[関連付けの作成]** を選択します。
# チュートリアル: AWS CLI を使用してサーバー環境にパッチを適用する
次の手順では、カスタムパッチベースライン、パッチグループ、メンテナンスウィンドウを使用してサーバー環境にパッチを適用する方法を説明します。
**[開始する前に]**
+ マネージドノードに SSM Agent をインストールまたはアップデートしてください。Linux マネージドノードにパッチを適用するには、ノードが SSM Agent バージョン 2.0.834.0 以降実行されている必要があります。詳細については、「[Run Command を使用して SSM Agent を更新する](run-command-tutorial-update-software.md#rc-console-agentexample)」を参照してください。
+ AWS Systems Manager のツールである Maintenance Windows のロールとアクセス許可を設定します 詳細については、「[Maintenance Windows を設定する](setting-up-maintenance-windows.md)」を参照してください。
+ まだ AWS Command Line Interface (AWS CLI) をインストールして設定していない場合は、インストールして設定します。
詳細については、「[AWS CLI の最新バージョンをインストールまたは更新します。](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。
**Patch Manager を設定してマネージドノードにパッチを適用するには (コマンドライン)**
1. 次のコマンドを実行して、`Production-Baseline` という名前の Windows のパッチベースラインを作成します。このパッチベースラインは、リリースまたは最後に更新されてから 7 日後に、実稼働環境のパッチを承認します。つまり、パッチベースラインが本番環境用であることを示すタグ付けがされています。
**注記**
`OperatingSystem` パラメータおよび `PatchFilters` は、パッチベースラインが適用されるターゲット マネージドノードのオペレーティングシステムによって異なります。詳細については、「[OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem)」および「[PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)」を参照してください。
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Production-Baseline" \
--operating-system "WINDOWS" \
--tags "Key=Environment,Value=Production" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" \
--description "Baseline containing all updates approved for production systems"
```
------
#### [ Windows サーバー ]
```
aws ssm create-patch-baseline ^
--name "Production-Baseline" ^
--operating-system "WINDOWS" ^
--tags "Key=Environment,Value=Production" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" ^
--description "Baseline containing all updates approved for production systems"
```
------
システムが以下のような情報をレスポンスします。
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. 次のコマンドを実行して、2 つのパッチグループの「実稼働ベースライン」パッチベースラインを登録します。グループの名前は「データベースサーバー」と「フロントエンドサーバー」です。
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Database Servers"
```
------
#### [ Windows サーバー ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Database Servers"
```
------
システムが以下のような情報をレスポンスします。
```
{
"PatchGroup":"Database Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Front-End Servers"
```
------
#### [ Windows サーバー ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Front-End Servers"
```
------
システムが以下のような情報をレスポンスします。
```
{
"PatchGroup":"Front-End Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. 次のコマンドを実行し、実稼働サーバー用の 2 つのメンテナンスウィンドウを作成します。最初のウィンドウは、毎火曜日の午後 10 時に実行します。2 番目のウィンドウは、毎土曜日の午後 10 時に実行します。また、メンテナンスウィンドウが実稼働環境用であることを示すタグが付けられます。
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Tuesdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * TUE *)" \
--duration 1 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows サーバー ]
```
aws ssm create-maintenance-window ^
--name "Production-Tuesdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * TUE *)" ^
--duration 1 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
システムが以下のような情報をレスポンスします。
```
{
"WindowId":"mw-0c50858d01EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Saturdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * SAT *)" \
--duration 2 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows サーバー ]
```
aws ssm create-maintenance-window ^
--name "Production-Saturdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * SAT *)" ^
--duration 2 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
システムが以下のような情報をレスポンスします。
```
{
"WindowId":"mw-9a8b7c6d5eEXAMPLE"
}
```
1. 次のコマンドを実行して、`Database` および `Front-End` サーバーのパッチグループをそれぞれのメンテナンスウィンドウに登録します。
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=tag:PatchGroup,Values=Database Servers" \
--owner-information "Database Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows サーバー ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Database Servers" ^
--owner-information "Database Servers" ^
--resource-type "INSTANCE"
```
------
システムが以下のような情報をレスポンスします。
```
{
"WindowTargetId":"e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=tag:PatchGroup,Values=Front-End Servers" \
--owner-information "Front-End Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows サーバー ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Front-End Servers" ^
--owner-information "Front-End Servers" ^
--resource-type "INSTANCE"
```
------
システムが以下のような情報をレスポンスします。
```
{
"WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE"
}
```
1. 次のコマンドを実行して、それぞれのメンテナンスウィンドウ中に、`Database` および `Front-End` サーバー上に不足している更新プログラムをインストールするパッチタスクを登録します。
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows サーバー ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
システムが以下のような情報をレスポンスします。
```
{
"WindowTaskId":"4f7ca192-7e9a-40fe-9192-5cb15EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows サーバー ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
システムが以下のような情報をレスポンスします。
```
{
"WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE"
}
```
1. 以下のコマンドを実行して、パッチグループのパッチコンプライアンスの概要を取得します。高レベル パッチコンプライアンスの概要には、それぞれのパッチ状態のパッチがあるマネージドノードの数が含まれます。
**注記**
最初のメンテナンスウィンドウ中にパッチ タスクが実行されるまで、サマリー内のマネージドノード数はゼロであることが予想されます。
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-group-state \
--patch-group "Database Servers"
```
------
#### [ Windows サーバー ]
```
aws ssm describe-patch-group-state ^
--patch-group "Database Servers"
```
------
システムが以下のような情報をレスポンスします。
```
{
"Instances": number,
"InstancesWithFailedPatches": number,
"InstancesWithInstalledOtherPatches": number,
"InstancesWithInstalledPatches": number,
"InstancesWithInstalledPendingRebootPatches": number,
"InstancesWithInstalledRejectedPatches": number,
"InstancesWithMissingPatches": number,
"InstancesWithNotApplicablePatches": number,
"InstancesWithUnreportedNotApplicablePatches": number
}
```
1. 以下のコマンドを実行して、パッチグループのマネージドノードごとにパッチ状態の概要を取得します。マネージドノードごとのサマリーには、パッチグループのマネージドノードごとのそれぞれのパッチ状態にある多数のパッチが含まれます。
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states-for-patch-group \
--patch-group "Database Servers"
```
------
#### [ Windows サーバー ]
```
aws ssm describe-instance-patch-states-for-patch-group ^
--patch-group "Database Servers"
```
------
システムが以下のような情報をレスポンスします。
```
{
"InstancePatchStates": [
{
"BaselineId": "string",
"FailedCount": number,
"InstalledCount": number,
"InstalledOtherCount": number,
"InstalledPendingRebootCount": number,
"InstalledRejectedCount": number,
"InstallOverrideList": "string",
"InstanceId": "string",
"LastNoRebootInstallOperationTime": number,
"MissingCount": number,
"NotApplicableCount": number,
"Operation": "string",
"OperationEndTime": number,
"OperationStartTime": number,
"OwnerInformation": "string",
"PatchGroup": "string",
"RebootOption": "string",
"SnapshotId": "string",
"UnreportedNotApplicableCount": number
}
]
}
```
Patch Managerの設定タスクを実行するために使用できる他の AWS CLI コマンドの例については、「[AWS CLI を使用して Patch Manager リソースを操作する](patch-manager-cli-commands.md)」を参照してください。