前回「AWS動作検証【1】（アカウント作成＞VPC作成＞EC2起動＞CloudWatch監視設定実施）」の続きとなります。
#■■ 筆者情報 ■■
・AWSの資格試験はプロフェッショナルまで取得済。
・AWSの操作経験は初心者並み。
・理論は解っていても操作は解っていない状況。
※資格試験取得に興味のある方は「AWS認定試験の勉強方法」を参照ください。
#■■ この記事を読んでほしい対象 ■■
・AWSの知識はある程度ついたので、AWS操作を一通り実施したい人。
・AWS公式ドキュメントをベースに手順を確認したい人。
※手順を簡単にまとめてくれているサイトも多々ありますが、可能な限りAWSの公式ドキュメントを読み解きながら確認を実施しています。その為、この記事のリンクの多くは公式ドキュメントに対して貼られており、どうしても公式ドキュメントのみだと解らない場合に、個人のHPを頼っています。
#■■ Systems Managerのパッチ配信 ■■
今回は作成したインスタンスにパッチ配信設定を実施しして、パッチが配信されることを確認します。
##作業前EC2のパッチ配信状況確認
事前にEC2インスタンスのパッチ適用状況を確認して、3月11日が最新であることを確認しました。
##AWS の定義済みパッチベースラインの表示（Systems Manager）
パッチベースライン設定を確認しました。
Windows Server では、事前に定義された 2 つのパッチベースラインが提供されます。パッチベースライン AWS-WindowsPredefinedPatchBaseline-OS では、Windows オペレーティングシステムのオペレーティングシステムアップデートのみサポートしています。また、別のパッチベースラインを指定しない限り、Windows インスタンスのデフォルトパッチベースラインとして使用されます。事前定義されたもうひとつの Windows パッチベースライン AWS-WindowsPredefinedPatchBaseline-OS-Applications を使用して、Windows Server オペレーティングシステム、およびサポートされている Microsoft アプリケーションのいずれにもパッチを適用することができます。
上記を確認し「AWS-WindowsPredefinedPatchBaseline-OS-Applications 」をパッチベースラインに変更しました。
##配信グループ管理用のタグ設定追加（Systems Manager）
配信対象のインスタンスに対して、タグを追加しました。
##メンテナンスウィンドウ用のIAMロール作成（IAM）
[AmazonSSMMaintenanceWindowRole] がアタッチされた IAM ロールを作成しました。
##メンテナンスウィンドウの登録（Systems Manager）
メンテナンスウィンドウの登録を実施します。
ここでスケジュールも登録しました。
| 例 | 詳細 |
|---|---|
| cron(0 2 ? * THU#3 *) | 毎月第 3 木曜日の午前 02:00 |
| cron(15 10 ? * * *) | 毎日午前 10:15 |
| cron(15 10 ? * MON-FRI *) | 毎週月〜金の午前 10:15 |
| cron(0 2 L * ? *) | 毎月最終日の午前 02:00 |
| cron(15 10 ? * 6L *) | 毎月の最終金曜日の午前 10:15 |
タスク設定のOperationは「Scan」を設定しました。
スキャン
Scan オプションを選択すると、[AWS-RunPatchBaseline] はインスタンスのパッチコンプライアンス状態を確認し、この情報を Patch Manager に返します。Scan では、更新のインストールや、インスタンスの再起動を求めません。代わりに、承認済み更新でインスタンスに適用可能なものが見つからない個所を示します。
インストール
Install オプションを選択すると、[AWS-RunPatchBaseline] はインスタンスに見つからない承認済み更新と適用可能な更新のインストールを試行します。Install オペレーションの一部として生成されるパッチコンプライアンス情報には、見つからない更新は示されませんが、更新のインストールが何らかの原因で失敗した場合は「失敗」状態になっている更新がレポートされることがあります。更新がインスタンスにインストールされるたびに、インスタンスが再起動され、更新がインストールされて有効になっていることが確認されます。
##処理失敗による原因調査と再実行（成功）
しかし、何度かジョブを実行させましたが、失敗します。調査すると、OS上でパッチ配信時にメモリが100%に張り付いて、メモリ不足エラーが出力されていることが確認できました。
もしかして、スペック不足、と考えて、インスタンスを停止してインスタンスタイプ変更を実施しました。
メモリは4倍増の認識です（ただ、無償枠の範囲外）。
ts.micro（CPU：1、メモリ：1G） → t2.medium（CPU：2、メモリ：4G）
再度実行したところメモリの使用率が90%になることはありましたが、処理自体は成功しました。
パッチの適用結果は「AWS Systems Manager＞マネージドインスタンス＞インスタンス＞パッチ」で確認可能です。
次は差分のパッチをインストールするため、Operationを「install」を設定して再実行しました。今度は、メモリは50～60%くらいですが、CPUは90～100%を行ったり来たりの状況になりました。ある程度時間が経過すると自動再起動が走って、インストールが完了しました。
OS上でパッチが配信出来ていることも確認できました。
最後にインスタンスタイプを元に戻しておきました。
t2.medium（CPU：2、メモリ：4G） → ts.micro（CPU：1、メモリ：1G）
できるだけ課金されない為には、無料枠に戻すのは重要です。
#■■ まとめ ■■
今回はSystemsManagerのパッチ配信設定の確認を実施しました。
SystemsManagerの設定自体は、前回のCloudWatchエージェントセットアップの際に完了していたので、今回は配信設定を実施して配信するのみです。特段難しいところはありませんでしたが、最後にジョブがエラーになるという問題が発生しました。結果的にOS側の問題と切り分けて対策できたのですが、SystemManager上での障害対策に関しては、まだ勉強不足であると感じています。
ここは、今後、切り分け方法や調査手順を整理したいです。
次回は「AWS動作検証【3】（AWS BackupによるEC2バックアップ・復元）」です。
以 上