はじめに
プライベートサブネット上にあるEC2インスタンスにパッチ適用する際、Linux（Amazon Linux系）やWindowsなどのOSによって構成が異なるため、それぞれのOS別の構成と、Systems Manager Patch Manager（以降、パッチマネージャー）を使ったパッチ適用方法について解説します。
ちなみに、EC2インスタンスがパブリックサブネット上のインターネットにアクセスできる環境の場合、OSによって構成が異なることはほとんどのケースでないです。
構成
プライベートサブネット上にEC2インスタンスがある場合、S3バケットやSystems Manager（以降、SSM）へのアクセス経路を考慮する必要があります。
プライベートサブネット上にEC2インスタンスがある場合、OS関係なく以下の設定は共通です。
- EC2インスタンスにSSMエージェントがインストールされていること
- S3バケットとSSMへのアクセスに必要なIAMロールがEC2インスタンスに関連付いていること
- S3バケットとSSMへアクセス可能な環境が、VPCエンドポイントやNAT Gateway、NATインスタンスを通じて提供されること
- VPCエンドポイントの場合、以下の3つが必要です
- com.amazonaws.region.ssm
- com.amazonaws.region.ec2messages
- com.amazonaws.region.ssmmessages
- com.amazonaws.region.s3
- VPCエンドポイントの場合、以下の3つが必要です
以下の記事を参考に設定しましょう。
ただし、OSによって異なる構成の部分がありますので、LinuxとWindowsに分けて説明します。
Linuxの場合
Linuxのリポジトリは S3バケットにホストされています。
そのため、パブリックサブネットにNATGatewayやNATインスタンスを設置しインターネット経由でアクセスするか、VPCエンドポイントを作成し、S3バケットにアクセス経路を確保した上で、パッケージを更新およびインストールします
下記のVPCエンドポイントのみを利用する構成が最もコストは低いです。
続いて先程の構成よりコストが高い、NATGatewayを利用する構成です。
NATGatewayを利用する場合でも、S3用のVPCエンドポイント（Gatewayタイプ）は、利用費や転送量が無料ですので利用しましょう。
ただし、標準リポジトリでないExtra Packages for Enterprise Linux (EPEL)などのサードパーティリポジトリを利用している場合、NATGatewayなどを設置し、インターネットにアクセスできる必要があります。
Windowsの場合
Windowsでは、次の二つのキーワードが関わってきます。
- Microsoft Update カタログ
- Microsoftが提供する更新プログラム（パッチ）のリポジトリのことです。
- Windows Server Update Services (WSUS)
- マイクロソフト社が提供している、同社製品の更新プログラム適用を制御するソフトウェアのことです
Microsoft Update カタログを利用する場合
Windowsに対してパッチマネージャーを使うには、Linuxと同じくS3バケットとSSMにアクセス可能な環境に加えて、インターネット経由でMicrosoft Update カタログにアクセスする必要があります。
Microsoft Update カタログにアクセスし、EC2インスタンスに適用可能な更新プログラムリストを取得します。
このため、下記の構成のようにパブリックサブネットにNAT Gatewayなどを設置し、プライベートサブネットにあるEC2からインターネットにアクセスできる環境が必要です。
下記の構成のようにSSMへのアクセスは、VPCエンドポイント経由でもよいですが、コストや作成の手間を考慮すると、VPCエンドポイントではなくNATGateway経由に統一した方がよいでしょう。
WSUSを利用する場合
ちなみに、インターネット経由でMicrosoft Update カタログにアクセスする方法以外にWSUSサーバーを利用する方法もあります。
構成図
ただし、WSUSサーバー自体を管理する必要があったり、ADが必要であったりするデメリットがありますので、利用する機会は少ないです。
AWSでは、AWS上でWSUSサーバーがデプロイできるCloudFormationテンプレートが用意されております。
LinuxとWindowsが共存
上記を踏まえて、プライベートサブネットにLinuxとWindowsの各EC2インスタンスが存在している場合は、以下の構成がよいでしょう。
構成図
パッチ適用方法
パッチマネージャーを使ったパッチ適用方法を解説します。
パッチマネージャーでスキャンとパッチ適用する方法は以下の４つあります。
- (推奨) 高速セットアップのパッチマネージャー
- AWS Organizations との統合に基づいて、1つのパッチ定義ポリシーで組織全体や一部の組織単位（OU）に対して、スキャンおよびパッチ適用できます
- 高速セットアップのホスト管理
- AWS Organizations との統合に基づいて、組織全体や一部の組織単位（OU）のみに対して、パッチをスキャンします。パッチ適用はできません
- メンテナンスウィンドウのスケジュールで、Run Commandを実行
- メンテナンスウィンドウでは、定義したスケジュールに従いタスクを実行するように設定できます。メンテナンスウィンドウの設定したスケジュールで、1アカウントの1リージョンに対して、スキャンおよびパッチ適用をRun Commandで実行します
- オンデマンド
- スケジュールした時間で１度限り、1アカウントの1リージョンに対して、スキャンおよびパッチ適用できます
今回は、AWSで推奨されている高速セットアップのパッチマネージャーを利用してパッチ適用します。
事前設定
事前に以下の構成をセッティングします。
本記事の構成の見出しで説明した設定に加え、EC2インスタンス（今回はAmazon Linux2）を作成するだけです。
高速セットアップのパッチマネージャーを利用
AWSマネジメントコンソールのSSMの高速セットアップからパッチマネージャーを選択します
スキャンとインストールを選択します
パッチマネージャーのターゲットを選択し、インスタンスプロファイルのオプションを有効にすることで、EC2インスタンスがSSMとS3を利用できるようIAMロールを自動作成しアタッチされます。ロールアタッチ済みの場合、IAMポリシーが追加されます。
最後に、高速セットアップの設定内容のまとめを確認できます。
結果
各ステータスやEC2インスタンスが準拠もしくは非準拠かどうか確認できます
[詳細を表示]をクリックします
関連付けというのは、インスタンスのあるべき状態を定義するSSMステートマネージャーの機能です。
もし、エラーが起きた場合、SSM ステートマネージャーやS3バケットからエラーログを確認しましょう。
下記のトラブルシューティング集から、確認したエラーログと似たログがないか確認するとよいです。
5
