• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。
# 代替パッチソースリポジトリを指定する方法 (Linux)
マネージドノードに設定されているデフォルトのリポジトリをパッチオペレーションに使用すると、AWS Systems Manager のツールである Patch Manager はセキュリティに関連するパッチをスキャンまたはインストールします。これがPatch Managerのデフォルトの動作です。Patch Manager がセキュリティ関連のパッチを選択してインストールする方法の詳細については、「[セキュリティに関連するパッチの選択方法](patch-manager-selecting-patches.md)」を参照してください。
ただし、Linux システムでは、Patch Manager を使用して、セキュリティに関連しないパッチや、マネージドノードに設定されているデフォルトのリポジトリとは異なるソースリポジトリにあるパッチをインストールすることもできます。カスタムのパッチベースラインを作成するときは、代替パッチソースリポジトリを指定できます。各カスタムのパッチベースラインでは、サポートされている Linux オペレーティングシステムの最大 20 バージョンにパッチソース設定を指定できます。
例えば、Ubuntu Server フリートに Ubuntu Server 25.04 マネージドノードの両方が含まれているとします。この場合、同じカスタムパッチベースラインで、各バージョンの代替リポジトリを指定できます。バージョンごとに、名前、オペレーティングシステムのバージョンタイプ (製品)、リポジトリ設定を指定します。サポートされているオペレーティングシステムのすべてのバージョンに適用される 1 つの代替ソースリポジトリを指定することもできます。
**注記**
マネージドノードの代替パッチ リポジトリを指定したカスタム パッチベースラインを実行しても、それらがオペレーティングシステム上の新しいデフォルト リポジトリになることはありません。パッチ適用オペレーションが完了すると、ノードのオペレーティングシステムのデフォルトとして以前に構成されたリポジトリーはデフォルトのままです。
このオプションを使用するシナリオの例のリストについては、このトピックの後半の「[代替パッチソースリポジトリの使用例](#patch-manager-alternative-source-repository-examples)」を参照してください。
デフォルトおよびカスタムのパッチベースラインについては、「[事前定義されたパッチベースラインおよびカスタムパッチベースライン](patch-manager-predefined-and-custom-patch-baselines.md)」を参照してください。
**例: コンソールを使用する場合**
Systems Manager コンソールでの作業時に代替パッチソースリポジトリを指定するには、[**Create patch baseline** (パッチベースラインの作成)] ページの [**Patch sources** (パッチソース)] セクションを使用します。[**Patch sources (パッチソース)**] のオプションの使用については、「[Linux 用 カスタムパッチベースラインの作成](patch-manager-create-a-patch-baseline-for-linux.md)」を参照してください。
**例: AWS CLI を使用する場合**
AWS Command Line Interface (AWS CLI) で `--sources` オプションを使用する例については、「[異なる OS バージョン用にカスタムリポジトリのパッチベースラインを作成する](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources)」を参照してください。
**Topics**
+ [代替リポジトリに関する重要な考慮事項](#alt-source-repository-important)
+ [代替パッチソースリポジトリの使用例](#patch-manager-alternative-source-repository-examples)
## 代替リポジトリに関する重要な考慮事項
代替パッチリポジトリを使用してパッチ適用戦略を計画する際は、次の点に注意してください。
**リポジトリ更新の認証を実施する (YUM と DNF)**
Linux ディストリビューションのパッケージマネージャーのデフォルト設定では、リポジトリへの接続が確立できない場合、アクセスできないパッケージリポジトリをスキップするように設定されることがあります。リポジトリの更新の認証を実施するには、リポジトリ設定に `skip_if_unavailable=False` を追加します。
`skip_if_available` オプションの詳細については、「[パッチソースへの接続](patch-manager-prerequisites.md#source-connectivity)」を参照してください。
**指定されたリポジトリのみがパッチ適用に使用されます**
代替リポジトリの指定は、*追加*リポジトリの指定を意味しません。マネージドノードにデフォルトとして設定されているリポジトリ以外のリポジトリを選択することができます。ただし、更新を適用する場合は、代替のパッチソース設定の一部としてデフォルトのリポジトリも指定する必要があります。
例えば、Amazon Linux 2 マネージドノードでは、デフォルトのリポジトリは `amzn2-core` と `amzn2extra-docker` です。パッチ適用オペレーションで Extra Packages for Enterprise Linux (EPEL) リポジトリを含める必要がある場合は、3 つのリポジトリすべてを代替リポジトリとして指定する必要があります。
**注記**
マネージドノードの代替パッチ リポジトリを指定したカスタム パッチベースラインを実行しても、それらがオペレーティングシステム上の新しいデフォルト リポジトリになることはありません。パッチ適用オペレーションが完了すると、ノードのオペレーティングシステムのデフォルトとして以前に構成されたリポジトリーはデフォルトのままです。
**YUM ベースのディストリビューションのパッチ適用の動作は、updateinfo.xml マニフェストに依存します**
Amazon Linux 2 または Red Hat Enterprise Linux など、YUM ベースのディストリビューション用の代替パッチリポジトリを指定する場合、パッチ適用動作は、リポジトリに更新マニフェストが完全で正しい形式の `updateinfo.xml` ファイルで含まれているかどうかによって異なります。このファイルは、リリース日、分類、および各種パッケージの重要度を指定します。次のいずれかのパッチ動作に影響を与えます。
+ **Classification** や **Severity** でフィルターしても、それらが `updateinfo.xml` で指定されていない場合、そのパッケージはフィルターには含まれません。つまり、`updateinfo.xml` ファイルのないパッケージはパッチ適用に含まれません。
+ **ApprovalAfterDays** でフィルターしても、パッケージのリリース日が Unix エポック形式でない場合 (またはリリース日が指定されていない場合)、そのパッケージはフィルターに含まれません。
+ **[パッチベースラインの作成]** ページで **[セキュリティ以外の更新を含める]** チェックボックスをオンにした場合、例外が発生します。この場合、`updateinfo.xml` ファイルを持たないパッケージ (または、**分類**、**重要度**、**日付**の値が適切にフォーマットされていないこのファイルが含まれている) は、パッチの事前フィルタリングされたリストに含まれ*ます*。(インストールするには、パッチベースラインルールの他の要件を満たしていなければなりません。)
## 代替パッチソースリポジトリの使用例
**例 1 - Ubuntu Server のセキュリティに関連しない更新プログラム**
AWS が提供する事前定義されたパッチベースライン `AWS-UbuntuDefaultPatchBaseline` を使用して、セキュリティパッチを Ubuntu Server マネージドノードのフリート上にインストールするために Patch Manager を既に使用しているとします。このデフォルトに基づいて新しいパッチベースラインを作成できますが、デフォルトのディストリビューションに含まれるセキュリティに関連しない更新プログラムもインストールするように、承認ルールで指定できます。このパッチベースラインがノードに対して実行されると、セキュリティに関連する問題と関連しない問題の両方に対するパッチが適用されます。また、ベースラインに対して指定したパッチ例外で、セキュリティに関連しないパッチを承認することもできます。
**例 2 - Ubuntu Server の PPA (Personal Package Archives)**
Ubuntu Server マネージドノードで、[Personal Package Archives (PPA) for Ubuntu](https://launchpad.net/ubuntu/+ppas) を通じて配布されるソフトウェアを実行するとします。この場合、マネージドノードで設定した PPA リポジトリをパッチ適用オペレーションのソースリポジトリとして指定する、パッチベースラインを作成します。その後、Run Command を使用して、ノードでパッチベースライン ドキュメントを実行します。
**例 3 - サポートされている Amazon Linux のバージョンの社内アプリケーション**
Amazon Linux マネージドノードで、業界の規制コンプライアンスに必要なアプリケーションを実行する必要があるとします。ノードでこれらのアプリケーションのリポジトリを設定し、YUM を使用してアプリケーションをまずインストールしてから、この新しい企業リポジトリを含むように、新しいパッチベースラインを更新または作成できます。その後、Run Command を使用し、`Scan` オプション付きで `AWS-RunPatchBaseline` ドキュメントを実行することで、企業パッケージがインストールされたパッケージに含まれており、マネージドノードで最新かどうかを確認できます。最新でない場合は、`Install` オプション付きでそのドキュメントを再実行することで、アプリケーションを更新できます。