パッチのインストール方法 - 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 を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

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

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

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

  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
    • カスタムのパッチベースラインについては、[承認済みパッチにセキュリティ以外の更新が含まれる] チェックボックスがオンの場合、updateinfo.xml にあるパッチと updateinfo.xml にないパッチの両方が適用されます (セキュリティの更新とセキュリティに関連しない更新)。

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

      sudo yum update --security --bugfix
  8. 更新がインストールされると、インスタンスが再起動されます。(例外: AWS-RunPatchBaseline ドキュメントで RebootOption パラメータが 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 を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

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

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

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

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

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

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

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

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

Debian サーバー

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

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

  2. 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がシステムを更新するときにも、同じプロセスが行われます。

    パッチのインストールの以降の手順は、Debian サーバー 8、9、10 に適用されます。

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

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

    注記

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

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

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

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

    注記

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

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

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

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

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

macOS

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

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

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

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

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

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

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

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

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

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

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

    注記

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

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

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

  8. 更新がインストールされると、インスタンスが再起動されます。(例外: AWS-RunPatchBaseline ドキュメントで RebootOption パラメータが 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 を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。

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

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

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

  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
    • カスタムのパッチベースラインについては、[承認済みパッチにセキュリティ以外の更新が含まれる] チェックボックスがオンの場合、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
      • カスタムのパッチベースラインについては、[承認済みパッチにセキュリティ以外の更新が含まれる] チェックボックスがオンの場合、updateinfo.xml にあるパッチと updateinfo.xml にないパッチの両方が適用されます (セキュリティの更新とセキュリティに関連しない更新)。

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

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

RHEL

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

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

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

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

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

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

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

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

SLES

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

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

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

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

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

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

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

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

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

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

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

  8. 更新がインストールされると、インスタンスが再起動されます。(例外: AWS-RunPatchBaseline ドキュメントで RebootOption パラメータが 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. パッチベースラインの指定どおりに GlobalFilters を適用し、対象のパッケージのみを追加処理のために保持します。

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

    注記

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

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

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

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

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

    注記

    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) に含まれるパッチに限定されます。

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

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

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

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

Windows

Windows Server インスタンスに対してパッチ適用オペレーションを実行すると、このインスタンスは該当するパッチベースラインのスナップショットを Systems Manager にリクエストします。このスナップショットには、デプロイ用に承認されたすべての使用可能な更新がパッチベースラインとして含まれています。この更新のリストが Windows Update API に送信されて、インスタンスに適用できる更新が確認され、必要に応じてインストールされます。更新のインストール後に、インスタンスが必要な回数だけ再起動されて、すべての必要なパッチが適用されます。(例外: AWS-RunPatchBaseline ドキュメントで RebootOption パラメータが 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サーバーをターゲットとするようにインスタンスに設定できます。