翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AMS 標準パッチ適用
AMS は AMS 標準パッチ適用モデルを使用して既存の顧客をサポートしていますが、このモデルは新しい顧客には利用できず、AMS パッチオーケストレーターを優先して廃止されます。
AMS 標準パッチの一般的なパッチコンテンツには、サポートされているオペレーティングシステムと、サポートされているオペレーティングシステム (IIS や Apache Server など) がプリインストールされたソフトウェアのベンダー更新が含まれます。
AMS オンボーディング中に、パッチ適用の要件、ポリシー、頻度、優先パッチウィンドウを指定します。これらの設定により、インフラストラクチャのパッチ適用のためにアプリケーションを一度にすべてオフラインにする必要がなくなるため、どのインフラストラクチャにパッチを適用するかを制御できます。
注記
このトピックで説明するパッチ適用プロセスは、スタックにのみ適用されます。AMS インフラストラクチャには、別のプロセス中にパッチが適用されます。AWS Managed Servicesメンテナンスウィンドウ (またはメンテナンスウィンドウ) は、AWS Managed Services (AMS) のメンテナンスアクティビティを実行し、毎月第 2 木曜日の太平洋標準時の午後 3 時から午後 4 時まで繰り返します。AMS は、48 時間前に通知することでメンテナンスウィンドウを変更する場合があります。オンボーディング時に AMS パッチウィンドウを設定するか、毎月のパッチサービス通知を承認または拒否します。
AMS は、マネージド Amazon EC2 インスタンスを定期的にスキャンして、オペレーティングシステムの更新機能を通じて利用可能な更新を確認します。また、 環境でサポートされている AMS ベースの Amazon マシンイメージ (AMIs) を定期的に更新しています。
検証後、AMS AMI リリースはすべての AMS アカウントと共有されます。DescribeImages Amazon EC2 API コールまたは Amazon EC2 Amazon EC2 コンソールを使用して、使用可能な AWS AMI リリースを表示できます。使用可能な AMS AMIs「」を参照してくださいAMI IDs、AMS の検索。
AMS は、ユーザーからリクエストされた場合にのみアドホックパッチ適用スケジュールを実行します。以前は、AMS は通知を送信します。現在、通知は送信されません。
注記
デフォルトでは、AMS は Systems Manager を使用してパッチを適用し、パッケージマネージャー (Linux) または System Update サービス (Windows) がデフォルトのリポジトリをクエリして、利用可能な新しいパッケージを確認します。day-to-dayオペレーションの過程で、デフォルトのパッケージマネージャーを使用して Linux ホストにパッケージをインストールした場合、そのパッケージマネージャーは、そのソフトウェアの新しいパッケージが利用可能になったときにそのパッケージも受け取ります。このような場合は、パッチ適用アクションを実行して (このセクションで説明)、そのインスタンスをオプトアウトできます。
サポートされるオペレーティングシステム
サポートされているオペレーティングシステム (x86-64)
Amazon Linux 2023
Amazon Linux 2 (AMS サポート終了日は 2026 年 6 月 30 日と想定)
Oracle Linux 9.x、8.x
Red Hat Enterprise Linux (RHEL) 9.x、8.x
SUSE Linux Enterprise Server 15 SP6
SUSE Linux Enterprise Server for SAP 15 SP3 以降
Microsoft Windows Server 2022、2019、2016
Ubuntu 20.04、22.04、24.04
サポートされているオペレーティングシステム (ARM64)
Amazon Linux 2023
Amazon Linux 2 (AMS サポート終了日は 2026 年 6 月 30 日と想定)
サポートされているパッチ
AWS Managed Services は、主にオペレーティングシステムレベルでのパッチ適用をサポートしています。インストールされるパッチは、オペレーティングシステムによって異なる場合があります。
重要
すべての更新は、インスタンスに設定されている Systems Manager パッチベースラインサービスのリモートリポジトリからダウンロードされ、このトピックで後述します。パッチ適用を実行するには、インスタンスがリポジトリに接続できる必要があります。
自分で管理するパッケージを配信するリポジトリのパッチベースラインサービスをオプトアウトするには、次のコマンドを実行してリポジトリを無効にします。
yum-config-manager DASHDASHdisableREPOSITORY_NAME
次のコマンドを使用して、現在設定されているリポジトリのリストを取得します。
yum repolist
-
Amazon Linux 事前設定済みリポジトリ (通常は 4 つ):
リポジトリ ID リポジトリ名 amzn-main/latest
amzn-main-Base
amzn-updates/最新
amzn-updates-Base
epel/x86_64
Enterprise Linux 6 の追加パッケージ - x86_64
pbis
PBIS パッケージの更新
-
Red Hat Enterprise Linux の事前設定済みリポジトリ (Red Hat Enterprise Linux 7 の場合は 5 つ、Red Hat Enterprise Linux 6 の場合は 5 つ)。
リポジトリ ID リポジトリ名 rhui-REGION-client-config-server-7/x86_64
Red Hat Update Infrastructure 2.0 Client Configuration Ser
rhui-REGION-rhel-server-releases/7Server/x86_64
Red Hat Enterprise Linux Server 7
rhui-REGION-rhel-server-releases/7Server/x86_64
Red Hat Enterprise Linux Server 7 RH Common (RPMs)
epel/x86_64
Enterprise Linux 7 の追加パッケージ - x86_64
pbis
PBIS パッケージの更新
リポジトリ ID リポジトリ名 rhui-REGION-client-config-server-6
Red Hat 更新インフラストラクチャ 2.0
rhui-REGION-rhel-server-releases
Red Hat Enterprise Linux Server 6 (RPMs)
rhui-REGION-rhel-server-rh-common
Red Hat Enterprise Linux Server 6 RH Common (RPMs)
Epel
Enterprise Linux 6 の追加パッケージ - x86_64
pbis
PBIS パッケージの更新
-
CentOS 7 事前設定済みリポジトリ (通常は 5 つ):
リポジトリ ID リポジトリ名 base/7/x86_64
CentOS-7 - ベース
updates/7/x86_64
CentOS-7 - 更新
extras/7/x86_64
CentOS-7 - 追加
epel/x86_64
Enterprise Linux 7 の追加パッケージ - x86_64
pbis
PBIS パッケージの更新
-
Microsoft Windows Server の場合、すべての更新は、Windows Update カタログを使用するように設定された Windows Update エージェントを使用して検出およびインストールされます (Microsoft Update からの更新は含まれません)。
Microsoft Windows オペレーティングシステムでは、Patch Manager は利用可能なオペレーティングシステムのセキュリティ更新のソースとして Microsoft の cab ファイル wsusscn2.cab を使用します。このファイルには、Microsoft が発行するセキュリティ関連の更新に関する情報が含まれています。Patch Manager は、このファイルを Microsoft から定期的にダウンロードし、それを使用して Windows インスタンスで使用できるパッチのセットを更新します。このファイルに含まれている更新は、セキュリティに関連していると Microsoft が判断したもののみです。Patch Manager は、ファイル内の情報の処理に伴って、最新の更新で置き換えた前の更新を削除します。したがって、最新の更新のみが表示され、インストール可能になります。たとえば、KB4012214 が KB3135456 を置き換える場合、KB4012214 のみが Patch Manager の更新として利用可能になります。
wsusscn2.cab ファイルの詳細については、Microsoft の記事「Using WUA to Scan for Updates Offline
」を参照してください。
パッチ適用とインフラストラクチャ設計
AMS は、インフラストラクチャの設計に応じて、変更可能またはイミュータブルなさまざまなパッチ適用方法を採用しています (詳細な定義については、「」を参照してくださいAMS の主要な用語)。
変更可能なインフラストラクチャでは、パッチ適用は、AMS オペレーションエンジニアが Amazon EC2 インスタンスに個別に更新を直接インストールする従来のインプレース方法を使用して行われます。このパッチ適用方法は、Auto Scaling グループではなく、1 つの Amazon EC2 インスタンスまたはいくつかのインスタンスを含むスタックに使用されます。このシナリオでは、インスタンスまたはスタックが基づいていた AMI を置き換えると、そのシステムが最初にデプロイされてから行われたすべての変更が破棄されるため、 は行われません。更新は実行中のシステムに適用され、アプリケーションまたはシステムの再起動により、システムのダウンタイム (スタック設定によって異なります) が発生する可能性があります。これは、ブルー/グリーン更新戦略で軽減できます。詳細については、AWS CodeDeploy 「ブルー/グリーンデプロイの導入
イミュータブルインフラストラクチャでは、パッチ適用方法は AMI の置き換えです。イミュータブルインスタンスは、Auto Scaling グループ設定で指定された AMI を置き換える更新された AMI を使用して均一に更新されます。AMS リリースは、毎月、通常はパッチ火曜日の週に AMIs を更新 (つまり、パッチを適用) します。次のセクションでは、この仕組みについて説明します。
AMS 標準パッチ適用の失敗
更新に失敗した場合、AMS は分析を実行して失敗の原因を理解し、分析の結果を通知します。障害が AMS に起因する場合、メンテナンスウィンドウ内にある場合は更新を再試行します。それ以外の場合、AMS は失敗したインスタンスの更新に関するサービス通知を作成し、指示を待ちます。
システムに起因する障害の場合、新しいパッチ RFC を使用してサービスリクエストを送信してインスタンスを更新できます。