パッチのインストール方法 - AWS Systems Manager

パッチのインストール方法

AWS Systems Manager の一機能である Patch Manager は、オペレーティングシステムのタイプ別に適切な組み込み機構を使用してインスタンスに更新をインストールします。例えば、Windows Server には Windows Update API を使用し、Amazon Linux には yum パッケージマネージャーを使用します。

以下の各タブを選択して、Patch Manager がオペレーティングシステムにパッチをインストールする方法を確認してください。

Amazon Linux and Amazon Linux 2

Amazon Linux および Amazon Linux 2 インスタンスでは、パッチのインストールワークフローは次のとおりです。

  1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、AWS-RunPatchBaseline または AWS-RunPatchBaselineAssociation ドキュメントの InstallOverrideList パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。

  2. パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  3. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

    ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。

    セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。

    セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。

  4. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  5. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  6. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。

  7. YUM 更新 API は、次のように承認済みパッチに適用されます。

    • AWS により事前定義されたデフォルトのパッチベースライン、およびカスタムのパッチベースラインについては、[Approved patches include non-security updates (承認済みパッチにセキュリティに関連しない更新プログラムを含める)] チェックボックスをオンにしない限り、updateinfo.xml で指定されたパッチのみが適用されます (セキュリティの更新のみ)。

      このワークフローに該当する yum コマンドは次のとおりです。

      sudo yum update-minimal --sec-severity=critical,important --bugfix -y
    • カスタムのパッチベースラインについては、[Approved patches include non-security updates (承認済みパッチにセキュリティ以外の更新が含まれる)] チェックボックスがオンの場合、updateinfo.xml にあるパッチと updateinfo.xml にないパッチの両方が適用されます (セキュリティの更新とセキュリティに関連しない更新)。

      このワークフローに該当する yum コマンドは次のとおりです。

      sudo yum update --security --bugfix
  8. 更新がインストールされると、インスタンスは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、パッチマネージャーのPatch Manager実行後にインスタンスは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

CentOS

CentOS インスタンスの場合、パッチのインストール手順は次のとおりです。

  1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、AWS-RunPatchBaseline または AWS-RunPatchBaselineAssociation ドキュメントの InstallOverrideList パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。

    パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  2. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

    ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。

    セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。

    セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。

  3. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  4. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  5. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。

  6. 承認済みパッチには、YUM 更新 API (CentOS 6.x および 7.x バージョン) または DNF 更新 (CentOS 8) が適用されます。

  7. 更新がインストールされると、インスタンスは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、Patch Manager の実行後にインスタンスは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

Debian Server

Debian サーバーインスタンスの場合、パッチのインストール手順は以下のとおりです。

  1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、AWS-RunPatchBaseline または AWS-RunPatchBaselineAssociation ドキュメントの InstallOverrideList パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。

  2. 更新が可能な場合、python3-apt (Python ライブラリインターフェイスの libapt) は最新バージョンにアップグレードされます。(このセキュリティ以外のパッケージは、[Include nonsecurity updates (セキュリティ以外の更新プログラムを含める)] オプションが選択されていなくてもアップグレードされます。)

    重要

    Debian サーバー 8 の場合のみ: 一部の Debian サーバー 8.* インスタンスは、廃止されたパッケージリポジトリ (jessie-backports) を参照するため、Patch Manager は、パッチ適用オペレーションが正常に完了するようさらに以下の手順を実行します。

    1. お客様のインスタンスでは、jessie-backports リポジトリへの参照はソース場所リスト (/etc/apt/sources.list.d/jessie-backports) からコメントアウトされています。その結果、その場所からのパッチのダウンロードは試みられません。

    2. Stretch のセキュリティの更新の署名キーがインポートされます。このキーは、Debian サーバー 8.* ディストリビューションでの更新およびインストールオペレーションに必要なアクセス許可の付与に使用されます。

    3. この時点で、apt-get オペレーションを実行し、パッチ適用プロセスの開始前に最新バージョンの python3-apt がインストールされていることを確認します。

    4. インストールプロセスが完了すると、jessie-backports リポジトリへの参照が復元され、署名キーが apt ソースキーリングから削除されます。これは、パッチ適用オペレーション前のシステム設定をそのまま残すために行われます。

    次にPatch Managerがシステムを更新するときにも、同じプロセスが行われます。

  3. パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  4. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

    注記

    Debian サーバーの更新プログラムパッケージのリリース日は確定できないため、このオペレーティングシステムでは自動承認オプションがサポートされていません。

    ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。

    セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。

    セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。

    注記

    Debian サーバーの場合、パッチ候補バージョンは、debian-security に含まれているパッチに制限されます。

  5. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  6. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  7. APT ライブラリを使用してパッケージをアップグレードします。

  8. 更新がインストールされると、インスタンスは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、Patch Manager の実行後にインスタンスは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

macOS

macOS インスタンスの場合、パッチのインストール手順は次のとおりです。

  1. /Library/Receipts/InstallHistory.plist プロパティリストは、softwareupdate および installer パッケージマネージャーを使用してインストールおよびアップグレードされたソフトウェアのレコードです。pkgutil コマンドラインツール (installer 用) と softwareupdate パッケージマネージャーを使用して、CLI コマンドはこのリストを解析するために実行されます。

    installer の場合、CLI コマンドに対する応答には package nameversionvolumelocation、および install-time の詳細が含まれますが、Patch Manager で使用されるのは、package nameversion のみです。

    softwareupdate の場合、CLI コマンドへの応答にはパッケージ名 (display name)、versiondate が含まれますが、パッチマネージャーで使用されるのは、パッケージ名とバージョンのみです。

    Brew と Brew Cask の場合、Homebrew は root ユーザーで実行されるコマンドをサポートしていません。その結果、Patch Manager は Homebrew ディレクトリの所有者、または Homebrew ディレクトリの所有者グループに属する有効なユーザーとして、Homebrew コマンドを照会して実行します。コマンドは、softwareupdateinstaller に似ており、Python サブプロセスを介してパッケージデータを収集し、出力を解析してパッケージ名とバージョンを識別します。

  2. パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  3. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

  4. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  5. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  6. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。

  7. インスタンスで適切なパッケージ CLI を呼び出し、承認されたパッチを次のように処理します。

    注記

    installer には、更新プログラムを確認してインストールする機能がありません。したがって、installer では、Patch Manager はインストールされているパッケージのみをレポートします。その結果、installer パッケージは Missing として報告されることはありません。

    • AWS により事前定義されたデフォルトのパッチベースライン、およびカスタムのパッチベースラインについては、[Approved patches include non-security updates (承認済みパッチにセキュリティ以外の更新が含まれる)] チェックボックスをオンにしない場合、セキュリティの更新のみが適用されます。

    • カスタムのパッチベースラインについては、[Approved patches include non-security updates (承認済みパッチにセキュリティ以外の更新が含まれる)] チェックボックスがオンの場合、セキュリティとセキュリティ以外の更新が適用されます。

  8. 更新がインストールされると、インスタンスは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、Patch Manager の実行後にインスタンスは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

Oracle Linux

Oracle Linux インスタンスの場合、パッチのインストール手順は以下のとおりです。

  1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、AWS-RunPatchBaseline または AWS-RunPatchBaselineAssociation ドキュメントの InstallOverrideList パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。

  2. パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  3. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

    ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。

    セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。

    セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。

  4. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  5. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  6. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。

  7. バージョン 7 インスタンでは、YUM 更新 API が、次のように承認済みパッチに適用されます。

    • AWS により事前定義されたデフォルトのパッチベースライン、およびカスタムのパッチベースラインについては、[Approved patches include non-security updates (承認済みパッチにセキュリティに関連しない更新プログラムを含める)] チェックボックスをオンにしない限り、updateinfo.xml で指定されたパッチのみが適用されます (セキュリティの更新のみ)。

      このワークフローに該当する yum コマンドは次のとおりです。

      sudo yum update-minimal --sec-severity=important,moderate --bugfix -y
    • カスタムのパッチベースラインについては、[Approved patches include non-security updates (承認済みパッチにセキュリティ以外の更新が含まれる)] チェックボックスがオンの場合、updateinfo.xml にあるパッチと updateinfo.xml にないパッチの両方が適用されます (セキュリティの更新とセキュリティに関連しない更新)。

      このワークフローに該当する yum コマンドは次のとおりです。

      sudo yum update --security --bugfix -y

      バージョン 8 インスタンスでは、Dnf 更新 API が、次のように承認済みパッチに適用されます。

      • AWS により事前定義されたデフォルトのパッチベースライン、およびカスタムのパッチベースラインについては、[Approved patches include non-security updates (承認済みパッチにセキュリティに関連しない更新プログラムを含める)] チェックボックスをオンにしない限り、updateinfo.xml で指定されたパッチのみが適用されます (セキュリティの更新のみ)。

        このワークフローに該当する yum コマンドは次のとおりです。

        sudo dnf upgrade-minimal --security --sec-severity Moderate --sec-severity Important
      • カスタムのパッチベースラインについては、[Approved patches include non-security updates (承認済みパッチにセキュリティ以外の更新が含まれる)] チェックボックスがオンの場合、updateinfo.xml にあるパッチと updateinfo.xml にないパッチの両方が適用されます (セキュリティの更新とセキュリティに関連しない更新)。

        このワークフローに該当する yum コマンドは次のとおりです。

        sudo dnf upgrade --security --bugfix
  8. 更新がインストールされると、インスタンスは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、Patch Manager の実行後にインスタンスは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

RHEL

Red Hat Enterprise Linux インスタンスの場合、パッチのインストール手順は次のとおりです。

  1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、InstallOverrideList または AWS-RunPatchBaseline ドキュメントの AWS-RunPatchBaselineAssociation パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。

  2. パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  3. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

    ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。

    セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。

    セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。

  4. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  5. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  6. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。

  7. YUM 更新 API (RHEL 7) または DNF 更新 API (RHEL 8) は、承認されたパッチに次のように適用されます。

    • AWS により事前定義されたデフォルトのパッチベースライン、およびカスタムのパッチベースラインについては、[Approved patches include non-security updates (承認済みパッチにセキュリティに関連しない更新プログラムを含める)] チェックボックスをオンにしない限り、updateinfo.xml で指定されたパッチのみが適用されます (セキュリティの更新のみ)。

      RHEL 7 の場合、このワークフローに対応する yum コマンドは次のとおりです。

      sudo yum update-minimal --sec-severity=critical,important --bugfix -y

      RHEL 8 の場合、このワークフローに対応する dnf コマンドは次のとおりです。

      sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \ sudo dnf update-minimal --sec-severity=Important --bugfix -y
    • カスタムのパッチベースラインについては、[承認済みパッチにセキュリティ以外の更新が含まれる] チェックボックスがオンの場合、updateinfo.xml にあるパッチと updateinfo.xml にないパッチの両方が適用されます (セキュリティの更新とセキュリティに関連しない更新)。

      RHEL 7 の場合、このワークフローに対応する yum コマンドは次のとおりです。

      sudo yum update --security --bugfix -y

      RHEL 8 の場合、このワークフローに対応する yum コマンドは次のとおりです。

      sudo dnf update --security --bugfix -y
  8. 更新がインストールされると、インスタンスは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、Patch Manager の実行後にインスタンスは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

SLES

SUSE Linux Enterprise Server (SLES) インスタンスの場合、パッチのインストール手順は次のとおりです。

  1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、InstallOverrideList または AWS-RunPatchBaseline ドキュメントの AWS-RunPatchBaselineAssociation パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。

  2. パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  3. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

    ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。

    セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。

    セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。

  4. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  5. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  6. 複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。

  7. Zypper 更新 API は、承認済みパッチに適用されます。

  8. 更新がインストールされると、インスタンスは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、Patch Manager の実行後にインスタンスは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

Ubuntu Server

Ubuntu Server インスタンスの場合、パッチのインストール手順は次のとおりです。

  1. パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、AWS-RunPatchBaseline または AWS-RunPatchBaselineAssociation ドキュメントの InstallOverrideList パラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。

  2. 更新が可能な場合、python3-apt (Python ライブラリインターフェイスの libapt) は最新バージョンにアップグレードされます。(このセキュリティ以外のパッケージは、[Include nonsecurity updates (セキュリティ以外の更新プログラムを含める)] オプションが選択されていなくてもアップグレードされます。)

  3. パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

  4. パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

    注記

    Ubuntu Server の更新プログラムパッケージのリリース日は確定できないため、このオペレーティングシステムでは自動承認オプションがサポートされていません。

    ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。

    セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。

    セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。

    ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [セキュリティ以外の更新を含める] チェックボックスがオンになっているかどうかによっても影響を受けます。

    注記

    Ubuntu Server の場合、パッチ候補バージョンは trusty-security (Ubuntu Server 14.04 LTS)、xenial-security (Ubuntu Server 16.04 LTS)、bionic-security (Ubuntu Server 18.04 LTS)、focal-security (Ubuntu Server 20.04 LTS)、または groovy-gorilla (Ubuntu Server 20.10 STR) に含まれるパッチに限定されます。

  5. パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。

  6. パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。

  7. APT ライブラリを使用してパッケージをアップグレードします。

  8. 更新がインストールされると、インスタンスは再起動されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、Patch Manager の実行後にインスタンスは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)

Windows

Windows Server インスタンスに対してパッチ適用オペレーションを実行すると、このインスタンスは該当するパッチベースラインのスナップショットを Systems Manager にリクエストします。このスナップショットには、デプロイ用に承認されたすべての使用可能な更新がパッチベースラインとして含まれています。この更新のリストが Windows Update API に送信されて、インスタンスに適用できる更新が確認され、必要に応じてインストールされます。更新のインストール後に、インスタンスが必要な回数だけ再起動されて、すべての必要なパッチが適用されます。(例外: RebootOption パラメータが AWS-RunPatchBaseline ドキュメントの NoReboot で設定されている場合、Patch Manager の実行後にインスタンスは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。) パッチ適用オペレーションの概要は、Run Command リクエストの出力で確認できます。詳細なログは、インスタンスの %PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs フォルダにあります。

パッチのダウンロードとインストールには Windows Update API が使用されるため、Windows Update のすべてのグループポリシー設定が適用されます。Patch Managerの使用には、グループポリシー設定は必須ではありませんが、ユーザー定義のすべての設定 (インスタンスのターゲットを Windows Server Update Services (WSUS) サーバーにするなど) が適用されます。

注記

Windows では、Patch Managerは Windows Update API を使用してパッチのダウンロードとインストールを行うため、デフォルトではすべてのパッチが Microsoft の Windows Update サイトからダウンロードされます。そのため、インスタンスは Microsoft Windows Update サイトに接続できる必要があります。そうでないと、パッチ適用は失敗します。別の方法として、WSUS サーバーをパッチのレポジトリとして構成し、グループポリシーを使って WSUS サーバーをターゲットとするようインスタンスを設定できます。